Basic idea of client prediction? (re: TGB real-time networking)

#1 Hi John,

Awesome. The Torque networking overview might also be helpful here.

Another thing I'd suggest before going full-bore on this: if you are primarily interested in getting things done for your games (as opposed to doing technology development for the challenge and fun of it), consider using the existing TGB network interface (CommandToClient and CommandToServer) to achieve what you're looking for. We call this layer "turn-based networking" or "TorqueNet Lite"... and that is because we generally try to underpromise and over deliver. But you can use the existing network functionality to do more than just turn-based games.

It depends on your game design, but you may well be able to at least start out using the existing interface and try to pass along player moves to the server using CommandToServer and send updates around via CommandToClient. You could add client-side prediction to your game this way as well, if needed. See if it does enough for your game. :) This will take a little slick design and implementation work, but nothing on the level of implementing TGE-style networked object state transmission and updating. And if your goal is to make games, it's always best to get rough tech up and running quickly so that you can start as soon as possible on prototyping and testing your gameplay. Indeed, the existing network functionality may serve you well through full release.

If you really do need TGE-style network state updating even to prototype (which, honestly, will not be the case in most any situation I can imagine), then yes, you can start with the TGB network upgrade tutorial on TDN, and go from there. To fill in the gaps, you should check out how TGE itself does server updating and client side interpolation and prediction of object state, and read the docs linked to previously to help understand the overall context. This doc may also be helfpul: www.garagegames.com/docs/tge/general/ch06s11.php.

Note as well that you may not have to worry about ghosting and scoping for your game... don't do more work than you have to (unless you are just interested in doing the technology development in and of itself... in which case, have a blast and please let us know how it goes!)

#2 Thanks for the reply!

The commandToServer and commandToClient might work out OK for me, but I'm still unsure about two aspects of creating a multiplayer TGB game:

1) Keep objects in-sync
2) Client prediction (eg. keeping objects moving until it receives an update from the server)

For example, let's say I want a very simple game where several players can walk around in a square room. Let's assume this room is pixel-based and not tiled-based. Let's also say that players can bump into each other but not pass through each other.

How would I go about keeping everything in-sync? I would think I would need to implement something like this:

1) Client presses to move his character forward.
2) Client procedes to move forward...
3) Client sends command to server...
4) Server either validates move or tells the client to move his character to a different location

I've been doing some reading and I realize the main problem of keeping everything in-sync is the time. By the time a player sends a move request to the server and receives the move validation, the time is already much later than when the move was originally requested. How do I fix this?

As you can tell I'm fairly confused about all of this but *desperately* want to learn how to do this kind of thing with TGB.

Any help would be GREATLY appriciated.

#3 Any further details on this? :(

#4 You could try looking at how other open source games implement networking. For example, netrek is an open source game that has server-side networking (that's not a technical term, just what I call it). In netrek, if a player tries to move in a certain direction, the server gives the 'go ahead' to move to that direction. This isn't good for players with bad connections, but if you have a good connection it's really good because you'll see no lag spikes.

A game which implemented it the other way around, which is more client-based, is subspace. However I don't know if there's any docs on how they did the networking.

But there are many open source games in development that use networking, for example, star control: timewarp.

#5 The usual way was to just send the player inputs to the server and let the server tell the client what to do (for authoritive stuff anyway).

Client prediction is basically where the client sends off the inputs to the server and in the meantime
tries to predict where everything will be at the next n timesteps based on current knowledge.

Once the server sends an update back to the client the client then checks to see how much
error there was and if so interpolates between the predicted values and the authoritive data
from the server. This prevents objects jumping around as they are corrected.

Hope that helps a bit...

~neo

#6 Well, if you're making a Clue-like, why would you need networking as "accurate" as say a fast-action multiplayer shooter? Or did your project change considerably? Maybe I just don't understand your project and it is closer to Sweet Home than Clue in a mansion sense.