Gamemaker and GCSE

gamemaker environment

Gamemaker environment, with list of assets on the left and a room displayed

One piece of software that I’ve enjoyed playing with is Gamemaker. This is a 2d games engine, reasonably easy to use, that can produce games to be uploaded to the website or given to friends as a stand-alone executable file. Gamemaker Studio is the latest version, and is available in a feature-limited free version, an academic version or full professional version. Note that I’ve changed the skin – I find the new default skin (appearance) of the Gamemaker environment very hard on the eyes, and the monochrome effect makes it harder to identify the different icons (You can’t say the blue or the red circle when every single button is in green or grey!).

Gamemaker is a step between Gamestar Mechanic and Scratch or Greenfoot: it is mostly drag and drop elements with settings, rather than scripting (although there is a scripting option) but with more flexibility than Gamestar Mechanic – the interplay of the objects is completely within the creator’s grasp, and there is the full ability to add your own assets: graphics, sound etc.

While Gamemaker serves well as an introduction to programming concepts, it is not a programming environment; rather it is a tool to introduce logical thinking and game making skills.

Using Gamemaker

The Gamemaker environment consists of a list of assets: sounds, background images, sprites, objects, rooms etc. Note that here a sprite is a graphic file, while an object is something that can be added to the game, whereas in Scratch the costume is the graphic and the sprite is the thing that can be added. Each room is one screen (e.g. level selector, start/finish screen), or one game level.

The man object, showing the Event/action interface

The man object, showing the Event/action interface

The basic syntax of Gamemaker is Event -> Action; When this happens, Do this. The creator chooses an event that may happen, e.g. When colliding with… When keyboard <X> pressed… When No more lives left… and then orders the actions that should take place as a result. In this example, the man is designed to move in a maze. He should respond to key presses by moving in the appropriate direction, and should not move when he hits a wall or when no key is pressed.

The direction can be seen/set by double-clicking on the Move in Direction button.

A game can be built up by creating more and more objects, setting their behaviours appropriately and adding them to the game room.

One way to introduce Gamemaker is with a set type of game with recipe cards for extra objects to add in order to increase complexity. Lower ability children can follow the recipes exactly while more able children can start to experiment with settings, and as they gain experience in different types of games they will naturally mix and match.

I find the easiest way to start students on Gamemaker is to start with a maze game. The first objects needed are an avatar and a block to act as the walls. Once the objects are created correctly it is a simple matter to add to them to a room to  create a maze to explore. Then extra objects can be added easily, such as coins to pick up, a door to move to a next level and a bomb or moving enemy. This works especially well as the first step up from Gamestar Mechanic, as the principles of the game/level design should already be understood. With lower ability students, I have created the basics of the game so that they start with something very similar to Gamestar Mechanic, and once they have created the object to move to a new level they work independently on level design while waiting for support to create further objects.

Strengths of Gamemaker

Where Gamemaker excels over Scratch is its built-in facilities to handle things like lives. As it is purpose-built for games, commands already exist to deal with such common features, and it is as simple as saying Event: No more Lives -> Action: Restart game. The game will then finish automatically and restart.

Games such as platform games need a lot more thought, and many objects will stretch children’s ability to work through logically, although features like the built-in gravity property of objects help considerably. Children with low ability/experience will still have high expectations, and so balancing what they want to be able to do with what they can actually achieve by themselves can be a challenge. On the other hand, some children really take to Gamemaker and quite happily explore options by themselves and there are teaching materials available if you look around (some on my site). There are two very good books, The Gamemaker’s Apprentice and The Gamemaker’s Companion, but these are fairly technical and require a good level of ability in order to access them. They are also written for earlier versions of Gamemaker, so might require some checking/adjustment.

Using Gamemaker for coursework/assessment

I looked into using Gamemaker for GCSE and similar qualifications, and found mixed results: OCR GCSE ICT contains a unit on creative use of ICT, for which the solution can be a multimedia presentation, multimedia web pages or a computer game, so using Gamemaker would be a valid way of fulfilling the unit. Other GCSEs did not appear to have that facility, however. Edexcel offers a single and double award ICT, for which the double award contains a unit comparable with the Creative Use of ICT in OCR; information on the types of tasks covered is limited, but the Examiner’s Report suggests that the expectation for a game-based solution would be a scoring system, rules to play/win, single player or turn taking and the ability to include user-created assets, so that would suggest Gamemaker is indeed a viable option.

