Virtual pet version 2

Time I returned to my virtual pet!  While I have written a detailed specification for the project, I decided to put in an intermediate stage when creating, so in this version there is no day or night, and the algorithms for the change in the variables aren’t completely worked out yet.  I do now have three variables for the pet: health, happiness and hunger.  Each has its own way of interacting with it: feeding, medicine and a ball to play with.  The player has to keep hunger down and happiness and health up in order to have the pet survive.  Health and happiness link to each other – an unhappy pet loses health faster, and vice versa.

virtual pet code version 2

code for version 2

I worked in Scratch originally for version 2, then when I could see repeated code I used BYOB features to pull out that repeated code and make it into a new block, complete with a passed in parameter.  This avoided the repetition as each requirement for death meant broadcasting a message explaining the reason, making the pet disappear and then stopping the script.

I found it straightforward to create my new block, including passing in a message to say why the pet died, and I also like the way that BYOB will change the colour of nested blocks, making it easier to see how they are put together.

Adding a timer to the game made it a little more interesting, as now it will record the length of time the previous pet lasted, but I still need to do a lot of work on the graphics, in order to have the pet show visually what his problems are.  Once I’ve done that, it may be possible to remove all displayed variables from on screen, to make the player look carefully at the sprite rather than just checking the numbers.

die block, including a passed in parameter

custom made “die” block

While the code for the project is becoming more complicated, it is still fairly straightforward, with one script per sprite.  Breaking into more than one script could lead to complications as different scripts running at the same time could interfere with each other, so I’m trying to be careful – for example I could have scripts to run animations for different interactions, but it might be possible to run two or more at the same time, with unintended results.

The project is coming along nicely, so now I need to reproduce this version in App Inventor. I also need to look back at the specification I wrote to see how it fits in with what I’ve done so far and then move on to develop it further, including day/night settings.

I’m still not happy with the gameplay and amount of interaction compared to feedback.  It’s a playable game, but without enough real challenge or interest yet to keep a player interested.  Thinking back to the original tamagotchi, that would beep for attention, and there were mini-games to play.  It was also a much longer-lived game, lasting for days and even weeks.  That’s not possible in Scratch, as it has no file-saving capabilities, but it would be possible in an android app, which is more likely to be the end format of this project.

It would also be possible in a Python project, which is something else I might try at some stage – that would make it usable on a PC, rather than on a mobile device.

Before I do much more with coding, though, I need to work on developing graphics and sound, as a game is so much more than just programming in the behaviours.


Virtual pet specification – details

virtual pet graphic

My first design for a virtual pet

If I’m to build a virtual pet game, I need to be very clear exactly what I’m expecting it to do.  Then I can start looking out for the code structures I need to implement.

I’m aiming for two products.  The simpler one will have a pet that the player can interact with, to feed and keep healthy.  The more complicated one will have a pet that can interact independently with its surroundings, and the player will need to make sure there is food available, for example, but the pet itself will decide when it wants to eat.

So for the simple version:

The pet will be awake three-quarters of the time and sleep the rest of the time.  It will have hunger, happiness and health, which will vary from 0 to 100.  All these will change over time, less so while asleep.  Hunger will be controlled by feeding it, health by giving it medicine and playing with it, and happiness by playing with it.  Waking it up when it is asleep will reduce happiness, but may be necessary if it is ill or starving, for example.

There will also be some interaction between the attributes: being too hungry will decrease happiness and health.  Hopefully I can encode this with maths, rather than needing extra if statements (making the change in happiness directly relative to the hunger and health values in some way).

There will be three buttons: feed, play and medicine.  Clicking these buttons will interact with the pet, changing the graphic and changing the appropriate value(s).

What I haven’t got for any of this is any incentive to keep the pet alive, no way to keep any kind of score.  I’m simply relying on the player wanting to keep the pet alive.  What I could do is add some sort of ageing system, whereby the maturity of the pet can be recorded.  Then the player can be trying to beat their own record of how long one pet has been kept alive.  That will go in the extended version, I think!

Code-wise: I will need a way to display graphics, plus buttons.  I need to respond to the pressing of the buttons by changing the graphics and the variables.  The variables will also change according to a timer that goes off regularly. There will be an element of randomness in the variable changes, particularly for illness, although hunger will be fairly steady.  A way of making it more complex would be to have variables changing at different rates according to activities, for example getting hungry quickly if playing and slowly if sleeping. I foresee lots of looping and lots of if statements in the code.

So I need to look for a way to display the elements, a way to run a timer to change the variables, a way to respond to button presses and code to loop and fork according to input from the buttons.

I know how to do this already in Scratch/BYOB.  It should be fairly straightforward to do it in App Inventor.  I have high hopes for Greenfoot.  Python seems a lot tougher, but there is a listing in the book I’m using that creates just such a virtual pet, that I should be able to adapt.  Processing is supposed to be good for graphic work – I’m hoping it’s a lot simpler than Flash, which would be another option for a project that involves lots of animation.  There are one or two further possibilities that I haven’t investigated yet!

