In the last issue, I talked about my experience in PyWeek, a week-long game jam done specifically with Python and the PyGame library. This week, we’ll talk more about PyGame itself and give some examples of how to do things in it.
To start with, PyGame is a pretty old library but one that’s still being used and updated for a reason: it’s an easy way to write your own game engines in Python.
If you’re not sure what I mean by “game engine” I mean a lot of the real guts of a game. A game engine is the code for things like physics, motion controls, or handling keypresses, mouse movement, and using a controller.
I think of games writing as being on a spectrum: on one end you have things like GameMaker where you don’t necessarily need to do programming to make a game. On the other end you could write all the code to:
- Talk to the graphics hardware to be able to put colors in specific pixels
- Load images from files and turn it into something that can be displayed on the screen
- Ask the operating system for keyboard/mouse/controller inputs
- Handle refreshing the screen many times a second
Most ways of writing games are in the middle. Things like Unity and Godot are more towards the GameMaker end; meanwhile, something like PyGame is closer to the full DIY way of making games.
To make a game in PyGame, you have a lot of freedom. What PyGame gives you to work with is the code that handles how to:
- Use sprites
- Display images
- Handle simple collisions
- Receive inputs from the player
- Control frame rate
- Load music and sound effects
Almost everything else is left to you, the game writer, to develop!
You can write your own physics or combat engines. You can develop your own ways of handling levels or scenes.
If you’ve ever used Scratch before, you’ve probably run up against times that you’ve thought “I don’t like the way Scratch does this”. I personally get that little twinge of “hmmm” every time I wish I could send a message to just a single sprite in Scratch. Well, the less “opinionated” a framework is, in other words the less it decides for you, the less likely you are to have moments like that.
Using a less opinionated framework like PyGame means you’re more likely to be able to do things exactly the way you want them. On the other hand, you’re probably going to be writing a lot more code than in something like Scratch or Gamemaker.
So how does PyGame work?
Well, if you have Python installed on your computer then getting PyGame is as simple as opening up a command line prompt and running:
python -m pip install pygame
PyGame is also very easy to get started with. Here’s a minimal little example that opens a window and then displays the text you type.
import pygame
pygame.init()
size = [600, 480]
screen = pygame.display.set_mode(size)
done = False
text = ''
alphabet = 'abcdefghijklmnopqrstuvwxzy'
while not done:
for event in pygame.event.get():
if event.type == pygame.QUIT:
done = True
elif event.type == pygame.KEYDOWN:
key = pygame.key.name(event.key).lower()
if key in alphabet:
text = text + key
elif event.key == pygame.K_BACKSPACE:
text = text[0:len(text)-1]
screen.fill((255, 255, 255))
font = pygame.font.SysFont('Arial', 25)
textSurface = font.render(text, True, (0, 0, 0))
screen.blit(textSurface, [100, 100])
pygame.display.flip()
This introduces a few different important concepts in PyGame.
First, that you need to actually write a “game loop”. It may not look like the one above, but there’s always going to need to be some kind of while-loop that is the top level control of the game.
Second, in PyGame you’re never actually drawing to your real screen per-se, but rather to a surface which is a data structure that holds records of what goes in each pixel of the window or screen the PyGame program will be displayed on. In PyGame you’ll be dealing with surfaces constantly. Sprites will have surfaces holding their current frame of animation. You write text to a surface, like in the above example. Finally, you have the surface that represents the window the game is being displayed on. Combining surfaces together is called blitting.
When you’re ready to display the next frame of the game you need to “flip” the display, which basically means that you take all that data that you’ve stored up for each pixel and plop it on the screen in one go.
That might seem a bit elaborate to draw to the screen. The thing is, though, that drawing to the screen with any game-making library is kinda like this, at least under the hood. PyGame, since it’s more low level than something like Unity, just makes the real process of rendering each frame a lot more obvious. Whether or not that’s a good thing is really a matter of taste.
Finally, the way you make games with PyGame interactive is by using its event system. If you’re coming from something like Scratch, this might be the most familiar-looking part of writing games in Python. PyGame takes all the data from your mouse, your keyboard, or your controllers and organizes it into a stream of events. Every time your game loop runs, you need to check what events happened and act accordingly. Was a key pressed? Was a mouse moved? How much was it moved? What key was pressed? These are the kinds of things you can check with the events in PyGame.
With just these few concepts in mind, you’re ready to start learning more about PyGame. I’ve written some longer tutorials on different concepts that are linked below. There’s also a good, free, book called “Program Arcade Games in Python & PyGame” linked below as well.
Learn More
Clarissa’s PyGame Tutorials
https://github.com/clarissalittler/pygame-tutorials/blob/master/Tutorial.org
The main PyGame website
The PyGame documentation
A free online book that teaches Python and PyGame
http://programarcadegames.com/index.php
Forum discussion about developing Unity of Command in Python
https://unityofcommand.net/forums/viewtopic.php?t=607&f=7
