Latency

What a pain this is! For my FPS, I originally planned to have all control processed on the server to keep things simple: if the user pressed a key on the client, that would get sent to the server, the server would process it and send back a command to the client to say "the unit you control has moved forwards".

In practise, even though the delay was a fraction of a second, it seemed like a lifetime, and movement was incredibly sluggish, as most people who've tried to write an FPS can probably attest to. Instead now, I've had to give the client details of all the map and all the other objects it could collide into, and get it to do the movement processing itself.

Now, when the player presses a key, the client checks for collisions before sending a command back to the server saying "this object has now moved forwards - tell all the other clients please". It works a lot better and movement is now brisk, but it's a lot more complex and involved since I have to do collision detection on the server AND the clients, and make sure they are all in sync.

N-Grave Up and Running

Nuclear Graveyard (or N-Grave as I like to call it) has now been up and running for several days, after my project was accepted by SOurceforge (actually, I'd be curious to know if there were any projects they didn't accept. But I digress). I've got two servers up and running and waiting. All I need now are some players! And to get those, I need publicity.

So far, I've created the obligatory web page, and even set up some forums. I guess I just need Google to trawl through it and add it to their directory?

Threads!

Every time I use threads I wish I hadn't! IMHO they exponentially multiply any problems you might have in code and often far outweight their benefit.

My latest bugbear (which I've come across before but not learnt my lesson) is "accidentally" using different threads to read incoming bytes from a scoket. Obviously this is a big mistake as the ordering of bytes is critical, so if you've got two threads reading the bytes, god-knows which thread is going to read which btye.

My first mistake was to create a new form which read some bytes; I temporarily forgot that forms run in their own thread, so my comms broke down until I spotted this.

My next mistake was to forget how quick computers are. Instead of the form using its own thread, the main thread waits until the form disappears and then reads the bytes after that. However, a split second before that my main game loop is started, which also reads incoming bytes. In the 100th of a second between the form being closed and the main thread realising that the form has been closed, my main game loop starts reading in bytes itself and causing chaos.

I know I should have a single sycnhronized method to do this, but there's loads of code to change. Suggestions welcome.

Nuclear Graveyard

After playing the excellent game Tremulous, I was inspired to fork Laser Squad 3D and turn it into something better. I'd been thinking of turning it into a fully on-line game for ages, but I couldn't quite see how to do it. After all, it's not your basic Quake variant; you control whole squads of people.

Anyway, Nuclear Graveyward is the result. If I get asked, I'll post about how I came up with the name (but it's not that interesting). I haven't actually released this game yet as I'm still tweaking it. (The problem with fully on-line games is that you can't afford to have any bugs in there without disillusioning loads of people in one go). If anyone fancies being a playtester or writing some instructions for it, just email me and I'll send you the game.

If you've played Laser Squad 3D you'll know the basics of how the game works. However, now it's fully on-line, it's slightly different. Players can join at any time and select any unit on their side (assuming it's not already being controlled by someone). So that means you can have several people playing against several people; you can have a squad of different human players playing against the computer. Strategy and communication between players is the key.