Question about Tom Bampton's Real-Time Networking
by John Klimek · in Torque Game Builder · 09/13/2006 (1:02 pm) · 8 replies
I'm a TGE and TGB owner and am trying to implement real-time networking into TGB. For my purpose, I only need to have projectiles (think of Scorched Earth) be synchronized on all clients.
Here are my questions:
1) What does $missionSequence mean? TGE's mission load code seems to refer to it quite a bit but it seems to be set to 0 upon server creation and then 1 once the mission is loaded. Should I just use "1" for my TGB $missionSequence?
2) The two important mission-load script calls seem to be "%client.transmitDataBlocks($missionSequence)" and "%client.activateGhosting()". When I call transmitDataBlocks sometimes it works and I see 14 datablocks being transferred but sometimes it doesn't do anything. Any idea why this is acting this way?
3) Tom Bampton told me for my Scorched-Earth game (eg. only having synchronized projectiles, nothing else will be networked) that all I will need is one NetObject. I think I've correctly copied the core networking code from TGE and into TGB, but I'm confused on what the NetObject will be. Do I create a NetObject that inherits from t2dSceneObject? ...or do I inherit from t2dSceneDataBlock? ...or neither?
I'm pretty sure that the example "SimpleNetObject" is being ghosted to all clients so I'm on the right track, but really need some more help.
Thanks in advance for any help!
Here are my questions:
1) What does $missionSequence mean? TGE's mission load code seems to refer to it quite a bit but it seems to be set to 0 upon server creation and then 1 once the mission is loaded. Should I just use "1" for my TGB $missionSequence?
2) The two important mission-load script calls seem to be "%client.transmitDataBlocks($missionSequence)" and "%client.activateGhosting()". When I call transmitDataBlocks sometimes it works and I see 14 datablocks being transferred but sometimes it doesn't do anything. Any idea why this is acting this way?
3) Tom Bampton told me for my Scorched-Earth game (eg. only having synchronized projectiles, nothing else will be networked) that all I will need is one NetObject. I think I've correctly copied the core networking code from TGE and into TGB, but I'm confused on what the NetObject will be. Do I create a NetObject that inherits from t2dSceneObject? ...or do I inherit from t2dSceneDataBlock? ...or neither?
I'm pretty sure that the example "SimpleNetObject" is being ghosted to all clients so I'm on the right track, but really need some more help.
Thanks in advance for any help!
About the author
Recent Threads
#2
1) I don't remember. Stephen wrote up some detailed information on TGE mission loading on TDN, I forget the URL but it's probably covered there.
2) No idea.
3) Create a NetObject that manages a static sprite. Don't use TGB physics on that sprite. The NetObject should derive from both NetObject and ITickable.
Using processTick() and interpolateTick() (make sure you only run interpolateTick() on the client, and advanceTime() can be empty), implement tick based ballistic physics. The physics code can probably be ganked from TGE's Projectile class.
The server's processTick() should update the clients every tick by setting a mask bit after updating the position. The packUpdate() / unpackUpdate() deals with sending the actual position.
The NetObject then sets the sprite's position based on either the calculated or provided position. The sprite only ever exists on the client and the NetObject just has a pointer to it.
There is some other housekeeping things you'll need to do, but they are all really simple.
@Eric,
Other then updating datablocks (which you'd have to do yourself anyway), the networking code doesnt touch any TGB specific code so it should work. TGE 1.4.2 is the closest to TGB so you'd want to use that to gank from.
T.
09/13/2006 (9:32 pm)
@John,1) I don't remember. Stephen wrote up some detailed information on TGE mission loading on TDN, I forget the URL but it's probably covered there.
2) No idea.
3) Create a NetObject that manages a static sprite. Don't use TGB physics on that sprite. The NetObject should derive from both NetObject and ITickable.
Using processTick() and interpolateTick() (make sure you only run interpolateTick() on the client, and advanceTime() can be empty), implement tick based ballistic physics. The physics code can probably be ganked from TGE's Projectile class.
The server's processTick() should update the clients every tick by setting a mask bit after updating the position. The packUpdate() / unpackUpdate() deals with sending the actual position.
The NetObject then sets the sprite's position based on either the calculated or provided position. The sprite only ever exists on the client and the NetObject just has a pointer to it.
There is some other housekeeping things you'll need to do, but they are all really simple.
@Eric,
Other then updating datablocks (which you'd have to do yourself anyway), the networking code doesnt touch any TGB specific code so it should work. TGE 1.4.2 is the closest to TGB so you'd want to use that to gank from.
T.
#3
I've managed to get the "SimpleNetObject" to successfully ghost to all clients! I think I'm getting somewhere!
I think I understand what you're saying about having the NetObject managed a sprite but still a bit confused (just slightly!). If I understand correctly, I'll implement a "setStaticSprite" function on my NetObject. I'll then use so the NetObject knows which t2dStaticSprite it is managing. Then, during processTick and interpolateTick I'll move this t2dStaticSprite.
My confusion is that this NetObject is only created on the server, right? Since the server is also a client, I call setStaticSprite and now the NetObject knows which sprite it is managing. However once the NetObject is ghosted, how does it know which sprite to manage on the OTHER client?
Also, do I really need to call transmitDataBlocks in my script? What is it even doing? (if anything?)
Thanks Tom! I think with just a little more help I'll really have this thing working.
09/14/2006 (8:41 pm)
Thanks for the replies!I've managed to get the "SimpleNetObject" to successfully ghost to all clients! I think I'm getting somewhere!
I think I understand what you're saying about having the NetObject managed a sprite but still a bit confused (just slightly!). If I understand correctly, I'll implement a "setStaticSprite" function on my NetObject. I'll then use so the NetObject knows which t2dStaticSprite it is managing. Then, during processTick and interpolateTick I'll move this t2dStaticSprite.
My confusion is that this NetObject is only created on the server, right? Since the server is also a client, I call setStaticSprite and now the NetObject knows which sprite it is managing. However once the NetObject is ghosted, how does it know which sprite to manage on the OTHER client?
Also, do I really need to call transmitDataBlocks in my script? What is it even doing? (if anything?)
Thanks Tom! I think with just a little more help I'll really have this thing working.
#4
Yes, this means that you actually have two copies of all your objects, and it's just one of the reasons why we didn't go this route with TGB's networking.
What you ultimately want to do is to put NetObject in between your SimObject and SceneObject in the class hierarchy, thereby all of your 2d objects have ghosting (networking) ability.
You'll then have to duplicate the concept of processTick(), all of the state masks for marking states as dirty and needing to be networked, and quite a bit more.
transmitDataBlocks() is important because you need to send your datablocks to any remote clients (to make sure they are in sync).
Once an object is ghosted to a client, the ghosting system will have the object instantiated on the client, and the NetConnection (GameConnection) takes care of updating that object based on server state via the ghosting system (packUpdate/unPackUpdate).
I apologize in advance for those users that don't own TGE, and therefore cannot see the information in this link, but here is the writeup I teach networking in TGE from during the Torque Tech Boot Camps: Torque Networking
09/15/2006 (12:03 am)
It's a bit more complicated than that John, mostly due to the fact that when you have a networked environment (even when a single executable is running, it's still "networked"), you actually have TWO simulations--the server, and the client.Yes, this means that you actually have two copies of all your objects, and it's just one of the reasons why we didn't go this route with TGB's networking.
What you ultimately want to do is to put NetObject in between your SimObject and SceneObject in the class hierarchy, thereby all of your 2d objects have ghosting (networking) ability.
You'll then have to duplicate the concept of processTick(), all of the state masks for marking states as dirty and needing to be networked, and quite a bit more.
transmitDataBlocks() is important because you need to send your datablocks to any remote clients (to make sure they are in sync).
Once an object is ghosted to a client, the ghosting system will have the object instantiated on the client, and the NetConnection (GameConnection) takes care of updating that object based on server state via the ghosting system (packUpdate/unPackUpdate).
I apologize in advance for those users that don't own TGE, and therefore cannot see the information in this link, but here is the writeup I teach networking in TGE from during the Torque Tech Boot Camps: Torque Networking
#5
I understand what you're saying about the two copies of all objects and that there are two simulations running (the client and the server).
However it seems like what you're saying contradicts what Tom is saying. From what Tom is saying it sounds like all I need to do is have one NetObject that manages (eg. changes the position of) a t2dStaticSprite (eg. my projectile).
Also, for my game I don't think I have any datablocks to really transmit because the only thing I'm ghosting is projectile data (I could be definitely wrong on this.....)
If I need to change the entire networking structure of TGB as opposed to just doing a slight modification this project will be impossible :(
...and I really want to create a multiplayer Scorched Earth... =(
09/15/2006 (5:51 am)
Thanks for the reply Stephen.I understand what you're saying about the two copies of all objects and that there are two simulations running (the client and the server).
However it seems like what you're saying contradicts what Tom is saying. From what Tom is saying it sounds like all I need to do is have one NetObject that manages (eg. changes the position of) a t2dStaticSprite (eg. my projectile).
Also, for my game I don't think I have any datablocks to really transmit because the only thing I'm ghosting is projectile data (I could be definitely wrong on this.....)
If I need to change the entire networking structure of TGB as opposed to just doing a slight modification this project will be impossible :(
...and I really want to create a multiplayer Scorched Earth... =(
#6
Tom's pretty good about tricking the system to do unusual things, so I have no idea what he has in mind :)
09/15/2006 (7:17 am)
I was giving out information in the general sense, not for the specific implementation you may have discussed with John, so I described how TGE networking is -usually- set up.Tom's pretty good about tricking the system to do unusual things, so I have no idea what he has in mind :)
#7
Read the link that Stephen posted, that looks like it will fill in some of the gaps.
As for the contradiction ... yeh, what Stephen was saying about all objects having networking is not really what you need. The processTick() stuff you don't have to worry about either, you can get that by deriving from ITickable in addition to NetObject (there is a TDN article on ITickable) and using isClientObject() and isServerObject() to early out of the relevant functions to achieve the same effect as the GameBase provided tick processing.
As for datablocks, it would probably be better if you setup the datablocks you're actually using to transmit over the network. But you probably don't really need to, you just need to make sure they exist on both the server and the client.
One last piece of advice: As soon as you have the networking "running" ... you need to test on two seperate machines. The earlier you can test that way the better, but of course it only makes sense once the game somewhat works. If you don't do that, then you're going to end up with lots of issues that work for the host but nobody else ;) If you don't have the hardware to test that way, set up a dedicated server and run that and the game on one machine.
@Stephen,
I was basically thinking that rather then network umpteen things he can just make the one NetObject that manages the sprite. Tick based ballistic physics can be ganked from Projectile, ITickable for the obvious bit, and the NetObject just updates the sprite's position on the client. I did something similar ages ago and it works quite well. It's the difference between getting networking for a game like John's running in a few hours and a few weeks since you don't have to go hacking up a ton of T2D code to get it working, plus not using T2D physics means there's no frame rate issues.
T.
09/15/2006 (9:51 am)
@John,Read the link that Stephen posted, that looks like it will fill in some of the gaps.
As for the contradiction ... yeh, what Stephen was saying about all objects having networking is not really what you need. The processTick() stuff you don't have to worry about either, you can get that by deriving from ITickable in addition to NetObject (there is a TDN article on ITickable) and using isClientObject() and isServerObject() to early out of the relevant functions to achieve the same effect as the GameBase provided tick processing.
As for datablocks, it would probably be better if you setup the datablocks you're actually using to transmit over the network. But you probably don't really need to, you just need to make sure they exist on both the server and the client.
One last piece of advice: As soon as you have the networking "running" ... you need to test on two seperate machines. The earlier you can test that way the better, but of course it only makes sense once the game somewhat works. If you don't do that, then you're going to end up with lots of issues that work for the host but nobody else ;) If you don't have the hardware to test that way, set up a dedicated server and run that and the game on one machine.
@Stephen,
I was basically thinking that rather then network umpteen things he can just make the one NetObject that manages the sprite. Tick based ballistic physics can be ganked from Projectile, ITickable for the obvious bit, and the NetObject just updates the sprite's position on the client. I did something similar ages ago and it works quite well. It's the difference between getting networking for a game like John's running in a few hours and a few weeks since you don't have to go hacking up a ton of T2D code to get it working, plus not using T2D physics means there's no frame rate issues.
T.
#8
I'm trying to get this networking stuff working right now but don't really understand all parts of it...
For example a simple platformer game or Tankbuster with multiplayer and so on... Just so one could see all parts that needs to be edited for all types of stuff
Or maybe relatime-networking could end up in TGB soon? ;)
10/10/2006 (4:00 am)
Is there any possibility that an small tutorial or even game that stem from this could end up on TDN?I'm trying to get this networking stuff working right now but don't really understand all parts of it...
For example a simple platformer game or Tankbuster with multiplayer and so on... Just so one could see all parts that needs to be edited for all types of stuff
Or maybe relatime-networking could end up in TGB soon? ;)
Torque Owner Eric Schuld