One idea for Python (and possibly for any of the written languages) is to separate display from engine, as I did when I was first learning programming, so building an engine that will do the main processing, and a separate class that  controls the display, enabling the display/input to be updated later.  This means I will need to know how to create more than one class for a project, but will make it easier to update. I have access to the easygui library for Python which will display a series of buttons to click, so a rudimentary interface should be straightforward.

What I need to do now is write the algorithm for the pet’s behaviour, and then translate it into the different languages.

Once I’ve got working versions of the simple pet game, I can start on a more complicated version with the pet acting more independently.  This will require far more graphics and an element of artificial intelligence, which should be fun to play with and lead to the possibility of building up complexity gradually, for example by the player buying objects to add to the house.  Guess I’d better get going on the simple versions!


Virtual pet – BYOB and App Inventor

It’s time to try out my project idea in different software.  I’m working on the virtual pet idea, and first creating in BYOB, and then in MIT App Inventor.

The starting point for the code is the project found at, but I have developed this a little and will be continuing to develop further as the project goes on.

BYOB virtual pet code

The starting point for the pet code


This is what the pet sprite code looks like in BYOB (more or less just Scratch, here; no extra features of BYOB used yet).  The timing is very short at the moment to allow for efficient testing.

BYOB feed me button code

The code to feed the pet

There is a button to click to provide food.  The variable hunger is set to apply to all sprites (global variable). Another option is to make it apply only to the pet, but in that case the button sprite would not be able to change the hunger value and would have to send a message to the pet instead, asking it to change its own code.

BYOB virtual pet stage

BYOB version game stage

This is what the game looks like so far: very simple.  The pet’s hunger is displayed onscreen and gradually goes up to 10.  If it gets to 10, he disappears. If the feed me button is clicked, this decreases the hunger by 1.  The next development will be to have a value for health, which will gradually decrease by a random amount and will require medicine to be given.



MIT App Inventor

The next task is to create the same project but in MIT App Inventor.  It says a lot for the usability of this system that I felt confident enough to try this project so early on in my learning.

virtual pet code in the app inventor

virtual pet code

The system itself was again straightforward: I designed the screen layout, and then used the blocks editor to build the code.  The only complication was that I could not find anything to reset the game, which in Scratch/BYOB I would do by clicking the green flag again, so I built in a reset button as well.  I defined my own variable, hunger, as a global variable as in Scratch, and defined a procedure block called showHunger, which would display the current hunger level in the label element.  This was then available to use whenever I needed it.  The clock element fires very frequently at the moment, again for testing purposes, and when it fires the hunger increases until it reaches 10, at which point the pet disappears, a message appears saying the pet is dead and the reset button becomes active.  Pressing it redisplays the pet and sets its hunger back to 0.

virtual pet running in the emulator

Virtual pet on the emulator

I had a few problems getting the blocks editor open this time, possibly because I was working on a different machine with slightly different security settings, but generally doing all the creation online makes it straightforward to work on my project wherever I want.

This shows the game in action so far.  The red button will reduce the hunger, which otherwise grows to 10.  Once it reaches 10 the pet disappears and the reset button becomes active.  Pressing that will bring the pet back and reset hunger.

So far so good: I have the raw bones of my project up and running in two different software platforms.  It’s playable, if rather simple and uninteresting, and I’m ready to start adding in new features.  Of course, it’s important to make sure that the new features don’t interfere with the original ones!

If anyone would like more details of the design side of the app, or any other information on my projects, or you just want to tell me if you’re finding it useful, feel free to comment on the post (link at top).

Software project: virtual pet concept

Remember the tamagotchi?  They made a reappearance a few years ago but didn’t seem to have the same impact as the original run, where school secretaries were forced to run crèches to avoid disruption in classes.  Still, it’s a fun concept, and one that I’ve seen used in a Scratch scheme of work.  Indeed, I’ve had a go myself with Scratch, and seen kids have a lot of fun with it too.

The concept of looking after virtual beings is by no means new, but it provides a fun way to build up a project, and you can start with the basics then add in more features as you go along – a definite advantage to object oriented progamming and a good way to develop a project without getting buried under details too soon.

I also remember fondly the LCP – Little Computer People.  The idea was that as you ran the program a little man would appear in the house onscreen, and you would see him moving around and carrying out various activities.

Nowadays we have The Sims, of course, but that’s a game that can require a lot of micromanagement.  What I’m looking to do is create something that’s fairly autonomous, but that can be interactive as well if you choose.  So you can play with it if you wish, or just let it play while you get on with proper work – but still need to take care of its basic needs.  Think of a tamagotchi as a goldfish, my project as a cat and the Sims as a dog!

I’ll be trying out different types of game making and programming software, experimenting with ideas and seeing what I can do.  Faced with the perpetual argument of which computer language to use, I’ve decided to investigate different options, to learn the basics of each, rather than the specifics of one.  It saves locking off options too early, and gives me experience that will help deepen my understanding of the software, the development environments and solving the underlying problems in different ways.

The options I see available at the moment are GamemakerScratch and its big brother BYOB, MIT App Inventor, Greenfoot (java), Python and smallbasic/visual basic.  I really, really suck at sticking to one thing, so this should be plenty enough to feed my indecision and develop a good grounding of the differences between these applications before I settle on a definitive approach to teaching programming.  And there’s always Flash if I get bored!