Teaching thinking by pretending to teach gaming.

Logic is a critical skill in game design. The ability to "test" one's logic is in my opinion a metacognitive skill that I don't believe I would have been able to get my year 9 students to do external to the activity of game design. Halfway through a game design unit I can see and evidence the progression in thinking achieved by each member of my class. The real beauty with the teaching of thinking through game design though is that it enables effective differentiation based on knowledge, thinking skills and ability.

I am using Microsoft Kodu as the game engine, and the game design task has listed certain elements to the game that must be included. One of these elements is the concept of levels. Within Kodu (and I will freely admit my knowledge is beginner) levels need to be represented differently to how they are thought of in popular games. There is not a way (as far as we have discovered) to generate stages within the game - as in you complete a stage and a new environment loads for the next stage. Observing the range of ways my learners implement the concept of levelling within Kodu is a great representation of their ability to think, apply and test logic.

Some examples that I have seen include vast open areas with sections that include different challenges. To cater for an increase in challenge script pages have been created that respond to game occurrences. For example, each section may have a golden apple. Within each section the non player characters have a page of script that responds to the number of golden apples eaten and increases their strength or damage accordingly. Others have clearly marked the number of the level (section) with a non player character that "says" through a speech bubble what level this section represents.

Some of the more enterprising students have areas of land joined by thin corridors. The corridors are blocked by an object that disappears dependent on a game occurrence. The programmed game occurrence indicates the completion of a level.

What is most exciting for me is the open sharing that is occurring when the learners are problem solving (testing logic). They swap computers, ask each other for advice, offer help without asking and a whole range of other occurrences. It is as if they realise that by sharing their knowledge, they will all create a better product. Kudos to them.

Teaching game logic with Google Blockly

My year 9 ICT class is currently learning game design. There has been a specific focus on learning the difference between game commands and game logic. I want them to understand that for each item of human input into a game there is a significant amount of game logic, and processing of that game logic, that occurs. This also has the side advantage of outlining to students why gaming machines need to be powerful in terms of processor and RAM.

We initially analysed snippets of side scrolling gameplay, identifying specific actions that require human input and mapping out the processes that represent game logic. The focus has been on the human controllable character currently. Last week I utilised Google Blockly, in particular the maze challenge, to further consolidate the difference between commands and logic.

Using Google Blockly required some preparation, as our default student system runs IE8. Google Blockly requires a browser capable of rendering HTML5 so to achieve this I installed the portable version of Mozilla Firefox on the network drive. There were issues with students trying to launch the portable version from the network with approximately 50% successfully opening Firefox. The program launch was delayed, sometimes up to 5 minutes. I am assuming this is due to numerous attempts to launch the same program off the network drive. A few students copied the installation to their local drives and the program launched as one would expect.

The concept of the Google Blockly maze is to build a script using the provided logic and commands that solves any of the mazes. Students quickly discovered they could solve a single maze by simply loading a list of commands, this required me to randomize the maze to illustrate to them that the same list of commands could not solve all mazes. I also purposely did not tell the students that aspects of the logic blocks could be changed. As the concept of testing scripts was important, this discovery would be more powerful if they achieved it independently.

Ultimately we spent 2 x 70 minute lessons on this activity. There was much discussion about solutions as they were developed and students were having conversations about errors in logic and the inefficiencies in grouping commands. The effective solutions all employed an "exploration" component in solving the mazes, and the smallest number of blocks used was 7. Personally, I could build a solution with 9 blocks.

This was an effective activity to reinforce the concepts of game logic, game commands and testing scripts. Next time I would ensure all students copied the installation folder of Firefox to their local drive before running the program.