So you want to make games? – Engine
In the simplest of terms, a game engine is a singular loop that performs several layers of tasks repeatedly. Each time the loop repeats, a single frame of your game is displayed. Hence why a game’s performance is often measured in “frames per second.” The human eye is only capable of differentiating about 10 to 15 images per second, but in order to create the illusion of smooth motion and animation you’ll need a minimum of 46 frames per second (as determined by Thomas Edison). Modern computer monitors typically cycle at 60 frames per second, and so there lies our goal.
60 frames per second doesn’t give an engine much time to process a loop, only 16.67 milliseconds. Any time you take beyond that will lower your frames per second and create a sense of “stuttering” or lag for the player. To make the situation even more complicated, not every frame is going to process in the same amount of time since a game is made up of many different events that are triggered at different moments, thus causing variations in processing.
In order to prevent player warping and to create a smooth gameplay experience, it’s necessary to use a high resolution timer to track each frame’s elapsed time in milliseconds. You can then multiply every object’s stated velocity by the previous frame’s elapsed milliseconds to create motion over time rather than motion per frame.
A really good engine can seemingly combine all the separate components for a game into a magical black box. If you’re making your own from existing libraries, the burden of creating that illusion falls squarely on your shoulders.
Lets say you’re making a 2D side scroller. Your design specifies a main character represented by a 32×32 pixel image (called a sprite). You load up your favorite image editing software, draw the best thing you can come up with, and save it to a file on your hard drive.
Now what? How are you going to bring that image into your game? Once that’s completed, do you want him to make any noise? How will you control the movement of the image? How will it interact with the game world? Will there be other players to interact with?
Each of those questions represents a layer of what game engines need:
- Asset Pipeline – imports content from standard formats into something you can use.
- Graphics – draws everything onto the screen.
- Sound – plays all audible content
- Input – translates keyboard, mouse, or other controllers into game functions.
- Physics – runs rules of interaction between game objects.
- Networking – communicates and synchronizes game sessions between multiple players
The last one listed, networking, is the only truly optional component, and that’s if you’re willing to limit your game to single-player (not a bad idea for beginners). All the other layers are needed in some way, shape, or form.
Every time you save information to a computer it has to be stored in some kind of format that can be read back. Otherwise the data would be useless and saving it would be pointless. The good news is that there’s already a lot of well structured file formats out there for almost any kind of file you need to use. For graphic images there’s png, tiff, jpg, and gif. For audio files there’s wav, ogg, and mp3. For 3D meshes there’s blend, 3ds, and obj. There’s numerous options outside of those as well. What you’ll need to do is decide what content creation tools you’ll be using (Photoshop, Blender, Gimp, Audacity, and so on), and then determine the easiest formats to export and then import into your game engine.
Many of the libraries I mentioned earlier have at least some import functions that can load a few standard formats. Though, just because they can load them, doesn’t mean your game engine can use them. Much of that will be decided by how you design the different components, thus leaving you with some programming to do.
If you’re using a prebuilt game engine, you’ll need to learn which formats it will accept for import, and then use the appropriate content creation programs.
One of the first things you need to worry about after getting your sprite imported is how to display it. In 2D games, you typically begin by drawing a square and then painting the image onto it. As a matter of fact, many 2D games these days are written in 3D engines in order to take advantage of advanced graphic hardware acceleration (usually via OpenGL or Direct3D). This is done by creating as many two dimensional squares as needed and texturing them with the imported images. Those squares are then sorted and drawn.
You may not have considered the need to sort all of your graphic objects each frame, but this plays a huge part in displaying objects which have transparent edges or translucent images painted on them. It would be a huge drain on resources to have to return to previously drawn images and redetermine how to display something behind it with the appropriate masking. For this reason, you always want to display furthest objects first, even in a 2D game where everything is drawn on the same z-axis.
Sorting a 3D scene is much more intensive than 2D, with the need to determine each objects distance from the camera, but computing those numbers is processing power well spent. Most developers create a single loop that is repeated each frame to first determine which objects can be seen (if an object is off screen or occluded by another object, don’t waste resources drawing it) and then assigning a numerical order to each one (by reordering them in a sorting tree to be traversed later).
I could go on and on with programming techniques and specifics on how to create your own graphic engine; entire books have been written on this subject. That’s not the purpose of this article however, so instead I’ll list some resources to help you along:
- Nehe GameDev Lessons - The lessons listed on their site will guide you through numerous techniques and beginner tutorials on how to write a graphics engine in OpenGL.
- Developing Games in Java - A fantastic book on game development that goes through the parts of a game engine.
- OpenGL.org - Home of the Open Graphics Library.
There are also a lot of prebuilt graphic engines available to developers these days. Ogre is a popular one that is both complete and well designed. Torchlight is one of the more popular games that have been successful with this approach. Keep in mind however that Ogre is only a set of graphical functions – you’ll need to find other libraries to complete the rest of your engine.
Now you’ve displayed your sprite on screen, along with the background and all the other objects to make up a scene. There’s still something missing though, things like background music and all the little bits of ambiance made up by sound. People expect to hear something when a character moves or performs an action, and a good piece of background music helps set whatever mood you want to convey.
Audio libraries are tricky these days. There’s licensing involved in most of the prebuilt options, though some of them like FMod and BASS offer cheaper prices for indie developers. There’s also OpenAL (the Open Audio Library) that’s free, but considered by many to be far more difficult to implement. There are those who’ve taken OpenAL and made something easier out of it though, like Paul’s Sound System for Java, or SFML. For Windows developers, Microsoft’s DirectAudio library is an obvious choice.
A game isn’t a game without some kind of user interaction, be it keyboard, mouse, controller, motion control, or touch screen. Every type of device you want to use will need to have a control layer programmed for it. Libraries exist for all sorts of devices and platforms. You may want to consider OIS for general PC games, as it’s fairly popular and well proven. For Windows games, I highly suggest sticking with Microsoft’s Direct Input libraries or XNA Game Studio. If you’re developing for mobile devices, the libraries are included in their SDKs (software development kits).
Some game objects, such as backgrounds or lighting, can be drawn and forgotten, but others will need to have physical aspects that dictate how they interact with the objects around them. This means including some sort of collision detection and management. Whether it’s a bullet hitting an alien or a player hovering over an item to score points, you’ll need something that can detect these events and trigger actions on a realtime basis.
“Realtime” is the term we use to define the type of math and organization involved in detecting every possible interaction under our 16 millisecond time limit. To achieve this daunting goal, you’ll need to have some good math skills and a way of seeing complex objects in simpler terms.
Not everything is about collisions though. Some games also require objects to have forces applied to them every frame, whether interacting or not. Gravity is the most common force applied to make games feel more realistic, though sometimes the lack thereof can be exciting as well.
Physics is one of the most challenging layers to create for a game engine. From the majority of experiences I’ve read on forums and other developer sites, I’d have to recommend you either keep it extremely simple (as in, represent everything as a box or everything as a sphere), or use a prebuilt library such as Bullet Physics for 3D games or Box2D for 2D games.
For those who simply must write their own physics model, I suggest you purchase Real-Time Collision Detection and give it a thorough reading. Hopefully your brain will remain intact as you do so! I’ll also be expounding on some simpler methods in a later article.
Though not required, multiplayer games have become nearly ubiquitous on PC platforms, and are quite popular on others as well. If you choose to include it, be prepared to add another whole round of programming and testing to get it working correctly. Microsoft’s XNA Game Studio has some nice networking code included that can simplify this for you, or if you’ve gone the Java route you can use the JVM’s built-in networking libraries. For the C++ crowd, you could use SFML’s networking code.
The Massively Multiplayer Online Game is a big catch phrase these days, and although some have been quite successful in launching one, the overhead costs of building and maintaining servers often deters indie developers away from it. To make matters worse, the MMO market is flooded with triple-A developers and indies alike, making it incredibly difficult to obtain visibility with would-be players.
Constructing your game engine is one of the more daunting aspects of game development. Often times you’ll notice even on smaller indie titles that two people were involved in its creation, a developer and a graphic artist. Each task literally represents a different side of the human brain. If you’re absolutely bent on going solo, it will work best if you keep those tasks separate. Write your engine and use dummy graphics to test it; once that’s complete, move on to creating better visuals.
I’ll be placing more technical references on formats and specifications, along with more details of each layer in later articles, so be sure to check them out.
Pages: 1 2