Home

Welcome to the ForTerra wiki!

Object handled

1. User
2. Spaceship
3. Gunfire
4. Asteroid
5. Movement trace

Game code workflow

origin I have created a couple real-time games like this. One was multi-player Asteroids (everyone was shooting at the asteroids, co-op play). I had great response time -- BUT, I was NOT "spamming" all clients with too much data -- this may be a problem. I got the game to run at 60 fps on the client with the server processing the physics at 30 fps. It only worked when all clients were Chrome (so they had web-sockets). Most browsers today support web sockets. I would check to make sure you have sockets first. Second, I wouldn't send too much data to all clients: One way is to process the physics on the server at a known rate (like 30 frames-per-second). Also, be processing the physics on the client. Send end-user-changes to all clients on the 30 fps boundary (not when you get the data). For asteroids this means: Each client AND the server knows the following:

1. Where every player-ship is, and everything about that ship (facing direction, floating direction, if boost is on or off)
2. Where every bullet is (location, direction, velocity, who fired it)
3. Where every asteroid is (location, direction, velocity)
4. 30 times a second, run physics, repaint screen

Now ...

1. When a client gives you a request (like, rotate my ship to the right) -- the client sends that data to the server (and does NOT process it locally)
2. When the server gets a user-request, it queues the request up to be processed next "tick"
3. The server tick (30 times a second): Process all queued events:
4. On a request to rotate a ship: Actually rotate the ship. Broadcast the ship data to everyone (location, facing-direction, velocity ...)
5. When a client gets a update-event from the server, it crams that new "correct" data from the server into it's local space. Note: If a client can't process everything at 30 fps, the ships will "jump" to their correct locations when the data is sent.