Skip to content

Glossary

This glossary lists every technical term introduced on this site, in alphabetical order. Each term links to the page where it is first explained, and each page lists its new terms in a Terminology callout at the top.

A · B · C · D · E · F · I · K · L · M · N · O · P · Q · R · S · T · U · W

A

  • abstraction – the OOP principle of hiding the complicated code inside an object so we only need to call its methods. (OOP Primer)
  • argument – a piece of information we pass into a method when we call it, such as the direction for link_rooms. (Stage 1: Create Rooms)
  • array – a collection that stores lots of values of the same type. (Stage 6: Use Items)
  • attribute – a quality that every object of a class has, such as a student's name, stored as data inside the object. (OOP Primer)

B

  • branch – one of the possible paths through code that uses if, elif and else, each of which needs to be tested. (Stage 2: Movement)
  • breakpoint – a place we mark in our code where the debugger pauses the program, so we can check the values stored at that point. (Debugging with Thonny)
  • bug – an unexpected result in a program, caused by a mistake such as a logic error. (Debugging with Thonny)

C

  • child class – a class based on another class that inherits all of its attributes and methods, also called a subclass or derived class. (Stage 4: Character Types)
  • class – a blueprint that describes a kind of thing, which we use to make objects that share the same attributes and methods. (OOP Primer)
  • class diagram – a UML (Unified Modelling Language) drawing of a class as a table with three rows: the class name, its attributes and its methods. (Stage 1: Create Rooms)
  • class variable – a variable that belongs to the whole class and is shared by every object made from it, so a change by one object is seen by all. (Stage 7: Victory Conditions)
  • code maintainability – how easy our code is to understand, fix and update later, helped by neat organisation and clear comments. (Stage 8: Usability)
  • collection – a data type that stores a group of values together, such as a list, tuple, set or dictionary. (Stage 6: Use Items)
  • comment – a line starting with # that Python ignores, used to explain our code or label the file. (Stage 1: Create Rooms)
  • computational thinking – breaking a real-world problem into precise, ordered and unambiguous steps that a computer can follow exactly. (Stage 1: Create Rooms)
  • constructor – the special __init__ method, called the dunder init, that runs automatically each time we create an object and sets up its attributes. (Stage 1: Create Rooms)

D

  • debugger – a tool that helps us track down bugs by showing what our program is doing, step by step. (Debugging with Thonny)
  • debugging – the process of finding and fixing bugs. (Debugging with Thonny)
  • dictionary – a Python collection that stores information in key:value pairs, so we can look up a key to get its value. (Stage 1: Create Rooms)
  • DRY – short for Don't Repeat Yourself, the rule that we should write code once in one place rather than copying it. (Stage 4: Character Types)

E

  • encapsulation – the OOP principle of storing important data inside an object and getting to that data through the object's methods. (OOP Primer)
  • evaluation – checking that a program does what it was meant to do by comparing each requirement against our test results. (Developing a New Program)
  • event – something that happens that a program can react to, such as the user typing a command, clicking a button or a sensor sending data. (Stage 2: Movement)
  • event handler – the code that responds to a particular event, such as moving the player when they type a direction. (Stage 2: Movement)
  • event-driven programming – a style of programming where the program waits for events, like the user typing a command, and runs the code that matches each one. (Stage 2: Movement)

F

  • falsy – describes a value that acts like False in an if statement, such as None, 0, an empty string or an empty list. (Stage 4: Character Types)
  • flag variable – a variable that stores True or False to control part of a program, such as running keeping the main loop going. (Stage 2: Movement)

I

  • infinite loop – a loop that never stops on its own, which we can end by pressing Ctrl+C in the Shell or clicking Stop in Thonny. (Stage 2: Movement)
  • inheritance – the OOP principle of making a new class based on an existing one, so the new class gets the existing class's attributes and methods. (Stage 4: Character Types)
  • instance – another name for an object, describing it as one particular copy made from a class. (OOP Primer)
  • instance variable – an attribute, such as name, where each object has its own separate copy. (Stage 7: Victory Conditions)
  • inventory – the collection of items a player is carrying in a game, such as the backpack in Deepest Dungeon. (Player Class)

K

  • key:value pair – one entry in a dictionary, where the key is the label we look up and the value is the information stored with it. (Stage 1: Create Rooms)

L

  • large language model – an AI model, also called an LLM, that has learnt from huge amounts of text and can write replies such as a character's dialogue. (Character LLM)
  • library – a collection of ready-made code that we install and import so our program can use it, such as ollama. (Character LLM)
  • list – a collection that stores values in order, can be changed, and is made with square brackets []. (Stage 6: Use Items)
  • local variable – a variable that only exists inside the function where it is created. (Debugging with Thonny)
  • logic error – a mistake where the program runs without crashing but doesn't do what we meant, so Python gives no warning. (Stage 4: Character Types)

