Creating a Wrapper For Disco is Dead’s Game Experience

With Disco is Dead’s development moving towards the polishing and refinement stage, an area of focus for our team has become the unification of our experience and its completeness. As per recommendations and feedback from trusted individuals, this means construction of a meta-game and framing system around the levels and core game experience, in order to make the game and experience complete.

The style our game is evoking is that of old school arcade games, as well as physical games such as Wii fit, etc.

With the end of the year approaching, we are moving through the implementation pf framing Features traditionally associated with such titles that should be incorporated into our game to make it more complete. The following are the features I will be working on in this update, along with the design goals each will help the game to achieve:



Main Menu

The game has had main menus in the past, but all are relatively simple, and none could really be manipulated using of slapping controller. to resolve both these issues, I will be developing a menu that both makes use of the controllers, and provides the players with indication of how they work. The symbols used to indicate the direction the players should slap in the menu will be the same as those used in gameplay; by using them in the menu, and highlighting their connection to physical directions on the controller, we will be able to prime players for gameplay inputs through the learning space of the main menu.

Design Goals: 

  • Create a menu whose appearance is appealing and blends in with the rest of the game.
  • Have the menu teach the player crucial inputs for playing the game.


Above: The former Main menu, now being applied as our title screen, exhibits no interface which is conducive to the control scheme we use.  



Credits Screen: Not an absolute necessity, but something that will help tie the game together and help make it more complete. Unity in design will be shown through allowing the players to slap at the credits as they scroll, turning it into a mini-game akin to those found in games like Rayman Origins and New Super Mario Bros. 

Design Goals

  • Create a proper, professional conclusion for the game.
  • Create a final, fun little component to tie into our theme.


Cutscene/Level Select: In order to allow both ourselves and our users to move easily navigate through the game for players, its important to have this feature implemented into the menu.

Design Goals

  • Create an option that allows both players and designers to easily select the level they wish to play.
  • Have it integrated in a more appealing way that simply a debug menu, for the sake of  polish.


High-score Table and Tracking: As our game draws its primary design from arcade titles, it is reasonable to assume that a major reward for players, particularly when showing the game in a public place like level up or other showcases. players will want to  try to get high scores, and we can compare players score and congratulate our current champions, and encourage people to try to top their scores.

Design Goals

  • Create a reward that holds value for players during short term play sessions – at showcases, etc.
  • Ensure that it meets all tecnical requirements and operates as intended.


Opening and closing each level: Each level should have a concrete beginning and end. To do this, an animation should be appended to the beginning of each level, showing the characters getting ready to go, and a ranking screen should be added to the end, to show the players how they did.

Design Goals

  • Frame each level as a part of a larger experience.
  • Provide players with feedback on progress, so they feel like each level is capped off by a meaningful result and assessment of their progress.

The Carrington Sisters - Elite Beat Agents ScreenshotThe Agents from Elite Beat Agents

Above – examples of the intro to a level and the rankings after a level in the comic book inspired rhythm/story game. 


Outcomes of Developing for These Issues

Over the course of reading week, I developed all of these systems in order to make the game a more complete experience for players.

Main Menu:

The main menu’s visual design was already somewhat underway, the main challenge was simply ensuring that it effectively presented the player with the ability to switch between options and helped them to learn the mechanics. the final design was to have a disco ball that could be slapped back and forth, spinning and revealing new options – The icons used in the menu are the same as those found in gameplay, and pulse when the player slaps in a direction, showing what each translates to on the head. This, coupled with some sound effects, visuals, and screenshake effects, helps the menu to be both thematically cohesive with the rest of the game, and help to prepare the player for the rest of the game in terms of icon to controller recognition and understanding.


Credits Screen:

