Monthly Archives: April 2017

To Ireland

Before I started my Masters of Entertainment Technology I visited an old friend in Northern Ireland. The following are a collection of photos taken during my trip.

Carrickfergus Castle

This slideshow requires JavaScript.

Belfast City Hall

Tesco Belfast

This slideshow requires JavaScript.

Continue reading To Ireland

Golden Expectations

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.

Fixed Visitation

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?

Continue reading Golden Expectations

Dominate – Freestyle

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.

Playtest Notes

Playtest 1

  • Date: March 29th 2017
  • Purpose: Playtesting initial concept
  • Playtesters:
    • Me
  • Time: 20 minutes
  • Playtester Comments:
    • 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?
  • Observations:
    • 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

Revisions

# Description  Purpose
1 Removed wood Was unnecessary
2 Bought chips Made counting easier
3 Made rule about connecting villages  Limit the construction of villages and temples to speed up the game
4  Gave temples life  Made possible a lose condition (all enemy temples hp goes to zero)
5  Wrote up rule set  Needed a document to playtest rules with

Playtest 2

  • Date: March 30th 2017
  • Purpose: First playtest with largely functioning game
  • Playtesters:
    • Me
    • Male – 21
    • Male – 23
  • Time: 40 minutes
  • Playtester Comments:
    • 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
    • Observations:
    • 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

Revisions

# Description  Purpose
1 Allowed world to wrap around itself Avoid issue of limitation of three building connections per building
2 Fixed in rule sheet to clarify village placement Clarification based on request
3 Added initiative system to allow the spell phase not be a guaranteed thing Stop the feeling that you were guaranteed to lose
4 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.

Playtest 3

  • Date: March 30th 2017
  • Purpose: First iteration of rule sheet, introduction of game to more ‘casual players’
  • Playtesters:
    • Me
    • Male – 28
    • Female – 30
  • Time: 45 minutes
  • Playtester Comments:
    • 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)
    • Clarify rules
  • Observations:
    • 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

Revisions

# Description  Purpose
1 Made game board bigger Reduce clutter
2 Made color coded tiles and villages Made one's own villages easier to see
3 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
4 Touched up rule page Added more pictures in case people didn't want to read

Playtest 4

  • Date: 5th April 2017
  • Purpose: Second iteration of rule sheet and 1v1v1 setting
  • Playtesters:
    • Me
    • Male – 26
    • Male – 30+
  • Time:
    • 10 minutes to understand rules
    • 40 minutes to play game
  • Playtester Comments:
    • 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
  • Observations:
    • 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

Revisions

# Description  Purpose
1 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
2 Added image of village and temple to rule set Wanted a visual indicator of what was what for easier understanding
3 Made a resource/belief tracker for easier counting Wanted players to focus on the game rather than counting chips
4 Added 2-1 conversion to rule sheet Improve the rulesheet
5  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

Playtest 5

This slideshow requires JavaScript.

  • Date: 8th April 2017
  • Purpose: Third iteration of rule sheet and 1v1v1 setting
  • Playtesters:
    • Me
    • Male 32
    • Male 26
  • Time:
    • 10 minutes to understand the rules
    • 1 hr 20 minutes to play game
  • Playtester Comments:
    • 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.
  • Observations:
    • 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

Revisions

# Description  Purpose
1 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
2 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
3 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

Playtest 6

  • Date: 9th April 2017
  • Purpose: Wanted to test what 1v1 was like
  • Playtesters:
    • Me
    • Male – 21
  • Time: 25 minutes
  • Playtester Comments:
    • 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
    • Observations:
    • 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

Revisions

# Description  Purpose
1 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

Playtest 7

This slideshow requires JavaScript.

  • Date: 9th April 2017
  • Purpose: Wanted to test out what the 1v1 with two temples was like
  • Playtesters:
    • Me
  • Time: 33 minutes
  • Observations:
    • 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

Revisions

# Description  Purpose
1 Added resource tokens onto village and temple tiles Making counting of resource income much faster

Playtest 8

  • Date: 10th April 2017
  • Playtesters:
    • Me
    • Male – 24
  • Time: 42 minutes
  • Playtester Comments:
    • 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
  • Observations:
    • Found it hard to find resource tiles since tiles were in a pile

Revision

# Description  Purpose
1 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
2  Made a box with compartments to make it much easier to find the piece you needed  Reduce the hassle in finding game pieces
3  Added the resource and belief token representations to the rules  Speed up the process of counting resources and belief

Playtest 9

  • Date: 10th April 2017
  • Playtesters:
    • Me
    • Male – 21
    • Male – 21
    • Male – 22
  • Time: 40 minutes
  • Playtester Comments:
    • 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
  • Observations:
    • 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

Revision

# Description  Purpose
1 Remove the rule of adjacent to three Players were not liking this rule and often players including myself forgot about keeping to this rule
2 Change the phrase resource cost to construction cost and phrasing around construction and upgrade of villages To clarify this
3 Added new rule for temple damage Made temples resistant to fireballs to reduce likelihood of player losing in one turn
4  Made changes to rule set based on confusions from playtest  Improve the ruleset

