Forum Games Collision Handling

Discussion relating to game development with Flash

Collision Handling

Postby LunarRaid » June 6th, 2010, 6:30 pm

Hey guys,

I'm new to multiplayer game development, so I was curious what some of you veterans might have to say. I am planning on a space shooter flash game. I have read through the multiplayer articles I have seen links to here, as well as other resources, but based on your experiences with player.io, should I just write a client that does rendering only and have the server handle all collision detection with client-side interpolation, or attempt to create a prediction engine?

Some of the prediction engines I've seen using this service have been rather lousy, but I also want smooth performance. I guess it's a cake and eat it too thing. What are your thoughts?
LunarRaid
 
Posts: 8
Joined: April 23rd, 2010, 11:48 pm

Re: Collision Handling

Postby Oliver » June 7th, 2010, 11:11 am

Hey,

but based on your experiences with player.io, should I just write a client that does rendering only and have the server handle all collision detection with client-side interpolation, or attempt to create a prediction engine?


Answer: It depends on how much time and effort you want to put into it.

My take is, that you're asking the wrong question. You shouldn't try to figure out how to get 100% accurate collision detection, but rather ask "What is required to make my players feel like everything is working fine.", and devise the solution based on that.

Solutions range from something very simple with basic interpolation, and clients reporting hits, to more advanced solutions with sync'ed timestamps and possibly server-side rollback of timeline'd events to deal with varying lag between different clients.

Some of the prediction engines I've seen using this service have been rather lousy, but I also want smooth performance


Just want to highlight that "lousy" prediction engines are not caused by player.io, but how the game uses player.io. Player.IO is just a service to send messages between clients and servers really fast. It's your job as the developer to figure out how to build a great game experience on top of these primitives.

- Oliver
User avatar
Oliver
.IO
 
Posts: 1159
Joined: January 12th, 2010, 8:29 am

Re: Collision Handling

Postby fox1980 » June 7th, 2010, 2:55 pm

This is just my opinion, but if you're making a fast paced shooter game you should let the client handle almost everything. Even if we can assume PlayerIO servers never lag, the client computer might, and a lag spike or rolling back doesn't look like an option to me on a fast paced game.
So if i was going to build a game like that, and keep in mind this is only my approach, i would let the client handle all the game logic, collisions, score, lives, etc... but at the end of the level i would send some kind of 'replay' information that i would have saved in an array when the game was running. The server would parse that information and check if moves were valid and everything is correct. For example if the client sent 100.000 score, and after you 'replayed' the game at the server you found out he only destroyed enough enemies for 20.000 score that's what you save.
It should use less bandwith too, since you're sending only 1 big message instead of several small ones, you could even serialize the replay info into a bytearray, compress it at the client and decompress it at the server. The bigger the message the more efficient compression becomes.
These are just my 2 cents.
fox1980
 
Posts: 206
Joined: April 1st, 2010, 10:39 pm

Re: Collision Handling

Postby LunarRaid » June 7th, 2010, 3:30 pm

Thanks for the replies!

Oliver wrote:My take is, that you're asking the wrong question. You shouldn't try to figure out how to get 100% accurate collision detection, but rather ask "What is required to make my players feel like everything is working fine.", and devise the solution based on that.


I'm not actually looking for 100% perfect detection, just detection that is fair across the board for all players. Never trust the client in the hands of the enemy!

Oliver wrote:Just want to highlight that "lousy" prediction engines are not caused by player.io, but how the game uses player.io


Yes, exactly. This is why I was asking which method to use, because the programming method I use will determine the 'apparent' performance.

fox1980 wrote:This is just my opinion, but if you're making a fast paced shooter game you should let the client handle almost everything.


Thanks for your input, but imho, this is a bad idea. :) In my personal experience with another multiplayer game service, people will abuse the system any way they can, and if the client is doing all the calculations, it would be ridiculously simple to cheat. Add that to the fact that due to lag spikes and everything else, there is no way to make sure all clients agree, especially on who hit who. You can only trust the server for this information.

---

All that being said, I believe I am going to aim for mostly server-side data. Shooting, for example, will play the charge sound the second you click the button, but will not actually fire until the server sends the 'weapon fired' confirmation back. I will allow ship rotation to be handled client-side so it appears like you are getting instant maneuvering feedback, but won't actually adjust position coordinates until the confirmation from the server. This will be an interesting experiment, and please continue to give me your input.
LunarRaid
 
Posts: 8
Joined: April 23rd, 2010, 11:48 pm

Re: Collision Handling

Postby fox1980 » June 7th, 2010, 3:48 pm

LunarRaid wrote:Thanks for your input, but imho, this is a bad idea. In my personal experience with another multiplayer game service, people will abuse the system any way they can, and if the client is doing all the calculations, it would be ridiculously simple to cheat. Add that to the fact that due to lag spikes and everything else, there is no way to make sure all clients agree, especially on who hit who. You can only trust the server for this information.


Ok, i was thinking more of a co-op game, players vs computer, and what you're doing seems to me more like a deathmatch game, so my solution ain't the most appropriate then. Have you already looked at the asteroids universe source ? http://playerio.com/#asteroids There should be a similar implementation of what you're trying to do.
fox1980
 
Posts: 206
Joined: April 1st, 2010, 10:39 pm

