An Adventure-game for Teaching Programming
By: Sebastian Ahmed
Tags: Teaching, Kids And Tech, Adventure Games, Python Programming

Introduction

In late June of 2020 (while trapped in the Austin summer heat), I had the idea of getting my older daughter to learn programming with a “big kids” language. Something other than Scratch (which she had dabbled with on and off). I decided that Python was the logical choice based on its low barrier to entry, intuitive syntax, elegant object-oriented programming (OOP) support and the interactive interpreter shell (for “doodling” code).

There are some decent books out there for teaching kids how to program, but my goal was to create something that we could discuss and extend as a longer-term educational project.

This is not one of my regular posts. It is intended to be fun and somewhat journalistic. If you are new to programming or are a parent and looking for something for your child to play around with to learn programming, my hope is that this may of some use to you.

Goals

Since the entire purpose of this little project was educational in nature, I wanted to keep things very grounded, transparent, and frankly avoid spending too much time on this, although it did end up being a several multi-hour sessions over a series of weekends sort of thing.

As such, the overall project goals were as follows:

Incorporate Python’s core features : lists, dictionaries, strings, functions, files

Use classes for everything, but keep it very lightweight. Introducing my daughter to the actual structure of a class was important since OOP is such a prevalent paradigm of almost any modern language

for everything, but keep it very lightweight. Introducing my daughter to the actual structure of a class was important since OOP is such a prevalent paradigm of almost any modern language No use of special game-engines (keep it grounded and transparent, but this meant more work for me)

Must be extensible via a simple API. The idea was that the first step would be for the student to extend the game (e.g., create new levels and test them out)

via a simple API. The idea was that the first step would be for the student to extend the game (e.g., create new levels and test them out) Keep it simple and have fun

With these goals in mind, I quickly decided that what was achievable was to create a text-based adventure game (and associated creation kit) in a 2D world. This would be reminiscent of terminal text-based adventure games of the early 80’s. There would be no graphics (although that changed during the development).

We decided to name this game Adventure. Because that is what entire process was.

Game Design

From the very outset, I had no intention of coding up a pre-baked adventure with a fixed set of rooms. This would have had a limited pedagogical-replay value. This would go against the “extensibility” goal. This meant that Adventure would need to be a game-engine and creation-kit first and foremost. It would provide a framework to build adventures allowing any arbitrary maze of rooms and objects to formulate levels.

In keeping with the OOP-lite goal, everything was going to be based on objects and so the design started with defining the main objects. The first set of objects were the true “game objects”. These were the “things” inside the game world.

Items — These were movable and usable objects in the game (health-packs, food, weapons, potions, spells etc.) — these ended up just being Python strings

Player — The protagonist. Has an inventory and a health level. Can pick-up, use and drop Items

Location — A location can have “items” and up to four directions of travel (forward, backward, left, right) to another location

Connector — Connectors represent the “fabric” pieces which connect locations. The reason this is a separate object is because it can contain obstructions

Obstructor — A stateful obstacle which occupies the connections of locations (enemies, fire, traps). Obstructors can damage a player’s health but can be overcome with certain Items. Obstructors can also drop Items once overcome.

Then came the objects which controlled the game world. These were the “machinery” of the game.

Adventure — For lack of a better name, the main game-controlling object which deals with movement and interaction of the Player with items, Locations and Obstructors. This object contains handles to the active Player and Level object

GUIWindow — This came later after a request by little sister who could simply not accept a game that did not have “graphics”.

The actual terminal interface is a simple procedural loop with few functions in the main game file. Some support was added (via regular expressions) to provide variation in the user input, for example, the following would all be equivalent in the terminal app:

“use key door”

“use key on door”

“use key on the door”

“use the key on the door”

Below is a screenshot of the gameplay. The last time I did a graphical interface was a Java application years ago at a start-up and it was not much better (did I mention this is not my day job?)