First off here is the source code. Next are a few ramblings about the code and/or design.
The physics is standard rigid body physics on a 2D plane. That is to say each vehicle has a position, angle, velocity and angular velocity. Forces may be applied to change these, either through collisions or from thrusters/wheels.
Each vehicle has two thrusters/wheels that apply force. By angling these thrusters the vehicle is able to turn. This means that the vehicles will handle in a similar manner to a hover craft.
In order to keep things manageable and playable several limits are imposed. The velocities and angular velocity are limited, so things cannot go haywire. There is also a lot of friction and damping going on. This means that vehicles will quickly come to a halt when no force is applied to them.
During each integration step, if a collision is detected the integration is restarted with a smaller timestep (down to a minimum of 0.01 seconds). In this way the impulse force from a collision will only take place over a very small amount of time, and the vehicle will only just be colliding.
Collisions between vehicles are simplified, so that angular effects are not considered. This was done as a) it made my life easier and b) nothing is really lost, as during a network game vehicles may not be in the same positions on all machines.
The game basically runs at full speed, the size of integration steps is determined by how long previous steps took (in actual time). Basically at least 100 milliseconds of timesteps are recorded and the time taken versus number of steps is used to calculate what the timestep size should be. In this way the game is constantly correcting how fast it is running. This has a slight side affect that if something else is running whilst playing the game, it might make the game seem a bit jerky. This will be worse if other programs only sporadically do work, as they'll cause a few timesteps to take a while, thus causing the game to appear to slow down then speed up briefly. This can make the game quite unmanageable. But obviously most people are used to closing all of their applications before attempting to play games, so it should be ok.
The assumption was made that all racing would occur on a track, which can be viewed as being an object with only one dimension. ie you can only go forwards or backwards. So each track is made up of sections (rather like a scalectrix track). Each vehicle starts on section 0. As the vehicles move the section they are on is adjusted. Then when checking for collisions between the track and a vehicle only the current section, the next section and the previous section need to be considered. This allows for a very quick collision check, as only 3 sections are looked at, instead of what could be 50 sections.
In the same vein, only vehicles that are in nearby sections are checked for collisions.
This has the side effect of allowing tracks to cross, forming bridges/tunnels.
The only thing to note is that the graphics are drawn on the same thread that does the physics. This was done for speed reasons mainly. It also ensures that what is drawn is completely valid (ie it is not be altered mid way through drawing).
The networking consists of two sections:
Game setup is all done over tcp/ip (so as to ensure data is sent and received correctly). It is also server (or host) centric. Meaning one player is given responsibility of doing the negotiations. Whenever a player connects to a host, the host first receives details about the player (ip address, port numbers etc) then forms a connection back to the player which information about current players and track names is sent over. This connection is kept open, so the player will be informed about other players that have joined after they have, and so that they can be told when the setup is finished ( the command DONE is sent ). Even after the initial setup is complete the connections to each player are kept open, listening for when the host has pressed reset and/or next.
After the setup each player knows about every other player. This allows the game to function in a peer-to-peer manner. Each time a player sends a position update (once every 20 milliseconds or so) the position is forwarded onto every other player. This helps keep packet latency low (which is important for this type of game), as there is no server for the packet to go via.
When a player receives a packet from another player the information is recorded and a flag is set to say that information has been received from that player. When the information is used to update the local copy of the vehicle that flag is reset (so the vehicle continues moving between packets being received).
There is an additional caveat to the vehicle updates. They contain a byte that denotes the current status of the player. This starts at 0 and goes up to 3, as packets are received from other players. So a players status stays at 0 until they have received packets from everyone. Then it is increased to 1, and does not go up to 2 until packets with status 1 are received from everyone and so on. This is used to form a crude (very crude) form of synchronisation. So that all players will be ready at roughly the same time.
The only other thing to point out is that is no security and no checking of information. It would be very easy to make your vehicle run faster and the other players would not know (except your vehicle would be a lot faster). The reason for this lack of security is that this game is firstly very simple and second it is only intended for use over office LANs and the like, when you can probably see the other players and cheating should not be a problem.
This game was written quite quickly, but I think it is quite good fun. My original goal was to actually finish writing a game for once. I think I have got most of the way there. The actual game works very well, but there are a few refinements missing. The setup GUI needs work (dialogs galore, yuck) and it won't deal very well with players disconnecting, but if you are playing the game against someone in the same room that's not too much of a problem.
Don't take it seriously, but feel free to improve on it. Different
vehicle types, power-ups, better graphics whatever.
Racing Game Home Page