How to Begin Programming Your Game - Part 1
Just got done coming up with a great game idea? Ready to sit and and start writing the code but don't know how to start doing it because you've never written a game before? Then this article is for you! I was you once, not too long ago, and I'm here to share with you what I've learned so you can skip the pain and agony I had when I started trying to first program a game. This article is part one of a series. The series is focused on helping a person writing a game for the first time to avoid a lot of the pitfalls many programmers fall into when doing this very thing. I hope to help others by passing on my knowledge.
Who This Article Series is Meant For
This article series is meant for the person who has a good grasp of C++ and is ready to write the program for their first game ever. It's going to use things like pointers, classes, inheritance and polymorphism. If you don't understand these things very well, brush up on your knowledge. It will make things a lot easier to understand. It is also intended for a person who is going to program from a basic library, in the case of this series SFML (SFML 1.6 to be exact). The ideas will translate to just about everything, but the details of code presented will probably only apply to C++ and SFML (and the SFML stuff disappears into the behind-the-scenes realm anyhow). It's also going to be done in Microsoft Visual C++ 2010 Express. Source code files will be provided where applicable, I'll leave it up to the user to adapt them to their own devices.
Why I'm Writing This Series of Articles
When I first started trying to figure out how to actually go about writing a game, I had the hardest time trying to find relevent and useful information (my googlefu sucks so I might just be a unique case). I found lots of articles and videos that spoke in vague terms, and most of them were pretty adamant on showing zero example of any actual code, which is what I was after. I just wanted to see what they did and why they did it so I could gain an understanding of what is suppose to be going on. That is the goal of this article series. Clear the mud and lift the fog of confusion by showing you, the reader, a basic and easy to use possibility of structuring your game code so you can avoid the hassle and terror I went through.
Disclaimer
This is ONE possible way of structuring a game. With any program, there are many ways to get the result you want. This is the way I've developed after a lot of work. It started off with me basically flailing about, then going on to make the God Object, then functions that branched out of a function, and then finally doing things that made real sense until I came to what I write here. It works for me. It will certainly help someone just starting out. I think it keeps the code nicely structured. That said, I'm sure someone somewhere is going to think and possibly even tell me I'm a dolt for doing things the way I do. Perhaps their right, perhaps their not.
What This Article Series Is NOT
This article series is not a guide to writing the specific details of the game. Things like collision detection won't be covered, or how to create an inventory system. Some of these things, like collision detection, will be present in source code files but the focus of the series is getting the framework and essentials down and working so a new game programmer has an idea of how to get started writing the code for their game.
I've Got a Game Idea, How Do I Start Writing the Code?
The First Step
The first thing you will want to do is immediately open your IDE of choice (Microsoft Visual C++ 2010 Express in my case) and immediately start hammering out beautiful lines of code. DON'T!!! I'm guilty of this myself. Sometimes it's OK to do, most of the time it's not. Some examples of when it is OK to do is if your project is small, could be done pretty quickly, and you have experience doing what you're going to do. Otherwise, you will probably end up programming a logjam that you won't be able to understand very well once you're done. There are examples in the Coding Horrors forum.
Sometimes when I'm trying to think of how a function will work I will open up a new random project and just start hammering things down. I think best about how to program something when I'm in the thick of trying to program it. On the whole though, if you try to write the entire game like this it will take longer and be a mess. I also do this less and less as time goes on (and have turned more to getting out my old school reel lawn mower and getting some sun and exercise).
The first thing you really should do is get a pencil and a blank sheet of paper and start thinking how the game is going to be structured from the user's view. I just found out about a website that is absolutely WONDERFUL for this called WorkFlowy. I suggest you check it out and give it a whirl. I think you will be happy you did (no I don't work for them or anything like that).
Identifying Your Game's States
Once you have your choice of putting thoughts to paper/transitor, start thinking about the first thing that is going to happen when the player starts your program. For most games, they get one (or a few) splash screen and movie intros. So make a note of that if you want it.
After that they go to the title screen, where you will either be met with a worthless screen where it's only purpose is to show you something until you push a button which will bring you to the REAL title screen (talk about a waste). Here you will be presented with options, such as start a new game, go to the options, load a saved game, and quit.
Each of these options are a different game state. It is a form of existence that your game could take that is distinctly different than another form it could take. It is the same as water being a solid state, liquid state, or a gaseous state. It's all water, but it exists in a form that is distinctly different than the others. It's behavior is differnt, it reacts differently to things, and things react differently to it.
The introduction splash screens are distinctly different in how the player interacts with them, the data it contains, and the functions it is doing behind the scenes. The title menu state (discarding the useless push a button screen) is a fork in the road. It could lead the player to many different states. It could take the player to the state in which they are trying to load a save game, or to the state where they fiddle with the settings, or it could take them to the meat and potatoes of the whole program, the actual game section of your game program.
Each of these are a state of being for your program. They look different, they behave different, they are different internally, and they are dealt with differently by the player, but they are still your program. Now begins the example game development. I will be making a rather simple game of Invaders from Space. Don't confuse it with that Atari game, I swear it's drastically different! Really! (OK not really). This is what I have so far:
Invaders from Space!
1) Intro state -shows introductory splash screen
2) Title Menu -has buttons for a new game, show high scores, and quit. -new game button goes to the main game state -high scores opens a sub state that gets and displays the high scores -quit will exit the game
3) Main Game -Fight the invaders from space until they are all destroyed or you have lost. It's kill or be killed!!!Now, go into each state and do the same thing. When starting a new game, what is the first thing the player encounters?
Identify Sub-states or States within States
In Invaders from Space, when the player begins a new game they will get a count down and then the action will begin. They will be able to move left by pressing the 'A' key and they will be able to move left by pressing the 'D' key. They will be able to shoot by pressing the space bar. They will only be allowed to have one projectile in existence at a time because they believe in extreme recycling or some such.
If the player pushes escape, they will engage the temporal freezing device, otherwise known as pause. The invaders will start at the top and execute the brilliant attack strategy of move one direction until they can't move anymore, stop, move down, then reverse course. Every once in a while they will increase speed to throw off the daring defender of the world.
This will continue until either the player manages to ward off the technologically superior invaders from space or succumbs to their overpowering might. If the player is defeated, they will be met with a screen that tells them they were defeated and asked if they would like to try again. If the player wins, then the game will check their score and if it managed to get on the list they will be asked to enter their initials. After they enter their initials they will be asked if they want to play again.
How many substates are there in this description of the main game state? Go ahead and go back through it and count them, I'll wait. Done? Good. The answer is seven.
- The warmup state,
- the battle state,
- the pause state,
- the defeat state,
- the victory state
- the entering initials into high score state and
- the play again question state.
The play again question state could even be a sub state of the defeat and victory states. Each of these are a state because the basic functions of the game have changed, both in how the player is interacting with the game and what is going on internally. It's OK to be generous with your game states. I don't think many people would consider the victory and defeat states to actually be another state, but you will see in the future why it is advantageous to be generous in your state assignments.
A Bigger Example
In a game I'm working on, the player is able to do research. Clicking research opens a state. Here they are presented with options for doing different types of research. Clicking one of those options will open a new state, or close the current state. In each of those they will be presented with more options, which will open another state, so on and so forth. The research state is comprised of some 30 or so states that reside inside of it or inside of it's sub states. I'm not done working out exactly how research works yet, but this gives you an idea of how generous I am with divvying out the title of game state to a portion of code.
Conclusion
After you have thought up and fleshed out your game design, the FIRST step to writing the code is thinking out and fleshing out your CODE design. Find places where your program is going to be doing things that set it apart from the rest of what is going on and it's the only thing it is going to be doing at that point. It might seem like a hassle, but it will save you many more hassles in the future.
Sit down and think through the game. Identify the different states that it will exist in and where those states are. They could be anywhere and everywhere. It will make more sense in the future articles on why these game states are so important. Part two will delve into what is typically the first line of code in my program after int main(), something I dub, for lack of a better work, The Game Engine, not to be confused with what everyone else calls a game engine (well it is, kind of, but game engine typically invokes tons of technical bits and lots of work in people's minds when they read the words 'game engine').
Here is what I came up with for a program flow in WorkFlowy.
