4
\$\begingroup\$

I'm working on a real-time game based on a grid. Each player can move a single square at a time. A server tracks the game state and notifies clients of changes.

It's possible for two players to make a conflicting move, such as attempting to move to the same square. How can I fairly resolve such conflicts when they happen?

My current approach is First come, first served: When the server receives a move, it immediately updates the game state to reflect that. It then discards any conflicting moves it receives later.

The problem is that the moment a move was received does not necessarily line up with moment it was sent. Players on a faster network connection will always have an advantage.

How can I deal with this?

|improve this question
\$\endgroup\$
  • \$\begingroup\$ Movement similar to what can be found here: youtube.com/… \$\endgroup\$ – Chris Evans Jan 10 '12 at 21:39
  • 1
    \$\begingroup\$ For two players moving onto the same tile at the same time, you'll need some way to determine who wins. It can be as simple as whichever command the server receives first. \$\endgroup\$ – Blecki Jan 10 '12 at 23:22
1
\$\begingroup\$

One approach to more fairly resolve conflicts would be to make the server logic work in turns, with very short fixed-time turns so play still proceeds in realtime.

During each turn, the server collects all moves, but doesn't immediately commit them to the game state.

A moment later, it closes the turn, detecting & resolving any conflicts in the moves received that turn and committing the result to the game state, updating clients as needed.

This way you can implement any conflict resolution strategy you want - pure random, alternating, influenced by unit rank or perks applied, etc...

|improve this answer
\$\endgroup\$
0
\$\begingroup\$

You could have all players send a timestamp with their moves. The server waits, collecting all players' incoming moves (or until some maximum latency), sorts them by timestamp executes them (applying the result to the game state), while discarding conflicting moves. It then notifies all players of changes and waits for another set of moves.

This way, players on slow connections are still treated fairly.

The only issue with this I can think of is that network-savvy players could cheat by forging their timestamps such that they always get the highest-priority move...

|improve this answer
\$\endgroup\$
  • 1
    \$\begingroup\$ I think you'd want the server to infer the sent timestamp from round-trip response time to that player, rather than trusting the client to give you an accurate timestamp. (This eliminates not only deliberate forgery, but also innocent differences in clock settings - you know for sure you're always working in "server time") \$\endgroup\$ – DMGregory♦ Dec 16 '13 at 17:41
  • 2
    \$\begingroup\$ @DMGregory: That would still be forgeable, though, although not as easily -- a hacked client could pretend to be on a badly lagged connection by holding messages in a buffer for a while before sending them. This would allow it to edit the messages while they're in the buffer, effectively pre-dating the changes. \$\endgroup\$ – Ilmari Karonen Dec 16 '13 at 20:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.