I spent some time trying to place a QGLWidget into a QGraphicsScene. Apparently, this is not a supported use of the QGraphicsScene class. One Trolltech engineer suggested creating a viewport using a QGLWidget instead of the typical QWidget (default). Neither approach worked and both ended up suspending the program on my Mac. There goes option number two for OpenGL sprites in the game.

Categories: Game Development
No Comments »

Before I began my investigation into the suitability of Qt for games, I wanted to use Qt’s new QGraphicsItem framework alongside the OpenGL support. I was curious to see if an OpenGL object could be wrapped by a QGraphicsItem and rendered into the same view. The short answer is yes, but the result is not very pretty or practical. Basically, it comes down to a fundamental issue with OpenGL and sharing rendering contexts with other engines. OpenGL doesn’t allow this by design, but you could use an QGLWidget and encapsulate that in a QGraphicsItem implementation. The result is very heavy weight, not particularly elegant, and doesn’t easily support animation of the OpenGL shape. With the latest version of the Qt API, you can render a QWidget object into an OpenGL rendering context, but not the other way around (without using a container like QGLWidget).

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.

Categories: Game Development
2 Comments »

I’m a big fan of the Monkey Ball series produced by Sega. Sadly, I can’t just bring the game everywhere I go since it’s shackled to a console, and you just don’t get the same experience on one of the portables. So to get my 3D rolling ball fix more easily on the road, I have turned to a game called Neverball. Neverball is actually two games in one package; the second game is called Neverputt. It’s a GPL licensed game, so you can fool around with it to your heart’s content and maybe even contribute something worthwhile back to the project when you’re done.

Which brings me to the focus for this series of articles, we are going to add some functionality to the Neverball game. But before we can inject a new feature, it helps to understand how the game works and the architecture of the software; otherwise, we risk adding code which is either buggy, incomplete, or just awful. Since I really appreciate the stream-lined codebase for this project, I definetly do not want to sully the project using inferior source code, but that doesn’t really concern me since every drop of code I write is pure gold.

As a logical first step, let’s review the overall structure of the project. If you download it from the project’s website, you will be given a choice of packaging suitable for Windows, Linux, or Mac OS X platforms. For the most part, I’ll be focusing on the Linux platform, since it tends to be my development platform of choice in the here and now (although that’s quickly changing to the Mac). However, I will not forget about the other two and will relay any useful information for those platforms when I come across it.

Neverball has a simple build file using to generate the executables and compiled map data, although there is a Microsoft Visual Studio specific project file so you are saved from toiling with Cygwin. You should have little difficulty in getting it to compile using your favourite Linux distribution. It has dependencies on a few SDL libraries like SDL_image, SDL_ttf, and SDL_mixer. I would also recommend developing and testing this program on a machine using 3D hardware acceleration. Depending on the sophistication of your CPU, software emulation may not be terribly fast and can prove frustrating when you’re jumping into the game so frequently.

The project is structured into basically four pieces: data, modules specific to Neverball, modules specific to Neverputt, and the shared source code used by both programs. Between the two projects, Neverball is the larger and more full featured game. Neverputt uses the same rendering engine but customizes the game setup, layout, camera, etc. to suit the game of golf. The 3D rendering is entirely performed through OpenGL; there are no DirectX dependencies which is a boon for us since it makes the project more consistent and easier to modify.

The underlying engine uses objects and maps constructed from within a program called Gtk Radiant. I believe the most compatible version for Neverball would be 1.5, but 1.4 or earlier may work as well. A word of caution, the Gtk Radiant project does not build particularly easily on Mac OS X 10.5. You can find pre-built versions on the Internet via a small variety of sites, or you can simply download it here. In the next article, we’ll look at how to set up Gtk Radiant and get it working; we’ll also be looking at some of the higher level architectural pieces which makes the world of Neverball come to life.

Categories: Game Development
No Comments »

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 »

I had my first attempt at a brainstorm for project Niblet last night. I used the software program called Curio to collect my ideas in a synergistic, multi-media, power-house document. Too bad you only get to see the rasterized and PDFized versions. A few people have scoffed at my desire to use Curio, they asked “why not just use a piece of paper and pencil?” Aside from the obvious cool software motivation, I often have the need urge to put stuff like this on-line in the off chance someone may find it useful or interesting better than most of the crap on MySpace. It’s a fool’s dream but there you have it.

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

