Game Ideas

Talking about the game concept for a game like Pong seems to be a little ridiculous, but I will try to keep things as general as possible. The important thing is that you think about what the game should look and feel like before you start coding. The bigger the game project is, the more important the design phase is. I’m not saying that you can’t write games or applications without any concept at all. In fact, most beginners will just start writing something and then improve it again and again until it looks good. The problem with this approach is that it is highly unlikely to find the best solution on the first try.

The game logic is very simple and it does not require much text or graphics (see Figure 2-1). This makes both the game code and your concept very simple to write. Just think about all the components required for this game (ball, paddles, and the screen borders) and write down your initial ideas.

Figure 2-1

Write Down Your Ideas!

Writing a concept does not necessarily mean you have to write down all your ideas, draw UML diagrams like crazy, and only start working when everything is fully planned. I’m completely against that approach because you can’t know how everything will work out. Additionally, beginners probably have no idea what the best way is to design a full game up front. Instead you can have a very clear picture of the game in your mind and after you think you have spent enough time on the design in your mind, you can start working.

If you have other people working on your game project too, it becomes harder to explain ideas and keep everyone in sync. Just for this reason alone you should make it a habit to write down your game idea on just one single page. You can not only show this to other people and get more input, but you will also think about things while writing down some parts of your game idea - and when you see it on paper it might seem more complex than in your mind and you have to think about additional dependencies.

For example, for your Pong game you know that you need two paddles and a ball, which moves between the paddles. But maybe only after you write down the initial ideas and think about the sprite textures might you think about the more detailed game play - how many lives does each player have, how do you find out if the ball hits the paddle edges, and how do you handle that? Does the speed of the paddle influence the ball speed and direction? What about increasing the ball speed after a while to speed up the game if both players are bored? Sure, many of these things can be improved after you finish the first version of your game. But it is a lot easier to take all these things into consideration before you write complicated code and then later see that you don’t even need that.

As an example, I will write down the design concept for the Pong game you will develop in this chapter. You might want to take 5–10 pages for more complex games, but don’t write 100 pages of concept text without coding anything. It will take too much time and it will get very hard to manage the concept. For the Agile Methodology you will often update the concept and change details. I usually don’t start with UML diagrams until at least 50% of the code is done, and the overview diagrams and the documentation gets updated later when the project goes final.

Game Idea: Pong

The game is a simple Pong clone for one or two players. In the singleplayer mode the computer will control the other paddle. In the multiplayer mode, two players can either control their paddles with two gamepads, with different keys on the keyboard on the same PC, or on the Xbox 360 console.

The game features a few 2D graphics for the ball and the paddles and a few sound files for the ball hitting one of the paddles or for losing a life. There is a very simple menu allowing you to select the following:

• Singleplayer

• Multiplayer

• Exit

The menu is implemented with a simple texture, the background is just a dark space, and most graphics are bright. You will try to make the game as much fun as possible.

Features and Game Play

The game has two screen modes: Menu and Game. The menu just contains the menu items that were mentioned in the preceding section, and the game consists basically of the ball and the two paddles and a simple scoring system. Take a look at a simple drawing for what you are trying to accomplish (see Figure 2-2).

Figure 2-2

Technology

Obviously you are going to use XNA Game Studio Express; there are no additional libraries you are going to use and because you will just render some simple sprites, there are no 3D models or shaders involved here. The game should run on both the Windows platform and the Xbox 360 console.

As you can see I managed to fit everything on a single page, which is one of my rules I use when I write game concepts: First fit everything on one single page, then get a little bit into coding and if required by your team or an external partner (for example, if you want to show the concept to a game publisher), write a whitepaper with 5–10 pages from the initial idea and add some early sketches.

I never talked about the programming itself in the concept; I just made sure that you know which technology to use. Now it is time to think about the implementation. Don’t think about your abilities when writing the game concept, it will just limit you too much. Keep it in the back of your mind.

A more complete example of a game concept is the Rocket Commander concept (see Figure 2-3). You can check it out from the PDF file in the directory for this chapter. It contains four pages and a cover and it features all the ideas for the Rocket Commander game. As you can see from the cover, the game looks very different from the concept, but the general game ideas are there.

Figure 2-3

Agile Methodology

The Agile Methodology is a conceptual framework for software development. The basic idea is to avoid big planning phases, which can often lead to risky and unrealistic project schedules that are hard to keep. For smaller projects you will use short time iterations anyway, but as projects grow bigger you might see yourself standing in front of problems that require months or even years to finish, and that is very hard to plan.

Instead of planning everything down to the most detailed level, only a very rough concept is done. Each part of the concept is then iterated through the agile process of planning this feature in greater detail, designing the code with help of unit tests, then doing the actual code implementation, and finally testing and documenting this part. This iteration should not take longer than a few weeks and is repeated for all parts of the big project.

Agile methods also include some other ideas about working better together, teaming up developers with the customers, testers, managers and designers, and so on. There are several rules that can be used to bring some structure into this agile framework to avoid having total chaos. Because of the shortened planning phase it looks like there is no detailed plan for the project, similar to a chaotic brute force coding approach. But in reality the planning process continues throughout the whole project and is much more useful than planning everything just at the beginning and having to live with all the mistakes made in that stage for the whole project.

