A possible solution for real time networking

#1 Thats awesome, thanks Jacob, I'm going to look into this right now. Cheers mate.

#2 I never stopped using TGB because of the networking issues..but between my lack of networking knowledge and lack of information on using TGB for multiplayer games, I definitely put off some ideas.

A tutorial would be awesome, if you can get one together I'm sure a lot of others will appreciate it too. Especially if it can handle realtime multiplayer "twitch" gaming. I'll check it out tonight.

#3 Heh...glad to see you spent a bit of time giving it a go :)

I tend to come back to this a lot, but I have two perspectives on the concept of real time networking in TGB:

--speaking as an employee and member of the Tech and Tools team, we keep coming back to there simply not being enough market demand for 2D real time networking to sponsor a release with a full implementation.

--speaking as a techie familiar with the concepts of real time networking, and the TGE and TGB code bases, all of the parts are there--it just needs porting of the NetObject from TGE to TGB, then focused development on the packUpdate/unPackUpdate, and finally implementing backstepping and related capabilities in the ::processTick.

Once fixed tick physics came into play (TGB 1.5), the challenge becomes much easier to implement a solution for a specific game. It's still a much bigger challenge to implement a generic/agnostic solution for all games, which is why it's not on the table as a TGB upgrade at this time.

#4 Stephen, last time I checked NetObjects were the same between TGE to TGB, no?

#5 If not the same, very close. I should be more specific: NetObject in TGB needs to be validated for ghosting, and proper processing of a bitstream in particular.

#6 @Stephen:

Hi,

I just can't resist this thread... the lack of realtime networking in TGB has been a thorn in my side for awhile. I like TGB a lot, I've been using it on and off since EA (I think it's an awesome product, I really do), but wouldn't it have been more work to remove TGE's netcode from T2D than to have left it in?

Quote:

"--speaking as an employee and member of the Tech and Tools team, we keep coming back to there simply not being enough market demand for 2D real time networking to sponsor a release with a full implementation. "

End Quote:

I can't argue with that and I'm sure you guys know a lot better than me (I'm not much of a businessman), but I find that odd considering how connected the planet is already with games, music, movies, etc over the internet.

Quote:

"It's still a much bigger challenge to implement a generic/agnostic solution for all games, which is why it's not on the table as a TGB upgrade at this time. "

(end quote)

TGE's networking isn't a solution for all games either... I know there's a difference, but isn't a level file in TGB just essentially the equivalent to a mission file in TGE?

#7 TGE's networking requires the ability to program in C++ (for all but the basic things that are included).

For just about any TGB game, you'll be creating dynamic fields for your game objects, which of course you will then want networked. In TGE, you'd change the (c++) packUpdate/unPackUpdate to read and write these datasets from the bitstream.

In TorqueScript, they are simply strings, which are absolutely terrible when it comes to bandwidth use, so you would have to implement a mechanism to basically run-time define the bitstream (more accurately, read/write off the bit stream) to handle user configured datatypes--which don't even exist in TorqueScript in the first place.

You would then have to write an interface to allow TorqueScript to define these datatypes, and indicate how each field is best optimized for the bitstream, and finally make sure they are all working across the NetConnection that exists.

The short answer being: no, for the primary market segment that uses TGB (TorqueScript developers), stream based networking was not (and is not) trivial to do.

#8 Ah, I see what you mean now.

It seems that the fully networked 2D engine is more of a niche market, but I think the reasoning for the odd complaint here and there regarding the networking in TGB is because of two things:

1) TGE has the networking that a lot of people want, but 3D assets are difficult to produce. Especially 3D assets worth looking at (in contrast to programmer's art, lol).

2) 2D assets are more easily attainable, but the networking isn't the same as TGE.

Looks like both sides of that sword are sharp, eh?

Thanks for your input. :)

#9 You hit the nail right on the head Chris. For me, it's more reasonable to make a game in 2D because of time constraints and general nostalgia for retro style gaming. I would like to see TGB have network capability similar to TGE. Having real time networking would open up some cool opportunities for smaller games with a semi-large player base (1-64).

#10 Wow Stephen

--speaking as an employee and member of the Tech and Tools team, we keep coming back to there simply not being enough market demand for 2D real time networking to sponsor a release with a full implementation.


I did read your other posts about the issues with realtime networking and TGB but can you immaging the new door of creative opportunities realtime networking would bring for TGB developers? A part the USP on the sale page :).

Please :) reconsider :)

Jacob a tutorial would be great!

#11 I'll open this back up, as long as we can stay civil :)

Give me a game use case for the need for real time networking. I'll either describe how it can be done via event based networking, or demonstrate that it's not going to work even with real time streamed networking in the environment you're describing (or, of course, if it's a valid use case and scenario, I'll admit that it's one that suggests development time for that one game is worth performing).

