Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Tutorial: Basic Game Design
- Game Idea
- Game Genre
- Game Engine Style
- Game Object Management
- Game Content Management
- Game Deployment
Game Idea [Top]
As a youth I'm sure I drove my friends, family members, and school teachers crazy with my constant discussion of my latest game idea. If you're anything like me, you probably have more game ideas than you have time to explore. As I matured (i.e. got older), I began to realize that having a game idea, even a good one, is only 1% (or 10% if its a great idea) of the total work involved. The other 99% is found in putting the design on paper and implementing the game idea. This is why I decided to create the Basic Game Engine tutorial (and GQE project) to help myself and others bring their game ideas to life.
I have also learned that many great game ideas are based on very simple concepts or principles. At the heart of many of the early first person shooter games was a simple maze. The player navigated the maze not knowing where they were going until they reached the end of the maze. The next level was simply a new maze to navigate with more monsters/people to kill on the way to the end. As first person shooter games evolved, the maze became more sophisticated and open, especially the multiplayer first person shooter games. So as a Game Designer your objective is to find a game idea that is basic enough to meet your ability to bring it to life. If you choose a game idea that is too complex for you to implement you will find yourself like me, rarely finishing the games you start. But before you despair, there are still plenty of variations to existing games that you can implement. So lets begin our discovery process by discussing Game Genres.
Game Genre [Top]
As humans, we like to group things into categories. Game designers are no exception. Over the years the game industry has created a list of Game Genres, which is just a fancy term for game design categories. Recently, I have been focusing on classifying my game ideas according to the game genre they fit best and exploring the differences and similarities between my game ideas and other games in the same game genre. By comparing and contrasting my game ideas to other similar games I can determine if the game is worth implementing in terms of complexity, uniqueness, and overall fun. With so many "Apps" available, it is becoming increasingly difficult to find a new game idea that stands out from the many "me too" applications available. That is why you must take time to develop your game ideas more fully before bringing them to life.
To help you explore your game ideas better I suggest you create a game design document. This document will act as a guide to you and your project members as you implement your game idea. It will also help you think more deeply about your game idea and figure out the game mechanics to your game early on. If you're serious about game development, you should be serious about taking time to develop a game design document before you start implementing your games. Most game companies require this type of document at the very least before entertaining (i.e. paying for) any game idea from their game designers.
Once you have created your game design document, the next step will be to create a basic prototype of the game. During the prototype phase of game development you create the minimum game structure necessary to implement the core mechanics of the game design. The first step in creating the game design prototype is to choose a Game Engine style.
Game Engine Style [Top]
The more games you write the more you realize just how similar they are from the implementation perspective. Even though there are several different Game Genre styles, many of them can be created using the same Game Engine Style. For example, you can create a Tic-Tac-Toe game using the same game engine as an Asteroids game. Even though the Asteroids game might be classified as an Action game and the Tic-Tac-Toe game would probably be classified as a Puzzle game in terms of Game Genre. This means that as a game designer you need to understand different Game Engine Styles and what they can offer in to you in terms of implementing your game design. The following is a list of different Game Engine styles that I have come up with from my years of programming computer games and reading about creating computer games. I would appreciate others contributing to this list from their experiences, so don't hesitate to edit this Wiki page and add your two cents to this section. Each Game Engine style involves different levels of complexity and it would be wise to examine your game design and determine which Game Engine style will fit your game design best. It would be very frustrating to try to fit a basic 2D game using a 3D game engine style. It can be done, but not without a lot of extra unnecessary complexity. For each engine style, I have tried to list how they compare in the handling of the following criteria:
- Object Management -- Management of each game entity
- Content Management -- Management of game assets such as images, sounds, music, etc
- Game Logic -- Handling of the game mechanics or rules
- Game Rendering -- Handling of drawing the game entity images and sounds
If you're a beginner to game design and game programming, this is probably where you should start. The most basic computer game using a Sprite Engine is Pong. Pong is a great beginners game, but I would suggest you start with Tic-Tac-Toe instead for your first game. Tic-Tac-Toe only involves simple input handling and game state logic, but Pong requires movement of graphics in addition to simple input handling and game state logic. There are even several examples of professional games using a Sprite Engine: Mortal Kombat, Space Invaders, Scorched Earth, etc. But I digress, lets define what a Sprite Engine entails:
Object Management: For the Sprite Engine, game objects are usually a simple array of every game object in the game, or a variable for each game object. The variable is usually a simple structure or class that represents the game object. In the case of Tic-Tac-Toe there would be only 10 objects total: 5 X's, 4 O's, and the Game Board. In the case of Pong there would only be 3 or 4 objects total: 2 Paddles, 1 Ball, and sometimes a border.
Content Management: For the Sprite Engine, content is also kept pretty simple. Many times the developer will hard code the drawing of each game object right into the code itself or provide a single image file for each game object. If the developer is really clever, they might even combine the images of all the game objects into a single image file and only draw a smaller portion of this image file for each game object. But management of game content is usually kept to a minimum for this Game Engine style.
Game Logic: For the Sprite Engine, game logic usually consists of hard coded IF/SWITCH statements that enforce the game mechanics for the game. These simple IF/SWITCH statements are often nothing more than simple collision detection or enforced boundaries for each of the moving game objects. In the case of Pong it would be some simple logic to control the movement of the ball to cause it to bounce off the walls and paddles. In the case of Tic-Tac-Toe it would prevent the player from selecting a spot that has already been taken and monitoring when a 3 in a row has been achieved.
Game Rendering: For the Sprite Engine, graphics rendering consists of drawing every game object to the screen during each loop through the game engine. There is often no need to consider what happens to the objects if they go off the screen as many Sprite Engine games don't allow such movements. But even if they did allow such movements, the number of game objects in the game are usually small enough that there is little performance impact in looping through each game object for every loop through the game engine.
As your improve in your ability to create simple Sprite Engine games, you should consider creating a Tile Engine next. There are lots of professional quality games that you can create with a Tile Engine. Some example of great Tile Engine games include: Checkers, Chess, Mario Brothers, Legend of Zelda, Ultima I-VII, etc. But lets define what a Tile Engine is:
Object Management: For the Tile Engine, game objects come in two varieties: foreground and background. Foreground game objects are usually a simple array of every game object in the game, or a variable for each game object. Background game objects are usually some sort of map or multidimensional array for every square in the game world. This added complexity must be managed better but is easier to learn and work with than other Game Engine styles.
Content Management: For the Tile Engine, content begins to be more of an issue. Usually a large single image containing all the background squares is loaded into the graphics card and used to draw the background for each iteration in the game engine loop. If the graphics card can handle it, a second large image is used to hold all the foreground game entity images if space is not available on the large background image. Besides the correct handling of these large images, content management is not much more complicated than the Sprite Engine.
Game Logic: For the Tile Engine, game logic handling also increases in complexity. Because the game world is usually much larger for Tile Engine based games, game logic takes considerably more time during the Game Engine loop. This is often because there are more game object entities moving around in these types of games. The more entities you have, the more chances for them to interact/collide with each other. This makes it harder to implement the game mechanics of your design. It is not unusual for game developers to consider implementing a scripting engine to make changing the game mechanics easier, but I don't recommend this until after you have created a few simple tile engine games first. The added complexity of incorporating a scripting language into your game engine might be too much and yield less benefits than originally thought.
Game Rendering: For the Tile Engine, graphics rendering becomes a huge bottleneck if not done correctly. There are several threads in the SFML forum that can help you do this right. The naive approach is to just loop through your map and draw each background tile sprite individually according to your map information. The problem with this approach is that it will consist of drawing over 768 sprites (32x32 pixel tiles on a 1024x768 pixel screen) for each iteration through your game loop and this doesn't even include drawing your foreground sprites yet. If your background tiles are in any way animated you may not be able to avoid this high cost. Another approach is to draw all your tiles to a large image first and then render this image and your foreground images last. This way you can just move this large image around as your foreground game entities move around on the larger game world. This reduces the redrawing of your 768 background sprites to only when your foreground game entities have moved at least 2 tiles in any one direction, and even then, you might be able to copy a portion of this large image on only redraw the new edge in the direction they have moved. But in any case this Game Engine style is more complex than a simple Sprite Engine style.
I'm sure many of you are wondering what I mean by Storybook Engine. There are several professional games that use a Storybook engine: Kings Quest series, Police Quest series, Space Quest series, Myst series, etc. Now that I have given you a few examples, you're probably hitting yourself in the head thinking "Oh, those kinds of games". I will admit that I am a really big fan of these kinds of games, but I was never very good and completing them without a walk through of some sort. For the beginning developer who has created a few Sprite Engine games, this is also a great engine type to consider. The ever popular Hidden Object games could also be created using this type of Game Engine style.
Object Management: For the Storybook Engine, game objects also come in two varieties: foreground and background. Foreground game objects are usually a simple array of every interactive game object entity for each screen in the game. Background game objects are usually nothing more than eye candy for each screen in the game. Object management is usually not as complex in the Storybook Engine as in the Tile Engine.
Content Management: For the Storybook Engine, content is even more of an issue than with the Tile or Sprite Engines. Usually the content behind the Storybook Engine consists of larger image elements that need to be displayed. With the Tile Engine, each screen is composed of smaller identical images that are repeated over and over again, but with the Storybook Engine, entire screens of images are displayed along with several larger foreground images too. But often the foreground and background objects are stationary and waiting for the user to interact with them, even if they are animated. This usually makes them more difficult to manage when your target platform has less than ideal graphics card support, but it is possible to manage.
Game Logic: For the Storybook Engine, game logic handling can either highly complex, or extremely simple. Most Storybook engines have a scripting language that allows the entire game to be changed by just changing the script and content. This is because most newer Storybook Engine based games are nothing more than point and click games. Game Logic ends up being nothing more than keeping track of which objects the player has picked up and advancing the player when s/he applies the correct object on another game object in the game. This game engine would benefit greatly from using a scripting language and time should be taken to implement a scripting language into the game engine since the Storybook engine rarely changes from one game to the next.
Game Rendering: For the Storybook Engine, graphics rendering can become a bottleneck if not managed correctly, but since the Game Logic is fairly easy, you usually won't need to optimize the Game Rendering too much. It is probably a little more complex than the Sprite Engine rendering, but less complex than the Tile Engine rendering.
First Person Shooter Engine
The First Person Shooter Engine is where many budding computer game programming enthusiasts try to start. This is largely because of their popularity in today's games. But in terms of complexity, the First Person Shooter Engine is very complex, especially in the multiplayer versions. If you're serious about creating a First Person Shooter game, I would strongly recommend you consider starting with one of the many open source First Person Shooter Engines available online. Id software has lead the way in providing the source code to many of their First Person Shooter Engines.
Object Management: For the First Person Shooter Engine, game object management becomes a very big deal. Its not that there are more game objects in the First Person Shooter Engine than in other game engines mentioned, but that the game objects must be kept in strict graphics rendering order at all times during each iteration through the game loop. Today's First Person Shooter games are even more complex than they were 10-15 years ago when they first came out.
Content Management: For the First Person Shooter Engine, content is probably only slightly more complex than with the Tile or Storybook Engines. Content for the First Person Shooter Engine can either be simple or complex depending on the goals for the game engine. I think most players would agree that have great game play and level maps is more important than having great content. But if you can have both, most players would like that too.
Game Logic: For the First Person Shooter Engine, game logic handling can be very complex compared to the other engines mentioned. The reason for this is that First Person Shooter Engines must deal with 3 dimensions, not 2. Some of the earlier First Person Shooter Engines were specifically designed to only work in 2 dimensions because the hardware didn't support the complexity of working in 3 dimensions. This is not typically the case anymore for today's First Person Shooter Engines. The most complex aspect of Game Logic in this game engine style is usually dealing with collision detection of the bullets/rockets/etc. But a lot of attention must also be spent in making sure objects remain in correct rendering order as was mentioned earlier.
Game Rendering: For the First Person Shooter Engine, graphics rendering is probably the most complex of all the game engine styles mentioned. In order to reduce the amount of time spent rendering each frame, a great deal of effort must be made to determine which game entity objects should be rendered and which ones should be skipped. This sorting of objects must be either done in advance (for the stationary background objects like walls, tables, stairs, etc) or at run time (for the foreground objects like blood splats, body parts, windows, etc) as the game is being played. It is even more difficult if you add multiplayer capabilities to the engine.
The difference between the Simulator Engine and the First Person Shooter Engine is probably pretty small. Simulator Engines are often stronger in the adherence to real Physics than many First Person Shooter Engines. Examples of Simulator Engines might include: Tiger Woods Golf, Flight Simulators, Football Simulators, etc.
Object Management: For the Simulator Engine, game object management becomes a very big deal. Its not that there are lots of objects to deal with in a Simulator Engine compared to the other game engine styles, but that each game object is accurately represented in terms of its physical properties. Without modeling each game object correctly, you won't get results that come close to matching real world Physics. It is not a surprise that today's First Person Shooter Engines are quickly converging with yesterdays Simulator Engines in terms of complexity and accurate representation of real world Physics. But sometimes is just plain more fun to play a game with fake Physics than real Physics.
Content Management: For the Simulator Engine, content is probably the same as that of the First Person Shooter Engine. The only primary differences are that more attention is paid to accurate lighting for the Simulator Engine than the First Person Shooter Engine.
Game Logic: For the Simulator Engine, game logic handling must be handled even more precisely than the First Person Shooter Engine. The reason for this is that computers store "Real" numbers poorly and because of this, errors build up quickly and cause problems with your real world Physics calculations. First Person Shooter Engines also only allow 2 degrees of freedom in terms of movement, but Simulator Engines often have 6 degrees of freedom for the player to utilize. This complicates the math involved in performing collision detection and other aspects. In addition to this, a lot of attention must also be spent in making sure objects remain in correct rendering order as was mentioned earlier.
Game Rendering: For the Simulator Engine, graphics rendering is probably even more complex than the First Person Shooter Engine. In order to reduce the amount of time spent rendering each frame, a great deal of effort must be made to determine which game entity objects should be rendered and which ones should be skipped. This sorting of objects must be either done in advance (for the stationary background objects) or at run time (for the foreground objects) as the game is being played. It is even more difficult if you add multiplayer capabilities to the engine.
Multiple User Dungeon (MUD) Engine
The Multiple User Dungeon, or MUD, Engine is often thought of as the precursor to the Massive Multiplayer Online Role Playing Game Engine. The reality is that most MUD Engines grew from the Text Engine games in the pre-internet era. Most of the effort in this Game Engine style is improving the content experienced in the game itself rather than the graphics or other aspects of the game.
Object Management: For the Multiple User Dungeon Engine, game object management is probably the most complex of all all the games mentioned previously. This is because by its very nature, multiple players are allowed to enter the game at the same time. This makes game object management particularly important because you might have multiple people trying to pickup the same object at nearly the same time. Not to mention the sheer size of the game world being shared by all these players.
Content Management: For the Multiple User Dungeon Engine, content management is probably the most complex of all the games mentioned previously. This is also because your players can consume (explore, experience, pickup, etc) more game object entities in a period of 1 hour than each player could consume if they were to play by themselves. Content management becomes complex because you must constantly produce new content to satisfy your players or they will invariably move on to the next hottest game.
Game Logic: For the Multiple User Dungeon Engine, game logic handling is only complex in that you must take into account the handling of multiple players who are attempting to access the system at the same time. Usually the game mechanics/rules are not very complex, but the timing of player events and the keeping of the global game state is pretty hard. Many MUD Engine's employe a database approach to deal with the shear number of game objects and users because it quickly becomes too difficult to manage at the players computer. This makes the complexity more manageable for the game company.
Game Rendering: For the Multiple User Dungeon Engine, graphics rendering is probably equal to that of the Tile Engine. The reason for this is that the Game Logic and Game Object management is what provides most of the content for the game, not the eye candy provided by the Game Rendering system. Most players care more about having something new to explore than what it looks like while exploring. Although the recent MMORPG games are changing this perception.
Massive Multiplayer Online Role Playing Game (MMORPG) Engine
As was indicated earlier, many Multiplayer Online Role Playing Game Engines were originally based on the MUD Engines of yesterday. The primary difference is the shear number of players allowed to play these games simultaneously. Examples of these games are: Everquest, World of Warcraft, Star Wars Online, Ultima Online, etc.
Object Management: For the Massive Multiplayer Online Role Playing Game Engine, game object management is probably the most complex of all all the games mentioned, even more than the MUD Engine. The reason for this is it becomes impossible to handle the number of simultaneous players in the same location. Therefore, players are separated into multiple virtual locations to keep the game engine complexity to a minimum. In other words, you might have several players that can see each other in World XYZ, but there are also multiple identical versions of World XYZ. Some players will be assigned to World XYZ A and others will be assigned to World XYZ B. To the player, they seem to see the same World as their friends, but might not be able to see each other while playing the game (please correct these statements if not correct). If game object management was complex in the MUD Engine, its even more so when you add a couple million more players to the game world.
Content Management: For the Massive Multiplayer Online Role Playing Game Engine, content management is even more complex than the MUD Engine. Players can consume entire worlds of brand new content that took developers 6 months to 2 years to develop in a mere 24 hours. Managing all of the content produced by the developers and deploying it to your players simultaneously can be a great challenge for these types of games. It is a very difficult thing to produce enough content to satisfy all of your players and so you need to find other ways to keep them occupied while you work on the next great level for them to explore and conquer.
Game Logic: For the Massive Multiplayer Online Role Playing Game Engine, game logic handling is only complex in that you must take into account the handling of multiple players who are attempting to access the system at the same time. Usually the game mechanics/rules are not very complex, but the timing of player events and the keeping of the global game state is pretty hard. In addition to this, you must also provide similar handling of game objects in rendering order as experienced in the First Person Shooter Engine games. This can make this game engine more difficult to deal with than the MUD Engine.
Game Rendering: For the Massive Multiplayer Online Role Playing Game Engine, graphics rendering is probably equal to that of the First Person Shooter Engine. This is because you usually need a lot of eye candy to keep the attention of your players compared to MUD Engine players. Especially after your players realize that they have explored all the content available to them in the game.
In summary, I would say that there are several different Game Engine styles being used in today's games. The key thing to remember is to use the right Game Engine style for your game design. And don't be afraid to try something new that none of us have considered. After deciding on which Game Engine style you need for your game design, your next objective should be to figure out how to manage all of your game objects and that is what we will discuss next.
Game Object Management [Top]
Game Content Management [Top]
Game Deployment [Top]
Please feel free to comment on the above topics and give us some additional insight in how you come up with your basic game designs and bring them to life. How do you stay motivated enough to get your projects completed?