Hello, guys.

I'm now working on a Flash multiplayer platformer game (2D hero arena). I'm quite new in the world of multiplayer games and really confused thinking of what approach to use to synchronize all clients. For the server I decided to use Smartfoxserver2x. I've read some articles on the internet and one of the approaches they suggest is to run the same game simulation on the server and to synchronize all clients with it. In this case clients would just send input events to the server and get back the updated position, etc. But the problem of this approach is that I would have to write all the game mechanics including it's physics (I'm using ActionScript 3 Nape physics engine for my game on the client side) on the server (on Java) and it's very complicated. And unfortunately, there is no Nape version for Java.

To understand better what I want to make, you can see this example http://92.243.68.118:8080/game/Platformer.html (AWD to move hero and mouse click to attack). At the end it's supposed to be multiplayer with minimum lag.

Currently players just send keyboard and mouse messages to each other via server and there is no synchronization at all. So players might see completely different things.

What approach can you suggest for such game?

p.s.

Few other things to mention..

1. In the final game users will be able to create gaming rooms (16 players max) that can be joined and left by other players at any time.

2. The game is in Flash so only TCP connection is available (no UDP)

I'm not an expert and others might be able to help you more, but if you're using Flash and you use the Adobe Media Server, you can set up a multicast where the server makes the introductions between the clients, and then they communicate directly with each other. The interesting part that I have read about this is that the multicast aspect of this actually uses udp. The protocol is rtmfp using udp underneath the surface. So while rtmp is striclt tcp, rtmfp seems a little different. So it might not be entirely correct to think that since you are using Flash, udp cannot be used.

I'm not an expert and others might be able to help you more, but if you're using Flash and you use the Adobe Media Server, you can set up a multicast where the server makes the introductions between the clients, and then they communicate directly with each other. The interesting part that I have read about this is that the multicast aspect of this actually uses udp. The protocol is rtmfp using udp underneath the surface. So while rtmp is striclt tcp, rtmfp seems a little different. So it might not be entirely correct to think that since you are using Flash, udp cannot be used.

Thanks for your answer. But I'm not using Adobe Media Server. As I've written, I'm using SmartFoxServer2x. In this kind of set up UDP is not available. It would be if I was using AIR. But the game will be in browser so I'm limited to using TCP.

I'm not really asking about the actual implementation using Flash. I'm asking how it is normally done. The only limitation is that I can't use UDP. So don't think too much of what technologies I'm using. Just think of possible ways to organize such game so that the clients would be synchronized and latency and server load would be minimized.

Btw, if anyone knows the game Teeworlds game, I think the concept should be approximately the same. It's a multiplayer real-time platformer/shooter which is very responsive in terms of lag. The question is how did they make it?

First: With the choice of technology you've made, the networking part of the game will not be perfect.

Second: You're probably best off to send key pesses and commands relatively frequently (20 times a second?) and then send a "state checkpoint" with what the state of the character is more seldom (say, once a second?) That will correct any discrepancies over time. Echo these updates from each player to all other players by sending one packet per player every network tick from the server, containing the collected input data from all other players.

Finally: With the model that you've chosen, you have to accept that users will be able to cheat, and that there will be some artifact where "I shot you first" won't be 100% consistent. You probably want to implement this as the client detecting the event, and sending a request to the server, and the server letting whoever gets the request in first be the "winner."

First: With the choice of technology you've made, the networking part of the game will not be perfect.

Second: You're probably best off to send key pesses and commands relatively frequently (20 times a second?) and then send a "state checkpoint" with what the state of the character is more seldom (say, once a second?) That will correct any discrepancies over time. Echo these updates from each player to all other players by sending one packet per player every network tick from the server, containing the collected input data from all other players.

Finally: With the model that you've chosen, you have to accept that users will be able to cheat, and that there will be some artifact where "I shot you first" won't be 100% consistent. You probably want to implement this as the client detecting the event, and sending a request to the server, and the server letting whoever gets the request in first be the "winner."

That doesn't sound so good. And what about games where one of the players act as a host? Like Warcraft 3, for example. There a host is basically a server. How is it made in such games?

p.s.

I haven't chosen the model really yet. The key thing is that I'm using Flash as one of the technologies.

That doesn't sound so good. And what about games where one of the players act as a host? Like Warcraft 3, for example. There a host is basically a server. How is it made in such games?

Typically, the host/server runs exactly the same simulation as all clients, and decides what happens.

For deterministic simulation, like Warcraft and other RTS games, it is often the case that the clients just send the inputs/commands for each step, and the server actually simulates them, and the clients don't make the commands take effect until the server has returned all commands for that time step.

If you're making a platform action game, then that model may introduce too much latency for you, and you might be better off looking at things like the "Source Networking" guide (FPS games like Counter-Strike use this.)

Accidentally I just wrote an article on basic structures for multiplayer games. Hope this helps you understanding the core principles of various approaches to multiplayer.

http://joostdevblog.blogspot.nl/2014/09/core-network-structures-for-games.html

Also, whatever you do, avoid TCP. TCP is not suitable for a fast real-time game like a platformer. If one packet gets lost all packets after it are delayed until that one packet is resent, adding needless amounts of lag. The only reason to use TCP is that you are new to the topic and TCP is easier to use, so it might be a good stepping stone before jumping on the more complex UDP.