Nuclex

It took me some time to figure out how to organize my code so it fits in with the XNA framework design. Because the game is so small, I did this by building some dummy classes and that I renamed and moved around in the project tree until I had reached an adequate design.

Maybe some people would have used an UML prototyping tool, but I am used to thinking in terms of design and code, so, just like a good chess player, I can see when a design will work out or when it will blow up.

Then I identified the hardest, probably most demotivating task at hand. If you can, I think it's always good to start there because this is likely the point where you often postpone working on the project for the rest of eternity.

The hardest part in this project seemed to be the dynamic construction of the level's 3D model out of a simple text file that defines the maze using pure ascii characters. You have to create a bullet-proof parser and then somehow build a contiguous vertex array for all the walls, floor plates and holes in pure code.

So day 1 ended with me writing a parser for the textual level file format I have layed out before.

Today, I started development on my first XNA game. It will be a rather simple game, the real-world version of which I once played in my childhood. This should allow me to get up to speed with the state of the art in 3D accelerated rendering again.

Because I have a job that requires me to sit in front of a PC for more than 9 hours a day, my interest in development at home is fading a bit. I hope this game will rekindle my interest for game development!

Back to the game, what I decided on is a simple game of balance where you have to carefully tilt the game board to maneuver a little ball around obstacles to the finish:

Because this is such a simple game, I will release it for free and in full, that means with all notes and its source code!

Sometimes, games have to render highly dynamic geometry such as sparks, bullet trails, muzzle flashes and lightning arcs. Sometimes it's possible to off-load the work of simulating these things to the GPU, but there are effects than can't be done by the GPU alone.

These cases usually occur when effects require heavy interaction with level geometry or when they require lots of conditionals to mutate a persistent effect state. And sometimes, the effort of simulating an effect on the GPU is just not worth the results. If you have maybe a hundred instances of a bullet trail at once, letting the GPU orient the constrained billboards for the trails instead of generating the vertices on the CPU might just not yield any tangible benefits.

However, there are still a lot of traps you can run into. A typical mistake of the unknowing developer is to render the primitives one-by-one either using one Draw[Indexed]UserPrimitives() call per spark/trail/arc.

This is not a good idea because modern GPUs are optimized for rendering large numbers of polygons at once. When you call Draw[Indexed]UserPrimitives(), XNA will call into Direct3D, which will cause a call into driver (which means a call from code running in user mode to code running in kernel mode, which is especially slow). Then the vertices are added to the GPU's processing queue.

By sending single primitives to the GPU, this per-call overhead is multiplied and can become a real bottleneck. To demonstrate the effects of making lots of small drawing calls, I wrote a small benchmark and measured the results on my GeForce 8800 GTS 512 and on whatever the XBox 360 uses as its GPU.

This post is not exactly related to .NET/XNA game development, but I like to keep track of what's going on in the world out there and I still like C++ better than C# ;)

Having played the whole engine shopping game more than once, here are 7 engines I'd take a closer look at if I were to write a game in C++. I've listed them in order of personal preference, but be warned, this is entirely my opinion and not based on proper research!