A possible solution for real time networking

#21 Stephen, what about Real-Time Strategy games, such as for example: Warcraft, or Dawn of War. Where you have multiple players on a single map trying to collect available resources (which diminish), build troops (within limits), Complete objectives (ex: hold a certain point on the map, find an item on the map, etc). Build additonal structures, explore the map, etc..

This part seems doable (mostly), but where I could see the difficultly is in the army vs army fights when you have both players trying to kill one another. Of course, this would involve certain tactics, weapons, advantages/disadvantes of terrain areas, etc.. This would include possible melee actions, as well as ranged actions for damage aspects.

Maybe I'm not absolutely clear about Event Based Networking, but it seems it wouldn't handle that information. But I could be wrong. I'd just like to know if this was even possible or not.

Thanks for your time. I'd also really like to hear more about what types of Event Based Networking are possible, and what conditions would fall under that category. This would greatly help determine what type of netowrking options are available within TGB.

Also, can TGE handle Real-Time, and if so, how are the dynamic fields accessed differently there as opposed to TGB?

#22 In reverse order:

--TGE does real time networking, but does not network dynamic fields. The primary development paradigm for TGE is if you have data that needs to be networked, you do it in c++ (make them persistent fields instead of dynamic ones).

--People are confusing information sent in events vs ghost streams, and use of those two systems. The data (can be) the same, it's the nature of the relationship between an authoritative server, replicated clients, and how networking interacts with physics, finally combined with the concepts of scoping and backstepping that mark the difference between event based and streaming networking.

You can easily duplicate the information that is commonly sent by a real time streamed network interface with events, it's all of the other things that aren't available in stock TGB.

--RTS games don't commonly use a server/client architecture, but instead use a combination of a deterministic game state, and peer to peer networking of input events. Commonly, RTS network architectures never send information about objects themselves at all--instead, they send information about what the player does within the interface (select unit x, click on location y, click on button z, etc), and then each of the other player's simulations are responsible for deterministically replicating game state based on those inputs, and the timestamps within the networked information determine how to apply the inputs on the local simulation.

Neither TGB nor TGE/TGE-A use this type of model--even the RTS add on kit uses a server/client model. There are forays in the more modern networked RTS games to move away from P2P and on to a server/client model, mostly to solve issues regarding cheating (map hacking, "infinite visibilty" hacks, and other related cheats), as well as some reliability and re-synchronization concerns that are more easily solved with a client/server model, but most of the well known RTS games use P2P networking pretty exclusively.

