car racing

[jontan6]

are there any good open source networking code? such that it is feasible to add it to a game like TORCS, and make it multiplayer? im assuming network coding is really difficult and a great beast in itself. hence some open source starting point might be great.

[rogerborg]

BZFlag might be useful, although I haven't looked into their code or network architecture. It's just the first open source game with a vaguely similar world state (multiple vehicles on a terrain) that springs to mind.

I'd recommend RakNet as a network library. It really takes the grind out of the low level network implementation. It supports self-synchronising objects, so should let you get a prototype implementation going quite rapidly.

I doubt that the TORCS hippies would accept RakNet as a solution, since they can't infect it with GPL, but perhaps you were just providing that as an example.

[jontan6]

thanks for the reply. yes i was just wondering why a good opensource single player game such as TORC, is not yet extended as multiplayer. i was thinking that adding network code is very very difficult. i.e. lots of issues with hacking and cheating

[rogerborg]

Network architecture and design is a big subject, but the principles are really fairly simple:

1) Design the server and the network communication (the packets) in isolation from the client.

2) The server's world state is definitive.

3) At all points in your design and implementation, assume that the client talking to your server is a cheating robot or a hostile script attempting a DoS or buffer overflow attack.

4) Never, ever, ever trust the clients. The server should ideally accept only action change requests from clients (i.e. "I want to do X from now on"). It can accept immediate world state changes ("I have moved to Y"), but should always validate them by doing its own calculations to check that they are possible.

[jontan6]

and im sure there are tons of issues on top of these principles =)

it sounds like coding such for a game (from the ground up) requires a lot of experience, and lots of IQ. Seems not possible for a noob to write production quality network code in a year right?

[wyrmmage]

Actually no, I wouldn't say that. I got some networking code up and running in C++ (I was using a port of a POSIX networking library from Linux to Windows, I believe) within two months with absolutely no networking experience; I'm sure my code wasn't terribly secure, but it could send little messages back and forth reliably without trusting the user (it was also using purely UDP, and my first version was written using TCP in about a month); if all you're doing is planning on creating a fairly simple game, you should be able to write good networking code in under a year
-wyrmmage

[rogerborg]

Indeed. Especially with a decent library, you can get a working solution fairly quickly.

What's important is that you plan and design it thoroughly, since debugging network problems can be a real pain in the back end, especially if you don't know what your behaviour is supposed to be.

[jontan6]

thanks for the inputs! there is actually a potential project for our group, a car racing game where player pay some money to play, and there are real prizes. something like that. but we are more of web developer guys, so i am skeptical. i think for 3D and physics there are lots of open source solutions, but im very scared of networking code. specially when there is money involved =)

[rogerborg]

You're right to be cautious. Getting the balance right is going to be tricky, especially in a driving game where frequent millisecond accurate changes of state (steering, acceleration, brakes) are vital.

You'll want clients to be able to respond to player inputs immediately, to give a good responsive feel. However, you can't trust clients to send accurate world positions, since it's almost trivially easy for them to speed hack. There are libraries available that hook into GetTickCount() / QueryPerformanceCounter() and allow players to simply 'speed up' their clients, for example.

One possible solution is this:

Allow clients to run their own world state. They still have to send state changes requests to the server, and those requests should be timestamped with the client's elapsed time since the start of the race. I.e. instead of sending "I am at position X,Y turning left NOW", the client sends "At 5.12 seconds, I was at position X, Y, and started turning left".

The server then runs its own simulation based on those inputs. Using any sensible network library, the server will receive inputs for each car in order, so when it receives an input from a client, it can wind back the world-state for that car to the correct state for that time. It can then verify that the car's position at that time appeared substantially correct (i.e. the client is running the same simulation as the server), and if so, it then applies the input, and winds the car's state forwards again to the current time.

The server then sends out regular state updates (based on its world state) to all clients. However, clients don't have to just immediately jump their local world state to conform; if the differences for a car are small, they can be ignored. If there's a significant correction to be applied, it can be done in a gradual interpolative fashion so that it's not so obvious.

This should (note: should) allow a balance between interactivity and security. Note that if a client tries to speed hack, it will send packets from the 'future': it's easy for the server to detect that, and act accordingly. It can't 'physics' hack (e.g. by altering the friction on the track, by altering either a file or memory), since in order to send correct positions in its state change packets, it must be running the same simulation as the server. Even if it weren't, then the server's world state is definitive, so there's no point in the client trying to change it: it might appear to win locally, but the server won't believe it.

That leads to the downside of this method: it's possible in a very close race for a player to appear to win in their local world state, but for the server to decide that another car actually won. I think that's unavoidable however you do it though, since you can't keep the world states on all clients in sync all the time.

[jontan6]

thanks very much for the detailed explanation. it seems doable, but really a lot of hardwork is involved =)

thanks thanks again!