Making Space Invaders in pygame - Part 1

The goal of this guide is to teach you a general process for cloning simple 2D games which will be helpful when you try to build and document your own game design for your A-Level Computer Science project. I'll try to go through the whole process here, but I will also try and link out to other helpful resources as we go in case you want more information on a particular subject. Anyway, let's get stuck straight in.

Research - What is Space Invaders?

It was one of the big hits of the late 70's and early 80's in video gaming, which is going back to even before I was born, when many people went out to an Arcade to play games on purpose built machines and the second generation of video game consoles was just being released. Space Invaders was especially popular on the Atari VCS, the first Atari game console to play multiple games (the first Atari console could only play Pong).

What did it look like? I hear you ask. Like this:



Which gives us a general idea of how it plays, but I think it also helps to see the game in motion so have a look at this video on youtube as well:



Two slightly different versions of the game there, I think the picture is from the home console version while the one on youtube is from the arcades originally as it has the extra 'credit' text which is usually used to show how much money you've pumped into the arcade machine and thus how many goes you can have on the game. Yep, people used to shove pennies and pounds into machines to play only until they died. Imagine how that affected the design of the games that were made...

There is no better way of getting a feel for a game than playing it however, so hopefully this will work too:



It should be arrow keys to move and space bar to fire.

Breaking down the design

All done playing? Good.

The big advantage we have when cloning an already existing game over designing a new one is that we know that the game's design is already possible to make because somebody already did it. While we don't know exactly what their code looks like, we can have a go at dissecting the game into smaller pieces and make some guesses as to how they work. Usefully, that is also the same process you'll need to go through with your own designs when taking them from ideas and sketches down towards the reality of code.

Let's start by looking at the picture again, but this time picking out all the different, interesting parts of it and giving them names:



I made that image by scribbling on the original using the General Image Manipulation Program, or GIMP for short - which is a free, open source paint program available from it's website here. Though many other paint programs are also available. I also used a drawing tablet I have lying around because my old man hands aren't as steady with the mouse as they once were.

The point of drawing over a picture is that it helps us think about the game as a collection of different, simpler parts and makes the process of recreating it a bit more manageable. Instead of 'How do I code Space Invaders?' we can ask ourselves a series of smaller, less taxing questions like; 'How do I code a score counter?'. Designing our code in this way will also help us keep it more organised, automatically.

The next useful step is to pick out each of those things we identify in the 'picture scribble' stage and see if we can break them down further by guessing how we might build them out of python data types and methods. It's not important that you figure out everything about how the game is going to work at this stage, it's just nice to have a broad outline and something to start from. The iterative design process is all about updating your design as you start implementing, testing and learning new things.

I think UML (Universal Modelling Language) class diagrams are a useful tool at this stage for documenting what your design thinking is. Though some explaining words around your diagrams are also useful. I use this online tool to make my diagrams. You can churn these out pretty quickly and if you save the 'code' you use to make them in the online tool somewhere then it's easy to go back and modify them later. Here is an example of my class diagram code for the ScoreCounter: 


[pygame.Sprite]^[ScoreCounter {bg:slategrey}|score: int; image: pygame.Surface; rect: pygame.Rect|_redraw_image();add_points(points: int); reset()]

Which looks like this:



Since the score counter is some pixels (though in the form of text) with a position on the screen I thought it was a good candidate to use pygame's sprite class . I also noticed that it has an integer number featuring prominently that goes up when aliens get shot so I thought a 'score' variable and an 'add_points()' method might be useful to keep track of that data and respond to the events.

Figuring out good class design is a skill that comes with experience, so don't worry if you aren't sure what to put at first, make guesses where you have an idea and leave things blank if you don't know, we can revisit these diagrams and the design they represent throughout the process of building the game.

I won't exhaustively explain each one, that kind of thing is your job in your projects, and I'd also likely be repeating myself as we go through the step by step process, but here are some more diagrams for the other things we identified in the scribbling stage:



Have a look at them, I've inherited from pygame's Sprite class for each of these and then added some names for methods and data that seemed appropriate after playing the game (and based on my experience with pygame).

On top of those, I think I'd also like to have classes representing:

I'm including these because I think they are common enough features in game projects that many of you will want to implement something like them. They also provide a nice structure for the high level of our project. These are their class diagrams:



If you are a wizard of coding you might recognise that I'm plotting to use the State Design Pattern to organise the code here - don't worry too much about what that is. Hopefully you'll see how it works when we build the program.

OK, I think that's enough initial design for now. Hopefully you've learned a bit about what Space Invaders is and a bit about the basic process of breaking down a game from a picture and an idea of how it plays into something that is a bit closer to code.

We'll look at some actual code in Step 2. Which you can come back and look at another time. Or, skip on ahead if you are really bored...

---> ONWARDS, TO STEP 2