Making Decisions

Decisions and Games

Learning Objectives

  • You can run a program even when some of its code is still unfamiliar.
  • You can modify a clearly marked part of a larger program using variables and decisions.
  • You can trace the values in the part that you change.

You have learned about variables, decisions, and tracing. Those ideas are already enough to change the behavior of a small game — or any small program.

You do not need to understand every line of a program before you can experiment with it. The example and exercise in this chapter use Pyxel and contain unfamiliar words such as class, def, import, and self. You will learn about those later.

Run an Unfamiliar Program

The program below changes the screen between red and blue whenever you press Space.

Press the play button (▶) to run the program. The program should open in the sidebar. Click the game screen and press Space a few times. Your goal is simply to run the program and observe what it does; you do not need to understand or explain its code.

No files opened Select a file to edit

Modify One Part of a Larger Program

The exercise contains a larger Pyxel program for a virtual pet — a tamagotchi. The pet gets hungrier and more tired as time passes, and you can feed it, play with it, and let it rest.

That program is split into three classes. One holds the pet’s state, one does nothing but draw the pet’s animations, and one runs the game. You do not need to know what a class is to work on it. Run the starter once, find class App, then find its def update(self): section. Change only the code between these comments inside that section:

# YOUR CODE STARTS HERE


# YOUR CODE ENDS HERE

Inside that area, you will use familiar variables, comparisons, assignments, and if statements to finish the game’s rules. One rule — feeding the pet — is already written there as an example. You may ignore the rest of the program even though it still runs around your code.

One of the rules chooses the pet’s mood, and the mood is the value that the animation class reads. A hungry pet shakes, a sleepy pet closes its eyes, a sad pet frowns, a happy pet bounces. Because the mood is chosen with a chain of if, elif, and else, the order of your branches decides what appears on the screen: a pet that is both hungry and tired looks hungry only if you check hunger first.

Complete the tamagotchi rules

0 / 20 points

Run the starter program. It opens a small Pyxel game with a virtual pet. The pet gets hungrier and more tired as time passes, and its face and animation follow its mood.

The program is split into three classes. Pet holds the pet’s state, PetSprite does nothing but draw the animations, and App runs the game. You do not need to read or understand those classes. You only need to find class App, then its def update(self): section and the clearly marked area inside it.

Important: Change only the area between YOUR CODE STARTS HERE and YOUR CODE ENDS HERE inside App.update. Keep the feeding rule that is already written there as an example. Below it, implement playing, resting, choosing the mood, and the pet leaving, in that order:

  • When P is pressed and there are at least 10 energy, subtract 10 from energy, add 15 to happiness, and set message to That was fun!.
  • When P is pressed without enough energy, leave energy and happiness unchanged and set message to Too tired to play..
  • When R is pressed, add 30 to energy and set message to Zzz... resting..
  • After handling the key presses, choose the pet’s mood: hungry when hunger is at least 70, otherwise sleepy when energy is at most 20, otherwise sad when happiness is at most 20, otherwise happy when happiness is at least 60, and otherwise neutral.
  • After handling the key presses, if hunger is at least 100, set gone to True and set message to Your pet ran away!.

The mood you choose is the value PetSprite reads, so a different order of branches gives the pet a different animation on screen.

The framework keeps energy and happiness between 0 and 100 for you, so you never need to check those limits yourself. Hunger has no upper limit, and time adds three hunger at once, so a pet can jump past 100 without ever being exactly 100. Reaching the limit means at least the limit rather than exactly equal to it.

You may organize the decisions in any clear way that produces the required behavior. The automated tests simulate Pyxel and key presses without opening a real game window.

Leave the framework code around the marked area as it is. Nothing stops you from editing it, so if the game starts behaving strangely in a way your own rules cannot explain, check whether a line outside the marked area was changed by accident.

Once you have completed the assignment, submitted it for grading, and received points from it, feel free to also experiment with changing the drawing logic.

The important lesson is that you can make a useful, controlled change without understanding an entire codebase. Trace the values in your section, test the result, and leave the surrounding framework alone.

← Reading, Tracing, and Explaining Programs
Recap and Feedback →