M

  • main loop – the loop that keeps a program running, waiting for the user's input and reacting to it each time around. (Stage 2: Movement)
  • method – an action that objects of a class can do, written as code inside the class. (OOP Primer)
  • model parameter – one of the values a language model has learnt, used to measure its size, so a 4b model has 4 billion parameters. (Character LLM)
  • Modelfile – a text file that tells Ollama how to build a custom model, including its base model, system prompt and settings. (Character LLM)

N

  • namespace – a labelled section that keeps names organised, so each class can have its own attributes and methods without them getting mixed up. (Stage 3: Character Creation)
  • naming convention – an agreed way of writing names, such as snake_case for most Python names and CamelCase for class names, that makes code easier to read. (Stage 1: Create Rooms)
  • nested if statement – an if statement placed inside another if statement, which creates more paths that each need testing. (Stage 6: Use Items)
  • None – a special Python value that means "nothing", often used to create an attribute before it has a real value. (Stage 1: Create Rooms)

O

  • object – a digital version of a real thing in our program, made from a class and holding its own attributes and methods. (OOP Primer)
  • object-oriented programming – a way of programming, also called OOP, where we organise our code around objects that hold data and actions together. (Introduction for Students)
  • Ollama – a program that runs large language models on our own computer, without needing an account or internet connection once a model is downloaded. (Character LLM)
  • override – to replace an inherited method by writing a method with the same name in the child class. (Stage 4: Character Types)

P

  • parent class – the existing class that a child class is based on, also called a superclass or base class. (Stage 4: Character Types)
  • polymorphism – the OOP principle that different classes can have a method with the same name that does different things. (Stage 4: Character Types)
  • pseudocode – the steps of a program written in plain English instead of real code, so we can plan the logic without worrying about exact syntax. (Stage 1: Create Rooms)

Q

  • queue – a collection where the first item put in is the first item taken out. (Stage 6: Use Items)

R

  • refactoring – changing how code is written without changing what it does. (Stage 4: Character Types)
  • requirement – a short, testable statement of something our program must do, given an ID such as R1. (Developing a New Program)
  • return value – the value a method sends back to the code that called it, such as the Room object returned by move. (Stage 2: Movement)
  • runtime error – a mistake that happens while the program is running, when Python tries to do something it can't and crashes with an error message. (Stage 4: Character Types)

S

  • self – the first argument of every method, which means "this object" so the method can use that object's own attributes. (Stage 1: Create Rooms)
  • server – a program running on a computer that receives requests, such as our game's messages, and sends back replies. (Character LLM)
  • set – a collection that stores values with no duplicates and in no particular order. (Stage 6: Use Items)
  • Shell – the panel at the bottom of Thonny where our program's output appears and where we type input. (Introduction for Students)
  • stack – a collection where the last item put in is the first item taken out. (Stage 6: Use Items)
  • state – the situation a program is in at a particular moment, such as which room the player is in. (Stage 2: Movement)
  • state machine – a way of thinking about a program as always being in one state, with rules that decide the next state when an event happens. (Stage 2: Movement)
  • string – a data type that stores text, written inside quotation marks. (Stage 1: Create Rooms)
  • syntax error – a mistake that breaks the rules of Python, so the program won't run at all. (Stage 4: Character Types)
  • system prompt – the instructions that tell a language model who it is, which gives each character its own personality. (Character LLM)

T

  • temperature – a model setting from 0.0 to 2.0 that controls how creative the replies are, with higher values giving more creative replies. (Character LLM)
  • terminal – a window where we type commands for the computer itself, such as ollama, rather than Python code. (Character LLM)
  • testing table – a table that lists each test with its expected result and actual result, so we can spot any differences. (Stage 2: Movement)
  • Thonny – a simple program for writing, running and debugging Python code, with a built-in debugger. (Introduction for Students)
  • truthy – describes a value that acts like True in an if statement, such as a non-empty string, a non-zero number or a list with items in it. (Stage 4: Character Types)
  • try block – code inside try that Python runs while watching for errors, so a matching except can catch an error instead of the program crashing. (Character LLM)
  • tuple – a collection like a list that can't be changed once it's made, written with brackets (). (Stage 6: Use Items)

U

  • UI – short for user interface, what we see on the screen when we use a program, such as text, buttons, menus and colours. (Stage 8: Usability)
  • UX – short for user experience, what it feels like to use a program, such as easy, confusing, fun or annoying. (Stage 8: Usability)

W

  • whitespace – the blank lines and spaces in our code, which we use to break it into clear sections. (Stage 8: Usability)