Teaching game

teach logo

working title for game

I have an irrepressible habit of turning everything I can into a game, so when searching round for a game idea I could create for myself, my job seemed an obvious inspiration. One game I’ve enjoyed playing is Diner Dash, and I fancied the idea of creating a similar sort of game about balancing the needs of a class of students and reaching the goal of good exam marks.

It also seems to be the ideal type of game for object oriented programming, with classes of students extended into sub-classes of different types of student, all of whom have slightly different needs. One-to-one teaching is straightforward, but the wider the variety of students in the class the tougher it will be to achieve success. The possibilities are endless!

Having mapped out the original idea, I need to start with a single student and work out the balances between the different variables to achieve reasonable gameplay.

I decided to stick to Python for now, although other options are Flash, Greenfoot or Scratch. Each of these offer easier access to graphics, but if we are to be using Python in school I need to have as much experience in it as possible. Flash also has the drawback of not being available on devices using iOS, which suggests to me that its days are limited, and Scratch, while great for first experiments, feels too self-contained to have wider use, while Python and Java/Greenfoot are more widespread and will run on a wider variety of machines and situations.

Next issue was the choice of editor. I started writing my code in Geany, as this is more compatible with pygame and other GUI modules, but then remembered that for the earliest versions it’s easier to test as I go along and for that I need IDLE, which allows me to type in commands directly. Having written out a first example of my code in Geany, I ran it in IDLE, tested some of it, and then amended the code and tried it again. Here I hit the first problem: I suspect that IDLE and Geany handle the indenting slightly differently, and so the code written in the two different editors threw spacing/tabbing errors. Having forgotten my earlier learning and not kept a log or changed file version, it took a bit of fiddling before I was off again, but this time I kept a log open to keep track of progress.

Adding in complexity to make the variables more interdependent proved successful on one level, but I need to know exactly what effect each variable is having, so at this point I’m moving to a spreadsheet so that I can explore the impact of different variables and weightings on the overall game more easily. I also need to draw up a proper flowchart so I can see what is happening.

I’m beginning to realise that this game will take lots of skill in lots of different areas: a spreadsheet model to explore the effects of the variables, maths skills to play around with the weightings, an understanding of game mechanics to achieve a playable game, graphics design to create the graphics needed, writing skills to write game instructions and even music skills to create music for it. And that’s before I even get to the coding skills!

At this point also I’m beginning to understand more of what my students will need to do when writing up their coursework, and appreciating the need to keep careful records of design ideas and progress. And thinking of the fun I’ll have playing with the settings to make sure that I don’t hit problems with transferring back to Geany as my editor!

 

Python codeword project

Another project I’ve been thinking of (for many, many years, actually, since I first came across the puzzle type) is a program to help solve codeword puzzles.  These are the ones that look like crosswords, except that each square has a number and each number stands for a letter of the alphabet, so you have to crack the code to solve the puzzle.  I love these puzzles but don’t like trying a letter out, changing my mind and having to scrub them back out of the book, so my idea is to create something that will replicate the grid on screen and allow you to type in a number and letter and have the program automatically replace for you, with a reset button for each number if you change your mind.

I think I’ve even made a half-hearted attempt to get going before, but never really got very far, but having seen the listings for python games using the console, including Reversi and tic-tac-toe (or othello and naughts and crosses if you prefer) I’ve realised that it’s worth making a start in console mode to get the basic functionality sorted, with a better interface as a future development.

I’ve had a frustrating time at some points in this project, but I’ve also learned a lot. There were two main learning foci – data structures and classes.  With data structures I think I hit problems because I was thinking too much about two dimensional arrays to store the grid, but in Python I have a list  of lists – the grid looks like [[codeword, codeword, codeword],[codeword, codeword, codeword]] where each of the inner lists represents one line in the grid and each object in that list is an object of a new class I’ve defined.

Python offers a useful way to iterate through lists: you simply call

for <element> in <list>:

and then you can run through them, for example:

for e in self.square:
    for f in e:
        if f.number==num:
            f.setLetter(let)

This cycles through all the elements in the main list, all the elements within that element, and if the number matches it sets the chosen letter.

The codeword object contains three attributes: it has a number, a letter and a boolean called fixed, which enables me to lock a letter/number combination when I’m sure it’s right (or if it’s one of those given as part of the original puzzle).

codeword console in action, showing grid drawn and redrawn

codeword console in action

So far I can display the grid in the console, change, lock, unlock or reset letters and redraw the grid to display any changes.  The next stage will be to provide a key, which shows which letters have been assigned and which are still available to use.

