This is fine and not detrimental to the project, so we'll continue using the new graphics framework minus the features relating to OpenGL. This gives us plenty of options for rendering, but 3D will be set aside for now (unless I get a spark of genius). We may revisit it later to explore different ideas, like the intro screen or credits; however, we will need to find out how well Qt supports direct pixel rendering. I am very familiar with various image classes, but whether they can be used in and efficient rendering pipeline is still an unknown.

I'm trying to be realistic here. Niblet is not an overly complex idea, but I would like to use compositing for a variety of effects and some effects like fire would need to be rendered using fast pixel access.

The first missing piece of functionality falls into the realm of input controls. While Qt can easily handle mouse and keyboard input, it cannot handle joysticks. Joysticks have numerous buttons and features, some of which can be accessed through standard interfaces; others require special drivers and access methods. Support for most typical joysticks can be easily implemented using a library like SDL. This is exactly what we will be using for Niblet. It would be cumbersome to try and incorporate SDL directly into our code, so we will be writing a wrapper or integrating it into one of the core classes and emitting Qt signals when input is detected. Since this sort of input almost always requires a polling mechanism, it will need to be done in the main game loop at some point. Careful planning will be required so that our game play doesn't suffer as a result of this new input method. Ultimately, if it doesn't work out to the benefit of the game, then it will not be used.

Qt does have support for audio, but that support is extremely limited especially when you want to anything other than your basic audio functions like playing, pausing, or stopping a sound. As I said, it's pretty basic, so we'll be using the OpenAL audio system. It's flexible, clean, cross-platform and open-sourced. It has more than enough functionality for Niblet, so it seems to be the better choice over similar audio libraries, such as SDL_mixer, whose future is not so certain. Even though on some platforms, the underlying implementation may in fact be OpenAL.

Other libraries for additional mathematics, physics, and OpenGL support, such as GLUT, will probably be used since (spoiler) at least some of Niblet will be rendered in 3D. At least, that's the plan since I want to see how well the two technologies can work together. There are many physics engines to choose from such as Box2D, Bullet, and Open Dynamics Engine. Many of these libraries also support collision detection which is a fine candidate for third party support.

Last but not least is the build system. We are currently using Qt's qmake utility which takes Qt project files and produces native project files for different development platforms. It's a pretty basic tool by itself and doesn't offer any platform discovery functionality. For example, using a build framework like autotools or cmake, one can write helper scripts which perform tests, discover libraries and header files, and execute tools which can be very useful for cross platform projects. The need is especially great when your project needs to be built easily by other people with a minimum of fuss. Niblet is not going to be a huge project by any stretch of the imagination, so qmake will do just fine. It's used to generate the build files for the entire Qt framework after all. Should I be struck by a desire to move to something more sophisticated in the future, don't be surprised.

The project has been extended to include addtional modules (mostly empty) and some additional framework functionality which allows me to suspend or activate game play amoung other things. The game's scene area has also been enlarged and auto-scrolls when Niblet approaches the borders of the viewport.

Instead of me wasting time assembling a .zip file every time I want to release an update, I'll just refer you to this handy-dandy Subversion URL. You can check out the project using this command:

$ svn co http://projects.resurrected-entertainment.com/niblet

To begin the project and to get the brain juices flowing (after the second cup of coffee, of course), I wanted to come up with a small, interactive demo which would make use of some of the classes related to QSceneGraph and QGraphicsItem. I also wanted to play around with the layers a little bit and see how suitable they would be for games. The first program is a simple one indeed; in fact, it's not really a game at all - unless of course you're really bored and you start to chase invisible dots on your screen. Just run demo, and you'll understand what I'm talking about.

I am basing this project off a classic so that I don't stray too far off topic. MS-DOS 5.0 shipped with a QBasic game called Nibbles. The game play revolves around a worm that you control through a maze of walls while looking for food. If your worm collides with a wall or itself, you lose one life. The difficulty revolves around the worm's velocity; it gets faster as you advance. The idea is to use that basic game as a model at first and build on it a little as time goes on; this will help to keep the project focused, which can be a real challenge for those who are new to game programming. To get things started, I have decided to dub the codename for the project: Niblet. The real name will be decided, if and when, this Qt game comes together.

The first problem is the worm, of course. It needs to snake around and grow to certain lengths when food pellets are ingested (or numbers as was the case in the original game).; I also like the idea of it shrinking in response to an item collected during the progression through a level. Anyway, the rules can be fleshed out later. For now, let's just get a very basic framework up and running. To compile the little demo, just run qmake and then make if you're on Linux or open up the project in Xcode if you're using Mac OS X; Windows users can open the project in Microsoft Visual Studio. If you're using Mac OS X Leopard, I suggest you try out Qt 4.4 which will produce a proper project file for Xcode 3.1.

As you can see, very little code is needed when using Qt. If you were to write the same program for Windows using DirectX or even through the GDI, you would need considerably more code just to handle the application start-up process and surface initialization. But that's the beauty of these SDKs, they essentially handle a lot of the routine programming so you can concentrate on building your software faster and better using these handy libraries.