Function Wizard - Game Design
The game premise, goals, and rules
The game places the player in a world where magic wielding requires a deep understanding of certain mathematical principles. The player is attending The Really Fancy Official Wizard Training School, where they are put through a series of training exercises meant to strengthen their understanding of functions and function transformations. Each exercise requires the player to use the specified function (line/parabola/sine wave) and apply the correct transformations to direct their water spell to put out the fire. On each level, the player is constrained in which function they may use and which transformations they may use. The player must also direct their spell to avoid any obstacles.
Mechanics
The player can cast a spell or apply a transformation to the given function. The transformations available to the player are vertical and horizontal translation (up/down and left/right shift), vertical scale, and vertical reflection. The first levels involve transforming a straight line, then parabolas for intermediate levels, and a sine wave for the final levels. There is no limit to the number of times a player can cast a spell. The transformations have upper and lower limits, which vary depending on the level. The game system is straightforward: when the water spell hits the fire, the fire is extinguished and the next level begins.
Procedural Rhetoric
The goal is for the player to learn about function transformations, and our game encourages learning through experimentation. There are no consequences for selecting an incorrect combination of transformations. To beat a level, the player must find a set of transformations so that the graph traces the desired path (from the player to the fire, avoiding all obstacles). This means the player will get to explore the effect of different transformations. Because the graph is displayed to the player, the player gets immediate visual feedback for each transformation. There is a wide range of values the player can choose for transformations (excluding reflection), and trying different values also helps the player to better understand how a particular type of transformation works. For example, choosing a positive value for the vertical translation moves the graph upwards, a negative value moves the graph downwards. Setting the vertical scale to a (positive) value less than 1 flattens the graph, whereas a value greater than 1 stretches the graph. Certain levels require stretching and others require flattening, and so the player learns that the exact effect of a transformation can depend on the specific values used, leading to an overall deeper understanding of function transformations.
Cause Map Diagram / Root Cause Analysis
Playtest Conclusions
In terms of player feedback, we learned that each person has different expectations for how the game mechanics work. Some players expected to be able to use the keyboard, whereas other players expected the arrow buttons to behave in different ways. Some players needed extra visual cues to understand what was or wasn’t an obstacle, whereas some players correctly identified obstacles right away. The exploratory and consequence-free format seemed to lead to learning for some players, whereas others simply used a brute-force approach, in which case it was not clear whether they were connecting what they were doing and seeing to what we wanted them to learn. Most of our play testers thought our last level, which was our most challenging, was fun and unique.
Our target audience is considerably younger and less technically proficient than our playtesters. While some of our playtest feedback can be applied more generally, it’s not clear what feedback that might be. For example, many of our playtesters in our first playtest expected to be able to press the spacebar to cast. A younger audience might be more familiar with a touch screen interface, and pressing spacebar might not be intuitive to them. In general, players with more gaming experience will have different interface expectations than players with little or no gaming experience. It was also difficult to know whether our game would help our target demographic learn about function transformations, since most of our playtesters were already familiar with the topic.
So overall, some of our conclusions from playtesting was that our interface should be flexible, allowing players to interact with the game mechanics in a way that felt more intuitive for them. We also believe that having a more diverse group of playtesters would lead to a better understanding of how our game design and mechanics lead (or don’t lead) to fun and learning.
