Before you keep reading...
Runestone Academy can only continue if we get support from individuals like you. As a student you are well aware of the high cost of textbooks. Our mission is to provide great books to you for free, but we ask that you consider a $10 donation, more if you can or less if $10 is a burden.
Before you keep reading...
Making great stuff takes time and $$. If you appreciate the book you are reading now and want to keep quality materials free for other students please consider a donation to Runestone Academy. We ask that you consider a $10 donation, but if you can give more thats great, if $10 is too much for your budget we would be happy with whatever you can afford as a show of support.
20.13. A Tamagotchi Game¶
There are also a lot of interesting ways to put user-defined classes to use that don’t involve data from the internet. Let’s pull all these mechanics together in a slightly more interesting way than we got with the Point class. Remember Tamagotchis, the little electronic pets? As time passed, they would get hungry or bored. You had to clean up after them or they would get sick. And you did it all with a few buttons on the device.
We are going to make a simplified, text-based version of that. In your problem set and in the chapter on Inheritance we will extend this further.
- First, let’s start with a class
Pet. Each instance of the class will be one electronic pet for the user to take care of. Each instance will have a current state, consisting of three instance variables:
hunger, an integer
boredom, an integer
sounds, a list of strings, each a word that the pet has been taught to say
__init__ method, hunger and boredom are initialized to random values between 0 and the threshold for being hungry or bored. The
sounds instance variable is initialized to be a copy of the class variable with the same name. The reason we make a copy of the list is that we will perform destructive operations (appending new sounds to the list). If we didn’t make a copy, then those destructive operations would affect the list that the class variable points to, and thus teaching a sound to any of the pets would teach it to all instances of the class!
There is a
clock_tick method which just increments the boredom and hunger instance variables, simulating the idea that as time passes, the pet gets more bored and hungry.
__str__ method produces a string representation of the pet’s current state, notably whether it is bored or hungry or whether it is happy. It’s bored if the boredom instance variable is larger than the threshold, which is set as a class variable.
To relieve boredom, the pet owner can either teach the pet a new word, using the
teach() method, or interact with the pet, using the
hi() method. In response to
teach(), the pet adds the new word to its list of words. In response to the
hi() method, it prints out one of the words it knows, randomly picking one from its list of known words. Both
teach() cause an invocation of the
reduce_boredom() method. It decrements the boredom state by an amount that it reads from the class variable
boredom_decrement. The boredom state can never go below
To relieve hunger, we call the
Let’s try making a pet and playing with it a little. Add some of your own commands, too, and keep printing
p1 to see what the effects are. If you want to directly inspect the state, try printing
That’s all great if you want to interact with the pet by writing python code. Let’s make a game that non-programmers can play.
We will use the Listener Loop pattern. At each iteration, we will display a text prompt reminding the user of what commands are available.
The user will have a list of pets, each with a name. The user can issue a command to adopt a new pet, which will create a new instance of Pet. Or the user can interact with an existing pet, with a Greet, Teach, or Feed command.
No matter what the user does, with each command entered, the clock ticks for all their pets. Watch out, if you have too many pets, you won’t be able to keep them all satisfied!