#12 Super Street Fighter Hyper Turbo Deluxe Gold online.
River City Ransom MMO?

The possibilities are endless.

#13 Neither of those mean anything to me at all.

Describe what game capability you want to accomplish, and as I said, I'll detail how to accomplish it, describe how it wouldn't work with real time networking in any case, or in the cases where it is the only option, suggest directions for custom coding.

#14 I have been trying to use event based networking into my Platformer Starter Kit. I have had small amounts of sucess with it too.

What I would love to see in the TGB network structure is a method of referencing objects in a scene between clients. To some degree you can do this with objects that are created when the level is loaded, but it is quite difficult, by my understanding, to do it with objects created on the fly (through spawners etc.).

I think that TGB's network structure works really well if you are prepared to create a game with event based systems in mind. If you create a game and then think that you want to make it networkable, you are going to be in big trouble (in general).

#15 Wow Stephen you've never heard of street fighter?! How about Mortal Kombat? Or Killer Instinct? King Of Fighters?

They are "fighting games". You basically beat up on the other player in the best of 3 rounds. I'd like to know if a 2D fighting game, you can play online, would be possible with event based networking. Somehow I doubt they would be.

#16 Note: the code below is a template. Must be modified for your game, based on how you do certain things like host/join, id your clients, and what data needs to be sent to other clients to do things.

$Game::ClientID = "Server1"; // different for each client playing
$Game::NetworkedObjectID = 1;

function t2dSceneObject::onAddToScene(%this)
{
  %this.networkID = $Game::NetworkedObjectID;
  %this.clientID = $Game::clientID;
  %this.isOwnedByMe = true;
  // rest of data here that might need to be initialized/networked, just to make sure it's initialized
  $Game::NetworkedObjectID++;
  notifyAllNewObject(%this);
}

function notifyAllNewObject(%this)
{
   // code here to determine if we are the 'server' or a 'client', and act appropriately.
  // could be as simple as setting a global variable if we "host" a game, or join one.

  // here you would put in any information that's important to other clients
  // to know about. For example, in most games you probably need to let the other clients
  // know what the configDatablock is, the position of the object, initial values, etc.
  // this can take the form of a series of arguments, or one big argument in a tagged format
  // (that you make up), whatever works for you

 %extraData = "";


  if ($Game::IAmServer == true)
  {
     for (%clientIndex = 0; %clientIndex < ClientGroup.getCount(); %clientIndex++)
     {
        %notifyClient = ClientGroup.getObject(%clientIndex);
        commandToClient(%notifyClient, 'NewObjectNotification', %this.networkID, %this.clientID, %extraData);
     }
   }
   else
   {
      commandToServer('NewObjectFromClient', %this.networkID, %this.clientID, %extraData);
    }
}

function clientCmdNewObjectFromClient(%networkID, %owningClientID, %extraData)
{
   // parse %extraData to determine what type of object we need to create, what initial values to give it, etc.

   // create a new object locally, and set it's values.
   .....
   // we don't own this object, so mark it as such. This will be important when we get updates, especially
   // so we know how to interpolate, if we should have collision be authoritative or "by courtesy", and other situations
  
  %this.ownedByMe = false;
  %this.networkID = %networkID;
  %this.clientID = %owningClientID;
}

function serverCmdNewObjectNotification(%client, %networkID, %owningClientID, %extraData)
{
     for (%clientIndex = 0; %clientIndex < ClientGroup.getCount(); %clientIndex++)
     {
        %notifyClient = ClientGroup.getObject(%clientIndex);
        if (%notifyClient != %client)
        {
          commandToClient(%notifyClient, 'NewObjectNotification', %this.networkID, %this.clientID, %extraData);
        }
     }
}

Disclaimer: I just wrote all that from scratch, but I've used the technique myself in the past and it, combined with a few more network event types (such as a position/Move update net event sequence, and an interpolation mode sequence, as well as other events appropriate for your game) will accomplish a very large majority of what most people need when they think about "real time networking".

#17

Quote:
Wow Stephen you've never heard of street fighter?! How about Mortal Kombat? Or Killer Instinct? King Of Fighters?

They are "fighting games". You basically beat up on the other player in the best of 3 rounds. I'd like to know if a 2D fighting game, you can play online, would be possible with event based networking. Somehow I doubt they would be.

Torque Game Engine's networking (what you are indicating you think should be part of TGB) will not in any way work out of the box for these types of games. There is a reason games like this aren't networked by default, and it mostly has to do with latency management, and threshold issues between reaction times, "game move" speeds, and the fundamental nature of networking through the internet.

In other words, networked 2D fighting games aren't possible with real time networking either, without huge re-writes of many aspects of the simulation and networking models. I've written up a walkthrough of network sequencing vs game move duration vs latency somewhere on these forums, but I honestly have no idea where, so I'll try quickly:

