Basics of Game Development

Whenever somebody talks about computer games, the first thing that comes to mind is playing them. Developing computer games does not generally come to mind. There is a distinct gap between computer gamers and programmers, each party the impression that the other is wasting his time before a computer. This kind of rift makes the world of computer game development an elusive one. So much so, most budding game developers are stuck with one question, 'Just how do you write a game?' This article aims to answer that very question. 

Developing a game isn't a simple task. It never was. In the early days of game programming, ie, the days of Pac Man and others, games were coded in Assembly language, a long forgotten art remembered only by engineering students. Times have changed since then. The tools have changed and made the lives of game programmers a lot easier, but the increasing demands of their customers kind of annuls that relaxation. 

So, what do you need to write even a semi-successful computer game? To answer this question, we need to analyze what goes into the making of a computer game. First, the prerequisite for any computer game these days is good graphics. Next, on the list is sound and music. Following this is level design and game play. The parts that we don't see are the AI (Artificial Intelligence) and networking. 

Tackling things one at a time, first how do we go about the graphics part of things? There are various tools available to the prospective game programmers. These are in the form of APIs or Application Programming Interfaces. The two most famous APIs out there are DirectX and OpenGL. DirectX is supported by Microsoft and OpenGL is supported mainly by Silicon Graphics International, both world leaders in their own fields. The topic of which one is better is the source of many a flame wars on the Internet, but I feel that OpenGL is a good place to start. Also, if you hope to program games on the Linux platform, OpenGL is your only way out.

HOW A SIMPLE GAME LOOKS CONCEPTUALLY

Coming to sound and other related fields, sadly, there isn't much of choice. The most tried and tested way is to use the DirectSound interface in DirectX or use Windows standard system calls. The factors of level design and gameplay are programmer dependant. There are a few tools that help you convert terrain elevation data, but frankly, most programmers will prefer to go about it themselves.

On the technical side, however, there are a lot more issues to be addressed. First, the most important talent any prospective game writer needs is a sound knowledge of a C/C++. Others would argue about the validity of other languages, but since system calls are provided only in these languages on both the Windows and Linux platforms, C/C++ is the only way to go. The other requirement as far as programming goes is a sound knowledge of your target OS and how it functions. Added to this, basic network programming experience would be a definite benefit. Lastly, but most importantly, as you get on with developing your game, you will need memory storage for all the data you would pile up in the form of textures, vertex arrays and audio frames. This calls for a sound knowledge of data structures (yes, that third-semester subject). Why data structures? Simply because data has to be stored efficiently in memory and your algorithms should be efficient-for example, a collision-detection algorithm should have an efficiency closer to O(n log n) rather than O(n2). 

Another major skill to be picked up is the way you use multiple threads in a single program. What are threads? Simply put, they are functions that can be executed in parallel. This is important because the graphics of your game should not have to wait for a sound to finish playing. Along with the concept of threads comes the concern of mutual exclusion, thread synchronization and critical sections. Unfamiliar with these terms? That's why we said a basic knowledge of OSs is required. 

Lastly, AI is one of the toughest parts to program. Bad AI can make your game lose its feel and overall brownie points. Other parts that need focus are sprite/character design, collision detection and I/O (keyboard/mouse/joystick). Sprite and character design often need to be done by someone other than the programmer for it to even pass off as good looking, while input

management can be done either by using DirectX of the Win32 API.

All the theory done, let's look about how a simple game would look conceptually.

Each block represents a thread and each arrow represents the way in which each of these threads communicates. The synchronization routines aren't exactly a thread that the user is aware of; they are the routines that keep calling all other threads and make sure that inconsistent data is not accessed. They also contain level data, triggers for certain threads, collision detection, common data such as health and ammo counts and anything that has to be shared. This also contains the critical section, the communication medium between threads. The graphics thread could be implemented using OpenGL and the sound could be implemented using Directsound. Of these two, the sound thread does not require much CPU time compared to the massive job of the graphics thread. It would, thus, be wise to set the thread priority of the sound thread to a lower value and that of the graphics thread to a higher one. The AI thread has to be placed at comparable priority to the graphics thread as the game cannot move on without the opponents move. 

The other most significant thread in the picture is the one handling user input. This is usually done using the message loop in games that wait for user input (chess, battleship, etc) and by polling the device in games that require a constant stream of input data (first person shooters, racing games, etc). Also, since this thread provides data to all other threads, it should be coded well to avoid unnecessary delays and deadlocks.

One topic we have left for the last is: Is you game idea an original one? Your game isn't going to make a mark out there it if is another cliché, simply because you cant match up to the originals. A good idea leads to good gameplay, one of the most important considerations. So, before you go out running to get that book on computer graphics or that book on data structures or OSs, sit down, take a while and plan your little project in such a way that it can win the love of the gaming community out there.

Although this article isn't a foolproof document on how to write a game, it is intended to give you a start. If not anything, it will give you a set of keywords to search for on the Internet, so that you may make a beginning.

Rakesh Iyer