The credits screen was farily easy to create, and fits in very well with the overall aesthetic. Players can slap the credits as they roll up the screen, and their scores are talllied, allowing for a fun microgame. The next step for this will be getting our complete credits for the game written out and lined up, so that player’s have a good number of objects to slap, as welll as testing it with players, to see if they enjoy it. Overall, it certainly will form a nice conclusion for anyone who plays through to the end of our game.


Cutscene/Level Select:

The level select is another area of the main menu. while it is functional mechanically, and follows the same style as th erest of the menu, we still may need/want to replace the basic level art that I have for each level with more finalized, polished peices before the final build. In particular, the tutorial’s art is not yet finished, so that will need to be added. The ability to load custscenes was judged to be a bit redundant, as there are only 5 major blocks of cutscenes, each being tied to a level.


High-score Table and Tracking:

The highscore table is functional, and displays the scores of players, shorting and resorting them, and has a nice visual aestehtic that allows for a name of a chosen number of letters to be put in. This may change later, as we discussed the possibility of having disco names for players to choose from. The system that I implemented just grabs the letters as strings from a list, so these could easily be replaced by words, etc. if we decide this is what we desired.


Opening and closing each level:

This is one area that probably still needs some more work. We will have an entire cutscene systems that leads from and to each level, and is on the verge of being implemented and connected. I was able to develop a system to determine and showcase rankings for players at the end of each level.

Conclusion and Moving Forwards: 

Overall, I was able to apply reading week towards some significant development in terms of the game’s framing and overall experience. However, some of these elements still require a bit of additional fine-tuning. Moving forwards, the next area of focus will be on play-testing and seeing the effectiveness of all elements that have been introduced, and making any necessary changes.


Images Courtesy Of:


Creating a Wrapper For Disco is Dead’s Game Experience

Tool Development – Level Sequencer

Through feedback and play-testing of Disco is Dead, our team was able to realize that our original design methodology for levels was not going to work out as intended. The initial design was to allow enemies to spawn in at random, while restricting the enemies that could be spawned in to specific pool for each individual wave. “Scriptable waves” were created, to allow this functionality, and for a time, this seemed adequate. However, through play-testing, our team was able to see that players were not receiving it as intended. The wholly randomized nature of spawning enemies would often lead to scenarios where one player did not have enough enemies, or however, as we move more from the early mechanical design development stages into the fully realized production and polishing phase of our development, it has become apparent that we need a way to exercise greater control over our level design, while still making use of the existing systems.

Wave Example.png

Example of early scriptable wave – enemies of different kinds can be assigned for the wave, with the odds of spawning being determined by their frequency in the list. The length can also be set. 

In order to resolve this issue, I set out to make a “Scriptable Sequence” scriptableobject, and managed to create a fairly simple one, along with alternate logic that allowed it to interface with the scriptable waves, so that it would “Spawn” enemies from the pre-instantiated enemy groups that we were already using in our system, which our primary coder had designed.

Enemy Manager Syst.png

Example of the method of enemy storage applied within Disco is Dead – numerous disabled enemies are stored in folders,awaiting the call to be enabled. 

Sequence Example.png


At Left – Example of the early scriptable enemy sequence – it allowed a designer to place any object as the enemy, and the associated script would then search for it in the appropriate folder based on which player the enemy was assigned to, spawning it if it was found inside said folder. Interval represents the amount of time since the last spawn. This system is workable, but somewhat inflexible and unintuitive, with few safeguards in place. For example, a user can call for a single target zombie to attack both players will find that it does not work, and likewise with a zombie that targets both players. furthermore, there was no way to remove an enemy from the sequence at a position, etc. 



This worked well enough in allowing me to test the logic and high-level design of waves, but the goal here was to produce a tool which could allow our team members, specifically our level designer, to work on assembling enemy sequences and level design without coding knowledge, and to make this system as straightforwards as possible. To this end, I started determining features the tool would need in order to be as simple to apply as possible.