Other exam boards appear to focus on business use of ICT or traditional multimedia such as web pages or presentations. Even BTEC ICT overlooks game making as a valid use of multimedia, focusing instead on graphics, animation, video, sound or programming.

Gamestar Mechanic and the new computing curriculum

learn to design video games with gamestar mechanicOne resource I was pleased to come across was Gamestar Mechanic. This is a purely web-based resource that teaches elements of game design. It’s aimed at 4-9th graders (I make that 9-14 year olds) and offers them a chance to move from playing games through fixing games to making and sharing their own. Of the many resources I’ve used with key stage 3, it’s the one I see consistently used voluntarily by the students outside of formal lessons. As we’re partway through our year 7 computing unit, which so far has looked at Scratch, I thought I’d take a closer look at GSM and see exactly what offers in terms of learning and how it fits in with the new computer-orientated curriculum.

One feature that makes GSM easy to use in class is that the registration system does not require an email address. It does, however, have a system to recover passwords that depends on students being able to remember a username and sequence of favourite colour, subject and animal, which isn’t ideal (it can change from attempt to attempt, let alone lesson to lesson!) so this time round I intend to make students make a note of their user name and passwords somewhere secure. They can use any nickname as their user name as long as it’s not already taken, but often it’s easier to tell them to use their school log-on names and passwords rather than spend hours trying to think of something suitable.

Once registered, the student is presented with a quest to work through. There is one quest available free, while others are available for those with premium membership ($19.95 for premium membership, and it may well be that students are interested enough to get their parents to pay for it, but free membership is plenty for school use).

There are two other areas of the site that will also interest users: in the workshop they can create their own games, while in Game Alley they can publish their games and try out those made by others, but more of those later.

episode 1 screen

Episode 1 screen

There are teaching materials provided by the website to serve as an introduction to the site, in the form of five lessons. Lesson 1 works through episodes 1 and 2 of the quest and then provides an opportunity to reflect on learning so far. The resources provided for lesson 1 are a set of cards that can be printed and used for matching – one set provides images of various concepts, while the other set provides names and explanations of those concepts, which are grouped into mechanics, space and components. For example, under the space group you will find bounded and unbounded space, under components you will find health meter and avatar, and under mechanics you will find collecting mechanic and exploring mechanic. This will give the students a whole collection of key terms and concepts to build the rest of the unit on, but I wonder just how many they will be able to take in and remember. The suggestion is that in small groups they work to pair up concepts and images and then everyone goes through the answers. I’m considering giving them worksheets with the concepts on and the cards with the names on, so they can fill in their worksheets and keep them for reference.

Lesson 2 introduces the core design elements, which are defined as space, components, rules, mechanics and goals. Episodes 3 and 4 of the quest provide a chance to investigate ways of changing each of these and showing the effect on the games. The resource provided for this lesson is a graphic to serve as a reminder of the core design elements.

Lesson 3 looks at balance, investigating how the different core design elements balance a game to achieve the right level of difficulty. This focuses on episode 5 and then gives students the first opportunity to build their own game. This ability is there right from the beginning, by the way, via the workshop, but each challenge the player completes in the episodes unlocks another feature they may use, either a different sprite, different background or something similar, so the further through the quest they get the more they have to use in their own games.

gamestar mechanic game creation screen

Games design screen

Lesson 4 gets the students to design their own game, and offers challenge cards for different themed games should you wish to use them.

Lesson 5 encourages students to play-test each other’s games and give feedback via the sheet provided. This guides them into answering questions like “What were the core mechanics of the game?” “how well was this game balanced?” and “how could this game be improved?”.

So far so good, but what got me really thinking was when I started looking at the new computing curriculum and how Gamestar Mechanic might be considered to fit into it, because that was when I struggled to find anything in there that would link easily to games design. While games design is only a small part of what computing offers, at the age of these students it’s their most immediate attraction and links in most closely with what they already enjoy doing, so whether it fits into the computing curriculum or not,  I feel it has a lot to offer.