Playtest 10

  • Date: 11th April 2017
  • Playtesters:
    • Me
    • Male – 28
  • Time: 42 minutes
  • Playtester Comments:
    • 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
  • Observations:
    • 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

Revisions

# Description  Purpose
1 When a temple is destroyed is becomes empty More sensical outcome and reward for the player who destroyed the temple
2 Clarified offering rules in rule sheet Improve the rule sheet

What Went Right

  1. 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.
  2. 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.
  3. Adding dice rolls to attacking heightened the tension in the game and had a positive effect on gameplay.
  4. 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.
  5. 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.
  6. 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.
  7. Procedural generation of the board helped make the board experience fresh each time, increasing replayability.

What Went Wrong

  1. 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.
  2. 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.
  3. 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)

Tiny – Spring Break

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

  • 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
  • Understood story
  • 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!

This slideshow requires JavaScript.

Teacher

  • 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)

This slideshow requires JavaScript.

How Improv is Relevant

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.

Continue reading How Improv is Relevant

Tiny – Week 13

This week was spent working on UX changes as well as polish to the game.

UX Changes

A number of UX changes were made .

One Gem Solutions

One gem solutions are The changes this work consisted of solving a number of one gem solutions that appeared during playtesting.

Tutorial

Changed protractor tool tutorial to an earlier level, then introduced it again in a later level to hopefully increase the probability that players will use it.

Anti-Cheat

During our playtest it was revealed that slotting and removing a gem constantly could be used as a cheat to beat a level. We solved this issue technically by having a check for slotting, and not allowing a win to occur if a slot had occur within sometime.

Game Flow

We reconsidered the flow of the first time play experience. Initially the first time players played the game they start directly at level one. The intention behind this was done in attempt to get players attention by showing them the most interesting thing first. This was changed to start with the map first because:

  1. It was our actual homepage.
  2. Many other games followed a standard of showing the map first rather than introducing the gameplay.

Tiny – Week 12

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).

Hammertime!

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
  • UI buttons were confusing
  • Change to allow free form manipulation of gems
  • Pointed us towards Robert Siegler a professor of psychology at CMU
  • 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.

Tiny – Week 11

Starting Week 11 we finished creating digital versions of our remaining puzzles. In addition we began working on the various aspects of the game that we presented to our playtesters at the end of Week 10.

More Pieces

We added a map to replace the original level select screen. The new map would serve two functions.

  1. It would display the progression of the game to the player
  2. Create a more visually appealing method of level section

We also implemented a reward system in the form of trophy’s added to ones treasure room after completing a ‘boss level’.  We hoped such an addition would add a motivational factor for completing the game.

Later in the week Jesse Schell played the game, and suggested a new way to show treasure room. Instead of having trophys placed on the desk, have shelves arranged in a geometric way with numbers on them to reinforce the central theme of angles. In addition to this we considered including random treasures which we hoped would add a surprise factor.

Continue reading Tiny – Week 11

Tiny – Week 10

During Week Ten we prepared designs for the final levels of the game. These levels were in line with the complexity metrics we established during Week 9.

During this process we also documented our puzzles, and their solutions. This document would not only help recreate these puzzles during development, but could be handed off to teachers as a supporting document.

Meanwhile we began preparation for The Entertainment Technology Centers playtest day. This would involve members of our target demographic visiting our project rooms to playtest our game. For this day we came up with a number of questions to ask our playtesters as well as prepared video and screen recording equipment to capture gameplay footage.

Playtest Day

On Playtest day we had five groups of playtesters. Each group played the game for approximately fifteen minutes. We then conducted a short interview with them, and found several good insights such as:

  • They really enjoyed the game, we never had a case of a bored playtester
  • Even when playtesters got stuck they cried out for help, and we had cases of playtesters working together to solve puzzles
  • The protractor tool was useful, but since there was no clear tutorial playtesters found it by mistake
  • Playtesters liked the art, music as well as the treasures we would reward them with
  • Playtesters didn’t object to the main character, but found certain animations weird

This slideshow requires JavaScript.

Angle Analysis

Recently we have been working to create an educational game on angles. Part of that requires designing puzzles that try to provide educational value. The following blog post is a continuation of a look at our process.

Breakdown

The most important part when analyzing our puzzles was first to recognize our puzzle metrics. Initially these metrics were as follows:

  1. Mirror Numbers
  2. Number of slots
  3. Number of gems
  4. Gem Types
  5. Receivers
Game Elements – Draft

First Pass

We began our first pass using these metrics to craft the thirty puzzles that would form the core structure of our game. The process essentially boiled down to a table of each of these metrics listed in columns. We incrementally increased metrics until key climax moments which we referred to as ‘boss levels’. Following a boss level we dropped the metrics to allow for the introduction of a new system in a simpler environment.

Level Structure Table

Second Pass

Our first pass at developing the puzzles allowed us to create the initial structure of the experience. On further examination, points three and four actually had more depth to them. We broke these points into each and every gem value. This additional depth warranted further analysis.