Criteria for designing a more user-friendly level sequencer tool:  

  • A custom editor will need to be used, in order to allow for the simplification of fields, and creation of a more logical-looking interface.
  • There should be adjustable fields for which player the enemy can target, either P1, P2, or both, as those are the only options we want designers to have. an extension of this is allowing a pair of enemies to attack at the same time.
  • There needs to be a more clear representation of the point at which each enemy will appear – timers should be more clear than being relative to the previous object’s instantiation.
  • Designers should not be able to call for the placement of any object that is not in the current wave. The placement of objects that are not enemies at all should also be prohibited – for example, designers should not be able to place a canvas prefab for the sequencer to spawn. (Although it would not act on it regardless, due to the way it is designed.)
  • Designers should be able to insert/remove enemies from the list at a specific position, so that they do not need to delete half the list to get rid of one enemy in the middle of the sequence.

Before moving forwards with the full creation of the tool, I had made several classes to support it, namely Sequenced_Enemy and the base Scriptable_Enemy_Sequence class, which are shown below.


At Left: Sequenced enemy is a class for all enemies in a sequence, that holds the enemy game object to spawn, the time at which it should spawn, and an enum for the player it should attack. The enum enemyTypes/EnemyType was added later, to facilitate the ability to use an enum to choose  the “enemy” GameObject without giving designers access to the full build’s worth of GameObjects.  



Seq2.jpg                              Above: The Base Sequence class for which a custom inspector was required – has the length of time that the sequence runs for , the index of the current enemy, and the list of Sequenced_Enemies. 

Custom Editor Tool: This was already under construction, and through filling it out and drawing from previous experience, creating this was not overly difficult. My main focus with this was to make it as clear and legible as possible, so as to make its application easier for members of our design team. to this end, the purposes of different fields and sections were clearly labelled, and the whole tool possessed a user-friendly interface.   


Above – Example of the final interface layout for an enemy sequence.

Adjustable Fields: For the most part, these were fairly simple, using Unity’s built-in fields to allow users to add information and make changes, though there were some issues with the creation of certain types of fields – for example, in order to prevent  designers from trying to spawn game-objects other than enemies, I designed enumerators that affect the enemy types, allowing us to choose which types the designer has access to, in order to make things easier for them.     

Clear Representation of When the Enemy Will Appear: This is still an area that will need some refinement, as thus far, I have not been able to figure out how to draw a graph or other visual representation of the enemies relative positions/progression throughout the sequence. In the meantime, I instead opted to change the way that sequencing worked – instead of having each enemy’s “Interval” be relative to the last enemy, making it difficult to picture its placement in the overall time of the sequence, each enemy is now placed at an absolute time within the sequence – 2 seconds, 5 seconds, etc. giving the designer a more accurate view of when they will be spawning in overall. For now, this will be satisfactory, however, I intend to seek further advice on making some kind of visual indicator for the sequence’s layout. 

Limiting the Types of Objects That can be Called in: This was a particularly challenging aspect of development, as I had to design code to convert an enum field to game-objects within the sequence, and vice versa. Due to the fact that the “Wave” scriptableObjects that utilize the sequences call downwards to them, the sequence cannot know which wave it will be placed into, so knowing which objects it has/does not have is implausible. due to this, I was unable to implement a means of limiting the enemy types that a sequence would use based on the wave it was in, since it cannot know the contents of the “Wave” it will be a part of while in the inspector.

As a final note, however, It would be possible to allow a user to define the wave that the sequence would be used in through the sequence’s inspector, and then limit their enemy choices based on that. however, this kind of cylical logic might be  

Insertion and Removal of Game-objects at Positions in List: One of the most important features was ironically, the easiest. I simply added functions tied to buttons that would allow users to easily delete any object in the sequence, insert new ones before the position they currently had selected, or append them to the end of the list. not overly flashy, but it allows the sequence to be edited with ease, and is fairly self-explanatory.


Above: Clicking any enemy in the list will select it for editing – Enums control the type/target of the enemies, while a slider can be used to adjust when it will spawn – subsequent enemies will have their minimum time for spawning set to the time when the previous enemy in the sequence spawned. 


