Delivery
Module 2 - Developing a Computer Game Prototype
The students began planning the development of their game, starting with a basic storyline synopsis which was then modelled in more detail with storyboards, a flow chart, and a final brief. This established what would happen in the game, the number of levels, the gaming environment, the different objects and characters that needed to be created, and the actions they would have to perform.
“We decided that this part of the students’ planning process would not be assessed and therefore we were able to give them some feedback on their ideas and their storyboard, and advice on what may not have been thought about in the implementation, before they went to develop the prototype,” Julie explains.
This feedback ensured that the students weren’t creating briefs beyond the confines of a Year 11 project.
“Before we started we also took the students through three different game types as examples so they knew the level and what was doable or not doable. And because of that, they knew what types of components they could use and then could use those in developing their own ideas.”
Once Julie and Luke approved each game plan, students began using GameMaker to create their prototype. This involved the creation of title pages, environments and the controls and actions that each discrete object would be able to do, such as jump or move in multiple directions. They also had to take into account collision detection and other aspects common to arcade game play.

For the creation of sprites, students had to ensure that no copyrights were infringed when sourcing images or created their own sprites using applications such as Photoshop.
Once , the students trialled and tested their initial concepts to make sure there were no glitches and that game play performed as planned. The prototype was then shown to their stakeholders for further feedback.
The second module finished with the students presenting their prototype game, usually involving about three to four levels of game play, in both an executable format that the teacher could play as well as the source code. This was also accompanied by documentation of the trailing and testing process.
The programming section was by far the most challenging aspect of the unit for Julie and Luke. “Because we let each student create their own game, they weren't all going to have the same outcome. So while they had a set of specifications to meet, we still had to look at every game they developed holistically and be ready for the fact that they could possibly have branched out into different directions with their program.”
However, this flexibility did have major rewards for the students. “It was good for the girls who really wanted to go further and they actually did more exploration independently and watched YouTube videos on how to do different aspects. While other students could just meet the specifications we set.”