Okay, open up the fourth file, and let's get nuts!

Now we've added three new sprite classes. Heavy! Well, not really. They do the same thing as the PlayerSprite class, they're defining new "stickers" that we can place on our screen.

What are the differences? Well, they load up different images and, therefore, are different sizes. The area that each takes up is called its bounding box--that will help us figure out how they will react to each other. More on that later.

They also have different update functions. The enemy will move around in a given direction until it hits a boundary, then it will bounce back in the reverse direction. It will do this for every frame--keeping moving one way until it can't, then move the opposite. Dumb AI, but it works.

Okay, keep looking at that third file. In the main function, we've added a couple new variables called player_sprite and player_sprites. player_sprite creates a new sprite, or "sticker" as we've been calling it. It does this by instatiating the PlayerSprite class. All this means is that we use the PlayerSprite class, which is just a definition, to create an actual sprite that we can move around on the screen. Since this is a one-player game, we just create one sprite and add it into the player_sprites (note the plural) group.

Now let's move it around! If you look in the event loop, you'll see we've added a few more key commands. These new commands set the velocity for the player sprite. It does not, however, move the sprite! This is important to remember. The keys are changing values of the sprite, but we leave it to the sprite to move itself! Let's see how this happens.

Okay, we're in control, but so what? This is boring! So, let's start blitting a few more things on here.

Open the third file. Near line 71, you'll see a line like this:

class PlayerSprite( pygame.sprite.Sprite ):

This is a class, the chief concept in object-oriented programming. DO NOT PANIC! Object-oriented code is designed to make your life easier, not harder. This class is a sprite, and you can think of it like a sticker or one of those animated Monty-Python characters. All a class does is define what makes a sticker a sticker. In this case, the sticker represents a player on the screen.

Ok, now open the second file. The first thing you'll notice is that we've added to functions, loadImageFile and loadSoundFile. Don't sweat these. They're just handy wrappers around a few functions that help us load up files that are located in the data subfolder. Feel free to use these as is in your own prototypes. They work well, and you almost certainly won't need to modify them.

Next, in the main function, we use the loadImageFile function to pull in the background image. Then we use the screen.blit function to blit that image.

Wait, blit? Wazzat? Blitting is like pasting an image onto the screen. Everytime we update graphics on the screen, we "blit" them. Think of this like a Monty-Python clip art animation. Right now, there's just the background, but we'll be pasting a few more things on here later.

Open the first file in the demo (01_lincolnkitty_basics.py) in a Python editor. This editor might be Idle, which usually comes with Python, your own favorite development environment, or even just a simple text editor.

This file is the skeleton from which you can build just about any prototype. It loads up the pygame and other important modules, creates a main function, sets up the screen, and start running (although only briefly, since nothing is happening yet.)

The most important thing to observe here is the "while" statement. This is the "main loop" of the application. It will repeat, over and over again, for every frame of the game sent to the screen (which we've set to be updated at 60 frames per second.)

At their heart, games and other applications run on a very simple three-part structure.

• The Controller
• The Model
• The View

Each is separate but dependent on the others. The controller takes all the input into the system, from the keyboard to the mouse to the internet connection. The model processes the inputs from the controller and makes decisions based on it. The view displays the results of those decisions as output to the screen.

That's it!

We'll be using a Python module called Pygame to prototype this demonstration game. To install Pygame, go to the links below.

Python and Pygame downloads, for Windows:
http://www.python.org/download/
http://www.pygame.org/download.shtml

For Mac:
Python 2.4:
http://pythonmac.org/packages/py24-fat/index.html
or Python 2.5:
http://pythonmac.org/packages/py25-fat/index.html
Be sure to get the Python, pyobjc, and pygame packages from the list if you don't have them already.

Also, you'll need the demonstration files I've prepared for this class. Download one of the "demo" files you see linked below, either the .zip or .tar.gz file.

Welcome to the Game Prototyping Workshop!

Making a game can be easier than you think. With a few simple concepts, you can start to piece together a prototype, in any language, that can help you test your mechanics, sketch out an interface, or examine different possibilities for artwork. In this workshop, we'll use Python to:

• Build the "main loop"
• Get input from the user
• Process the rules of the game
• Display the result on screen as graphics

all by making a simple version of Space Invaders! In one short evening!

Let's get started!

Okay, this really tears it for me. No more Salon.com. And it's because of an article called "Why Johnny Can't Code".

With that kind of headline, that article should have been great for me. It is exactly the kind of area I'm investigating--how we fail at teaching code to novices.

Turns out, it's a three-page rant that we don't have command-line Basic anymore. The author makes a huge leap from this to saying that kids aren't exposed to the "nitty-gritty" anymore and, therefore, our civilization is doomed. Huh?

• intro
• games, but not just games
• applicable anywhere
• solvinh problems on paper and in your head

• branching decisions about how you teach things