We then went about constructing a meaningful method of presenting what we called ‘angle distribution’. Using this we mapped out each and every gem per level. This method of analysis revealed several levels that were problematic for different reasons such as:

  • High angle overlap
  • Had no garbage
  • Levels that were similarly structured
Gem Distribution Analysis Result

These key points conflicted with our main educational objective of improving familiarity with both numeric and visual representations of angles. As for one having a large degree of similar angles meant that the exposure to different angle values in the 360 angle system was lower. So for our second pass we went about redesigning certain levels adding in garbage, and choosing angle gems carefully to avoid overlap.

Third Pass

On making a third pass at the we again found a problem. Our third pass took the form of playing the levels. What we found was some gems were included that were direct solutions to problems in hard puzzles.

Third Pass Adjustments

We needed to weed out as though it is good that players are able to discern such a solution, we felt that doing so would mean engaging less with the angle gems in the level as several other gems were left out entirely in the solution. Thus we weeded such scenarios out during our third pass.

Conclusion

Essentially the process boiled down to a number of steps:

Analyze

  1. Carefully study the components within our structure
  2. Extrapolate areas for further fine grained analysis
  3. Develop a tool for analysis

 Adjust

  1. Apply the tool
  2. Identify and address problem areas
  3. Replay the experience
  4. Repeat adjustment

Using this process we iteratively analyzed our puzzles redesigning when necessary to ensure levels had particular solutions to problems with minimal overlap. Now with a clear design process, all thats left to do is playtest and hope the design worked!

GDC 2017, Game Design Workshop

I was fortunate enough to be able to attend this years Game Developer Conference (GDC). Whilst there I had the pleasure of attending its Game Design Workshop.

The Game Design Workshop took place over two days. Both days included a general session, and an elective. I attended both Day 1 & Day 2. The following is a brief account of the experience. If you are an aspiring designer, and have the opportunity to attend the workshop this is a must do event!

Day 1

SiSSYFiGHT

On the workshops first day we played SiSSYFiGHT. After playing a few rounds, we were asked to come up with a new theme for the game. This involved each team member writing sticky notes, grouping them then voting on a theme.

With a theme of ‘artists vying for attention in the art world’ we added a steal mechanic. The steal mechanic would allow the attacking player to gain the points the other player lost. We quickly found that this mechanic made the game go on infinitely.

We then changed our chosen mechanic to Favor. The Favor mechanic gave a single point to the player of our choosing. This mechanic was better balanced, and encouraged cooperative behavior.

Game of Games

The first elective I chose was Game of Games run by Marc LeBlanc. For the elective we created a system (we did a card game) with a single rule. Our rule had players first play two cards of the same suite. Then play another two cards which had to add up to the higher of the last played two cards. We then were instructed to merge our game with another.

Fortunately the merge was easy as the other game employed a rule that was similar to ours (it was another card constraint rule where the total of the two cards needed to add up to an odd number). We repeated this system merge process four times, until finally we had to merge sixteen different systems.

During this ‘ordeal’ the hardest part was merging a card based system with a dice based system. Our first attempt to tackle this merge was setting up two asymmetric games which were played simultaneously against each other, but this was not a satisfactory outcome.

Equipment

We continued to struggle until Marc LeBlanc allowed us to cut from the system during merging the only constraint being to keep the core components (the dominoes, dice, and cards). At that point we brainstormed and came up with a method of dealing with this which was to combine the system through a medium they all shared, which was numbers.

What we created was a game which involved matching numbers based on eleven dice that were initially rolled, and remained fixed throughout the game. Cards, and dominoes played sequentially, and had to get a pair of numbers that matched the dice’s number to be able to claim it. The winner claimed six out of eleven available dice.

A Messy Attempt at Rules

By the end of  the workshop Marc LeBlanc introduced the MDA Framework, an awesome way of design a game.

Continue reading GDC 2017, Game Design Workshop

Tiny – Week 9

Puzzles!

At the beginning of the week 9 we had our halves presentation. Following this we met Jesse Schell on Tuesday, and presented our thoughts on how we would go about designing our puzzles. His suggestion was simple.

JUST MAKE PUZZLES. Worry about the details later.

So that is what we did.

The inspiration for our puzzles came from a combination of two sources:

  1. The teaching material that our client used
  2. A map of element complexity against time

Elemental Complexity

The process of considering elemental complexity began with a consideration for the interest curve of the experience. Essentially we wanted an initial large peak then a period of rest, followed by ascending peaks with rests until a climax at the end.

When designing puzzles Level Design for Games by Phil Co suggested listing the elements of a game, and systematically designing puzzles with incrementally harder arrangements of elements.

In our case we intended to use the elements to increase complexity, but explore fundamentally the same (problems related to the 360 angle system). The elements of our game were:

  • Clockwise Gem
  • Anticlockwise Gem
  • Beam Generator
  • Power Gem
  • Receivers & Obstacles

With these elements we create a table of level against elements, and incrementally increased the number of elements. When a new element was introduced we would drop other elements to lower the difficulty experience for players to more clearly grasp the new element.

Continue reading Tiny – Week 9