During the development of this project, there are going to be things which Qt simply can’t, won’t, or doesn’t do. I am going to talk about a few of the features which must be implemented using other libraries, or if you’re feeling particularly creative, by writing large chunks of hand-crafted code. Besides being 100% organic, it also gives you a lot of background knowledge and can grow into its own project.

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.

Categories: Game Development
No Comments »