Entropy Interactive

Designing the Game

The first step in creating a game engine is designing it. To do that we must decide on what the engine will do. This may seem simple, but it is the most common place for new game engine programmers to make a critical mistake, unfortunately dooming their entire project. That mistake is being to general. Game engines that try to do everything rarely get finished, and an unfinished engine often doesn’t do anything at all. We are going to try and avoid that pitfall by being much for specific in our design.

There are many different ways to focus the design of a game engine. Choosing one genre of games to design your engine around is a good start. It focuses the functionality of your engine down to a smaller subset of features. The less features that need to be implemented, the sooner (and therefore more likely) you will finish your game engine. We, however, will go a step further. Our engine will be designed to run just one specific game.

That may seem to contradict the idea of game engine re-usability (which is the whole reason we are making an engine rather than just a game), but even two very different games often share a lot of the same code. There will still be a few parts of the engine that just will not fit in to another game, but if you were to design an engine to do everything, I can guarantee that there would be a lot more than a few parts that would go unused.

The Game

Now it is time to choose what game we will build our engine around. It is a good idea to pick something simple (an MMORPG would be a very bad idea). Tetris and Packman are common choices; however I am not going to use those simply because I find them rather boring. Instead I will be designing my engine around Asteroids.

Asteroids is a simple game, but it will provide an excellent example on how to design a game engine. We will be making a few changes to make the game more interesting and to learn about a few more areas of game engines.
Now it is time to define what features our game will have. This is a very important step because this will also define what our engine will need to do. I will make a simple list of the features that I want to include, but I encourage you to think of some additional features to try and include into your game.

• Vector graphics: I will keep the appearance of the game similar to the original Asteroids. Ships, asteroids, and aliens will be drawn with strait lines. There will also be text that will be displayed.
• Ship upgrades: The SS Triangle will no longer be limited. There will be additional weapons, engines, and other upgrades available to the player.
• Shields: The game will incorporate a shield system to the ship. They will be able to deflect asteroids and block enemy fire.
• Physics: When your shields deflect a rock, it will bounce off, sending your ship in the opposite direction. Your ship will also will accelerate and decelerate in a realistic fashion. The same rules that apply to your ship should also apply to other objects.
• Infinite universe: Your ship will always be centered on the screen and you will be able to fly in any direction as far as you want. This will take some work dealing with the creation of new asteroids among other things, but it should add some uniqueness to the game.

Modules

We will be dividing our engine into a group of components called modules. Each module will have a specific function. We will try to keep the dependencies between modules to a minimum. That will make the engine more reusable. Here is a list of the modules that we will need.

• Graphics: Drawing and window control.
• Sound: This one is pretty obvious.
• Input: User input from the keyboard and possibly mouse.
• Physics: Something to deal with the simple physics in our game.
• Math: This will be important for a variety of area, graphics and physics in particular.
• Files/Resources: Saving and loading game data.
• AI: The aliens may not be able to beat Garry Kasparov at chess, but they will need to be a legitimate threat to the player.

This is not necessarily the final list. More modules may be added, combined, split, subdivided, removed, bisected, blow up, and other things which I can’t even imagine at the moment.

Programming Language

The language I will be using for this game engine will be Java. I chose Java for several reasons.

• Familiarity: I am familiar with the language and comfortable programming with it. That is always an important thing to consider when creating any program. Rarely, if ever, will you be able to do something in one language that you couldn’t do in another. It is therefore a good idea to pick a language that you know well. Some things are, however, easier to do in different languages.
• Garbage collection: I am trying to create a game engine that is as simple as possible. Garbage collection is one of the most difficult things to get right, especially for a new programmer. By taking that out of the picture, creating the engine will go much faster and smoother.
  Object oriented design
• Object oriented: One of the best things you can do for a game engine is make it object oriented. Objects are an excellent tool to create abstraction, which really is the goal of a game engine. They also help to make your code more expandable and maintainable, two very important aspects of a game engine.
• Cross Platform: Java is a cross platform language. If you are running Windows, OSX, Linux, or any other operating system, the code should (theoretically) run the same.

There are other reasons that I chose Java, but those are the most important. The IDE I will use is Netbeans. None of the tutorials are specific to Netbeans, so you are free to use whatever tools you want. There are many other Java IDEs out there, and I recommend you try a couple before you choose one.

My coding style falls pretty close to the general excepted conventions for Java. There may be a couple smaller differences, but rarely will you find something that looks completely unexpected. I would suggest to all programmers that they should (if you haven’t already) read up a bit on general coding conventions. It makes it much easier for others to understand your code when you need help.

-Eric