One aspect of the computing curriculum is to use two or more programming languages. Does this provide a programming language? Well no not really, but it does provide objects that have attributes. By changing those attributes the student interacts with elements of the game and causes changes. While this does not count as a programming language, I would certainly argue that it is an important step towards moving into object oriented programming in systems such as Greenfoot, by providing a way to play with parameters and settings in a very controlled and accessible way.

Object oriented programming gets no mention in the computing curriculum, which is a shame. I’m starting to get the impression that it was written without the needs of children in mind; I can’t imagine too many children being excited at learning sorting algorithms, but give them a chance to learn games programming and they’ll be much more engaged (I know that object oriented programming and games design are not the same, but the latter provides a very good way into the former). What they learn via games design can then be applied more widely as they develop their skills.

game alley screen

Game Alley – published games

What about the creative element of the computing curriculum? Undertake creative projects that involve selecting, using and combining multiple applications … to achieve challenging goals… well it’s selecting, using and combining multiple elements and experimenting to see how they work together in order to achieve a playable game, does that count? It’s not really multiple applications, although it is multiple elements, which can include sound. What students can’t do with this, as far as I can see, is design their own elements. I’ll be taking a look at Gamemaker very soon, which is a natural successor to Gamestar Mechanic and does offer this facility.

Create, reuse, revise and repurpose digital information and content with attention to design, intellectual property and audience – well it’s doing some of that, not intellectual property maybe, but attention to design and audience, and combining the elements in a suitable way, particularly if you use the challenge cards to set a specific purpose or setting for the game.

Maybe Key Stage 2 would fit it better? After all, if the students haven’t been through computing at key stage 2 there’ll be some need for overlap for a year or few. Here we have solve problems by decomposing them into smaller parts, use sequence, selection and repetition in programs; work with variables and various forms of input and output, use logical reasoning… I would argue that it covers all those, although maybe not in the way those who created the curriculum were expecting them to be covered.

What it does do is provide a common language and set of concepts for games design that can then be developed further in many directions, so that students can move on to programming their own objects while already aware of concepts like level design, object interaction, responding to events and parameters.

Key stage 4? Here we fare much better.  It should provide a chance to develop their capability, creativity and knowledge in computer science, digital media and information technology and to develop and apply their analytic, problem-solving, design and computational thinking skills, all of which I would say it does. Considering the restrictions on it, however, I would suggest that GSM would need to be used as a springboard to Gamemaker, Greenfoot or Scratch, all of which are much more versatile and provide more opportunity to incorporate a wide variety of imported assets. It does, however, have the advantage of allowing students to focus on the game design elements and how they interact without worrying too much about how they create them, so they are not trying to learn everything at the same time.

So strangely, this seems to fit in far better with the older key stage than with the younger ones (although, of course, the key stage 4 curriculum was deliberately left very vague in order to fit in with the many ICT and computing qualification courses already available).

profile page showing badges earned

Each games designer earns badges as they learn

Looking at the old ICT levels, Gamestar Mechanic seems to fit in much better: strand 1 covers planning, developing and evaluating systems, using feedback to develop work, strand 2 covers creating sequences of instructions and changing variables and explaining the impact, and strand 3 covers presenting information in a range of forms for specific purposes and audiences.

In summary, while GSM doesn’t completely seem to fit the new computing curriculum, it does seem to have a lot to offer as an introduction to game making, and as part of a larger unit or with explicit teaching on various aspects such as changing parameters and looking at audience and purpose, it does have a place in either late key stage 2 or early key stage 3 learning. More importantly, I would argue, it engages students and keeps them coming back for more, and shows them the satisfaction of creating their own games for others to play and comment on. Any frustration they eventually feel at the limitations of games created through this method can then be directed into Scratch etc, where they have much more control but need to create the behaviours themselves.

game review screen - players encouraged to fill in detailed responses

Game review screen