Then I need to tie the engine to an interface, as the console display makes it hard to see the words properly and it’s tiresome to have to type commands directly into the console rather than clicking on buttons.

The idea of writing classes and functions to deal with different aspects of the project is to make it modular, so that I can replace my current codeword object with a similar object that will respond to the same calls but display things differently, so that it’s easier to replace/modify small areas of code rather than having to write the whole lot again, but in Python you can define more than one class in the same file, and indeed have your main program code there as well, whereas in Java it’s usual to have one class per file and import them all.

I haven’t mastered the art of modules yet to include code from other files that I have created, but then I haven’t really needed to, as my entire project is only 134 lines long, including comments and whitespace.

There’s still plenty of room for improvement: as well as the interface upgrade, it’s also possible to provide an option to save and restore games, and the method of inputting the grid needs to be streamlined – at the moment I have to type the numbers in for each line separated by a space, with 0 for a blank.  A check is made that I’ve entered the right number of values for the line, but not that they’re correct, and any mistake means restarting.

Still, I’ve made a working prototype that’s proven the possibility, and had fun developing my thinking skills in the process.  I’m also starting to remember some of what I learned about interfaces to objects, encapsulation and various other topics.  I had an issue with Python’s typing at one point as it doesn’t need its variable types declared, and I was getting muddled between ints and strings, but it just means it’s down to me to watch what I’m doing rather than relying on the language to enforce type or flag up problems.

I’m constantly reminded, though, that it helps to understand what’s going on and what the principles are, and so the importance of understanding theory as well as having practical experience, and how each feeds into the other constantly.

I’ve provided the code below, if anyone’s interested in looking – it’s very much a Work in Progress, and probably very clumsy and muddled in places, so be warned!

codeword puzzle assistant

Using my skills

It strikes me that on the one hand the way to get better at anything is to practise, and on the other hand there’s little point in having a skill if you’re not going to use it.

So I hereby vow that I’ll be looking for ways to use my ICT and programming skills to develop resources and show what can be done.

I have made an animation about the intranet/extranet/internet, and I use extended facilities in our school Moodle system wherever I can.  I’ve also made screen capture videos explaining how to do various things related to games creation and web design (I like your videos Miss but I have to keep watching them over and over and keep stopping them! Me: that’s the point of them).  Now it’s time to step up and really start seeking out ways to use and develop my skills and resources.

One thing that I intend to do is to create a seat planning tool.  In my classroom I’m lucky enough to have computers round the edge of the room plus tables in the main area, so each seating plan I create has to have two related spaces for each child – I try to keep the place at the table related to the position of the computer they use.  So a plan where I drag a name to a place at the tables and their computer place is automatically labelled too would be useful.

There are many topics where detailed written, well laid out step by step instructions would go well side-by-side with tutorial videos, so students can choose their preferred way of working.

I’m sure there are many topics suited to a multimedia, multi-pathway approach of presentation (yes, the dreaded OCR Nat unit 4, but in something other than a simple powerpoint, hopefully!).

I’m also sure that there are many other possibilities I haven’t even thought of yet.

Getting the students used to seeing high quality resources and knowing they were created by someone they know should be a good step towards inspiring them to see what can be done and that the gulf between creators and users doesn’t have to be as massive as it is currently.

Any other suggestions for projects more than welcome!

 

Revisiting Greenfoot

I still want to see how Greenfoot can fit in with the OCR GCSE assessment tasks, so it’s time I learnt more about it.

So far I’ve learnt about adding methods, using IF statements and code blocks and listening for key presses.  We’ve also seen how to add objects to the world and how to have those objects removed by another object (eating a lettuce, for example).  The beauty of Greenfoot is that inheritance means the classes can be exactly as complex as they need to be – in the scenario I’m working on, there are various different animal types that all inherit from Animal, which inherits from Actor.  This means they all have the behaviours that are written for Actor, but also some that are written for Animal.  This means that methods/behaviours can be preprepared and inherited from a superclass, to be used without the learner needing to create them or understand how they work, and these have been dealing with things like removing an object when it is eaten.

Turtle game with bugs and counter

Turtle game with bugs and counter

Now it starts getting much more interesting.  We’ve taken the basic game of turtles moving around and eating lettuces, while being chased by snakes, added a variable to count the number of lettuces eaten and end the game at a set number of points and now we’ve added sound.   Then comes getting objects to talk to each other.

We add a new animal class, a Bug, whose code is mostly copied from the snake as we want it to move by itself.  We add code to the turtle telling it how to eat the bug and add to the score.  Then we need to tell the turtle that when it eats a bug we want another bug to appear in the world somewhere random.  This means we have to learn how to create a new bug, obtain the reference to the world and pass the bug reference to that world to make it appear somewhere random.  This produces an interesting new ability, that of creating objects on the fly.