It's important to note your fundamental game mechanic here first off: in most any game like this, the mechanic is:

Player A initiates a game move (fighting action, move action, whatever)
Player B can react to that game move before it's completed (in at least some cases), and initiate their own game move (block, dodge, move away, etc)

The result of the game move is based on the combined simulation state result of both moves.

Now, let's say one of your fighting moves is a quick jab, that takes all of 500 milliseconds (half a second). Another move might be a "backstep", that takes 200 milliseconds (2 tenths of a second).

--"good" network: low latency, round trip time is 300 milliseconds (roughly equivalent to a "ping" of 150 ms", which is pretty common in a non-dedicated server environment)

Player A initiates "quick jab". On Player A's machine, the jab will land 500 milliseconds later if nothing else happens.

Player B receives notification of the "quick jab" 150 milliseconds later, and begins their simulation state change. Player B has a "human lag" of 200 milliseconds (takes the player 2 tenths of a second to recognize, and react with the logical move), and then initiates "back step", which takes 200 milliseconds.

On Player B's simulation, we have:

--Quick Jab at time 0 (which is really 150 milliseconds later than Client A, but we'll get to that).
--200 millisecond human delay
--200 millsecond back step action time

total time on Client B is 400 milliseconds, and the quick jab takes 500 milliseconds, so on Client B, the quick jab is avoided.

On Player A's simulation, we have:

--Quick Jab at time 0 (when it was actually initiated)
--150 millisecond propagation time
--200 millisecond reaction time (on client B)
--initiation of back step by Client B at 350 milliseconds into the sequence
--at 500 milliseconds into the sequence, Player A is first notified that Player B attempted a back step, but the maturation time of the quick jab has just happened, so on Client A's computer, the jab lands.


This is the fundamental issue with any type of networked fighting game, regardless of the underlying network technology--the game action speeds are of the same order of magnitude as the network latency, and therefore you become desynchronized just about immediately, and are constantly playing "catch up".

Torque's networking (real time networking) will not in any way solve these problems--Determinance is one of the very few melee based games that has had any luck at all with this type of game mechanic, and I'm sure that Ian will say that state synchronization and sequencing was a pretty big issue for them.

In fact, while I personally have not fully designed or implemented a game like this (although as you can see I've spent quite a bit of time thinking about it), I would suggest that in fact some form of an event based system is mandatory if you want to be able to have any type of success.

The way that would work would be something like a re-entrant state machine where you would inject "response" events back into the FSM and rewind the initiating player's FSM (deterministically of course) based on the "response action event", and be able to successfully re-integrate the combined states into a result. This fixes the resolution of combat combinations issue (in theory at least), but doesn't even begin to address the desychronization issues that are unavoidable in any networked situation--there is no such thing as "negative ping", and receivers of events/real time update streams are always "behind the times" compared to the initiator of the events/streams.

#18 Thanks for taking the time to explain this Stephen. These are some of my favorite games and I've always wondered if it'd be possible to make one work as multiplayer. I was hoping it'd be possible, somehow, but I figured it'd be fairly tricky due to the blisteringly fast gameplay. I've been toying with a small prototype of a fighter and I know if I were to ever make a full game of it people will inevitably ask for multiplayer. I do recall playing Mortal Kombat online on a console long ago.. but I guess todays computers (or internet rather) is less reliable than my Sega Genesis over dialup. Either that or the programmers had something like you describe in place to make the gameplay appear smooth.

#19 I'm not saying it's impossible--I'm simply saying that "real time networking" as it's implemented in TGE (not TGB as we all know) isn't the solution to this particular problem set.

#20 Hi Stephen,
thanks for getting deeper into it.

I have just downloaded the latest version of TGB as finally I should have some time to spend with it.
I have no experience of network coding (well I'm not a programmer anyway) and when I was talking about 'real time networking' I was simply borrrowing these words from the posts before mine; what I really was trying to say is for a way to have multiplayer games with TGB, not just turn based games; I used the words 'real time networking' as oppose to 'turn based'.

Event Based Networking maybe is the answer for many situations? In this case, is event based networking going to be implemented in TGB? Or maybe tutorials/posts available to show the basics? Would this work for existing multiplayer game genres like Driving Games, Shooters, sport games... you did the example of Fighting Games but I did play fighting games online, on Xbox. And there are other sport games of course you can play online on any consoles, well 3D games but that shouldn' matter.

So coming from a noob point of view, in terms of creating a Muliplayer online game that is not turn based, one would wonder how to have non turn based TGB multiplier games work.

And as a noob, the same way one is aware that you can have a multiplayer FPS or driving game work on TGE you would hope, dream of having the same possibilty with TGB (real-time, event based... whatever the solution is especially hoping that TGB would come with a built in system to refine for individual cases...)

This could even be a good idea for an add on pack to sell individually if robust enough, or maybe different packs refined for individual basic game genres