And that reminds me of another aspect that appears to be missing from the new computing curriculum: there is no mention of collaboration in there, of working together as a team to achieve a common goal and of supporting each other in their learning. This was present in the old system (use ICT to communicate and collaborate) and would appear to be a vital digital literacy skill, considering the extent to which young people use ICT to share ideas in the real world. In Gamestar Mechanic they have a chance to do this by writing reviews for games.

Still, until the new computing curriculum is confirmed and we have more concrete information about what it entails and how to deliver it I’m happy that my students will indeed experience the games design fun of gamestar mechanic.

 

 

codea – coding on ipad for ipad

While browsing code.org last night I came across a link to an ipad game that promised to help teach sequencing and control – a game called cargo-bot. There was mention of the app that was used to create it as well, so I went off to investigate.

a screen of cargo bot, showing a puzzle

cargo-bot, showing all tools available. Match the pattern at the top to complete.

Cargo-bot itself is free, and provides exactly what was promised – a way to practise sequencing instructions. If you’ve ever played with light-bot, it’s very similar, but also offers conditional instructions. The aim is to move the coloured crates and stack them in the right place in the right order, using only commands like left, right and down, plus the facility to create subroutines and loops.

The really interesting part comes when you start looking into how Cargo-Bot was created. An app called Codea, which costs £6.99 ($9.99 in the US, I believe), provides a way to code directly onto the ipad using Lua. The coding for several examples is included, and this includes the complete listing and graphics bundle for cargo-bot.

codea's front page

codea’s front page, showing example projects and link to wiki and tutorials

While learning yet another language isn’t necessarily the best idea, I couldn’t resist, and so bought and installed the app and started playing.

my game in action

my game in action

Within about an hour I’d produced my own program that drew a character on screen who responded both to gravity (tipping the pad) and touch.

The longest aspect of this coding was having to switch constantly from the app itself to the wiki with its tutorials, find the right place in the tutorial and then swap back again and try to remember. I did try to borrow another ipad so I could use both at once, but ended up reverting to the tried and tested method of paper and pen!

codea's editor adds extra buttons to help type in code

editor, showing the quick buttons on the top row

The editor seems to provide a lot of help, for example a button to provide brackets, another to provide speech marks, both leaving the cursor in the middle for typing, and a quick += button. Pop-ups provide help with coding, and I did eventually find a comprehensive in-app help system.

built in reference guide

built in reference guide

There are a couple of graphics bundles provided, plus a program that lets you design your own sprites pixel by pixel. You can also link it to your dropbox account and use graphics you’ve placed in there.

I haven’t looked into how you export the game from codea to become a stand-alone app, but cargo-bot is living proof that it can be done and the game can then become part of the app store.

Even without this, the app provides a fascinating way to write your own code not only for ipad but on the ipad itself.  While I wouldn’t rush out and buy a class set of ipads just for this, given the opportunity to try it out I think it would be an excellent way to encourage interest in those who want to try coding. There’s a wiki that’s easily available from within the app, which includes tutorials, and while typing on an ipad can be fiddly, the editor provides enough help to take away a lot of the pain.

code listing

my complete code listing

My program has the sprite moving across the screen to respond to gravity (tilt the pad and it moves) and to touch (it jumps to the touch point).

Code is colour coded and clear to read, with parameter help and code hints. Auto completion options help to make ipad coding a straightforward affair.

One thing that I’m reminded of when looking at this is that while once upon a time it just felt like there was hardware and there was software, nowadays there are the hardware providers, the end product coders and a whole variety of people in the middle, who are providing things like game engines, physics engines and so on – the steps in the middle seem to be growing fast, each level building on the last to produce an end product that is the result of many hours of work by many people.

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!

 

Computing club

Every week after school I hold a computing club in my classroom.  In theory it’s open to anyone, but in practice I tend to get year 7 and 8 pupils coming in (11-13 year olds).  There’s a complete mix – some of the brightest kids in the school, but also those who might struggle with academic work.  A good mix of boys and girls.  They’re fairly free to choose what they want to work on, so this evening, in the midst of an OFSTED inspection, I had a couple of boys and three girls working on gamemaker projects, a couple of boys dismantling the old computer again (with less success at rebuilding it than the older students!) and one boy sitting working through a Python exercise sheet, as well as a couple of others working on various other projects.  These were kids who were all willingly staying behind after school to learn more about building their own games, programming computers and how they work.