Users can also define the traits of a ScriptableEnemy before adding it to the list, as seen above. In this way, they can quickly add multiple instances of an enemy to the array at the click of a button.

Overall, this aspect should make tweaking sequences for play-testing much easier, and provide our level designers with an effective tool for designing,laying out and testing levels and different combinations of enemies. 

Review, Conclusions and Next Steps:

In closing, The construction of this tool was a great learning experience for me, and a way to re-sharpen my skills in tool development within Unity. The tool I designed should serve our team well in the design and creation of levels and game flow for Disco is Dead. The goal for this design tool was to help our team easily design and test levels within our game, as play-testing and feedback from a variety of sources showed that thought out, sequenced levels would contribute to a more interesting, designed player experience, and to this end, the design of this tool needed to support this outcome. There were some significant design challenges to be addressed, including the need for more sequenced, specifically designed levels, (versus randomly generated ones) and it is my belief, based on the criteria I was aiming for in this tools design, and the success I had in achieving them through this custom editor, that it will go a long way in streamlining our design process and facilitating faster testing and iteration of levels through giving our level designer the ability to design sequences on her own, eliminating the coders need to be involved, and freeing up more time for other aspects of our design process.  

Moving forwards, I intend to give consideration to the “Scriptable_Enemy_Wave” scriptableobject, and whether a custom editor is needed there as well, as this is the interface that takes the waves and makes use of them. if it is deemed a worthwhile and necessary endeavor in our game’s design, I will be creating a follow-up development log on the subject.  

Tool Development – Level Sequencer

Disco is Dead – Development of The Disconomicon

Currently, our team is working on development of a showcase level for the game – which will be the second level of the overall experience, out of three main levels. In order to finish off this experience, and provide a real reward to players at the end, we wanted to design a boss to close out the experience. Throughout the level, the players learn about new types of enemies, and then are tested on that knowledge, as they must fight them. thus, the boss is the culmination of learning and testing, designed to challenge the player to prove their mastery of the systems. The design of this boss is the challenge I am currently undertaking.

Learning Outcomes for Boss

Level two will be introducing three new kinds of enemies – Projectile enemies,  enemy balls, and lane shifting enemies. The design of each should be explained:

Projectile Enemies


these cannot be slapped directly – they throw projectiles towards the players, which can then be sent back to kill their thrower by inputting the correct key press or joystick direction. These teach players that some enemies can only be damaged using their own attacks.

Zombie Ball Enemy


This is a singular, large enemy that slowly rolls towards the players – in order to defeat it, they must beat it back rapidly by slapping repeatedly in the direction indicated. this builds off teaching this mechanic using shield enemies in earlier levels, but invites players to cooperate to overcome a more powerful foe by attacking it together. when beaten, the ball flies back the way it came, wiping out all zombies on the screen. this thus extends from the teaching that the projectile enemies carried – that, in some cases, enemies’ attacks can be used against them.


Lane Shifting Enemies


These enemies are unique in that each time they are hit, they switch between lanes, changing the player they are targeting, and the player that can hit them. they shift slowly so that players can clearly see what they are doing, and react in turn. These enemies teach cooperation and coordination, forcing players to cooperate to avoid being hit – it is not simply enough to swat the enemy away, you must also ensure that your teammate is ready to take on the new threat as it shifts into their lane.

So then, from these three ideas, I can begin to shape a concept of what the boss should be like

Prototyping and Inspiration

Thematically, the boss has already been conceptualized through the development of the narrative – as our game is themed around both the undead and Disco, we have decided upon the “Disconomicon” an evil, sentient book that is causing the zombie menace.

Before starting the level two boss design, I had been doing a bit of prototyping for a potential level one boss, which has since  now discarded, designing a projectile and charge attack for it. This design exercise showed that getting the boss to come in close to the players and then back off again as somewhat cumbersome, and that throwing enemies as projectiles made it hard to see what buttons were required to hit them.

