Introduction: Angle Jungle is an award winning app built by a team of students at Carnegie Mellon University’s Entertainment Technology Center in 15 weeks for Pennsylvania’s Intermediate Unit 1. Angle Jungle has value to first graders and above, its primary purpose though is as a supplement for 4th to 6th graders learning basic geometry.
Platform: iOS | Time: 15 weeks | Role: Game Designer | Team Size: 4
Design Goal: The goal of the project was to achieve the following transformations in our target demographic:
Primary Transformation: Build familiarity with the angle by having players solve puzzles that use a mechanic that encodes the numeric and spatial representations of angles
Introduce positive and negative angles
Introduce clockwise and anticlockwise rotation
Introduce angles greater than 180 degrees
Build familiarity with the protractor tool
Design Challenges: We faced a number of design challenges during this project:
Protractor tool introduction
Finding an mechanic which made angles essential
Crafting fun and engaging puzzles
Crafting additional sources of motivation
My Contributions: As the game designer on the project I took the lead on directing our creative efforts. My efforts helped create a well received, fun, and engaging experience which made a good attempt to achieve our transformational goals. Other areas I made significant contributions in were:
An ideation process that created the main mechanic of the game
Can puzzle complexity serve a transformational goal?
In this article I will consider this question, by first describing the design process used to create puzzle complexity which serves a transformational goal. Next I will contemplate the results of that puzzle complexity which is contained in the game my team created.
Angle Jungle is an educational puzzle game for fourth to sixth graders studying geometry. Initially our requirements were up in the air, though we eventually settled on the following rather vague objectives:
From our paper prototypes, we choose to refine two based on feedback.
We parallel we began the process of creating digital prototypes based off these paper prototypes.
Our breakthrough moment came when Jesse Schell, our Professor, posed to us that though these games used angles, both could be played without thinking about angles. We therefore needed to make angles essential to the experience. This priceless notion lead us to create Angle Jungle’s progenitor, which we called Treasure Hunter.
Treasure Hunter we believed embodied a system where angles were essential. At its heart a mechanic that encoded the relationship between the numeric, and spatial representation of angles.
We then began refining Treasure Hunter.
After positive feedback from playtesting we next created a digital prototype.
This digital prototype went through multiple iterations.
At this point in the development process we had the beginnings of a game. The game cried out for something more though. It cried out for a greater experience.
How does one go about creating an experience? There are infinite ways, but we began with considering the difficulty curve within our experience.
The above graph is an abstract difficulty curve which displays a sequence of tense and release cycles of increasing difficulty. This curve would form the underlying foundation of our experience.
With an idea of what we wanted the experience to look like, next we conceptualized the elements within the greater experience. The inspiration for this process came from a number of sources including the learning materials of our target demographic.
Our aim was essentially to gamify our target demographics learning material through gameplay elements which attempted to capture aspects of the kind of problems they faced in the classroom.
These gameplay elements would form the core components of the experience.
Whilst conceptualizing our gameplay elements we also considered the possibility that the puzzle may not be intrinsically motivating enough for players. We therefore created two additional supporting motivational factors.
A gender neutral character than needed assistance (inspired by Jesse Schell’s lens of help). Given the use of characters in educational experiences is fairly common, and that there exists research on the potential beneficial effects for players. We hoped this would augment learning within our experience.
In addition we created The Cabin. The Cabin would contain our players reward in the form of treasures and trophies. The Cabin would act as motivational element by creating Golden Expectations (expectation of rewards) through the aesthetic use of empty shelves as well as serve as a measure of game progress.
We also recognized the need to space out our rewards for better impact. We therefore arranged rewards into evenly spaced intervals.
Together these pieces could further flesh out the difficulty curve of our experience. The peaks of our difficulty curve would now commonly correspond to the introduction of gameplay elements, and the dips, periods of rest at The Cabin.
The experience needed more though. It was a skeleton crying out for substance in the form of puzzles. It cried out for depth, and complexity.
With a high level view, and the fundamental elements of the experience in mind we went about crafting puzzles, inspired by our source material and gameplay elements.
This process resulted in a jumbled pile of puzzles which though was a good first step, did not fit the experience structure we wanted. We therefore turned to a mighty tool.
The spreadsheet consisted of columns of each gameplay element which we incrementally increased to increase puzzle complexity. This tool complemented the design process as we created more puzzles based on these new complexity constraints.
Two additional considerations came to mind during this process:
Include drops in puzzle complexity when introducing new gameplay elements to allow for more effective tutorials
Have the majority of learning occur early when complexity is low
The result of this work was a structure of thirty levels which we then playtested.
Although initial playtests were largely positive they revealed two design issues:
Certain puzzles contributed to a lack of ‘Angle Diversity’ (high occurrence totals of fewer number of angle values in the total experience meant a lesser exposure to different angle values)
Several puzzles had one gem solutions (solutions which required only one angle gem on more complex levels meant less interaction with different angle values within a puzzle)
Both these issues were detrimental to our goal of building familiarity with the angle system, therefore further puzzle analysis was required. Our analysis was twofold:
Angle Distribution Analysis – A spreadsheet of counts of each angle value used throughout the experience
Angle Solution Analysis – A comparison of solution angles against angle values used
These methods revealed a number of such ‘issue’ levels.
The result of iteratively applying this analysis was that both the complexity and angle diversity was maintained, and improved. This ultimately meant a better attempt at achieving our transformational goal.
So what objective was our experience serving? Though we began with a vague set of requirements. At the end of the project we ended up with a concrete primary transformational objective, and several secondary transformational objectives.
Build familiarity with the angle system by having players practice solving puzzles using a mechanic that has an encoded relationship between the numeric and spatial representations of angles.
Sharon Carver – ‘The actual angle choices at the various levels and the angle meter seemed to work well and COULD promote learning of the concepts and spatial relations of angles, as long as students don’t game the system’
In addition to our primary transformational objective we took the opportunity to introduce a number of secondary transformational objectives in manners that were natural extensions of the core experience.
Protractor Tool Usage
To solve a puzzle a player had to work out the angle that was required to be made to hit an objective. This provided a natural opportunity to introduce a scaffolding tool, the protractor, a measurement device that’s original purpose was designed to aid in angle measurement.
By making this tool available we built in the protractor in a manner that was of a natural clear benefit to our players. We hoped by doing so to build familiarity, and appreciation of the tool by creating a puzzle environment where it was undoubtedly helpful. Playtesting showed that this strategy ‘seemed’ to work.
Sharon Carver – ‘I especially like the meter that shows the full 360 degrees while the player is working on selecting angles. It would definitely be worth testing the impact’
Introduce both anticlockwise and clockwise rotation, and angle addition and subtraction.
Angles Above 180
Expose students to angles greater than 180 degrees.
Whilst exposing students to our core mechanic (an encoding between the numeric and spatial representation of angles) through out the experience, initial levels would allow brute force approaches to be rewarded in order to draw in the player with easy rewards.
Considering the support of such ‘brute force’ (choices made without solid reasoning) approaches, the following criticism was raised:
What if players are not doing the thinking you want?
In defense of brute force we responded with a number of counter points.
Absolute mindless play is rare, so given the numeric angle values are essential, even with a brute force approach players are likely to at least reason about this aspect of the game
Supporting brute force approaches makes the experience more accessible (we had first graders reach level 22 with help!)
Brute force approaches are only reasonably satisfying in low complexity puzzles (playtesters who solely practiced this method eventually called the game stupid on more complex puzzles)
Most importantly though, we admitted that when complexity was low players would not have to think ‘much’.
This was intentional.
The experience allowed it for a deeper purpose.
We intended to combine that brute force motivation together with puzzle complexity as a transformative tool. As puzzle complexity increased we intended that the balance naturally shift to incentivize a ‘logical’ approach (choices made based on solid reasoning) given it is more efficient than a brute force approach.
In addition, we believed the benefit of a slow increase of complexity would naturally create skill appropriate ‘teachable moments’, which could be capitalized on by teachers, as students reached the boundary between brute force and logical. A complexity design of this type I called transformational complexity given the experience it created during gameplay.
The results of this process we believed created an experience that contained:
Suitable learning and puzzle complexity curves
An appropriate pattern of tense and release
Rewards interspersed appropriately
An exposure to a wide variety of angle values
A mechanic where angles were essential (encoded the relationship between spatial and numeric representations of angles)
Relevant and hopefully effective motivational elements
As part of the educational game project my team was working on we were required to build a reward system. This system took the form of a trophy room which would display trophies that players had earned. After playtesting though we found we had created an expectation for treasure which we were not fulfilling. The following is a gameplay video where our players would collect treasure chests at the end of each level.
So in order to fulfill this expectation we created additional art assets which we would use to fill up our empty room. We faced a dilemma in this regard. We did not want to force players to see treasure added to the room at the end of every level. This would be far too disruptive to the game experience. So how does one fulfill the expectation of reward without forcibly having the player see the reward appear?
Well one thing helped us in this regard. We already designed fixed reward intervals through the trophy system which forced players to go to the trophy room and observe the new trophy being added to the trophy room.
In our experience we had periods of fixed visitation where the player would be guaranteed to be seeing the Trophy Room. Looking at the experience more methodically we were giving trophy’s at the following intervals (we had thirty levels).
One and thirty were absolutely necessary since they began and ended the experience. The others were decided based on difficulty curve which was designed in previous weeks. Again we asked ourselves the question. How does one fulfill the expectation of reward without forcibly having the player see the reward appear?
As part of the Game Design course taught by Jesse Schell at Carnegie Mellons Entertainment Technology Center, we were required to create whatever game experience we wished. The one requirement we had for this experience was that it was to be excellent! So I created Dominate, a tablet top strategy game!
In addition to creating the experience we prepared a marketing and rule sheet, as well as a written record of our iterative playtest driven process. The following is materials from my playtest notes.
Date: March 29th 2017
Purpose: Playtesting initial concept
Time: 20 minutes
A significant number of broken rules
Two resources for construction, sheep and wood were unnecessary
Need a method of counting the different resources, can’t keep track of it mentally
How do I know when I won?
Playtesters had trouble counting tokens
Giving players the choice of resource location made resource placement polarized and clumped
Since no restrictions of village placement players would build lots of villages around themselves making the game drag out longer
Made counting easier
Made rule about connecting villages
Limit the construction of villages and temples to speed up the game
Gave temples life
Made possible a lose condition (all enemy temples hp goes to zero)
Wrote up rule set
Needed a document to playtest rules with
Date: March 30th 2017
Purpose: First playtest with largely functioning game
Male – 21
Male – 23
Time: 40 minutes
Fireball need chance on hit, I didn’t like knowing I would lose for sure
Who casts first should be based on a dice roll, again I didn’t liked knowing I would lose for sure
The rules for village placement are confusing
Found resource collection rate difficult to count
Liked the strategic element in fireballing then converting enemy villages
Players had a good time
Players wasted a lot of time counting resources
Found an issue when a player placed their temple in a certain pattern, they became blocked from building
Both my playtesters were programmers
Allowed world to wrap around itself
Avoid issue of limitation of three building connections per building
Fixed in rule sheet to clarify village placement
Clarification based on request
Added initiative system to allow the spell phase not be a guaranteed thing
Stop the feeling that you were guaranteed to lose
Add a conversion of resources to belief 2:1
People seemed to enjoy the spell phase more than the build phase so I wanted to charge up the spell phase. Also it was one method of increasing the utility of resources making investing in resource growth more useful.
Date: March 30th 2017
Purpose: First iteration of rule sheet, introduction of game to more ‘casual players’
Male – 28
Female – 30
Time: 45 minutes
Make the game board bigger!
Color code the villages!
Board is so cluttered, can’t see anything!
Don’t need initiative rolls every time, just do contest rolls on build if wanting to build in the same spot (everyone declares where they are planning to build then builds)
Playtesters got bored waiting for their turn
Playtesters didn’t read the rules at all
Playtesters had great difficulty counting belief and resources
Playtesters found the world wrap rule super hard to visualize
Both my playtesters were more artistic individuals, casual game players – from the previous playtest it seems that my game is more suited to strategy game fans
Playtesters converted all their resources in belief as they found that part most fun
Playtester though the strategy of high belief would work. but lost because had no base of resources to sustain that burst of belief
Made game board bigger
Made color coded tiles and villages
Made one's own villages easier to see
Introduced contest rolls on build
Way to allow free for all building while allowing to resolve two players wanting to build on the same place
Touched up rule page
Added more pictures in case people didn't want to read
Date: 5th April 2017
Purpose: Second iteration of rule sheet and 1v1v1 setting
Male – 26
Male – 30+
10 minutes to understand rules
40 minutes to play game
Include pictures of tiles on instructions
So what is the victory condition?
Mention influence earlier
Use the word adjacent, its more clear
Clarify construction rules, they are not clear
Mention that villages at 1 development level cannot be destroyed
Typo on spells, town not village
Watching these playtesters reading the rules showed that I needed to change the information order to make the document easier to process
Playtesters were confused that they needed to select separate colors
Playtesters placed tiles on top of each other which I needed to verbally clarify
Playtesters found the phrasing of various parts of the rules confusing, and had to jump back and forward in the rule book to understand the rules
Players found the overlap rule confusing
Players found counting the resources wasnt too bad
Player suggested using higher value counters to make collection of resources faster
Players suggested a counting tool to keep track of how much you need to collect
Players suggested bidding resources to win the spell phase
Players suggested building should not be simultaneous but instead be one after another like before
Players suggested a thematic change to lighting bolt
Player had difficulty understanding the rules at first but then got into the game
Players felt the counting of belief and resources was most tedious
Reduce cost of fireball to 1 but introduced a probability of it missing (intention is to create more tension when attacking)
Create a balanced fireball spell with an element of chance
Added image of village and temple to rule set
Wanted a visual indicator of what was what for easier understanding
Made a resource/belief tracker for easier counting
Wanted players to focus on the game rather than counting chips
Added 2-1 conversion to rule sheet
Improve the rulesheet
Made variety of fixes to rule sheet e.g reordered sections – clarified victory conditions – made explicit mention that tiles dont stack – clarified construction rules – explicitly said players are assigned colors
Improve the rulesheet
Date: 8th April 2017
Purpose: Third iteration of rule sheet and 1v1v1 setting
10 minutes to understand the rules
1 hr 20 minutes to play game
Playtester complained that reading the rules felt like studying
Very interesting moment when players said no need for chips use the income tracker to keep a track of how much you have instead
Playtesters mentioned income tracker could use a zero
Playtesters suggested having some visual indicator for turn order
Players wanted the resource and belief tokens on the income tracker to be more obvious
Playtesters found the income tracker awkward to use, and instead wanted more numbers on it instead of having to do arithmetic
Playtesters wanted a more efficient way of removing and adding villages to the board, and suggested making color coded physical representations of the village which could be placed and removed from the board
Playtesters suggested carefully considering how to manage the player who would lose the game early – either give them incentives to stay after losing, design it so they can continue and have an incentive to stay, or accelerate the game to end quickly
Playtesters suggested trying 1v1 or 2v2 game format.
First time I explained as little as possible and had playtesters read the rules and play, had to explain income tracker.
Playtesters understood how to generate the board, and do the initial game setup
Had to explain the income tracker
I needed to explain both how to represent development levels, how to use the income tracker, and using d6 to represent hp on the temple
Players never used the offering mechanic
With three playtesters the maximum amount of belief/resources reached around 15-16
What happened was a Mexican standoff moment where each player had direct access to attack the other players temple, and it turns out that based on chance of spell phase the weakest player actually won the game because one player destroyed one other player and the weakest won the spell phase of the next turn and killed the other player before they could retaliate
Changed the income tracker to the warchest a tool for keeping account of how much resource and belief a player has
Completely eliminate the need to use chips for keeping track of a player's belief and resources
Kept the offering mechanic
Wanted to test how it would affect a game when used properly and it was designed reduce the power of the spell phase and also mess with the power that a guarantee of casting spells first gave
Changed the income tracker to warchest also added a zero on it
Completely removed the need to use chips to represent the amount of resources you had allowing players to focus even more on the core experience
Date: 9th April 2017
Purpose: Wanted to test what 1v1 was like
Male – 21
Time: 25 minutes
Playtester got upset and felt cheated by the game because didn’t fully understand the rule of only allowed to connect to three adjacent buildings
Playtest was short, and other player lost very quickly, playtester wasn’t happy at all, felt cheated by the game
Problem was they were in a situation where they could not build anything anywhere – I think a solution that would be in the 1v1 game mode give players two temples rather than one to add more skill to it
Used the offering mechanic to spell first
Made three game modes – 1v1v1 – 2v2 – two players with two temples each – 1v1 – each player has two temples
Avoid the disastrous playtest happening again with giving a single player two temples
Date: 9th April 2017
Purpose: Wanted to test out what the 1v1 with two temples was like
Time: 33 minutes
The dynamic was certainly different, two allied temples were placed back to back
Other two were on sides of map
What ended up happening was that middle two gained lots of resources and that built up over time, eventually the aggressive village tactic was overcome by resource snowballing and the central allied players eventually won, and the two outer players forfeited before the end of the game
Found that placing resource chips (chips that represent the resource income of a tile) made counting of resources so much faster, will do it in future playtests
Added resource tokens onto village and temple tiles
Making counting of resource income much faster
Date: 10th April 2017
Male – 24
Time: 42 minutes
Initially I was doing well then the playtester converted a critical village and I lost
Playtester liked the idea of converting resource to belief
Told me that playing required multidimensional thinking, resource gain, blocking, and long term growth
Resources became so important because of offering system
Required finding critical villages and capturing them, anticipating your enemies offering
Playtester commented that warchest system was good, but they didn’t mind the old system of counting chips one by one
Playtester appreciated new method of displaying village and resources on map
Found it hard to find resource tiles since tiles were in a pile
Playtester found better way of arranging belief and resource tokens on warchest. Keep it by the side as to not obstruct the numbers. Will update that in the rule set
Improve warchest by having tokens not obscure the warchest
Made a box with compartments to make it much easier to find the piece you needed
Reduce the hassle in finding game pieces
Added the resource and belief token representations to the rules
Speed up the process of counting resources and belief
Date: 10th April 2017
Male – 21
Male – 21
Male – 22
Time: 40 minutes
Asked if resources were generic
Couldnt find use for belief
Confused about building only within area of influence
Found village upgrade table super confusing they thought it cost one to upgrade to level 2
Got confused by a line that said build first cast spell last
Highly disliked the whole 3 adjacent village thing
6×6 feels small for 4 players
Game suffers from same problem as RISK where one player clearly snowballs to victory
Feels like you know who is going to win from the start based on the position
Playtesters said consider a large map and multiple temples
Playtesters suggested giving temples some resistance to fireballs
Read the rules in 6 minutes – skimmed it
Allied players placed their temple in a resource rich but locationally disadvantaged position, and were unable to get lucky enough to break out of their bad positioning and so lost the game
Playtesters did not know the rule of adjacent first and so placed thinking they could place anywhere and that they said messed up the game for them
Remove the rule of adjacent to three
Players were not liking this rule and often players including myself forgot about keeping to this rule
Change the phrase resource cost to construction cost and phrasing around construction and upgrade of villages
To clarify this
Added new rule for temple damage
Made temples resistant to fireballs to reduce likelihood of player losing in one turn
Made changes to rule set based on confusions from playtest
Improve the ruleset
Date: 11th April 2017
Male – 28
Time: 42 minutes
Destroyed temple should become empty
Board still needs to be bigger, still feels cluttered but is improved from before
Fun game, liked the warchest system
Moving around map, places hard to reach
Didn’t want to place 1 belief villages as it was suboptimal
Inert villages seem weird in 1v1 didnt think to convert own because it felt you already owned it
I would play again
Real time strategy board game
Wished there was another dimension to movement
Player went crazy in converting to belief to try and take me out quickly
I invested in building up resources and eventually snowballed to victory
When a temple is destroyed is becomes empty
More sensical outcome and reward for the player who destroyed the temple
Clarified offering rules in rule sheet
Improve the rule sheet
What Went Right
Warchest system was a marked improvement over the old system of counting chips. The warchest cleared up the playspace and created an easy way for players to keep track of their resources without fussing around with chips. This allowed them to focus on the game.
New method for representing income and belief made collecting resources at the start of the turn much easier, before a significant amount of time was wasted counting, and this was a marked improvement.
Adding dice rolls to attacking heightened the tension in the game and had a positive effect on gameplay.
Once players got over learning the rules they had generally positive feedback about the experience, particularly that throughout the game players had the option of several interesting choices.
Adding the resource to belief conversion rule was highly appreciated. By doing so it created a good reason to invest in growing one’s village network so that a player had more resources to convert to belief. Now players would avoid wasting placing villages that weren’t connected to a resource. This helped address the problem I had seen in my first playtest of arbitrarily building villages.
The way the game was designed allowed it to be very easily scalable in terms of grid size, number of players, temples per player, resource tiles per column. This design supported a wide variety of game modes 1v1/2v2 which felt distinct, and so the game was more accommodating to different numbers of players.
Procedural generation of the board helped make the board experience fresh each time, increasing replayability.
What Went Wrong
Playtesters didn’t spend much time reading the rules, and so made suboptimal choices in the game and got upset, and felt cheated by the game. What was particularly bad was placement of temples and villages. If placed incorrectly could mean the game was lost if players didn’t get lucky with die rolls.
As one playtester pointed out my game suffers from the problem in RISK where one player will snowball to victory and this is apparent. This caused forfeiting to occur multiple times to save time because the odds were clearly stacked against the player. RISK attempted to address this problem with country cards that gave bonus armies, perhaps something equivalent would help my game.
Procedural generation of the board acted as a double edged blade. If in the case the board was generated in a manner that made blocking of a players progress easy, new players felt upset and cheated (in tandem with point 1)
During Spring break we had the chance to playtest a digital prototype of our game. The game consisted of five puzzles, and the intention of the playtest was to see if our target demographic and client (Colonial School) liked the game, and their thoughts. Feedback from both the teacher, and our target demographic was as follows:
Kids like the game
Thought it was easy, wanted more challenge
Understood the mechanic immediately
Completed the game within 5 minutes
When asked about characters they wanted they mentioned all kinds of animals they saw in the jungle
Again asked for a wrestler
Had no major complaints about art or mechanic or story
One kid wanted dragons
One kid recognized it was a maths game but kept playing
Asked for more levels!
Teacher liked the game
Said reverse angle gems (move in opposite direction) would be fine but only on advanced levels
Wanted some source of competition so star rating system should have a total for students to compete against each other
Teacher said using games to teach angle of shapes would be fine
Teacher said students are not taught physics at their level (leaving physics out is a good idea)
Improv is a skill we use every single day, it is a facet of how we deal with the unknown, and its development has incalculable benefits to our lives. Whilst at The Entertainment Technology Center the following exercises I found most useful:
I Own This Place
In this exercise we would receive a card from a pack of playing cards which would assign us a number. Based on that number we would adopt a status between extreme high and low.
Learning the concept of high, and low status as well as their traits has allowed me to reflect on myself. Not only do I better recognize status traits in others, but I intend to use this knowledge. I aim to exhibit higher status, and avoid lower status traits as I feel they are essential for many things including leadership positions which is what I aim for in my career.
Different Language Conversation
This exercise involved sitting in a semi-circle, and talking to each other in different languages.
My take away was a reinforcement of how paying attention despite not understanding is important. In and out of the industry we will have conversations where we don’t understand the ‘lingo’ of the speaker, such as when listening to highly technical speakers. Listening intently in those cases improves the conversation by respecting the speaker, and allows for a smoother transition to a language one does understand.
At the start of week twelve polishing the game was on the forefront of our minds. In this regard, design wise we continued to struggle with small, but vitally important decisions namely considering the visual representation of angles during gameplay and the introduction our scaffolding tool (the protractor from week eleven).
We met with Jessica Hammer on Thursday to get a perspective on what we had done and the issues facing us. She told us the following:
Clarify our learning goals and sort it out into a table
Make red and blue gems beam movement uniform, so red always goes anticlockwise, and blue always goes clockwise
Reconsider the visual representation of clockwise movements
Interest in protractor tool introduction and suggested we put it on level three where we introduce no new things and so cognitive load is not high
Jesse to the Rescue!
Following this we met with Jesse Schell on the evening of the same day. Being the masterful designer he is, Jesse gave us a suggestion of displaying the spatial representation of the angle.
Jesse’s suggestion was when the beam rotated clockwise, the beam maker would make the full 360 degree representation pop out, and be subtracted from when the beam moved past 0. In the case of the beam rotating anticlockwise the sector would grow as the beam moved anticlockwise.
We implemented this feature, then spent the rest of the week playtesting the levels we had, and weeding out one gem solution angles.