Tower Defense Game: Game Loop and Initializing PyGame

PyGame

If you have never used Pygame before, there’s a few things you should know about it. Pygame is what I’d term a “low-level” library. Its main aim is to provide a canvas – literally – that you can draw on, with a wide range of useful game development primitives and helpers to get you building.

Out of the box, you get:

1. Simple Sprite management

2. Primitives for simple collision detection

3. Basic sound mixing

4. Software or Hardware-accelerated 2d canvas drawing thanks to the SDL library

5. Vector and Affine Transformation (like rotation and scaling)

6. Keyboard/Mouse and event handling

7. A number of drawing primitives, like circles, lines, rectangles, etc.

That, more or less, is it. At the outset that may not seem like a boon, but for a Python developer it absolutely is!

You’ll learn far more building your games with these primitives and, as you’ll see, you can do a lot of cool stuff with these primitives once understand the basic concepts.

Initializing PyGame

Initializing PyGame is going to follow the same initialization of all other aspects of our game, which should look a bit like this:

1. The game is started

2. PyGame is set up and initialized

3. Assets we need are loaded

4. The game proceeds to its next task, whatever that might be, like showing a menu or an intro

The important thing here, though, is that we want to do points 2 and 3 once. PyGame has to do a lot of housekeeping behind the scenes when it’s initialized, and it absolutely does not want to be initialized more than once — expect crashes and errors if you do!

We should also ensure we only load assets once; as you’ll see, we want to keep a high frame rate and loading assets is anything but fast.

That, in fact, goes for lots of other things: if we only have to do it once, we should strive not to do it more than once. Sounds obvious, but it’s easy to miss things, and getting it wrong can take its toll on the game’s frame rate.

Let’s start out by importing PyGame:

>>> import pygame

Now to initialize PyGame.

def init(screen_rect: pygame.Rect, fullscreen: bool = False):
    pygame.init()
    window_style = pygame.FULLSCREEN if fullscreen else 0
    # We want 32 bits of color depth
    bit_depth = pygame.display.mode_ok(screen_rect.size, window_style, 32)
    screen = pygame.display.set_mode(screen_rect.size, window_style, bit_depth)
    pygame.mixer.pre_init(
        frequency=44100,
        size=32,
        # N.B.: 2 here means stereo, not the number of channels to use
        # in the mixer
        channels=2,
        buffer=512,
    )
    pygame.font.init()
    return screen

This function accomplishes quite a bit, so let’s go over each part:

1. Every game occupies a certain screen size — that is what screen_rect is for. As you’ll see in a bit, I will define this later on to be a multiple of the size of our graphics tiles.

2. We can run the game in fullscreen mode if we specify that function parameter

3. We insist on 32-bit color depth. That leaves us with 8 bits for each of the three color channels computers use: red, green, and blue. And another 8-bit channel for the alpha channel, which governs the translucency of the pixel when it’s drawn to the screen.

   The color depth is important. We make use of semi-translucent pixels frequently. So even if you’re interested in low-bit-depth pixel art, you may still want 32 bits for no other reason than to make it possible to do seamless alpha blending.

4. We also initialize the sound mixer with sensible defaults.

5. And finally, we initialize the font rendering engine, so we can draw text to the screen later.

Now, at this point, you can run this init function with a suitable rectangle size:

>>> init(pygame.Rect(0, 0, 1024, 768))
<Surface(1024x768x32 SW)>

Done right, a window with a black canvas should appear. But as you’ll quickly realize, it doesn’t respond to events; not from your keyboard or mouse, nor from your operating system! Your OS will quickly report that it appears it’s hanging.

That’s because we are not responding to events from the operating system. The OS does all the heavy lifting here: it draws stuff, it reads from your peripherals and transmits them to the window and the underlying event loop that would ordinarily transact those event messages.

So, then… how do we process these events?

The Game Loop

Reduced to its simplest parts, a game loop is nothing more than an infinite loop with stuff in it:

while True:
    do_something()
    do_something_else()

But of course, it’s never really that simple. For starters, you need to separate things that you only ever want to run once – like initializing PyGame – and things you definitely want to do more than once, like drawing stuff to the screen, or reading events from the mouse or keyboard.

Indeed, our game loop exists to centralize activities we must do every frame. Some of those things are:

1. Drawing stuff to the screen

2. Telling all our sprites to update themselves: enemies keep traversing the path they are walking; bullets keep flying.

3. Checking if there are any collisions we should deal with: a turret catching sight of an enemy; or a bullet impacting an enemy.

4. Handling OS and keyboard/mouse events

5. … and things like checking if we’ve won or lost the game; whether to spawn more enemies; etc.

And, finally, to instruct PyGame to wait until the next cycle is due to run.

frame length = 1 second / desired frame rate

pixels per tick = 1000 pixels / (60 fps * 2 seconds)

DESIRED_FPS = 60

clock = pygame.time.Clock()
while True:
    # ... do game loop stuff ...
    pygame.display.set_caption(f"FPS {round(clock.get_fps())}")
    clock.tick(DESIRED_FPS)

from dataclasses import dataclass


@dataclass
class TowerGame:

    screen: pygame.Surface
    screen_rect: pygame.Rect
    fullscreen: bool

    @classmethod
    def create(cls, fullscreen=False):
        game = cls(
            screen=None,
            screen_rect=SCREENRECT,
            fullscreen=fullscreen,
        )
        game.init()
        return game

    def loop(self):
        pass

    def quit(self):
        pygame.quit()

    def start_game(self):
        self.loop()

    def init(self):
        pygame.init()
        window_style = pygame.FULLSCREEN if self.fullscreen else 0
        # We want 32 bits of color depth
        bit_depth = pygame.display.mode_ok(self.screen_rect.size, window_style, 32)
        screen = pygame.display.set_mode(self.screen_rect.size, window_style, bit_depth)
        pygame.mixer.pre_init(
            frequency=44100,
            size=32,
            # N.B.: 2 here means stereo, not the number of channels to
            # use in the mixer
            channels=2,
            buffer=512,
        )
        pygame.font.init()
        self.screen = screen

# Replace width and height with the desired size of the game window.
SCREENRECT = pygame.Rect(0, 0, width, height)

class SomeClass:

    def __init__(self, a, b, ...):
        self.a = a
        # ... etc ...

@dataclass
class MyClass:

    a: int
    b: str

class Foo:
    def init(self):
        # ... as before ...

    def __init__(self, screen, screen_rect):
        self.screen = screen
        self.screen_rect = screen_rect
        self.init()

    @classmethod
    def create(cls, fullscreen=False):
        game = cls(
            screen=None,
            screen_rect=SCREENRECT,
            fullscreen=fullscreen,
        )
        game.init()
        return game

Running the Game Loop

We’ll need a way of running the game loop when we start the game.

def start_game():
    game = TowerGame.create()
    game.loop()

if __name__ == "__main__":
    start_game()

Create a new file – in the demo it’s called main.py – and put something akin to that in it. When you run python -m tower.main, it should invoke start_game and call our (empty) loop.

Next Steps

We need to design the actual game loop, and because our game has several distinct screens (a menu, game editor, the actual game play, and a score screen) we need a way to think about the design of this game. That’s where state machines come into play.

Summary

Dataclasses automate a lot of tedium

They are almost always a straight upgrade from ordinary classes — and let’s be honest, most classes we write are ordinary. This course will only scratch the surface of what you can do with dataclasses, so I recommend you take their use to heart, and experiment with them in other projects you work on.

The class method factory pattern captures common requirements

Many times, you will create an object, and then immediately carry out a number of activities against that object: assign this; and call that. If it’s a one-off, no problem. But often, it’s a general pattern, and something you need to do frequently, or at least indicate that there’s a common set of standards your class and application expects.

You can use the classmethod pattern to help you manage that.