flinging     charge

                   Throwing Pattern                                                    Charging Pattern

In order to resolve the issues presented by this first prototype, I made a few design decisions as to how to approach :

A. the boss should not charge in, but attack using projectiles – this supports its nature as a book, and prevents the awkwardness of the charge attack. It also allows for the use of different types/patterns of projectiles.

B. Who the projectiles are aiming at, and the inputs needed to repel them should be immediately clear – we have placed colored rings around enemies, but the projectiles themselves should be color coded, and should not be placed so high on the screen that the inputs required to reflect them back at the boss are obscured.


A partial source of inspiration for the Disconomicon’s design was in the form of bosses from other games, such as Phantom Ganon, from The Legend of Zelda Ocarina of Time, who required you to reflect his attacks in order to damage him, and the Monster Book of Monsters from Harry Potter and The Prisoner of Azkaban, which was a similarly malign book which attacked by shooting waves of its pages at the player. Both of these bosses presented unique styles that made them memorable experiences for players, that shook up the game’s traditional formula. That, along with reinforcing the learning presented throughout the level, is what I am hoping to accomplish with this boss’ design.


The Monster Book of Monsters – attacks indirectly using projectiles


Phantom Ganon – a boss based around allowing the player to reflect projectiles

Design and Development 

Initial brainstorming for the design of the boss brought certain concepts to light. obviously, the boss would need a variety of different patterns of attack, and challenge should increase within the fight as it progresses. to facilitate this, the boss was designed to have four initial attack patterns corresponding to the enemies introduced throughout the level – a barrage targeting one player, a barrage alternating between two players, a giant attack that both players need to strike repeatedly to knock it back, and a wave of six zombies that charge towards the player.


Meteor attack – Draws on learning from the zombie ball. Players must quickly mash the indicated direction to slow the massive shot’s approach and then repel it back towards the Disconomicon.


Barrage – Draws on learning from the throwing zombies, firing a sequence of fast-moving fireballs towards one player. these can be repelled with only a single hit, and sent back into the Disconomicon.


Alternating Barrage – Draws on learning from the throwing and lane changing zombies, as it attacks players sequentially one after the other. players must time their hits according to the intervals.


Summon Horde – Draws on general learning form enemy types,and presents players with a sequence of enemies to be defeated. this attack is an additional challenge, as the enemies cannot be used to hurt the Disconomicon.

Testing and adjusting these functions led me to tweak some of their functionality – the zombies that the boss spawned in accelerated too quickly, and the boss was boring without a means of ramping up the difficulty. in order to do this, I added functionality to ramp up the boss’ speed and aggressiveness as the players damaged it more, drawing from the “Bloodied” mechanic that many other games have applied (bosses gaining new attacks or changing up their patterns at lower health.) This served to make the experience more varied, and rewards the players with greater challenge as they progress through the fight.


When at low health, the Disconomicon becomes far more aggressive

Conclusion and Plan

Through observing the learning objectives from within the level, drawing inspiration from the designs of other bosses throughout past games, and testing and iterating upon my own design, I was able to develop a prototype for a boss that should cap off the level two and showcase experience nicely. The boss utilizes attacks that draw from the behaviors and learning taken from all enemies that were introduced throughout the level, and combines them into an experience that should challenge players and test their skills, while not being overbearingly frustrating. From this point, I will be taking the boss in for testing, and getting feedback on the experience and how to improve it. I will also be requesting art assets from the art design team, in order to replace the placeholders that I currently have in place. once the play-testing has been completed, I will follow up with another Development Log to review what was found, and the changes that I will be making to develop the experience further. at this time, we will not be including the boss fight in the trailer we will be submitting for Alt Ctrl GDC, as we do not anticipate it being polished enough to show off, but we do have plans to tease its existence, and make sure it is finished in its entirety before the presentation at GDC, should we be accepted.

