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.



About emmyleigh
Writer/editor/proofreader who loves technology

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: