Real time swords game

Started by
5 comments, last by Bagheera 17 years ago
Check this out. For simplicity's sake, my game is a real time swords fighting game. If I press left, my opponent must also press left in order to block. Let's assume normal human reflexes (three quarters of a second), so for a hit to contact we're looking at, say, a second. The 1st networking demand: Allow normal gameplay up to 200 ping (round trip of course). We'll start with a P2P, one on one model. Here's the problem: Player 1 presses left at time 0. Time 100ms player 2 receives the message. Time 750 + 100 = 850ms, player 2 blocks. Time 950 player 1 receives that player 2 blocked, and the block is synced and successful on both monitors. However, what is player 2 decides to block a little later? On his screen, he should successfully block. But since the message will not reach player 1 in time, how on earth should it all work? New situation: Time 0 - Player 1 attacks to the left Time 100 - Player 2 recieves message Time 100 + 950 - Player 2 blocks (should be a successful block) Time 1000 - The hit is made on Player's 1 screen Time 1050 - Player 1 receives block message Now what?! I've already displayed blood, made a horrible sound effect and life has been taken from player 2 - From player's 1 perspective. From player's 2 perspective - He already blocked. How would you design this? Keep in mind this game depends entirely on responsiveness, and a hands-on feel.
Advertisement
Unless you're running a quantum computer you can't :).

This is the same problem that FPS games encounter with movement. Clients can only predict what will happen, and when global state mis-matches, they roll back. This is obvious with characters warping all over the place when an individual client gets out of sync.

The design for this would need to take into consideration acceptable latency, then base animations off that.

All you need to decide now is how to determine who's the authority - who's game state will be preserved. When your clients lost sync, you need an independant method to determine which client will roll-back the state (health, not animations).


Other option is of course to sync clients based on every move. They both send actions to each other, then wait until they receive responses. This isn't ideal, since your game update loop will be determined by client latency. Connecting to someone at with high ping will slow down your game loop.

This can probably be masked again by designing a game around it, and assuming that clients must sync every 1/2 second, else you stall the game for both, one way or another.

But there is no algorithmic solution when dealing with multiple human players - there simply is no way to reliably predict the action, so synchronization is a problem that must be solved one way or another, but cannot be bypassed.

With NPCs you could use a shared random number generator to calculate identical "random" values on all clients.
Make the contact and block animations look the same for the first 300 milliseconds after the critical time, so there's time to agree on the state before determining which response to play out.
enum Bool { True, False, FileNotFound };



Real sword fighting requires reflexs/reactions alot faster than 750ms.

Do a test. Watch a TV show and throw your hand up before your face every time you see the camera frame change to a different view. That will give you a better idea of what you could make the allowed reaction time. You should now have a bit more leeway in the timing (a 'lame' reaction will probably be closer to half your 750....) and resolution across the network latency.
--------------------------------------------[size="1"]Ratings are Opinion, not Fact
Bagheera. I understood none of your abuldoshibulnohekinocheckinomoff. But keep trying buddy.
Quote:Original post by Bagheera
Check this out. For simplicity's sake, my game is a real time swords fighting game. If I press left, my opponent must also press left in order to block. Let's assume normal human reflexes (three quarters of a second), so for a hit to contact we're looking at, say, a second.

The 1st networking demand: Allow normal gameplay up to 200 ping (round trip of course).

We'll start with a P2P, one on one model.

Here's the problem:

Player 1 presses left at time 0.

Time 100ms player 2 receives the message. Time 750 + 100 = 850ms, player 2 blocks.

Time 950 player 1 receives that player 2 blocked, and the block is synced and successful on both monitors. However, what is player 2 decides to block a little later? On his screen, he should successfully block. But since the message will not reach player 1 in time, how on earth should it all work?

New situation:

Time 0 - Player 1 attacks to the left
Time 100 - Player 2 recieves message
Time 100 + 950 - Player 2 blocks (should be a successful block)
Time 1000 - The hit is made on Player's 1 screen
Time 1050 - Player 1 receives block message

Now what?! I've already displayed blood, made a horrible sound effect and life has been taken from player 2 - From player's 1 perspective. From player's 2 perspective - He already blocked.

How would you design this? Keep in mind this game depends entirely on responsiveness, and a hands-on feel.


Make some 3D visual with celstart =)
14 - I didn't understand you either, so we're cool in that respect.

Everyone else - Thanks for your help!

What I'm going to try is to have the block animation not actually block in the first 100ms. How it works in my game is that your sword has to actually block the incoming blow, as the collision is checked between the swords. If in the first 100ms of the blocking animation your sword is not raised enough to successfully block - Then you won't actually block! This creates the effect that the user will understand that he cannot wait until the last moment in order to block. Tada!

This topic is closed to new replies.

Advertisement