Re: Collision Handling

Postby Oliver » June 7th, 2010, 3:55 pm

Yea, the asteroids is a good example game: https://code.google.com/p/multiplayer-asteroids/

it sync's time between different machines and timestamps everthing to get very little different across different machines.

We've once been involved in a shooter game that also did this, with the additional feature that when a shot was fired client side, it was timestamped and sent into the server. When the server receives those messages, it would rollback the game state to exactly that time, and then playback the movement of all actors including the bullet to see if it hit anything. That might be overkill for a bunch of games, but it made everything very secure. I think Quake3 uses something like that.

- Oliver
User avatar
Oliver
.IO
 
Posts: 1159
Joined: January 12th, 2010, 8:29 am

Re: Collision Handling

Postby LunarRaid » June 7th, 2010, 4:19 pm

Thanks Oliver, that sounds beautiful. I was actually thinking about time stamping, but wasn't sure about bandwidth overhead. Thanks for bringing up asteroids, I had meant to ask how that was handled. I am not sure if time stamping would be absolutely necessary for what I am doing; the laser shots aren't instantaneous hits, so they'd have a slower velocity to travel anyway.

I'm actually trying to get away with rendering as little physics code as possible on the client. I am using papervision3D, which uses enough of the processor without complex physics calculations. I think the most I am going to try to render on the client physics-wise is having the ship move along a trajectory and perform rotation calculations based on mouse input. All the heavier stuff between players would be server-side code, which would probably be easier to write in C# anyway. I just need to find some kind of 3D collision system based on primitives (a cone and 2 bounding boxes would suffice for the ship collision).
LunarRaid
 
Posts: 8
Joined: April 23rd, 2010, 11:48 pm

Re: Collision Handling

Postby danielm » August 4th, 2010, 1:30 pm

For what it's worth, Quake 3 didn't have any such tricks (other than the very fancy movement prediction), so playing with significant lag was always a challenge. Some mods have played with the concept though, and I believe Counter-Strike was one of the first to implement a "rollback" when calculating hit messages. Afterwards this has become more common, but occasionally despised because it can lead to strange situations (e.g. the effect of suddenly being hit by an opponent who isn't even in sight anymore). I don't know about the situation in more recent games.

In Quake-like games, there have been two different approaches, depending on whether the weapon is a "hitscan" (instant hit detection, like the machine gun), or a projectile weapon (like the rocket launcher).

Rollback works a lot better with hitscan weapons, which is why this feature has become very popular with games like Counter-Strike, which almost entirely use hitscan weapons.

For projectile weapons, the commonly used approach is a bit trickier and much less elegant: Instead of rolling back the state of the game during hit detection (which could be very frustrating when players try to visually evade a shot), the projectile would be immediately "warped" forward by the amount of time that has passed since the player originally fired the shot, thus synchronizing the projectile's location on the client and server. The obvious downside of this approach is that sometimes you can't see it coming before it hits you... And it has usually been limited to compensate for only up to a certain amount of milliseconds of lag.

The second approach has generally been much more controversial than the first, and the benefits may not quite outweigh the advantages. And since projectile weapons are "lagged" anyway by their flight time, compensating for a bit of lag is probably not worth it, unless you want to simulate offline gameplay as precisely as possible. Things get more tricky when you have projectile weapons that hit almost instantly. In this case the rollback is probably appropriate again.

Not sure if any of this is useful information, it just triggered some memories. :) I once made an implementation of this for Unreal Tournament 2003, when the idea was still new and exciting.

I think an important consideration is to decide between mild lag compensation to make the game smooth and playable for players with average latencies, or more severe lag compensation to make the game fair for players on very high latencies.

For the former, you can take for granted that a player will not lag too much behind the actual situation, which means that decent movement prediction is all it takes to make the game very playable. Players on higher latencies will see objects (including their own ship) warp around wildly as their positions are corrected from the predicted position, but they will not negatively impact anybody elses gameplay.

For the latter, you have to use more aggressive methods like the before mentioned timeshifting on the server or even allowing the client to retro-actively override state on the server. Such methods will lead to much better gameplay for the lagging player, but on the other hand it will cause very strange effects for everyone else (which can often appear unfair to the players on low latencies).

Balancing between these two extremes can be very challenging.
danielm
 
Posts: 9
Joined: August 3rd, 2010, 8:41 pm

Re: Collision Handling

Postby Benjaminsen » August 4th, 2010, 2:46 pm

I do agree that you can easily create fun an engaging games without dipping into time slicing and similar advanced approaches. In fact my first multiplayer games used no such methods, resulting in a whole set of strange lag issues. Today I could not imagine not using synchronized time-stamps and time slicing, even for slow moving projectiles such as rockets.

The posted Multiplayer Asteroids example is actually not a particularly good example as it totally lag server-side time slicing and a lot of client interpolation. I did however opt to make the example simpler to make it easier to understand.

It's also worth noticing that Flash is a fairly laggy environment for multiplayer games, thus demanding better lag handling systems.

Lastly, welcome onboard danielm, I shall look very much forward to see what you create using our API!

/Chris
Benjaminsen
.IO
 
Posts: 1444
Joined: January 12th, 2010, 11:54 am
Location: Denmark


Return to Games