Disco is Dead – Development of The Disconomicon

Disco Is Dead – Summary Schedule

As part of our process during this sprint week, our team has composed a summary schedule, outlining all tasks, respective disciplines, time-frames, and assigned individuals that we can currently foresee from now until the end of the design and development process for Disco is Dead, in April of 2017. 

The schedule is below, and the full-Resolution PDF of the document can be seen at:


Disco Is Dead – Summary Schedule

Disco Is Dead – October 31 – Nov 4th Sprint Week

From Monday, Oct 31 to Friday, Nov 4th, Sheridan College is hosting a sprint week for capstone teams, during which time they must record their design goals and provide an overview on them for review by an industry professional. To this end, our team has been preparing a schedule and objectives for this week, which can be seen below.


Team 5/ Third Floor Games – October 31st – Nov 4th Sprint Week – Game – Disco Is Dead

Sprint Week Objectives
  1. Completion of Makey Makey System implementation – have touch sensitive controllers prototyped and tested with live playtesters.
  2. Completion of Comic-Book Cutscene System for Vertical Slice Level.
  3. Creation of Arcade Mode for Game – Revision of UI to clarify game experience for players.
  4. Playtesting Custom Controllers and Arcade mode to test and discover weaknesses to be addressed.
Team Member
Coulter Baker
1. Verify that Makey Makey works with Game Systems.
2. Brainstorm ways to effectively connect  MakeyMakey’s two required inputs to one slap.
3.  Connect Makey Makey to slappable controller.
1. Begin Development of  Arcade Mode.
2. Add scoring systems to the game  
3. Implement wave system for arcade mode.
4. Balance speed of game and input with Makey Makey controller.
1. Implement new UI and test with users .
2. Collaborate with UI designer and continue to iterate on UI as needed to get visuals working well.
3. Finish first pass of Arcade Mode.
1. Test arcade mode and make revisions.  
2. Choose best enemies for player experience.  
3. Tweak enemies as needed.
1. Revise Arcade Mode.
2. Change and decide on a primary super mode based on feedback.
3. Make plan for how to move arcade mode forwards through further development.
Jeffrey Barkun
1. Showcase new enemies to group
2. Start on new Cutscene Editor (Complete by Thursday Latest)
1.Showcase game build at Sheridan Club Fair (with XBox Controllers)
2. Continue work on Cutscene Editor (Complete by Thursday Latest)
1.Showcase game build at Sheridan Club Fair (with MakeyMakey)
2.Continue work on Cutscene Editor (Complete by Thursday Latest)
1.Show Cutscene Editor to Jennifer and Nuha to receive feedback on initial design (Get Feedback on how to make it easier for them to use) (If Cutscene Editor is done before then, show it earlier).
1. Make plan for next steps of implementing Cutscene Editor
Nuha Alkadi
– Receive feedback on draft script.
– Edit draft script.
– Showcase game build at Sheridan Club Fair (with XBox Controllers)
– Start recording footage of process.
– Storyboard Level 2 (Vertical slice).
– Edit video.
– Showcase game build at Sheridan Club Fair (with MakeyMakey)
– Record placeholder dialogue for Level 2 (Vertical slice).
– Edit video.
– Work on arranging and editing cutscenes.
– Edit video.
– Finish arranging and editing cutscenes.
– Edit video and submit.
Melissa McQuarrie
1. Allocate enemy types and create beat chart for Level 1.
1. Showcase game build at Sheridan Club Fair (with Xbox Controllers).
2. Write Playtest summary.
3. Allocate enemy types and create beat chart for Level 2.
1. Showcase game build at Sheridan Club Fair (with Makey Makey Controllers).
2. Write Playtest summary.
3. Clarify final boss design and create beat chart for Level 3.
1. Revise beat chart for Tutorial.
1. Define transitions between each level and cutscene.
2. Establish main gameplay beat map for entire game.
– Level 2 cutscene storyboard (rough)
– Level 1 cutscene storyboard (rough)
– revise UI from playtest feedback
– level 3 story cutscene storyboard (rough)
– rig one enemy and player in spine and animate a walk cycle for each
– create first pass arcade effects
– level 1 first pass cutscene pieces
– polish UI, polish rigs and animations for enemies and player, polish effects
Jennifer Johnson
Backgrounds: Warehouse, Back alleyway, Disco nightclub, streets and top of hill
Cutscene Gameplay:
Level 2 storyboards
Cutscene Gameplay: Level 2 cutscenes
Cutscene Gameplay
Level 2 cutscenes
Cutscene Implementation
  • Level 2