I will not talk much about the Agile Methodologies in this book, but I will use unit testing and the short concept first, unit test design, then code iteration throughout all projects in this book. If you want to read more about unit testing I recommend reading the website of Martin Fowler at http://martinfowler.com.

Martin has also written several books and I can recommend his Refactoring: Improving the Design of Existing Code book, which you can also find on the website. You can find many more links and information about the agile software development process on his site too.

Solving Initial Difficulties

Ok, now you have an idea about your game, but you have not spent much time about where you get the graphics from, what you do about the sound files, and how to implement them. What about the problem with the ball hitting the sides of the paddle? Do you even need a simple physics engine for the ball?

All these questions usually arise after the design phase and for more complex projects it can take weeks, if not months to just figure out some of the basic problems. For example, the first .NET 2.0 game I did was Rocket Commander and I had a nice idea to have thousands of asteroids on the screen, and millions in the level as a whole. I had some cool ideas about letting them collide and bounce off each other; it was not really clear how to implement it in an optimized manner. After some initial tests I found out that I couldn’t even render 100 asteroids without a significant performance drop. Instead of rewriting the game concept and making a really boring game without many asteroids at all (which is the game principle of Rocket Commander - without the many asteroids you don’t really have a game at all), I tried to solve this problem by rendering a lot of asteroids sorted by shaders and material settings, doing very early skipping of asteroids if they were not visible, and having the physics only apply to the nearby asteroids.

Even after working and optimizing the asteroids for a week until they rendered at a great performance, the physics were still way too slow. Just updating 5 to 10 thousand asteroids in viewable range every single frame to see if any of them hit any other asteroid was just way too much, even with the best optimizations applied. I still wanted the asteroids to collide and behave correctly after collisions. If I did just check a certain amount of asteroids each frame, the algorithm often missed collisions and only caught up when both asteroids had already penetrated each other, causing even more troubles than removing the physics altogether. I was close to giving up because I had already spent 50% of the total project time just solving this single problem, but then I got the idea to separate the space into sectors. Each sector had a certain amount of asteroids and every time an asteroid left a sector it was removed and added to the new sector. For collision checks asteroids had only to check their own and all neighboring sectors, which still sounds like a lot of collision checks, but the sector logic did improve the physics performance by a factor of 100 and even more after more optimizations.

In most game projects I do nowadays I spend more than half of the time solving the initial problems and then dividing them up into smaller problems, which again have to be solved. The game itself is then later assembled by just putting these pieces together, and almost like magic the whole game is done in a matter of days. Though this is the best approach to finish a game as quickly as possible, it can be frustrating to see no results for a very long time, and in the past I always iterated the game until I was pleased with the results. This did take a very long time. Thanks to the agile development process, I’m now able to work on the problems and not iterate an almost endless loop of improvements.

What does this mean for your Pong game? Well, the game is very simple and you won’t spend a lot of time improving it 100 times. But say you just implement a basic version of Pong with a hard-coded paddle for the computer on the left side moving up and down depending on the ball position and controlling the right paddle. Then later after improving and testing the single-player game you might want to add 2-player support and it gets hard because you hard-coded the computer code. You might comment the computer code out or even remove it and restructure the game play code. Then a little bit later after testing the 2-player mode you might want to add the menu and again you have put the code at a different location, re-implement the computer game code, and so on.

Though this is all good practice and forces you to refactor (refactoring means changing the layout of your code without changing the functionality to improve maintenance; see Martin Fowler’s book, Refactoring) it is a lot easier to just focus on one part of the game at a time and have several game versions and tests running side by side. You will do exactly that in the next part of this chapter, and hopefully you can grasp what I mean. Refactoring will occur more naturally and makes your code more usable and lets you see the result much quicker thanks to unit testing.

One of the problems you will solve in the next part is how to handle the ball physics and how to detect which part of the paddle you hit.

Creating Some Textures

Before you start coding you need some textures to display stuff on the screen. Even if you use dummy bitmaps here or get some graphics from somewhere else, it is still important to think about the final graphics, which dimensions the ball and paddles should have, and things like that.

Again for your Pong game it is pretty simple, but more complex games might require an art concept, a lot of sketches and someone who has a good idea how to manage all this artwork and how to get them all done in time for the game programmer to implement them. Back in the early days of computer games almost all games were created by one individual, and though this is the easiest way, today no serious game is developed by just one person. Most good artists are not programmers and most programmers are not good artists. If you do a simple game it does not matter so much, but the bigger your project gets, the more time you will spend with finding teammates, skilled artists, and modelers and putting everything together.

Take a look at the graphics for your game (see Figure 2-4). You will use three textures: (1) PongBackground.dds for the background, (2) PongMenu.png, which contains the logo, menu items, and all other texts for your game, and finally, (3) PongGame.png for the paddles and the ball.

Figure 2-4

Additionally you will import two sound files (PongBallHit.wav and PongBallLost.wav) into your project and add a simple XACT project to play the sounds. To learn more about sounds and XACT, please read Chapter 9.