PGDmC: 2-bit Racer

[Ingemar]

Test upload made! It is called "2-bit racer test 1.zip" and is a binary for Mac OSX 10.6.

The game looks a bit strange since the cars have no wheels, but otherwise it is getting close now. The game AI works, it is not very good but it is possible to perform a full race, currently with two opponents. A full race is three laps.

Linux/Windows version? Well... no. I won't have time. Most of the code is fully portable, especially to Linux, and to Windows shouldn't be hard, but I don't have time for that. Most critically, I don't have any Windows development system with FPC that I am comfortable with. But if someone would like to help me with that, it might be easy.

[Ingemar]

I just tested the game on two other Macs, with less than pergfect results. The other Macs are older, have less powerful GPUs. On an old MacBook, with GMA950, I could make it run once I turned off the shaders, and even then it ran less than smooth.

But I believe that the judge's Macs were rather better than my main MacBook, and then it should work just fine. I better upload a shader-free version just in case. It doesn't look as good but the chance of running at all improves a bit.

[chronozphere]

AI can be really tricky in these kinds of games. If you are using a 3d environment you will probably need to set out invisible waypoints or some other datastructure to "guide" the AI. This can take a lot of time to fine-tune.

And yes, making it a fun game is allways the hardest part. I've written two games in pascal and while they both worked great, they were still not well-balanced and still miss that replay value a good game needs.

Good luck (You'll need it)

[Ingemar]

I am soon ready to make another upload, with a whole bunch of fixes, but it would be really interesting to know if anmyone out there with a fairly modern Mac can run the game. Anyone?

[Ingemar]

I realized something unpleasant but important: The speed of my game was not limited by my timer but by my CPU. That means that other Macs can work very, very differently. In order to fix that, I fixed the worst bottleneck (Immediate Mode code). The whole game went VA-VA-VOOM and got totally unplayable - but really smooth. So now I have to re-tune the whole mess.

I knew all along that Immediate Mode wasn't an good idea, but the difference was bigger than expected.

[WILL]

Yeah one of the more important parts of making a game is the timing of your 'frames'. I'm not talking graphical frames per-say, but your game's running frames. Each update of your game objects and environment. This is key to a nice running game.

[Ingemar]

Yeah one of the more important parts of making a game is the timing of your 'frames'. I'm not talking graphical frames per-say, but your game's running frames. Each update of your game objects and environment. This is key to a nice running game.

That is certainly the case and I should have planned for it. There should always be a "dt". But the other way to do it, which was how I did it, is to lock the frame rate and work from that. Sadly I didn't notice that I got less than the planned fps. It wasn't exactly hard to see, 11 fps instead of 50, but you quickly get used to 11 fps.

But I will fix that now.