Hi I am currently in the early stages of developing a 2D mobile game in C++ using cocos2d-x and box2d to handle the physics simulation. It is meant to run on multiple platforms and eventually I am planning on adding a mobile cross-platform multiplayer aspect which I would like to also be able to run over the mobile network. Looking ahead I understand that due to float handling and device architecture differences I would get differences in the physics simulation between devices. The gameplay is turn-based ( 1v1 )and asynchronous( players should be able to take their turn at any point in time regardless of how long ago their opponent moved ).
Each turn has two phases in which
first: the player will first move all of his characters and
next: be able to attack( phase where the physics simulation will take place ).
Ideally I would be able to replay the events which occur in one simulation onto the other device.
What is the best way to set up networking architecture in order to maintain the same physics simulation ( or results ) on both devices?
Should I run the simulation on one device and then send the resulting information to the other? Or should I set up a server which could handle user input, simulate the physics and then send that to both devices?
From what I understand about synching physics in games is usually people fix the TimeStep and GameTicks across devices however this is more for realtime synchronization correct? Would this be useful for my project since the physics does not have to occur simultaneously ( just needs the same output )? Are there better techniques I should look into?
I am new to networking so any information one any viable techniques could be useful although I have done some research on the subject. I would also consider writing my own physics to bypass issues with network integration.
Server architecture for physics in a turn based game networking
You'll want to use a server-client architecture. The server will be the arbitrator which runs the game world and sends all the connected clients messages to update their game world state. Since its a turn based game, you can send a list of actions sent to the server and the results of those actions. So, the server would run the physics simulation and send the results to the connected clients.
With this architecture, you can support most hardware platforms since you're not relying on the clients to calculate the results of a physics step (and in terms of security, this is a best practice since a client could modify the results before sending them back to the server).
If there is a time span of several days between turns, it doesn't make sense to keep the game state in memory while a game is in progress. Especially if the game is never completed by the players. So, you'll probably want to have some sort of backend database to store the state of all the ongoing game sessions after a certain timeout period has been reached. If you're supporting cell phones, theres a good chance that the signal gets lost so you'll have to have some way to resume a game from its last state. All of this suggests that you'll also want to be able to identify returning players so that you can see if they have games in progress, so some sort of indentification scheme might have to be created (logins? unique id's?)
With this architecture, you can support most hardware platforms since you're not relying on the clients to calculate the results of a physics step (and in terms of security, this is a best practice since a client could modify the results before sending them back to the server).
If there is a time span of several days between turns, it doesn't make sense to keep the game state in memory while a game is in progress. Especially if the game is never completed by the players. So, you'll probably want to have some sort of backend database to store the state of all the ongoing game sessions after a certain timeout period has been reached. If you're supporting cell phones, theres a good chance that the signal gets lost so you'll have to have some way to resume a game from its last state. All of this suggests that you'll also want to be able to identify returning players so that you can see if they have games in progress, so some sort of indentification scheme might have to be created (logins? unique id's?)
For turn-based cross-hardware games, none of that advice is necessary. As long as you send the action and the result, and the other end can play a suitable animation to show that result, you're good.
Yes, in that system, one client can cheat. Currently, phones and consoles make it easier to detect and turn off hackers/cheaters, so it's less of a problem. If you really want to solve for that, you need a game server that arbiters the result of the turn, and lets both players know the outcome.
Yes, in that system, one client can cheat. Currently, phones and consoles make it easier to detect and turn off hackers/cheaters, so it's less of a problem. If you really want to solve for that, you need a game server that arbiters the result of the turn, and lets both players know the outcome.
If it's only 2 player, you could go peer-to-peer. When it's time to do a physics simulation, who's ever turn it is becomes the simulation master, and it's results is what will determine the outcome.
I would start the simulation on both devices, but send updates at a fixed rate (every 100-200mS?) from the master to the other device with the master's current state (ie, location, velocity, and state of each object in the game), and if the 2nd device has strayed any, it would get back on track.
Just my thoughts on a simple method for this.
I would start the simulation on both devices, but send updates at a fixed rate (every 100-200mS?) from the master to the other device with the master's current state (ie, location, velocity, and state of each object in the game), and if the 2nd device has strayed any, it would get back on track.
Just my thoughts on a simple method for this.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