Disco Is Dead – October 31 – Nov 4th Sprint Week

Deep Dive Plan and Annotated Bibliography – Systems For Emergent Narratives In Games

Treatment Focus:

The interactive medium of games affords new opportunities for narrative design, and interactive design within narratives. Currently, a new direction in the future of game narratives appears to be in the construction of narrative systems, such as the nemesis system in games such as Shadow of Mordor. Through analysis of past and potential future examples of such design, I will be conducting a case study on the development of narrative systems in games, and seeking to analyze their potential and the direction that this aspect of game design is taking. The intent of this research is to develop my own understanding of the narrative and technical design of such systems, and how I can position myself as an expert in this aspect of the field of narrative design from both a story and technical angle, to make myself a highly valued asset to their development from both a narrative and technical angle.


Annotated Bibliography

Graft, K. (2015, February 4). Designing Shadow of Mordor ‘s Nemesis system. Retrieved October 06, 2016, from

This article provides a brief overview and summary of the of Shadow of Mordor’s ‘Nemesis System,’ along with insights from Michael De Plater – the game director, into the design choices, objectives, and outcomes of the system. These elements include Self-Determination Theory, Player Experience of Need Satisfaction, and GNS Theory. The article elaborates on how traditional narrative was allowed to slide in order to facilitate the emergent.  The article includes insights on how aspects of sports, and allowing the player to construe the greater stories and fill in the blanks were used to the design’s benefit. In concluding, it presents recommendations on how the lessons learned can help designers to create more engaging player-driven narratives in the future.

This serves as an important resource, providing some firsthand advice and insights from the designer of one of the most potentially influential emergent narrative systems of recent years, as well as providing information on other theories such as the aforementioned Need Satisfaction and GNS, which can provide a further research topic to develop understanding as to what needs narrative/game experiences fulfill, and how these influence the design of their underlying narrative systems.


KL, T. (2014, April 29). 4-Layers, a Narrative Design Approach. Retrieved October 06, 2016, from

This article, published on Frictional Games’ Official Blog, presents an alternative approach to game and narrative design, deemed the 4-Layer approach, which maintains that story and gameplay must entwine and support each other in order for a game to present a well-rounded narrative experience. Through addressing four layers of design – Gameplay – that is, ensuring that gameplay supports story, and that they are congruent; Narrative Goal – providing short-lived narrative reasons for short-term goals, tying the player’s motivation more closely to the story;  Narrative Background – designing narrative, such that the player’s actions make it appear, tying narrative and gameplay even more closely together, to that they are aligned in beats, etc.; and finally Mental Modeling – which outlines how the designer can consider the player’s mental model of the game, and how this can extend into the activity of play, and help expand the experience beyond what is onscreen, the article makes a case for the model’s value in that it incorporates considerations of story directly into game design, making it an essential part of the process.

This is a valuable perspective to consider, as it presents a unique view of narrative design, and how game designers can work to more closely entwine narratives and gameplay. In turn, this can be used to gain insight into how one can design systems that more effectively draw in the player, and create more valuable experiences through emergent narratives that stem from gameplay, through tying the two more closely to one another. The article also provides clarifications as to where the approach’s weaknesses are, giving quantifying information for consideration.


