PDA

View Full Version : [AS3] multiplayer racing game question


johnnycash
12-14-2008, 05:17 PM
Hi, I plan to make a Java server and AS3 clients for a simple car racing game.
If I use TCP sockets will the game run smoothly enough? I mean, the clients will have to send a lot of messages per second to update their positions. Will the oponent's cars be seen as if they running on a continuous trajectory?
I've used sockets in the past but not for real time situations.

Is there any other consideration I should take that you can think of?

Thanks in advance,

Johnny

sydd_hu
12-14-2008, 05:26 PM
I think you should use a socket server otherwise you'll get huge delays (like 1sec).
UDP would be the best, but flash does not support that.
For socket server use smartfoxserver (cost ~1000-2000 USD depending on max concurrent users).
or use red5 which is a free open source java based socket server, but it has much less support if youre stuck
good luck with that project, it can be pretty difficult to make real-time multiplayer games

johnnycash
12-14-2008, 05:39 PM
The thing is I have to program the Java socket server, so using a third party one is not allowed. Thanks for the answer.

newblack
12-14-2008, 07:48 PM
it's important to have a well-defined pipeline with minimum input necessary. i'm also currently working on a real time multiplayer game; the basic logic follows (from any instance of the game's pov):

main loop:

accumulate all forces acting on game elements
solve for acceleration and advance the physics simulation by time elapsed since last frame
resolve collisions
check for item collection, end scenario etc.


handle local user input:

dispatch a time-stamped message to all other players with that user's input configuration (keys pressed etc.) and position, velocity and angular velocity.


handle remote player input:

rewind the physics simulation to the message's time-stamp
update remote player's state locally according to the received message.
integrate forward with all new appropriate forces acting on the sender's character over the elapsed time since the stamp. (in my case where there's no interaction between dynamic objects- just dynamic -> static, i ONLY rewind/re-integrate the sending character's simulation).


this works surprisingly well for latency up to ~250 - 300ms. latency above that and there will be very noticeable instantaneous positional pop, relative to the velocity and acceleration of the sending player. it's fair to deem that unavoidable, imo.

what makes this pipeline work is having a black-box physics simulator so that i only need to send an update when the user's input changes. there's no way to avoid a reasonable differential and so it's fine to use a variable time-step as far as i'm concerned (negating a reproducible run of the simulator).

hth!