The next job is to add a counter.  At this point in learning the code for a counter object is given, which is another good way of protecting the learner: sometimes you want them to be able to add and use a new class without having to create it, and in this case it’s as simple as copying the code from a text file and pasting it into the new empty class.  We can then use that class by adding it to the world and calling its methods without worrying how they’re implemented, although the curious can always take a look.

The turtle needs to be able to access the counter, and so we learn about constructor methods, and how to pass the world’s counter reference to the turtle.  At this point we also see how to add objects to the world object using code rather than by placing it manually.

A few adjustments to the point scoring process leaves a complete playable game.

In this session (videos 11-16 from Mik’s blog) a lot has been covered, from the simple steps needed to add sound effects to the game to some massive concepts involving references and object interactions, and on the way we’ve seen a couple of ways that the learner can be helped to focus on the concepts they need to learn rather than getting bogged down in details they just don’t need yet.

I still don’t know how to use Greenfoot for the sort of tasks needed for OCR GCSE computing yet, but I’m left far more optimistic that there will indeed be a way, as well as admiring the way that Greenfoot helps the student understand, from easy to access code documentation through layout tools to code completion.

 

Yousrc – introduction

yousrc logo

Yousrc

Yousrc is an online resource that promises to teach programming skills by building simple programs that can easily be played on an android mobile phone via their own yousrc app.  Now I finally have an android phone with a large enough screen (touch wood!) I can have a play and try this out properly.

simple yousrc code

simple program

The resource contains many features useful to schools, including the ability to register as a teacher and then register your own students and provide them with their logins and monitor their accounts without having to go via students’ email addresses.  It also promises that all apps are moderated before publishing and therefore child-friendly, and this goes for all resources and forum posts as well.  I’m not sure how they would maintain that on a much larger scale, but for now all this is available for free, with an optional paid version offering more online space, more support and more teaching/learning resources.

Currently if you have students registered within your school they submit apps for your approval.  If you approve them, they then go to a member of the yousrc team for further checking, before they are published and available to anyone.  The site features some projects if you wish to see the sorts of things that have been produced.  This is an example game made by the project’s owner.

I’ll be starting by working through the teachers’ resources available from the site.  There are six lessons available to teachers, which take you from creating your first “Hello World” program to displaying, moving and bouncing an image, plus using input via mouse and adding sound effects.  These promise to introduce the basic programming structures: loops, if statements, functions, global and local variables etc.  By the end of the sixth lesson the student will have written a program that has a logo moving around the screen, making a sound as it bounces off the edges and stopping and ending the app if the logo is clicked on.

Yousrc uses its own language, ELC, and all sourcecode for published apps is freely available.  It makes use of the Java runtime environment.  Code is written into the browser, in an editing window which can be run fullscreen if preferred.  Code is colour coded for ease of understanding, and there is a built-in checker to pick up syntax errors.  Apps can then be run onscreen from the editor, and you can optionally see all variable values as the app is run.

a program to animate the logo

animating a logo

Running apps on your mobile phone entails installing the free yousrc android app and then logging in with your details.  You can then access all your apps, published or unpublished, or look at other published apps, although I couldn’t find a search feature and I found the main app rather slow to respond at times and very difficult to work with.  There is a search feature on the main website, however.

One issue could well be the difference between designing an app with mouse input and with touchscreen input, so I’ll be looking into how that is handled.  When an app is played on the phone, a touch pad appears at the right of it with arrow keys and a space key, or there is the option to switch to motion sensors.  I found dragging my finger onscreen had the same effect that moving the mouse would have done on the computer version of the game.

First impressions are that there is a lot of support available for this tool, and the language I’ve used so far is straightforward and recognisable, but it will take more experience before I really see what the software is capable of and how far students are likely to be able to take it.  There is also the issue of how different the language is from any of the standard languages, so again I’ll be looking at that as I proceed.  I’ve found nothing wildly different so far, however.

I hit a few technical problems with my system to start with, so I’ll be keeping an eye on that as I go on as well: one essential requirement for software for learning is that it is stable, but in my case it could well have been a browser add-on causing problems.

This is tougher to get going with than App Inventor, but it does look and feel a lot more like proper coding, and I suspect the learning would be more intensive (which is both good and bad, depending on circumstances!).  The selling point for me is being able to see your own work on your mobile phone, so I’ll be revisiting at some point soon to move on a little further.

 

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!

 

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!