Games and Programming in the Wild

Recap, Feedback, and Where to Go Next

---

This is the last chapter of the part, and the last chapter of the course. It looks back over the games you built, then over the whole journey from the very first print, and finally points outward to where you can go from here.

In this part you set the study log aside and made games. After a chapter on the game loop — update changes the state, draw shows it, thirty times a second — you built eight of them, each adding one idea on top of the last:

• An idle clicker reduced a game to its bare skeleton: a few variables, a timer, a button.
• Asteroids introduced velocity, a list of moving objects, and wrapping.
• Breakout added bouncing — reflection as a sign-flip — and a list of bricks.
• Conway’s Game of Life was a breather built on a 2D grid and the build-a-new-grid rule.
• The maze treated a grid as space to walk through.
• The Galaga-style shooter ran two interacting lists and taught the safe way to remove items from a list.
• The lunar lander added acceleration, so that gravity and thrust gave the ship real weight.
• Finally, 2048 was turn-based, its clean single-grid state making undo almost free.

After those games, you practised using AI to make one focused change at a time, checking the result against your rules and knowing when to stop adding features. In the capstone, you applied that judgment to designing, building, and finishing a small game of your own.

Underneath all the games is one idea, which is the same idea that has been present throughout the course: a program is state plus the rules that change it.

A game’s state is a player position, a score, a list of enemies; the study log’s state was a list of sessions. A game’s rules run thirty times a second in update; the study log’s rules ran once when you asked them to. The setting could hardly look more different — a falling spacecraft versus a CSV of study minutes — but the skill is identical: decide what the program must remember, give that state a clear shape, and write the rules that move it from one valid state to the next.

Recap Quiz

The recap quiz below draws on the main ideas of this part. Complete it before the feedback form.

A Short AI Retrospective

Now that you have completed and improved your own game, write a brief retrospective on how you used AI while working on it — a few honest sentences are enough:

• Where did AI genuinely help? Maybe a feature, a bug, or an explanation that unlocked something.
• Where did it hurt or slow you down? Maybe a rewrite you did not ask for, a wrong library call, or a feature that made the game worse.
• What do you do differently now than at the start of the course? Which skills feel solid, and which need more practice?

You do not have to share the text, and there is no single right answer. The point is to notice how your workflow has changed. In Reading Code You Didn’t Write, the goal was to read a small piece of code you did not write and say what it does. While building and improving your own game, you directed a longer collaboration: specifying changes, checking suggestions, rejecting rewrites, and deciding when the project was finished. Carrying that judgment into whatever you build next matters more than any single game or chapter.

Feedback

Please take a moment to reflect on your work in this part. Your input helps us improve the materials.

Where to Go Next

You have reached the end of the course, but not the end of the road. Here are some future directions, depending on what you found interesting.

If you found the games interesting, keep making them. The fastest way to improve is practise: make another small game, finish it, make the next. When Pyxel starts to feel small, the natural next step in Python is Pygame, a larger, more capable 2D library — bigger images, sound, more control, and a much larger API. Everything you learned here transfers: it still has a loop, still separates updating from drawing, still represents the world as state. It is simply roomier, and now you know how to learn a roomier library safely. Beyond that lie full engines like Godot (which has its own Python-like language) for when you want to build something substantial.

If you found the data and tools interesting, Using Libraries and Data Visualization were a doorway, not a room. The Python ecosystem for working with data — analysing it, visualising it, building models from it — is vast and is one of the most in-demand skills in the world. Learning to work with databases is also a natural next step, and the same skills apply: decide what you need to remember, give it a shape, and learn how to work with it.

If you want to build things people use, the next frontier is usually the web: programs that run in a browser or on a server, that many people can reach at once. This often also involves databases, and the same skills you have learned — state, rules, libraries, and learning new libraries — are exactly what you need.

Whichever way you go, the most important advice is: build things. You become a programmer by making programs, finishing them, and making the next one. You have done that many times over in this course already.

Thank you for working through the course. Now go build something.