Introduction: General Programming Section

 

By Scott Bilas

 

Before you start tearing into the gems that are waiting for you in this section, let’s do a fun little exercise and try to get back to basics. Ask yourself a question: what is an engineer, or perhaps, what is it that you do? Is an engineer a person who writes code, someone who would, for example, make lots of triangles draw really fast? Not necessarily, of course. Plenty of engineers don’t write much code at all. Engineering is about solving problems.

Let’s put this in the context of a game, and ask a new question: what is an engineer’s role at a game development studio? The answer is simple: an engineer’s role is to serve the team. Setting aside for the moment our tendency to fill many roles at once, a typical team is divided up into three main groups. First we have the designers, who figure out how the game is supposed to work and be fun. Next we have the content developers, generally artists, composers, and level designers, who create the assets required to enact the design. And finally, we have the people that work down in the basement, taking far too long to accomplish their tasks as usual: the engineers. We are the ones who build the systems that connect the content assets with the game player. In other words, we, the engineers, spend all our time serving the team by building tools. Serving? Tools?

What people generally think of as a “tool”, such as a level editor, or a batch script processor, is only the obvious, visible part of the picture. Everything we create as engineers is a tool, whether it’s the engine that plays back and blends the animations created by the artists, the in-game databases that manage the interactive content, or the debugging infrastructure that tracks memory usage patterns. Ultimately what we do is create software tools for bringing a game’s design to life.

Many of our tools live offline, and are used to create and preprocess data for efficient playback or simulation through the game engine. Examples of these are BSP compilers, texture compressors, resource assemblers, and level editors. These tools tend to remain in the hands of developers and mod makers and are not necessary to run the game, but are essential to creating the game. Recently, games have started integrating tools like these into the game engine itself. This is often done to speed up the development process by allowing significant portions of the content to be edited from within the game while it’s running.

Other tools that we create live exclusively within the game itself. Some common examples of these are scripting engines, physics simulators, and the user interface. Each of these is, at its core, a command processor that receives instructions and does something useful with the information. In other words, these are tools that interpret and shape the content as dictated by design, and as such they combine to form the game that the player experiences.

Sometimes, as engineers we create tools for ourselves that live within the game. Modern games are so complex that they require vast levels of support by the game itself in order for us to effectively debug and optimize them. With tens of megabytes (and soon hundreds of megabytes) of memory at our disposal, the staggering quantities of content that we are churning through our games requires us to create complex support systems in order to keep our heads above the water. We create debugging systems, profilers, type databases, utility libraries, stack-dumping exception handlers, logging utilities, self-check code, and, well, the list could fill a book. Conveniently, that’s what the gems in this section of the book are all about. These gems will help build or enhance a solid foundation for game development. Enjoy!