Introduction: I had the privilege of joining Ubisoft Düsseldorf as one of the first level designers on Assassin’s Creed Nexus VR, progressing from foundational architecture through senior iteration to lead over 4 years of development. I designed and shipped the Italy level content for the Oculus platform alongside a multidisciplinary team, establishing standards and mentoring designers that carried through to launch.
Platform: Oculus VR | Time: 4 years | Role: Level Designer → Senior Level Designer → Lead Level Designer | Team Size: ~15 (level/design) | Design Goal: Deliver immersive, high-fidelity Italy missions grounded in AC lore while establishing scalable design architecture.
My Contributions
Foundational Work
Established a content extraction pipeline from Assassin’s Creed 2, collaborating with original AC2 team members and technical art to recover and validate legacy assets—work that became training documentation for art teams across Ubisoft.
Translated narrative briefs into foundational level design documents for Return to Monteriggioni and Cult of Hermes Reborn, working directly with directors for validation.
Collaborated with mission tech teams to architect scripting standards and methodologies that became the reference for all Italy missions shipped.
Senior Iteration & Delivery
Owned execution and iteration on Return to Monteriggioni and Cult of Hermes Reborn, delivering golden flow, puzzle support, narrative integration, enemy encounter design, and cross-disciplinary collaboration (audio, VFX, environment art).
Cult Headquarters: Designed and delivered this bespoke space from concepting through final dressing—touching level design, scripting, blockout, audio, narrative support, and environmental art integration.
Designed Venice Carnival and Leonardo’s Workshop experiences, each requiring tight narrative pacing and spatial storytelling.
Leadership
Led a team of technical and level designers through launch, shifting focus to critical refactors and high-risk technical work while empowering team autonomy and growth.
Mentored external designers and onboarded new team members with documentation and knowledge transfer.
Supported hiring efforts through CV assessment and candidate evaluation.
Outcome
Assassin’s Creed Nexus VR launched to critical acclaim and industry recognition, validating our design pillars of immersion, agency, and environmental storytelling in VR.
Jibran Khan built the Angle Jungle game as a Free game. This SERVICE is provided by Jibran Khan at no cost and is intended for use as is.
This page is used to inform visitors regarding my policies with the collection, use, and disclosure of Personal Information if anyone decided to use my Service.
If you choose to use my Service, then you agree to the collection and use of information in relation to this policy. The Personal Information that I collect is used for providing and improving the Service. I will not use or share your information with anyone except as described in this Privacy Policy.
The terms used in this Privacy Policy have the same meanings as in our Terms and Conditions, which is accessible at Angle Jungle unless otherwise defined in this Privacy Policy.
Information Collection and Use
For a better experience, while using our Service, I may require you to provide us with certain personally identifiable information. The information that I request will be retained on your device and is not collected by me in any way.
The game does use third party services that may collect information used to identify you.
Link to privacy policy of third party service providers used by the game
I want to inform you that whenever you use my Service, in a case of an error in the game I collect data and information (through third party products) on your phone called Log Data. This Log Data may include information such as your device Internet Protocol (“IP”) address, device name, operating system version, the configuration of the game when utilizing my Service, the time and date of your use of the Service, and other statistics.
Cookies
Cookies are files with a small amount of data that are commonly used as anonymous unique identifiers. These are sent to your browser from the websites that you visit and are stored on your device’s internal memory.
This Service does not use these “cookies” explicitly. However, the game may use third party code and libraries that use “cookies” to collect information and improve their services. You have the option to either accept or refuse these cookies and know when a cookie is being sent to your device. If you choose to refuse our cookies, you may not be able to use some portions of this Service.
Service Providers
I may employ third-party companies and individuals due to the following reasons:
To facilitate our Service;
To provide the Service on our behalf;
To perform Service-related services; or
To assist us in analyzing how our Service is used.
I want to inform users of this Service that these third parties have access to your Personal Information. The reason is to perform the tasks assigned to them on our behalf. However, they are obligated not to disclose or use the information for any other purpose.
Security
I value your trust in providing us your Personal Information, thus we are striving to use commercially acceptable means of protecting it. But remember that no method of transmission over the internet, or method of electronic storage is 100% secure and reliable, and I cannot guarantee its absolute security.
Introduction: Whilst at Automaton I worked as a Level Designer, where I iterated and developed world content for Mavericks a next-gen Open-World MMO FPS developed in CryEngine using SpatialOS.
Platform: PC, Xbox One, PlayStation 4 | Time: 2 months | Role: Level Designer | Team Size: ~40
Design Goal: Deliver a 1.8km battle royale play space for the alpha release of Automaton Games’s original IP‘Mavericks’, a next-gen Open-World MMO FPS developed in CryEngine using SpatialOS.
Paper Maps
Papers map concepts.
Natural World/Minor Points of Interest (POI’s)
Iterated and developed the natural world whilst distributing minor points of interest for further iteration by art. Major tasks for this included:
Reference gathering.
Terrain sculpting.
Texture painting.
Foliage placement.
Blockout, and iteration of POI’s.
Mid Size POI’s
Blocked out, and iterated a number of mid sized points of interest.
River VIllage
Sawmill Deforestation Iteration 1
Sawmill Deforestation Iteration 2
Iterated on flow, and cover of existing mid sized points of interest.
Large POI’s
Sawmill POI
Trainyard POI
Biomass POI
Enhanced existing major points of interest, as well as blocking out significant areas of the Sawmill, and Biomass POI.
Introduction: I once again had the opportunity to work for DICE LA. This time round I was given additional ownership, and made contributions in Battlefield 5’s content Chapter’s 3 and 4.
Platform: PC, Xbox One, PlayStation 4 | Time: 1 year | Role: Multiplayer Designer | Team Size: ~100
Design Goal: Support Battlefield 5’s live service pipeline with high quality content for players.
My Contributions
Chapter 3: Trial by Fire
Firestorm
Augmented EA Criterion’s design of Lake Village a major point of interest in Battlefield 5’sFirestorm game mode.
Using Confluence I created level design notes for implementation by level artists of natural areas, major and minor POI’s in a several 1km areas of the Firestorm launch map.
The note format prepared in confluence was set by EA Criterion as a standard for level designers on the project.
Mercury
Initial fortification design, then iteration with a senior designer.
Introduction: Over the summer of 2017 I interned at DICE LA, a studio of Electronic Arts. My time was spent working with DICE LA to ship the downloadable content In the Name of The Tsar for Battlefield 1.
Platform: PC, Xbox One, PlayStation 4 | Time: 12 weeks | Role: Game Designer | Team Size: ~90
Design Goal:
Deliver high quality level content through iteration.
Develop my ability to analyze and critique level design in a professional environment.
Practice supporting the efforts and vision of senior designers on the team.
My Contributions:
Bolstered Battlefield 1’sDLC content with map analysis. This took the form of:
Collecting, processing, and documenting Battlefield 1 level data for use by senior level designers.
Offering map feedback on flow, map features, cover, spawn placement, and play space volumes.
Used Frostbite’s visual scripting language to implement:
Content bug fixes from JIRA tickets.
Then iterate based on feedback of game modes such as Supply Drop, Team Death Match, War Pigeons, and Domination for multiple levels in the DLC pack.
Dice that determine a persona in a social situation
Team based game where there are fixed resource which each collects
Game has a number of chips, and a dice is thrown that has on it a number of concepts e.g fruit, country. Whatever comes up the first person to name something in that category wins that chip.
Game where two players roll together to score points, matching dice score a point mismatching lose points, single winner to 6 points win – problem is that probabilities are ⅙ of scoring so losing happens a lot more.
Game where players throw dice and winner takes chips
What about a game that you roll and everyone but you can see your dice
From these ideas I developed some candidates.
Candidates
Candidate 1
Taking idea two and the game LCR I developed a prototype. In this prototype players would hold three cards they kept hidden. Each would initially be one of each color card R,G, or B. The mechanic was two dice were rolled and based on the number you had to pass one card to the person opposite, left or right to you. The goal of the game was to collect all of a certain color.
Playtest
Date: February 1 – 14:00
Playtesters: Me
Time: 10 minutes
The game felt too random, and didn’t feel good having three cards and having to hand away two every turn. It destroyed a player’s strategy of trying to collect all of them.
I tried a team version of this game, and had trouble at end when judging if you had won or not. This was because players had no good way of guessing whether their team mate had the last card that they didn’t have. Finally I moved on to another candidate.
Candidate 2
Considering idea 5 I found a dice game called Mexican. I liked the idea of dice battling against each other for lives. I modified this idea to instead use numerically increasing value gains with chips.
Initial Rules
Each player has two dice and 10 chips
Players throw 1 chip on the first turn and one more every turn
Each turn a player trolls two of their dice and the winning player takes double what they bet
In the case of draws players reroll till a winner emerges
Playtesting
Playtest 1
In this playtest I did not have any prepared materials and so used a mish mash of dice and tokens.
Date: February 1 – 20:00
Playtesters:
Male, 24, semi novice dice player
Female, 22, novice dice player,
Me
Time: 5-6 minutes
Playtester Comments:
Token added a lot, nice glass smooth
Didn’t like how dice were different in any other way than color, felt like some dice were better than others
Would make for a nice drinking game
Enjoyed it, and didn’t bet extra at all
Intense, short experience with very little strategy, but fun
Playtesters thought 6-6 should be a special case
Draw cases not well defined
Observations:
Playtesters had trouble counting tokens
Revisions
#
Description
Purpose
1
Changed rule set now when a round of players have been completed only then is the minimum amount increased
Slow down the game to try encourage strategic thinking.
2
Draws split the pot evenly
Handling of draw cases
3
Bought chips
Made counting easier
4
Made 6-6 a special case as an automatic win
Reward for special case
Playtest 2 - 1
Date: February 2 – 21:00
Playtesters:
Male, 24, semi novice dice player
Male, 30, advanced player
Me
Time: 15 minutes
Playtester Comments:
Casual players enjoyed it less because of slow down of pace
More experienced players played the strategy of making slightly bigger bets at the beginning, but still lost and felt frustrated because the game requires little skill
Observations:
Special case of 6-6 never occurred
Increasing the bet by one per round added a lot of tension quickly, might make it after a whole round of players to encourage strategic thinking
Revisions
#
Description
Purpose
1
Added 1-1 special case
Increase the probability of a special roll
Playtest 2 - 2
Date: February 3 – 21:00
Playtesters:
Male, 24, semi novice dice player
Female, 22, novice dice player
Male, 25, experienced player
Me
Time: 8 minutes
Playtester Comments:
Casual players still had fun
Hardcore player still didn’t have fun at all because they interpreted the game to have little or no strategy which did not appeal to him
I played with the casual players from Playtest 2-1 who preferred that version
Observations:
Game snowballed if player initially won, because they would continually bet minimum and people initially lost tended to keep losing chips.
Game became a more fun for remaining players who started betting all in or big bets to end quickly but was boring for people who got out early.
Revision
I wanted to add an element of skill so I overhauled the rule set and added a thematic element to the game.
Thematically I imagined a king setting a standard somewhere on a bell curve and a bunch of jesters trying to out do each other with displays to Please The King!
#
Description
Purpose
1
Made each dice the same size
Eliminate 'feeling; of difference between dices
2
Added a public non player controlled dice to control probability calculations
Added more strategy to the betting system with a fixed value judgement
3
Added a mechanic called King's favor
A method to addressing stalemates. First consideration of numeric difference to consider many cases of non matching rolls. Next is consideration of matching rolls based on numerical matching. Design moves towards kings exact preference
4
Rethemed game to call it Please the King!
Wanted to create a motivation and story around the game to add to experience
Wanted to start working on a written rule sheet so I didn’t have to explain it every time
Playtest 3
Date: February 4 – 17:30
Playtesters:
Female, 22, average player
Male, 33, experienced
Me
Time: 15 minutes
Playtester Comments:
One play tester didn’t like the idea of being able to go all in
Needed more clearly defined value judgement, maybe a card with rules on how to interpret the values
Wondered what it would be like if the reroll could involve, re rolling meant ability to choose either to re roll one or two
Wondered if king had more than two dice if it would be more interesting
Liked the idea of pleasing the king, gave a motivation, said it made sense thematically
Observations:
Playtesters understood game pretty fast
Three players, one got out early, who got bored
Winner and second place came close, leading to a climax where losing meant sudden death
No complaints about increasing of 1 tax per turn
Playtesters said only one minimum bet reroll is better
Revision
#
Description
Purpose
1
Added rule for only one reroll per turn
Stop the person with the most money winning by rerolling a lot
2
Created a physical board for the game
Reinforce thematic element
3
Used a royal seal in the king's box to signify royalty
Reinforce thematic element
4
Used a raised platform to show king is above all others
Reinforce thematic element
5
Made the Jester money boxes to remind Jesters that their death is at the bottom of the box
Reinforce thematic element
6
Changed pay theme to instead of all in instead have it so that Jesters must collect money to pay by the end of the season or be beheaded!
Added a survival motivation
7
Made a railing on the platform to help with dice from falling off the platform
Dice fell off the table
8
Reduced the number of chips
Shorten the experience so a player who got out early is less likely to be bored
Playtest 4
Date: February 6 – 20:00
Playtesters:
Female, 22, novice player
Female 23, noice player
Male, 33, experienced
Me
Time: 15 – 20 minutes
Playtester Comments:
Playtesters liked the theming
Started to feel tedious at end
Felt great till end
First person to get out felt helpless and frustrating cause they got out early
Felt long
Losing playtester liked Last Chance feature (roll without paying tax, winning didn’t so much)
Observations:
First player out at round 5
Second at round 9
Third at round 12
Average score: 3 – 3.5
#
Description
Purpose
1
Changed to 10 chips
Shorten the game
Playtest 5
Date: February 7 – 13:30
Playtesters:
Male, 50, super hardcore player
Me
Male, 23, novice player
Male 21, experienced player
Time: 15 minutes
Playtester Comments:
Playtesters suggested changing to D10 instead of d6
Players found matching system super confusing
Match system is fussy
Interesting ideas
Observations:
10 chips was good
Nobody was too bored
People didn’t roll on the board
People would often forget to pay in
Revision
#
Description
Purpose
1
Changed matching system to have it by value comparison rather than number comparisons by dice
Realized odd calculation was what was important so wanted to simplify the experience so players could focus on that
Playtest 6 - 1
Date: February 7 – 14:30
Playtesters:
Female 21, semi novice player
Male 23, semi novice player
Me
Time: 10 – 15 minutes
Playtester Comments:
Playtesters found it frustrating that one player would be a clear obvious winner around the middle of the game
Observations:
Comparing and rolling went much more smoothly and playtesters due to simplified comparison system
Playtesters would again forgot to pay in
Playtest 6 - 2
Date: February 10 – 20:00
Playtesters:
Male 23, semi novice player
Me
Time: 15 minutes
Playtester Comments:
Had fun
Found three dice a little difficult to calculate
Revision
#
Description
Purpose
1
Changed Jesters 2D6 to a D4-D8-D12
Wanted to make choice of probability choice more interesting
2
Tiered payout system instead of payout to only one player
Tried to solve problem of winner being too apparent early
3
Updated rule sheet
Add structure in to make experience easier to absorb
4
Changed king's dice from 2D6 to 5D6
Wanted to create cases where players have to maximise and thought adding more dice would be fun to roll
Playtest 7
Date: Friday 11 – 17:50
Playtesters:
21 male, hardcore player
30 male, hardcore player
23 male, experienced player
24 male, experienced player
Time: 15 minutes long
Playtester Comments:
Felt like it took 30 minutes when it took 15 minutes
Told to consider probability distribution more
Found counting the Kings 5D6 a slow tedious task
Players didn’t think it was fun to roll King’s dice because the King’s dice is not their dice
Suggested rephrasing the rules to make it easier to understand
Observations:
One playtester didn’t like maths, and used his phone to keep track of numbers
Playtesters used their fingers to record differences
Playtesters arranged payouts in advance of the round to make it faster
Revision
#
Description
Purpose
1
Modified the rule sheet to include terms and bullet points with breakdowns as well as more explicit details
Make the game easier to understand
2
Included a method of keeping track of your difference
Take the mental load off the player
3
Changed players D4-D8-D12 to D8-D10-D12
Due to analysis of probability curve and number distribution (refer to Anything Else section)
4
King’s Dice changed from 5D6 with pips on them to a D20 and D10 with numbers
TO make it easier to read and I preferred the more flat probability curve (refer to Anything Else section)
Playtest 8
Date: February 13 – 20:35
Playtesters:
Male 21, hardcore player
Male 24, semi novice player
Me
Male 23, experienced player
Time: 15 minutes
Playtester Comments:
Found rules difficult to understand
Figuring out people’s dice roll most difficult
Observations:
Understood rules quickly and game was resolved with payouts = 21,22,15,10
Revision
#
Description
Purpose
1
Introduced a sheet of numbers and player use a token to mark what their difference from the king's favor is.
Make figuring out players difference easier
Playtest 9
Date: February 13 – 23:00
Playtesters:
Male
Me
Male
Time: 15 minutes
Playtester Comments:
As soon as one playtesters heard about terms then they switched off
Instead of difference players put down the number they got so they could visualize the difference easily
Observations:
Using the new scoreboard worked well.
Revision
#
Description
Purpose
1
Added a day counter row as well
Get another unnecessary detail out of the player's head
Final Set of Rules
You are one of several jesters performing at the King’s week long banquet. Jesters got bills to pay so to win you must earn the most money before the banquet ends!
Rules
Jesters earn money by gaining the Favor of the crowd who pays them based on the day’s performance. The Favor a Jester receives is judged by the difference from the King’s Favor to a Jester’s Dice roll in terms of numerical value. The different Favors are as follows:
Lowest Difference
King’s – 4
Queen’s – 3
Prince’s – 2
Duke’s – 1
Highest Difference
Money is paid out to each Jester from lowest to highest difference from the King’s Favor.
Turn Structure
The game takes place over 7 days (turns). Each day has four phases:
Perform
All Jesters Perform by rolling their dice.
Kings Favor
The Kings Dice are rolled setting the King’s Favor.
Improvise
A Jester can choose to Improvise. This can be done only once per Improvise phase.
If multiple Jesters wish to Improvise, rolling must occur at the same time.
Payday
Jesters receive their payout based on the difference from their Dice to the Kings Favor.
In the case of draws:
Non drawing players first receive their payout depending on their difference
Drawing players must Improvise until there is a difference
The loser(s) of the draw receive the lesser payouts
The following are examples of payday payouts.
Example 1: If the King’s Favor was 20, then a Jester at 19 is one closer than a Jester at 18. Therefore the Jester at 19 wins the King’s Favour and the Jester at 18 wins the Queen’s Favor.
Example 2: If the King’s Favor was 20, then a Jester at 19 draws with a Jester at 21 as both are one away from the King’s Favor. Both players must Improvise until there is a difference. The lower Jester gets the Queen’s Favor and the higher the King’s Favor.
Terms
Kings Dice – The D20 & D10
Jesters Dice – A set of D8, D10, D12 given to each player
King’s Favor – The number rolled by the Kings Dice the center of the board
Perform – Jesters rolling all their dice
Improvise – Jesters rerolling one or more of their dice
Additional
The Day & Difference sheet is a useful tool for keeping track of what day of the banquet it is, and what the King’s and each Jester dice rolls are. Place recognizable tokens for each Jester and King on the values from 1-28, and move a token along the Day row to keep track of what day it is.
Estimate of Cost
I estimate per item cost at:
Dice – 16.99 for 36 dice, making it 0.47 per dice, 14 are required so = $6.5
Board & Boxes = $10
Day & Difference Sheet (Multiple) = $2
Tokens for recording day and value = $1
70 chips = $7.5
Post It Note Sheet = 50 cents
Pen – 0.5 dollar = 50 cents
This comes to $28, but I can likely get discounts on many of these items buying in bulk.
So I say approximately $20-25 estimated cost.
Anything Else
In Playtest 7 I did some probability analysis using anydice.com
Kings Dice
The bell shaped curve is 5D6’s and the more flat curve is the D20 and D10. I went with the more flat curve because I preferred having a distribution with more equal probabilities over a large range of values for the King since this would be the number players would aim to get.
Jesters Dice
With the King’s new probability curve in mind I analyzed the Jesters Dice. The previous player’s probability distribution which had a max value of 24 was skewed towards the lower spectrum of possible ranges. Looking at bell curve that touches up to 30 it was more fairly distributed and given the three dice of D8,10,D12 it would make for a less obvious choice instead of D4,D8,D12 (roll D4 for least change, and 12 for most) which I would consider more interesting.
Platform: iOS | Time: 15 weeks | Role: Game Designer | Team Size: 6
Design Goal: The goal of the project was to promote a sustainability mindset in our target demographic.
Design Challenges: We faced a number of design challenges during this project including:
System design
Setup & Tweaking
Multiple difficulty configuration
UX challenges
UI Design
Tutorial
Trash Visuals and Content
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
Introduction: Angle Jungle is an award winning puzzle game 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.
Awards: Serious Play 2017 Gold Award Winner, CHI Play 2017 Jury Award Winner, Finalist for 50th Carnegie Mellon University Founders Award
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
Secondary Transformations:
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
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
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)
A brief description of the process you used to create your adventure. Include any brainstorming notes, etc.
I begun the process of creating my adventure with a theme/fantasy. I had a number of ideas including:
A sports adventure theme
A wild west themed game
A game with vampires
I settled on doing something set in the time period of the Roman Civilization. In particular I loved the setting of the movie Gladiator so my intention was to recreate a similar storytelling experience.
Next I searched for an interest curve that roughly mapped onto what I wanted to create.
Next, based on the five point on the interest curve I imagined the main scenes of the story with a brief description of what I wanted to achieve in that scene, and the main story beats.
Capture – I wanted the player to be captured.
Training Ground – A scene in the gladiator house of them learning skills and familiarizing themselves with their new world
Gladiator Battle 1 – First gladiator battle, high intensity
Villanus Mansion – A more social situation, with a puzzle
Gladiator Battle 2 – Last gladiator fight, high intensity, kill the boss to win one’s freedom, or kill each other.
I was inspired by the game Shadow of Rome, and wanted to find a system that support combat and social situations. I could have used the roleplaying 101, but I instead chose to use a system from a tabletop RPG game I had played before called Vampire The Masquerade (VTM). More specifically I used Vampire: Dark Ages (medieval setting) for their armour, and weapons.
To flesh out my world of I needed to perform significant research, namely:
Be aware of the different types of gladiators to give my players and generated enemies some grounding in the world
I also wanted to include animals at one points so I found applicable stats.
Made a list of important characters and some of their traits to help me roleplay them.
Each scene needed a map so I drew one, including details about who was in each scene.
Refamiliarize myself with VTM’s leveling scheme, social and combat systems.
Found example stats to base my NPC’s on.
There were also a number of things I did not do:
Also thought of adding in some currency and letting players by equipment but thought this might add too much added complexity.
Thought of adding special sections such as chariot racing but left it out due to the added complexity.
All of this I compiled into a long supporting document I used whilst DM’ing that I will include in the following section.
Story: To smoke or not to smoke! That is the question! Control a jammer’s good or bad conscience, and convert their brain waves to help them make the “right” choice! The game is about two sides battling to gain control, the neurons resist the attack themselves and the player gets a limited amount of time to conquer all they can.
Design Challenge: To design a game that captured the concept of Waves as dictated by the theme of the 2017 Global Game Jam.
My Contributions: I directed the design of the project as well as assisted the lead programmer with tasks such as adding the neuron layer on top of our atom system. As well as programming the user interface surrounding the game.
As part of Jesse Schell’s Game Design course at The Entertainment Technology Center we required to analyze and ‘improve’ the game of Hopscotch.
The goal of the game is to complete Hopscotch Toss the fastest.
In Hopscotch toss there are two teams which compete against each other on a standard Hopscotch board.
Both teams have two players, a jumper and a catcher.
The catcher stands at the final safe square on the Hopscotch board
The jumper at the start of the Hopscotch board
The jumper throws out three markers:
When a marker is thrown the timer begins
If a marker misses a square the marker is placed on the first square
The jumper begins playing hopscotch with the aim of collecting and throwing markers to the catcher one at a time.
If the catcher drops the marker the jumper must return to the start
Once the jumper reaches the catcher who must have three markers in hand, the jumper turns round and continues playing Hopscotch.
When the jumper reaches the start position reverse jumper and catcher roles. Now the second round of Hopscotch Toss starts.
First team to complete two rounds wins.
Development
Part 1 - Analysis & Brainstorming
What makes a hopscotch a good game?
Simple to understand rules
Requires little equipment
Trains limb coordination
Easily extensible to multiplayer
Clear win state
Gamifies natural hopping movement
Low skill entry barrier
Immediate feedback on game state
Problems with the game your design might try to solve.
Not friendly those with physical disabilities
Can become boring due to its simple rule set
Primary mechanic is jumps
A static game space
Minimalist Aesthetics
Has no story
Does not incorporate elements of modern technology
Tests the body but not the mind e.g recall of facts, events etc.
Brainstorm 50 ideas on how you could improve Hopscotch
Blindfolded
With someone on your back while playing
Jumping only when music is playing
During a handstand
On a climbing wall
With multiple tokens
Whilst singing
Where you start with no squares and draw one turn by turn
Three legged
On stairs
Backwards
Eating icecream
With two people at once
With only one square
On a board with tiles that turn in a pool
Played using your fingers
On a trampoline
Interplanetary
Over Skype in different countries
Where you cant jump in squares based on a coloured dice, or coin?
Story based, and where marker was thrown player has to participate in a story event and if they lose they dont get to score a point by playing a round of hopscotch
Edible, where a player can eat one square but has to make another one with provided food
Where the game space drawn from star constellations
Meta – smaller hopscotch games feed in a larger one. Two people play against each other in each mini game, and the winner moves forward on one square on the board till they reach the meta game marker and return as in a normal game
Color coded special square events which if a person steps in they have to do like shout a word, if they fail they have to go back to the start
Place the marker not by a throw but by a dice roll
People are put into teams based on costumes
The person has to do a dance move when spinning round at the end
The person has to do karate punches on each jump
Throw the marker again when it is picked up
Two people have to mirror each other on different games
It is attached to another game that based on your speed gives you more points/ progresses more in the level
In VR with rivers of lava
Where each item rotates round and one has to jump from square to square
One player throws the marker and stops at that position. Then throws the marker forward again. The next player jumps to the position of the last player who jumps to the next place the marker is now at. The process continues until the marker has been returns to the beginning.
Competitive, two games of hopscotch, the marker can be thrown onto another hopscotch game to make it harder for them to complete the round
On a dart board. Objective is to hit the center of squares avoiding the one other player threw the marker dart at.
Three legged – two people tied together play
Relay, where the marker has to passed from game to game.
Players stand in Hopscotch squares and pass the marker to other players to complete the game.
Where the panels light up and one must jump only on lit panels
On the moon
On a single wheel cycle
With sword fighting battle rounds per block, losing sends you back to the start
Complete Hopscotch in a tiger cage before the tiger is let loose in it
With a slide at the end of the game
There are two markers and those are the only ones that can be jumped in
There are markers on every square and winning is jumping and picking up as many as possible in a given time.
One person is continuously jumping and another person throws a marker and tries to have the player jumping fall on that marker.
On a keyboard one has to press the 1-9 keys in the same pattern, and avoid the marker square set by the computer.
Part 2 - Selection
From your list of ideas select three and describe them in more detail
Based on number 25, 39 and 48
Picto Hopscotch – Hopscotch is played in the traditional American school yard manner except for one difference. Each row has a picture associated with it. When the player jumps on any square of the row they must shout out the picture. If they do not the player has to go back to the beginning again.
Relay Hopscotch – Two hopscotch play spaces are set up. One person from each hopscotch space begins playing, and completes a game and gives the marker to an awaiting second player who plays a game of Hopscotch. First team to complete both hopscotch games win.
Hopscotch Toss – Two teams play Hopscotch competitively. Both teams have a jumper, and catcher. The jumper plays hopscotch and collects the markers and throws them to the catcher. The team with all the markers in the catchers hand and jumper at the end win.
Part 3 - Improvement
Hopscotch Toss
An Attempt at solving problem 3 by introducing throws
The goal of the game is to complete Hopscotch Toss the fastest.
In Hopscotch Toss there are two teams which compete against each other on a standard Hopscotch board.
Both teams have two players, a jumper and a catcher.
The catcher stands at the final safe square on the Hopscotch board
The jumper at the start of the Hopscotch board
The jumper throws out three markers:
If a marker misses then the player rethrows
When the last marker is thrown the timer begins
The jumper begin playing hopscotch with the aim of collecting and throwing markers to the catcher one at a time.
The team is fastest to get all the markers in the catcher’s hand and the jumper at the end wins.
First Loop
The first iteration of gameplay showed me various areas that needed more detail and consideration. Useful moments that occurring during my playtests were:
Instructions should be short and concise otherwise they bore playtesters. So I should better prepare my rule for fast and easy digestion.
Great design moments had laughs or confusion which immediately drew my attention to areas of the game I needed to work on.
Playing the game exposed rules that I needed to clarify such as how to handle drops, fumbles of the jumper, missed throws.
Bad
I did not consider adding the throw to the timed phase of the game. Doing so might add tension to that part of the game.
The catcher reported wanting to do more.
I had only one game setup at a time, it would have been more enjoyable to have both games occurring simultaneously.
Good
Players clearly enjoyed throwing markers and catching them.
The game was picked up very quickly due to its rule set
Second Loop
With the second iteration I intend to adjust the rule set to include new cases for when the jumper and catcher fumbles.
The jumper throw phase is included in timing.
If the marker is thrown out of boundaries it is placed on the first Hopscotch square.
If the catcher drops the marker the jumper stops moving until the catcher picks up the marker and returns to the safe zone.
Playtested with the above changes had the following effects:
Heightened the tension during the beginning of the game.
Made jumpers more careful with their throw. They would take safer shots, but those who successfully made riskier shots got greater rewards.
Heightened the tension during drops, particularly on the catcher as they scrambled to get the marker..
Playtesters reported having an enjoyable more fluid experience. They also made two suggestions:
The experience be ‘circular’. When the jumper reaches the catcher who has three markers in hand, the jumper turns round and continues their Hopscotch game (without the markers) instead of ending the game. On reaching the beginning of the Hopscotch board the Catcher now switches roles and becomes the Jumper, and the game continues.
The jumper returns to the start if the catcher drops the marker.
Introduction: Developed on the Oculus Rift with PS Move, DinoRancher had guests play atop a Triceratops armed with an electric lasso. The goal of the guest was to shepherd a herd of Stegosaurus to safety, protecting them from danger.
Story: You are a DinoRancher armed with your electro lasso and trusty trike. Travel across the desolate wasteland, and protect your herd from those nasty predators!
Design Challenges:
Herd behavior
Enemy types
Environment design
Integration of the PS move into Virtual Reality
Trike movement system
Design Goal: To create an experience that made the guest feel like a cowboy travelling through the desert protecting a herd of dinosaur from predators.
My Contributions: As producer I arranged meetings, delegated pending tasks, and contributed creatively. In addition as a programmer I was responsible for setting up the games environment which included, asset preparation, level design and developing agent behavior.
Introduction: Developed on the CAVE with Makey Makey, NoseDive had guests play in the CAVE environment using airplane controls we constructed using Makey Makey.
Platform:CAVE, and Makey Makey in Unity 3D | Time: 2 weeks | Roles: Programmer – Game Designer – Producer | Team Size: 5
Story: Our game had our guests take the role of make shift pilots thrust into having to fly a plane to safety through a terrible storm when the captain has become incapacitated.
Design Challenges:
Adapting to the CAVE environment.
Creating an authentic flight simulator experience with an easily understand story.
Design Goal: To create an authentic story of saving the day through the game we created.
My Contributions: For NoseDive I was producer, designer and programmer. Being producer involved scheduling and coordination of our teams artist, programmer and sound designer. In addition I assisted my fellow programmer with environment and Unity prop setup.
Introduction: A Playroom was a developed on the HTC Vive. A virtual reality device that allows a guest to walk around a calibrated virtual reality space with hand held controls.
Platform:HTC Vive in Unity 3D | Time: 2 weeks | Roles: Designer – Producer | Team Size: 5
Story: The setting of the game is in a play room where the guest encounters a ghost boy who needs help in-order to ‘move on’.
Design Challenge: To design a game for naive guests, conduct play tests, and make three predictions of what the guest will do all whilst having the guest ‘feel free’.
Design Goal: Round 2 of Building Virtual Worlds was indirect control round. This required we build an experience that felt free, and was intuitive enough for a guest to play from start to finish without any instruction or guidelines.
My Contributions: I analyzed, and designed the guests interactions as well as wrote our main non playable characters dialogue. In addition I conducted play tests which gave us invaluable feedback which we used to further develop the experience.
Development
Interaction Design
I focused on interaction development by first analyzing what we currently had. From that I wrote a draft story design which was a rough version of what we would aim for. Our current gameplay was clearly a linear story experience, and I believed we could achieve a greater sense of freedom by allowing a player a choice of what game to play.
From this notion I created two different interaction models.
Interaction Analysis – Development Diagram
I then met with the team, presented my two plans. We choose plan 2 which I further developed into a more detailed version.
Interaction Analysis – Component Breakdown
Audio would play a vital aspect in driving this interaction model therefore I worked with our sound designer on a script for the game which we iterated over based on feedback (script documents).
Playtesting
Once the various audio cues, and interaction model was implemented we went about play testing the game. I conducted play tests with over fifteen naive guests which included an audience of fellow students, professors and non-students. This feedback was then used to polish elements of our experience.
Sample Play Test Feedback Form
In conclusion we correctly predicted each of the three interactions, and the guest understood our story, all with no guidelines or instruction from us.
Full Story
We began our project with brain storming, and research into the platform on which we were developing. We came up with several ideas including:
Darkness– Use light to guide the guest through a street.
Space Exploration– Explore the universe, and pick a planet to colonize.
Dreaming – Flying a plane, flying elephants, flowers turn to buildings (freedom from constraints).
Empty Room – Furniture place (guide them to a correct place).
Having difficulty grappling with the concept of ‘freedom’ we spoke to a member of The Entertainment Technology Faculty Jesse Schell. After meeting with Jesse Schell we honed in on an idea of a ghost boy which we would help in some manner through objects around him.
Next we thought about location, which was first a storage room due to it making sense to have many object, we then changed to a play room as it offer the potential for a ‘warmer’ environment for guests to feel comfortable.
After creating a basic room with a simple number of interactions which included:
Playing catch.
Place a train on the train track.
Hide & Seek.
Give a hug.
We had a prototype ready for interim.
Interim
After interim our two main points of feedback were
Make the boy and game generally less ‘creepy’.
To develop our interactions.
Less ‘Creepy’
Point 1 was a significant design challenge which we tackled by investing time into solving by:
Making our main game character look more human like.
Soothing music.
A warm game atmosphere.
A friendly, light and clear character voice.
Interaction Design
I decided to tackle point 2 by first analyzing what we currently had, then writing a draft story design which was a rough version of what we would aim for. Our current game play was clearly a linear story experience, and I believed we could greater the sense of freedom by allowing a player a choice of what game to play.
From this notion I created two different interaction models.
Interaction Analysis – Development Diagram
After meeting with the team, presenting the two plans and convincing them of the need to carefully design the experience, we choose plan 2 which I then further developed into a more detailed version.
Interaction Analysis – Component Breakdown
Implementation
Audio played a vital aspect in our experience so I worked with our sound designer on a script for the game which we iterated over three times based on feedback (script documents). In addition to audio we used a number of other techniques including:
Lighting – To direct the players focus.
Meeting the Boy
Color – Brightly contrasting objects such as with the yellow train on a blue chair, and a red book on a beige floor caught the players attention.
Train & Puzzle
Uniformity – A suggestive picture fragment was placed in the frame, and other similar looking puzzle pieces were placed around the level.
Puzzle Placed
After implementing these features with a new interaction model we went about play testing the game. We conducted play tests with over fifteen naive guests which included an audience of fellow students, professors and non-students.
Based on the feedback we received we continued to polish elements of the game. The end result of our work was that not only did we accurately predict each of the three interactions, but the guest completely understood the story behind our world all with no guidelines or instruction from us.
Introduction: Multi is a game built on Game Maker for Windows using Game Makers scripting language. Players control a character who traverses a series of levels in a platformer style game play.
Platform: Windows | Time: 3 weeks | Roles: Programmer – Game Designer – Artist – Sound Designer | Team Size: 1
Design Goal: The primary ‘design goal’ with this project was to further my design skills whilst practicing level and mechanic design.
Design Challenges:
Creating levels that were interesting to play with the mechanics I created.
Difficulty design.
Teaching players how to play.
Audio which included, character, and environment sound design.
Made the majority of art assets (character art and animation taken from a game maker tutorial)
Collected audio that suited the game play from free sources (credits bundled with Multi).
Conducted play testing with younger audiences which I believed would be interested in the game.
Download:
Follow the link below to download a .zip file containing the game. When the download is complete, unzip the file then have a look the read-me and, then run the .exe file to play the game.
Story: Jam-O-Draw was inspired by the classic etch-a-sketch game.
Design Goal: We wanted to create a multiplayer artistic experience with a fascinating reveal.
Design Challenges:
Adapting to an unfamiliar platform.
Creating an aesthetically pleasing experience using visuals and audio
Having the user interface during the experience be responsive and informative.
My contributions: My primary role on this project was as producer which involved making creative contributions, arranging meetings, coordinating our artists, programmers and sound designer to create the game in a timely manner. My programming responsibilities included assisting my fellow programmer with development, and preparing the game environment and assets.
Introduction: Seize the Sky was built during Building Virtual Worlds at Carnegie Mellons Entertainment Technology Center. The world was constructed using Oculus Rift, and Leap Motion. Using these technologies we put our guest into a virtual reality space with an ability to use a natural interface in our world.
Story: A mighty giant heads towards a town with murderous intent. A country side boy notices, and cries to Zeus for help to defeat the giant to save the city. You are Zeus, save them all!
Platform: Oculus Rift + Leap Motion in Unity 3D | Time: 2 weeks | Roles: Programmer – Game Designer
Design Goal: Our design goal with Seize The Sky was help character A (the boy) who is afraid of character B (the giant).
Design Challenges:
Incorporating a satisfactory use of Leap motion.
Achieving our a sense of character A is afraid of character B.
Level design.
Game-play design.
My Contributions: As the lead programmer on Seize The Sky I made large contributions to the code base for this project. I also took an active part in the design process with working with the team to develop various aspects including game play, and level design.
Development
Iteration 1
The development process started with being assigned teams. In our first team meeting we made clear our skills, started brainstorming ideas, and kept good development processes in mind.
This slideshow requires JavaScript.
During brainstorming we tried using several appropriate methods, such as gesture centered brainstorming (due to our use of Leap Motion). Finally we had five initial ideas:
Help mend relationship between characters.
Play piano to make baby sleep.
Use light to guide a character home.
Keep animal safe growing to adulthood.
Hold characters hand to guide them.
This slideshow requires JavaScript.
With our initial ideas we further boiled them down to three concepts with the following reasoning:
Concept one was hard to conceptualize compared to our other ideas which seemed simpler and more clear.
Concept five could be incorporated into concept three.
Creating sketches of each concept we then sought out the advice of our professor Jesse Schell.
With Jesse Schells feedback we went with concept C, because we wanted to explore squeezing in Leap Motion.
We then began further conceptualizing the idea with sketches, and research into the capabilities of Leap motion and Oculus.
This slideshow requires JavaScript.
With this in mind we began assigning tasks to complete, considering game play, and used a scrum board to assist us in tracking tasks.
This slideshow requires JavaScript.
On the technical side we used a NavMesh, and simple A.I. to run the behavior of the Hunter and Deer. The behaviors of the two agents were essentially:
The deer always moved to nearest tree that has an apple.
The Hunter patrolled around fixed points, and if it came close enough to the deer it began chasing it.
The result of our hard work was the following.
We then received feedback at interim, which sadly wasn’t good…
Building Virtual Worlds at Carnegie Mellon University starts with each student being assigned a role in Round 0. Since I have a Computer Science background, my role was that of programmer; this entailed I build a world that employed a number of basic features in Unity, such as:
Loads models and textures.
Play animations.
Use intervals, lighting, collisions, and multiple scenes.
When considering the world, what I noticed was the amazing talent of the artists and musicians around me. It occurred to me what a shame it would be for their work not to be seen. I decided then that my virtual world would be a gallery of other peoples work. My first task was then to coordinate of assets with artists, and sound designers.
Creation
Artists were initially required to create animated lunchboxes, then dragons, and sound designers were required to create music for a clip of game play from a previously made world. I decided to meld the two by attaching audio sources to several of the artists assets that would constantly play music made by our sound designers.
