Task 6 – Implementing Your Game—Martin Levins

A discussion of how your students approached the implementation process and their key difficulties

When teaching a 9/10 class who wanted to “know how to make a game” I quickly discovered that they had no concept of anything to do with programming. This was around 5 years ago before NSW adopted the Australian Curriculum.

We looked briefly at the Pong game in scratch with the idea of getting a grip on the flow of data and logic, then discussed what sort of game we’d want to develop.

The class (all boys) didn’t like Scratch as it was “too babyish”, so we looked at some Python code and they decided to go back to Scratch.

I referred to it as a way of prototyping: we were using Scratch 2 at the time which allowed export of pseudocode from the app (something which is sadly missing from the latest versions). Pseudocode allowed us to better understand the flow of the app, and, eventually, “translate” into a language of their choice.

I suggested we start with a simple game that they would write for year 2 kids, which led us to the building of some understanding of the client base, what interested them and what their capabilities (largely dexterity) were

Some simple exercises later, the students could see that anything worth pursuing would need planning but curiously could not step away from the computer to do this.

I allocated a whiteboard to each group (the room was covered in whiteboards)  and had them section this off into roles, timelines, ideas, flowcharts; whatever would assist in the planning process.

I can’t emphasise enough how difficult it was to convince the kids that planning was the most important part and, even though they had acknowledged it, they failed to plan.

I was amazed at how far they got with this. A simple cat and mouse game morphed into a game on multiple levels, with portals to other worlds with changing “behaviour” of cats and mice.

The code that they wrote largely worked, but a lot of it was spaghetti code which proved to be impossible to decipher when they ran into problems.

Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live
John Woods

This (planning, not psychopaths) is a real challenge, especially when media and common discussion uses the word “code” as if it is something that exists in isolation and is some sort of holy quest that all must achieve.

When I taught woodwork, the mantra was “measure twice, cut once” but this similarly was a difficult practice to preach.

The empathy phase of Design Thinking tells us that we need to understand the user, something that was addressed by making the sponsor of the project a year 2 student.

I took hope when the older students said that the kids were bored with their game. When I asked “why”, they said it was because their game was too easy. “Make it harder” was my reply. They returned to say that the years 2s were now bored because it was too hard.

A lovely platform for discussing how games are designed, and another reminder of why the planning process was so important.

In a 21 minute instructional video on the Smart Garden, it’s useful to see that the discussion of code occupies less than 5 minutes.

+ There are no comments

Add yours