#23 Stephen, thanks for the information. I really appreciate it. Though I'm still a bit in the dark on what exactly could be done with Event Based Networking, I'll have to look it up (unless you might have some additonal input on that subject). I haven't gotten the RTS kit, so I'm not completely sure of what methodology is being used on that, but from what you're saying it's using a client-server aspect, and not a P2P. I'm just curious as to whether that content pack allows for RTS style of play, and if so, can it be stripped from TGE to function in TGB with source code? I have both TGB and TGE, and am familiar with C++ code, as well as networking functionality. Granted, my experience is limited, and the greatest dilemma about Networking (at least in my common knowledge) is Replication (or what you might consider ghosting). I dealt with that issue with UT2004, and managed to create a game type that actually worked (wasn't much fun.. but that's another story). I'm just curious as to if the structure is similiar to say.. winsock. I'm quite familiar with that protocol, and from I have seen thus far, it's more or less the same structure.
I would really like to be able to get a RTS style game created with TGB, simply because it'd be far easier for me to work with as far as setup is concerned. That's why I asked about the RTS set (I know it's for TGE, but if I could access the code, then I think I could implement it into a TGB setting). It'd take time, and someone far more knowledgable in C++ might be better at it, but it's an interest of mine to undertake.

I haven't really worked much with Real-Time networking code (with the exception of Unreal), so I'm not exactly familiar with how packets are sent over, and what kind of data is allowed, and the time rate stuff, so I'd have to look into that some more. I am pretty familiar with Turn-Based network code, and it seems that is pretty much what is currently in place and functioning (as can be seen with the Checkers demo). I'm just wondering how Event-Based Networking differs (or expands upon) that architecture.

Another idea that I'm curious about is say like a racing type of game with multiple players, I'm assuming the same type of problems occur with the rest of the Real-Time interaction as with what has been mentioned thus far, though granted, maybe not quite as bad (unless you have actions like Mario-Kart or something, where you can actually damage the other player), but even this might be still doable.

I'm going to look deeper into what is currently in place, I do have a game that works on Winsock, that I'm going to try and get working on a TGB interface, and see how that goes. But, I also want to look into Event-Based networking, and see how much more needs to be implemented in.

I know it's been asked before, but I'm sure there's quite a bit of Network architecture from TGE that would need to be carried over, I'm just wondering if there's good documention of the TGE network code here. I've seen some, but nothing really detailing it all out. Any and all info that could be shared with this topic would be greatly appreciated by not only myself, but I'm sure many other community members as well.

Thanks.

#24 There is some pretty strong theory level documentation about networking in the TDN Torque Networking article. It has some empty links (feel free to fill pages in as you do your research), but is a great place to start.

Note that the overview page covers both event networking and streaming networking (otherwise known as "ghosting"), so it mixes the two together. Only the event based concepts are appropriate for stock TGB.

There still seems to be a very big misunderstanding about what event based network strategies can and cannot do, and partly that is due to marketing terms used in describing the capabilities out of the box with TGB.

I'm pretty familiar with both TGE and TGB networking, as well as the general concepts of multi-player game design (I wrote the original article above, as well as teach networking in our boot camps), and off the top of my head I cannot come up with a single thing that the Torque ghosting system (real time/streaming networking) does that cannot be emulated with events. The primary difference when it comes down to it is performance and ease of use, since the ghosting system available in TGE is designed and implemented specifically for the tasks it needs to accomplish, while events are more generic in nature--so you would have to mimic much of the functionality that TGE's ghosting system provides.

Multi-player game design/theory really is pretty complicated when you get down to the nuts and bolts which is why I think so many people haven't even thought of simply doing what they need to with TGB's networking for multi-player games, but it's pretty easy to set up a quick prototype to demonstrate principles.

Try this as a reader exercise (I'm not going to drop out the entire solution here in one go, but I'll keep an eye on the thread to see if you get stuck in any major places):

Using any of the demos/tutorials (asteroids would be relatively easy, but you could do it with the fish tutorial even), have a "server" game, and a "client" game, and have the server send out all data about all objects to the "client". All the client is going to do is to mimic exactly what the server is doing--no input, or anything crazy (this is a first attempt prototype after all).

Some events that you will need to design and implement:

--newObject--what class to create on the client, what data it needs to do so (position, datablock possibly, etc)
--moveObjectTo -- where to move the object to
--positionUpdate -- just a "ping" event to send to the client to make sure that the client's version of the object is in relatively the correct place. WARNING: the client's objects will never be in the exact place--never forget that by the very definition of a networked game, your states are guaranteed to be desynchronized between client and server (if of course the simulation is dynamic...a pure static simulation with nothing moving, the client will eventually become synchronized).
--destroyObject -- remove an object from the simulation.

Some things you'll need to think about:

--the "server" should be fully authoritative on all of it's objects. In other words, if the server says you should move to a spot, then you should move to that spot. Eventually you'll want to implement collision, interpolation, and other concepts on the client, but leave that for a later iteration.

--you could use setPosition on the client and send data every single onUpdate(), but that is not very network efficient. It's probably better to send a set of world coordinates that your object is moving to, and have the client use moveTo to get there.

--you'll need an algorithm on the client side to determine if your current location of an object is so greatly different from the server's that you must warp...be careful with this, you don't want to confuse positions you are moving to with positions that you should be at.

Along the way think about the advantages, disadvantages, and issues regarding allowing the client to use collision/collision response, and how you might approach that in later iterations.

#25 Stephen,

I've considered writing a tutorial on this for TDN, but I'm not really sure if it will be any use. I've designed it based on the Asteriods tutorial and have gone through everything you've described above but wanted to get a bit more in-depth with using the NetObject code with ghosting. It wouldn't be generalistic in any way but maybe it will quiet this issue?

Here was the sample I wrote up a few weeks ago before I ran out of time:

Part 1
Tutorial Aspects: Create a project, create a blank level, and create a simple menu
This part goes over creation of a new project and blank level and simple menu to handle creation of a new game, resume a game or quit.

Part 2
Tutorial Aspects: C++
In this section we will dive into the dreaded C++ code and build our own object that will be our player. With this new class we will build in our networking functionality!

Part 3
Tutorial Aspects: Scripting!
Time to get to some scriptin'. We will build our player creation function and add in our simple stolen behavior.

Part 4
Tutorial Aspects: More Scripting!
This part goes over the build of client / server communications. We will build our connection and object loading features. After this part you will be able to have two or more connections and see ships flying around your screen(s). Exciting! (Due note they should be choppy and horrible at this point)

Part 5
Tutorial Aspects: Interpolation and Extrapolation in C++!
Fix up the communications by adding interpolation and extrapolation on the movement of our ships. We will open up the C++ object we created earlier to add in the desired functionality.

Part 6
Tutorial Aspects: C++, Scripting and TGB Editor
In this part we will start adding extra bits to the whole process, collision detection and a tile map with a "planet". Heck while we're at it lets add the ability to shoot other ships and detect too!

Part 7
Tutorial Aspects: C++, Scripting
In this section we will add physics to our "game", making the "planet" on our tile map have a gravity effect on the ships.

Part 8
Tutorial Aspects: Scripting
The final part to our series is just to add some fun to the whole process. We'll add health / damage to our ships, add damage to the shots and collision with the planet. After that how about a simple score system to tie it all together?

#26 Why do you doubt about it being of no use?

I would surely learn from it.

#27 Not necessarily no use, but there are possible limitations. Here are the notes I wrote up for the tutorial:

We are not using Torque datablocks in the way they were designed for TGE. TGB has broken them for transfer and started to use some not as datablocks but as regular objects. In order to keep things simple for the tutorial I have decided to not implement the changes to get them back in working order.

Dynamic fields are not accessible over the network so be careful with their usage. They are fine in places where the server is the only part of the model that cares about the value. If however you want the clients to see it that is beyond the scope of this tutorial.

This is not built with optimization in mind, just functionality.

#28 I'm also not certain on a few aspects such as behaviors since I haven't delved too deeply into them yet. It is not generalistic enough for any type of game but it should be enough to allow TGE's ghosting to be used.

Though is it far superior to the event model? Stephen would be the one to answer that question.

#29 Hi, has anybody implemented the realtime networking to TGB as is in TGE? I will pay a lot of money for the implementation. I can read, how to create it, but I have never heard, that anybody finished it :(

#30 Jacob, I would be very interested in your implementation of Raknet into TGB. If you are still there, please answer me.

#31 Had a lot of positive experiences with raknet at work... so I'd also be interested in even a light weight integration into TGB.