Categories: Game Development
No Comments »

A few days ago, I decided to experiment with Qt as it applies to game development. You haven’t heard of Qt? Well, it’s an SDK for cross-platform development which has really started to take off in the cross-platform arena over the last couple of years. KDE, a desktop platform for Linux, is based on the Qt library; so is the VOIP application called Skype. They even have a mobile platform called Qtopia for those who are interested in small devices. You can find out more information on the Trolltech website.

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.

Categories: Game Development, Programming
No Comments »

There are two sides to every coin. Game development can be hard or game development can be easy. These are relative terms, of course. Just because writing a game can be easy, doesn’t mean your grandmother could do it (although I wouldn’t hedge any bets, especially with mine). Personally, I think writing any finished application is an achievement for any programmer working alone. With the help of my colleagues, I have produced several applications which have made it onto store shelves, but I won’t take the credit since my part was just one piece to the puzzle. Of course, some applications cannot be programmed by just one person. Oh sure, one software developer could work for years or decades to achieve their goal, but who has the time and talent required to design and engineer something as complex as Metroid Prime, Photoshop, or the KDE Desktop on their own? It just doesn’t happen in the real world because life inevitably steps in and takes over.

However, all is not lost for the eager programmer setting out to create a game. It all boils down to following a few simple rules and having a few good resources available. For the next couple of weeks, we’ll look at some of the tricks of the trade and present a list of books which I have found very useful while exploring game development. So, without further procrastination, let’s dive right in to our first topic.

Game Design – The key difference between finishing a game and an unfinished hack is managing expectations. Yes, we would all love to design and build a game like Halo, but that’s not terribly likely and will almost certainly lead to failure. Instead, try and reduce the scope of the project by carefully choosing the characteristics of a game you wish to include. Care must be taken to use only those features which are absolutlely necessary. You should spell out how you want your game to work, what features need to be written, and any third party tools you plan to use which can save you time. In essence, you need to write a bit of documentation. Yes, I know, documentation is a bore and some of you may find it difficult. But you don’t need to write a best-selling novel, just outline what you want to do and how you want it to work.

By translating those exciting images and ideas you have into something concrete, you’ll be able to assess your goals and overall design much more easily. It also makes your game much easier to digest for other people. If you wanted to hire an artist, for example, you would need to describe the concept in fragmented conversations over the phone or via the Internet. It would make the job of the artist so much easier if you had the design for the game already completed. In fact, most artists (the smart ones anyway) won’t accept a contract without a working game design in place. Without this document, you would be unable to tell the artist which assets need to be produced now and what can wait until later. If you know all of the work which must be completed before the artist draws a single pixel, he/she will be able to commit to a schedule and a price.

Over the last few years, several good books have been written on designing (and managing) game development projects. However, these books tend to focus on many details which are only relevant or important to large scale projects. Naturally, there are excerpts which you will find useful, but don’t get overwhelmed by the sheer volume of information. Generally, you don’t need to concern yourself with all of those details; the object of this lesson is to finish a fun game you want to create in your spare time. If followed some of those books to the letter, it would take ages to complete a project and you may find your interest in the project begin to drift after a year or two.

Project Management – When you are creating a game by yourself and for free, I don’t recommend setting a schedule. Schedules are for people and companies who must release the game in a timely manner because their economic futures depend on it. The bottom line for you and me, however, is that schedules aren’t very accomodating for new game developers and they aren’t very much fun when you’re ten weeks behind your target date. If you don’t need to release a game in six months, then why would you care that your line drawing algorithm is taking twice as long to craft as expected?

On the other hand, you could always use the project as a way to enhance your project management skills, which is admirable but you may find the accuracy of your estimates vary considerably. This is partly due to life, who once again chooses to interfere with your project. As a programmer at work, I can count on having at least five or six hours a day for solid work. At home, my free time will vary wildly. If you only consider the cost (in time units) and forget about dates, then you may find your estimates more useful. If you really insist on reading a book to brush up, then I recommed:

• Joel Spolsky’s book entitled Joel on Software. It’s a compilation of articles for novice program and projects managers. It has a number of good practical tips which can benefit almost any software project, including projects done by the hobbyist.

Categories: Game Development, Programming, Reflections
No Comments »