A game a week - 1

Introduction

Like a huge amount of software people, when I was young I learned how to write code because I wanted to make games.

Now fast-forward 30 years, and I’m a full-time software engineer, I lead software teams, working on big, complex projects, but I’ve still never finished a single game.

Looking back, the reason that I never finsihed a game was due to the scale of my vision. Back when I had the time to make games, I never set out to make ‘small’ games. They were always too grand, the vision too large, assuming that any knowledge which I was lacking could be picked up along the way. So each time I set out to write a game, I failed.

I think that I’ve learned more humility since then, and I’ve learned how to learn. I’ve learned about building understanding via incremental steps, immediate feedback loops, and the small victories which bring progress.

I still want to make games.

So I figured that I should start with small games. And build one a week (or whenever I have the time). I just built my first one.

pong.py

pong.py game screen capture

This isn’t even Pong. It’s more like a half-finished Breakout clone, though it’s missing the bricks to break. But it does some things which I’d forgotten about: initialising a screen, creating a timed input look, responding to input. These are foreign to me, given that I’ve spent most of my career dealing with the HTTP request/response cycle. Real-time code is a mystery to me (I had to seriously rethink my approach once I typed import threading!)

The stack is unimpressive: Windows, VSCode, Python, PyGame. I use Windows in my ‘real’ job, though I run a remote VSCode server, so it’s effectively Linux. I forgot how many hoops you need to jump through to run simple code on Windows (and how unpleasant the Windows shell is). None of this was insurmountable, but I suppose that building web software all day on Unix-likes spoils you; it’s all so simple and well understood.

The game has no standout features. The ball only follows a 45-degree path; my geometry is terrible, and I didn’t want to exercise it here. The game has a completely linear difficulty progression; I challenge anyone to score more than 20 points before it becomes too fast and unbalanced to keep up.

Nevertheless, I’m pleased that some of the knowledge came back to me, and that PyGame is still around (it’s the same library which 15-year old me was using so long ago), and that it seems that some of my real-world experience has helped me see these things as annoying details to be understood, rather than insurmountable obstacles.

Here’s the code.