It was the sort of scene that gives you a warm feeling inside 🙂

We do want eventually to be able to work on App Inventor, and to work properly on the lego robot in the cupboard, but for now they seem content to figure out how to make the boss die when they attack it enough, how to make the chest open when the man touches it, how to get a character to pick up a sword or simply marvel at the insides of the machine they take so much for granted these days.

Incidentally, a great introduction to game design for younger children, and a good step between playing games and using game maker, is gamestar mechanic.  In it they’re introduced to different game mechanics through a series of game challenges, starting by playing them, and building up to tweaking the settings in the games in order to fix them.  On the way they unlock features to add to their own games, and are encouraged to publish games for others to review.

One important lesson we learnt that way was not make the first level too hard – if you have stats on your game that says 200 people have played it and 2 people have completed the first level, you know you’ve started too tough!

Our year 8s were introduced to it at the end of year 7, as the final lessons of the summer term and as the end of a unit on gamemaking that saw them doing all tasks from designing graphics through programming via Scratch and eventually into level design through gamestar mechanic, and I still see several of them returning to the website as their activity of choice when given a few moments to themselves.  Indeed, some have continued on the site at home and built and published their own projects.

 

Simon says – Time to play!

the scratch version of simple simon from MagPi magazine

the original Scratch project, courtesy of MagPi

Well, we’re back at school now and settling in.  I’m looking forward to the first few computing classes next week, but I took time out this weekend to have a play on Scratch and BYOB.  I started off with a project from the latest MagPi magazine, on building a Simple Simon game in Scratch.

The game itself was straightforward, following the code given, although I was reminded in the process exactly what the broadcast and wait block does (broadcasts a message then suspends activity on that thread until the receiving thread has finished). That might well come in handy when I sort out the animations for my virtual pet, as I’d been concerned that other scripts might interrupt any animation that’s run.

However, when I played the game, I found one thing that didn’t feel right – it generates a four tone/light sequence, asks the player to repeat it, then generates a completely new five-tone sequence, which quickly makes it very difficult to play as the difficulty increases.  I seem to remember that the original version of the game would add one to the sequence each time, rather than changing it to a new sequence, so I decided to produce my own version and move it up to BYOB in the process.

The game loaded fine from Scratch, although there were one or two issues with the length of list, which apparently is handled slightly differently between the two programs.  However, I was soon picking the code apart and working on the alterations I wanted.

the block I built to cycle through a list and broadcast each item

the block cycles through a list, broadcasting each item in turn

My first problem was that the original game would generate each tone, broadcast it and then add it to the list.  If I was going to add a number to the existing list, I would need to find a way to cycle through all the objects in the list, broadcasting them one by one.  This seemed an ideal candidate for a self-built block.

Looking around the help system for BYOB and finding words like predicates thrown around merrily made me realise that despite appearances this definitely is not just for kids – while kids can quickly get up and running doing something with Scratch, it’s capable of some pretty powerful stuff, even more so in the BYOB version, although the more high-powered you go the more fiddly it gets to produce the blocks needed, with blocks within blocks within blocks.

Simple Simon game, BYOB version

Simple Simon BYOB version

I had to modify the flow of the main program in order to set up a 4 tone sequence, broadcast it, wait for response, then check it.  If the response is correct it adds to the score, generates and adds a number to the sequence then rebroadcasts, while if the response is wrong it takes a life away and replays the sequence as it is.

I definitely needed paper to scribble my thoughts on to work out the logic of the program, but it went together fairly well.  You know when a game is playable, when you have problems forcing yourself to test it rather than just playing!

The new version is more playable than the original, it makes a little use of the extra facilities of BYOB and I learnt a lot about the use of lists in Scratch/BYOB in the process.

The game currently keeps score during the game but is reset on restarting – one improvement would be to add in a high score variable, to keep track of the highest current run. I could also start the score at 4 instead of 0, so that it reflects the number of notes in the sequence.  An alternative would be to start with a one-note sequence, but that might make the game too slow to get started.

 

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.