Riedl, M. O., & Bulitko, V. (2013, March 22). Interactive Narrative: An Intelligent Systems Approach. AI Magazine, 34(1), 67-78. Retrieved From:

This article concerns the development of interactive narrative systems throughout the past 20 years or so, and some of the questions it still poses, with particular note being given to the concepts of authorial intent – that is, the elements of narrative designed by human minds; Virtual Character Autonomy – how characters in the game can perform independently, thus developing emergent narratives without the need for specific authorial intent; and Player Modeling – which relates to how interactive systems can change their experience and direction based on the player’s preferred method of play, e.g., a player with a more aggressive playstyle will be given more challenges/plot points that require fighting to solve. The article closes by posing questions related to the furthering of interactive narratives, and intelligent systems, and reviewing the progress that had been made at the time of its publishing, and asserting the value of this direction for the field of narrative design, and as a mode of entertainment and its value to human nature.

This article is useful as it takes a look at different approaches to narrative design, and how designers can blend and use them to generate differing experiences. However, it is less recent than the others, and presents a somewhat different approach to narrative design. For this reason, it will need to be weighed against the information in the other articles, and supplemented with the knowledge that has been gained since its publishing.


Ryan, J. O., Mateas, M., & Wardrip-Fruin, N. (2015, December). Open Design Challenges for Interactive Emergent Narrative. Interactive Storytelling Lecture Notes in Computer Science, 14-26. doi:10.1007/978-3-319-27036-4_2 Retreived from

This paper, from the Center for Games and Playable Media at the University of California, proposes a number of research questions through which to approach the design challenges for emergent narrative systems. These challenges include the means for creation for modular content; representational strategies for said content; means of enabling the systems created to recognize their story elements; and story support, pertaining to the decisions a system makes on how to deploy and utilize story-like series of events that it has generated. In each case, the article provides a breakdown of the challenge, and suggestions as to how designers can approach and attempt to overcome it, in order to direct research and hopefully aid in the creation of solutions to these design challenges. There is also thorough reference to numerous other research undertakings and games that have made strides towards addressing these challenges, presented as supporting evidence for its claims. The article concludes by summarizing these elements and posing potential directions to guide to those seeking to develop emergent narratives in the future.

This source is particularly important, not only for the questions it asks, and its own assertions with regards to the considerations in designing narrative systems, but also for the wealth corroborating evidence and sources it offers. With 90+ citations from other supporting and related resources, the paper provides an excellent central source, from which many others can be obtained, and used to support the direction of the deep dive and elaborate further on the development of emergent narrative systems and their development/design.


Kroon, J. (2016). Nemesis Narratives: The relationship between embedded and emergent narrative in Middle Earth: Shadow of Mordor. Retrieved October 07, 2016, from

This paper, written as the thesis of a MA student, concerns the interplay between embedded and emergent narrative within the game Shadow of Mordor, and what this design means for narrative design in games as a whole. The author supports this thesis through thorough analysis of narrative structures within and without games, and references to theories of narrative design within games, such as Celia Pearce’s Six Narrative Operators, among others. The first three chapters are used to establish cause, and the author’s stance on theories of narrative design within games, leading up to the fourth, wherein he analyses the game based on his parameters, explaining its context, and the fifth, where he draws his conclusion, and proposes that the game marks a key point in the development of game narratives, and potentially represents the beginning of a new direction for game stories overall.

This source is valuable for its thorough analysis of the intricacies of Shadow of Mordor’s emergent narrative systems, and its situation of them amongst the larger theories on game narrative as a whole. At the same time, this is the work of another student, and while it is developed in a scholarly manner, it is worth cross-referencing with other sources, and its own sources, to corroborate and ensure the validity and factual soundness of the information and opinions presented.







Deep Dive Plan and Annotated Bibliography – Systems For Emergent Narratives In Games