next »

[nikki]

Hiya,

I am new to building multiplayer games, I've followed the socket.io tutorial and now I have a chat program which is hardly relevant...

The game I want to make is a parallel turnbased tactical shooting game (with a planning phase and a execution phase).
It wil be playable by something like 8 humans at once, also AI opponents should be possible and many (100) civilians.
You as player control a group (maximum 20-ish) of agents

I've put a bit of thinking into it and I think I have a plan for  the planning stage:
while in the planning phase you create a stack per agent of actions it would try to do in the execution phase, at the end of the planning phase all that data is sent to the server.
The server generates actions for the civilians and AI opponents.

What I don't really know is how to handle the execution phase, my naive idea would be to -after the planning phase- first let the server play out the whole execution step in memory, and then to send back some kind of animation description to all clients.

However when the game would run at 60fps and there would be 100+ agents and a execution phase of 3 seconds I think this is not doable. (60 * 3 * 100) = 18000 steps, if those would contain a bit of data I quickly get at tens of megabytes of data that need to be send to each client. at each phase beginning.

At all you guys who have experience in these things, what would be a good way to tackle this?

[Layl]

I would advise running the execution phase on the server and record actions taken by units. Actions such as Move, Shoot, Reload, Idle, DamageHealth (in case the unit gets damaged, you can't entirely make sure the simulation on the client will be exactly the same). Along with the actions you record timestamps (relative to start of the execution phase) and where appropriate duration.

After your server is done executing the simulation, it sends over the recording to the clients, which can then replay it.

[nikki]

Ah yes, that makes a lot of sense, timestamps and durations instead of frame per frame data, thanks!

[Milkybar]

When the server has received all player actions and generated all the actions for the NPC's could you not just send all the planned actions to each client and have them all play out the scenario. As long as you code the game in a deterministic way all players should end up with the same result.

You could send a copy of the ending frame for that turn to all players just to make sure everyone is in sync.

[Layl]

I would argue though that it's very difficult to make a game entirely deterministic. There's bound to be something somewhere not entirely being in sync.

[Milkybar]

I would argue though that it's very difficult to make a game entirely deterministic. There's bound to be something somewhere not entirely being in sync.

I dunno, it depends a lot more on what type of game you are trying to make. Civilisation 5 is a pretty huge and complex game but it has a very well defined order of operations that happen within a turn. Or Frozen synapse has a huge number of possible outcomes but is entirely determined by both teams relatively small plans (move here to xy -> look at xy -> crouch -> ect...). A lot of stuff like animation and particles don't need to stay perfectly in sync, as long as the core game pieces stay in order.

I think the man factor of if this is possible depends on if your game logic is either A) independent of the the passage wall clock time e.g. civ 5. Or B) you are willing to run it at a fixed update delta time e.g. frozen synapse.

[nikki]

the kind of game I am going for is very similar to frozen synapse actually , does that make either method better or worse in your two opinion?

I am inclined to try out Layl's way first, I was wondering: assume my execution step lasts for 3 seconds, what would be a sensible way of running that on the server, just letting all clients wait 3 seconds is offcourse the easiest, but how would you do to improve that? I assume the timestep could be alot higher on a server (without the need to render) but what would be a sensible speed for such a thing?

[jscottmiller]

The determinism should not be hard to achieve provided that you do not tie your logic to a timescale based on either server or client timestamps pulled from the local clock. Instead, events should follow an abstract notion of time (say, 60 units or ticks per second). When it comes time for the client to replay these events (within some kind of render loop), it can determine the correct event to play based on its local start time. If the client falls behind, it should be able to interpolate to determine the correct animation / sound / whatever to play.

You'll want to make sure that these events are sent using some kind of reliable channel - that is, all clients are guaranteed to get all of the events in the same order. If you are using socket.io (which I think only uses TCP-backed channels) and are waiting for the server to generate the full event list first, you should be OK.

As for the 3 second delay - there is no reason that the simulation on the server needs to take place in real time. Once all the client inputs are finalized, the server can run the simulation as fast as it can, queuing up the events. Most game engines give you a way to advance simulation time.

In the planning phase, are players able to see the plans being created by other players? That seems like a tricky bit to keep synchronized. You might want to look inter Operational Transforms for managing that state http://en.wikipedia.org/wiki/Operational_transformation.

[ThemsAllTook]

I would argue though that it's very difficult to make a game entirely deterministic. There's bound to be something somewhere not entirely being in sync.

I've done it. It takes a little bit of work, but isn't as hard as it might seem at first. Fixed timestep takes care of most of it, and after that, it's just a matter of making sure any random numbers used in gameplay are seeded consistently. The biggest issue is that floating point calculations sometimes happen differently on different computers, so if you need cross-platform determinism (as in, the game plays identically on all platforms for a given input sequence), you have to use fixed point numbers for all fractional calculations. Again, sounds daunting, but actually isn't so bad once you do it. Something like libfixmath gives you math.h functions in fixed point form.

[Siilk]

The determinism should not be hard to achieve provided that you do not tie your logic to a timescale based on either server or client timestamps pulled from the local clock.

If every client will calculate the outcome of actions completely on their own, problems might arise with rng-based actions, like hitting/missing a target for example. So at the very least, outcomes of such actions should be predetermined server-side.

[jscottmiller]

So at the very least, outcomes of such actions should be predetermined server-side.

Definitely. I should have mentioned that I was assuming that the action structure proposed by layl would be used. 

Actions such as Move, Shoot, Reload, Idle, DamageHealth

All actions would represent deterministic outcomes.

[Netsu]

The determinism should not be hard to achieve provided that you do not tie your logic to a timescale based on either server or client timestamps pulled from the local clock.

If every client will calculate the outcome of actions completely on their own, problems might arise with rng-based actions, like hitting/missing a target for example. So at the very least, outcomes of such actions should be predetermined server-side.

Or, if the rng computation order is guaranteed to be the same for all clients, you could sync the rng.

If there's any risk of a client diverging from the 'official' outcome computed on the server you do a prediction-correction model where the client predicts the outcomes as best as he can and, if what the server sends him differs, he corrects himself.
Dunno how important that would be in a turn-based game though, where super quick response times aren't of the essence and you could easily just send action requests to the server and wait for the server to send back action descriptions to all clients.