TGB v1.1 - Possible to make networked Scorched Earth now?

#1 Real time networking AFAIK will not be coming for a while, but for something like a networked version of scorched earth do you really need it ? To my thinking wouldn't it be better for the client to handle the physic's side of it and you just pass the details to the client ? So for instance, the 1st player has his turn, selects a normal missle, angle 37 degree's power 50% and hits shoot. This gets sent to the server, checked however you want to do it, the server works out the damage caused and sends all the details back to all the clients which then render out the physic's of the animation. Then the next player has their go, etc. Is there any real need for real time networking ?

#2 Well, the problem is that the physics are not calculated the same on every person's machine. Also, if the server/player alt-tab's from the game window, the physics go crazy. If I understand correctly, the physics updates are somewhat related to cpu cycles and that's why alt-tabbing out of a game causes very bad results.

Either way, the physics don't react the same for each person, so I can't simply say "projectile.setVelocity()" (or whatever the TGB syntax is)

I'm very open to any ideas as to fixing this problem (or getting around it) though =)

#3 Match the end-point on all clients and have them all determine the impact using a static table. That way the end-point is the same and the "calculations" are the same on each client. It isn't a "physics intensive 'real' situation" but it could work very well. It worked for Artillery back in the day.

#4 Can you elaborate on this a little more? (eg. the static table)

In my game, I would like to have "blackholes" that modify the projectile's movement if it gets too close to them (which is EXTREMELY easy using built-in TGB physics, but nearly impossible [??] to synchronize). I'd also like to have anti-air turrets that can knock projectiles out of the air (or at least modify their course).

Can I have all of that and still have it synchronized across all clients?

#5 One of the tricks that was often used on older hardware was to compute complex algorithms that took CPU cycles into lookup tables and use that data for calculations. You could do something similar, but the problem is in terms of needing to know midpoints in any trajectory to alter with other projectiles and matching that among clients.

It would be nasty to synchronize timing in the tables. I was thinking in terms of calculating consistent terrain deformation. Have you looked at implementing Tom Bampton's hooks into TGE's network ghosting and tailoring it to your specific implementation?

#6 Yeah, I've look at Tom Bampton's Wiki article, but all he really provides is the code without any explanation. You need to throughly understand (at the code level) TGE's networking to have Tom's code of any use. On top of that, I'd still need to write client-side prediction algorithms for each object since TGB doesn't support any of this.

#7 As I see it, a scorched earth clone doesnt really need a lot in the way of physics. You could just write your own time based projectile code ... should be pretty simple and easy to write interp/prediction code for. Having a look at TGE's projectile code may help, you'd just ignore the 3rd dimension (note that in TGE Z is up). TGE projectiles use a raycast for detecting collision, so you'd have to find a different solution for that, but the maths should be relevant.

You can do the "cannons" all client side. Firing would simply be a matter of sending the server the relevant angles and power. The server would then spawn the projectile and tell all the clients about it. Explosions are simply client side effects when the projectile hits the ground/whatever. Thus, you don't need to worry about prediction/interp for any other objects, since projectiles are the only thing that needs it.

You don't really need to worry about scoping for this, just have everything set as ScopeAlways. In fact, I dont think you need to worry about prediction either. All you need is interpolation for the projectiles.

I think a scorched earth clone would be fairly simple, with or without TGE style networking. If you have a codebase with TGE networking in, you should only need to create one new C++ object for projectiles, and the rest is really simple client side stuff. If you wanted to be clever you can send the image maps etc over the network (there's code for that in the TDN article I think), but you can get away with just telling the client what level to load and assuming everything is correct.

Incidentally, the TDN article is deliberately light on information to raise the barrier to entry because I didnt want to get loads of emails from people who can't code asking me annoying questions. However, the actual concepts behind it are really simple. "Scoping", "interpolation" and "prediction" sound big and scary, when actually they're just fairly simple math. Well, maybe prediction is a bit more complicated, but you dont need it for this :)

T.

#8 John,

There are a set of calls to fix the frame-rate for physics calculations as well as controlling how they work during stressful situations such as alt-tabbing away from the application. Simply saying the physics doesn't work or goes crazy is just saying that your application doesn't work or goes crazy really.

Trying looking at the calls "setScenePhysicsFPSActive()", "setScenePhysicsTargetFPS()", "setScenePhysicsLimitFPS()" and "setScenePhysicsMaxIterations()".

Essentially, "setScenePhysicsFPSActive()" turns on/off the system that maintains a constant FPS simulation rate for the physics and "setScenePhysicsTargetFPS()" sets the actual frame-rate. Most rigid-body simulations won't work very well below 60fps and always the higher the better. The problem is that if you set it too high and the system you run it on can't achieve that, you won't get exactly the same result each time.

