I’ve had an idea for a multiplayer game for some time (various screen shots have been posted recently). Now I’m getting down to the brass tacks.
Right now I have it set up as a Peer-to-Peer Network. Every move one player makes is sent via the BT communications to every other player… Which I can see as making issues with latency . Did player A move before or after the Bullet from Player B reached them etc.
Another idea was a client / server… where there would be X number of instances of the Player Code (client) runing on various iPads, and a single instance of Controller code (Server) running on another iOS device (even an iPhone). All the clients send their “moves” to the server, who then processes them via the game logic, and sends the appropriate results back
This server would do all the heavy lifting, the clients would basicly just be responsible for drawing the POV of a given player and accept the simple command input (move, turn, fire)
I’m thinking it would have to run this server on its own device, as a background process on a client could not use BT to talk to itself.
The downside is if this got to the App Store, it would be TWO required apps. One the server (which would be free) and the 2nd the Client which would require multiple instances
You are correct for most of the structure and communication with games. Let me step back and go through some thoughts:
When the game is designed, the logic and graphics are kept separate. The reason is that the server will need to run the logic and does not run the graphics. The server’s workload is greatly lightened since there are no graphics are required.
Each client game looks after graphics and sends their position to the server. The server then sends all positions and AI character positions to the clients. The client program then draws all of the players and AI characters.
If the program loses connection with the internet, or the client can play without a server, then the client must also be able to act with a server. Again, this is why the graphics and logic are kept separate.
The server and client are built into the same program, and can be used to self-host as a server, or to use a common world-wide server.
Does this make sense? The morning cup-of-coffee hasn’t kicked in yet
Oh that makes total sense, So you are suggesting then the best implementation would to be have the server running by itself (headless for the most part) on a device that is NOT hosting a client.
I think the server could be run on an iPhone, but the clients (due to display requirements) require iPads (or an ARM mac desktop)
Yes, that would be the easiest way to program it. This way the game is also scalable. Some games allow the players to play offline, and then connect to the main internet server when wanted.
This is where broadcasts with UDP make a ton of sense
That way when a message is sent out by one player ALL other players receive it
Each player doesnt need to send a message to each other player individually
Latency could still be an issue but because UDP is so darned fast it may not be as big a problem as you suspect
If player A fires and that gets sent out as player B fires then you can determine by timestamps which happened first
Those timestamps would need to by synchronized across all devices/players
But, that too could be a message sent out over UDP periodically to all other players from “the first player to start the game” - kind of “the time keeper”
EDIT : A quick scan of Core Bluetooth suggest this ISNT how it works at all and this MAY not be possible with BT.