To help minimise the effect here, you can use "setScenePhysicsLimitFPS()" which states the threshold FPS at which point TGB will start to do multiple iterations of the simulation to break down the large time segment (low fps) so that the simulation continues to run smoothly. Obviously the more interations you do, the more costly it is so you can control the maximum number of iterations using "setScenePhysicsMaxIterations()".

Also, don't forget that to do rigid-body physics requires small time-segments (high fps) to do accurately. On top of this, to keep TGB running fast I chose to use a Euler integrator which isn't the most accurate but it is fast. I'd like to implement different (even swappable) integrators in the future.

Guidelines:-

- Turn Physics FPS active on
- Set a fairly high FPS target (approx 60-80 fps)
- If you're expecting very low fps then set the Limit FPS to <60fps.
- Set the max iterations experimentally on the lowest spec hardware you expect.
- Think about hooking into the alt-tab stuff to stop the simulation instead.

Even with this, the system could be made much easier and there are definate improvements to be made. The good thing is that you'll get these improvements as we progress.

Hope this helps,

- Melv.

#9 You could always take the arc and power (and any other factors like wind) and calculate the path the projectile will pass and then generate a path based on certain points (using the different type of path modes to smooth it out) on both clients and have the projectile follow that path, so each client will see the same thing :)

#10 First off, thanks everybody for the great replies! I really do appriciate it!

@Tom: I do own TGE so I could try to imeplement the TGE projectile physics, but I'm afraid that understanding that is a bit above my level of experience. Perhaps if I look over it long enough I might be able to figure it out, but I've already tried (for TGE networking) and didn't have much success. However, it sounds relatively simple to synchronize 2D objects. (eg. the server would simply object object positions according to the physics engine). I would even think that the type of object would be irrelevant... (if it moves, the server tells each client to move it...)

@Melv: Would the methods you mentioned guarantee the same exact results on every PC? It sounds like it should, but it also sounds like if a machine slows down (eg. other processes running the background) then the physics could be thrown off-course. I guess I *COULD* implement simulation pausing on alt-tab, but I would need to pause ALL clients (eg. 8 players per game I was hoping) and I don't think this is really feasible. (However, thats the least of my concerns at this point).

@Matthew: That approach would work perfectly if I didn't want to have projectile path affecting items such as blackholes and anti-air turrets. For example, if a projectile (shot from a tank) got too close to a blackhole it would be thrown off-course, etc. With these gameplay ideas it's not possible to do it the "easy" way. =)

So it sounds like my options are:

1) Dig deeper into TGE and try understanding it's projectile and networking code so I can implement ghosting, etc, into TGB. [very hard]

2) Throw out my gameplay ideas such as blackholes and anti-air guns and reduce the game to a simple "projectile follows given static path" [makes game very boring]

Please don't take any of this post as a criticism of Torque... (sometimes I think I come across sounding a bit harsh) I'm simplying trying to evaluate what is capable given my experience with programming, etc...

#11 There's not really that much to it. All you need to look at is processTick() and interpolateTick() ... it's really basic maths. processTick() gets called every tick (32ms) and sets the position, interpolateTick() gets called inbetween ticks to update the position to a point between the last tick position and the next one based on how much time has elapsed.

I really think that in this case TGB's physics are serious overkill and will just cause you more problems then they solve. As you have TGE, you can gank all the maths required directly from TGE's projectile class (which does ballistic projectiles, and that's basically what you need) and hack them to be 2D. Then you also have the major advantage of no frame rate issues.

A basic networked prototype this kind of game is doable in 6 - 12 hours. If you don't have the experience and you have to look a lot of stuff up, maybe it would take you a week or two. Still, it's really easy and most of the code you need already exists in one place or another.

My advice is stop deluding yourself into thinking that it's horrendously difficult, sit yourself down in front of the computer and follow the advice in this thread. Forget about your shiny gameplay elements for now and just do a simple scorched earth clone. You'll probably find it's nowhere near as difficult as you think it is now.

Once you have the basic prototype running, adding anti-air guns will be simple - you'll already have the code, its the same as for the cannons, possibly without ballistics. Black holes are just relatively small changes to the projectile physics and are similarly easy. In fact, once the prototype is running, everything seems a lot more doable and that's when it really starts to get fun.

Also, the TGE networking is very easy. Follow the TDN article to get the basic thing running. Then all you need to add is a NetObject for the projectile - there are other articles on TDN to figure that out. Make all your NetObjects ScopeAlways, then you dont need to worry about scoping. As I already said, you dont need prediction. Interpolation is basically just dead simple the processTick() / interpolateTick() combo I already mentioned. You don't need to worry about GameBase, just use ITickable (there's another TDN article on that) ... with ITickable, you won't want interpolateTick() running on the server, so just stick the following as the first part of the interpolateTick() method:

if(isServerObject())
   return;

T.

#12 Sorry, maybe I'm dumb, but why do you need the same trajectory on all clients?
Let the server calculate where the projectile will hit.
Send this information to all clients and let them do the rendering.


I think the actual problem might be the deformable tarrain.