Prototyping, Building On Mechanics, and Design Tests – Coulter Baker – Dev Log #2

Prototyping, Building On Mechanics, and Design Tests

Coulter Baker

October, 2017

Since my previous Development Log, our team has made some major strides towards refining and developing the mechanics proposed and testing their design in order to determine which ones resonate with players, and where improvements need to be made. Our goal over the past week was to determine which mechanics worked best through internal and private testing, in order to choose which to display at a more extensive and open play testing session at Game Dev Drinks in Toronto this past Wednesday.

Our first major decision was on the core dynamic of gameplay, which was between the Button Sequence (DDR) slapping mode, wherein each enemy has a sequence that needs to be input, in order to create more rapid, skill based gameplay, alongside the Directionally Contingent slapping mode, wherein players must slap in the direction that enemies are currently situated in, much like the original game. This decision would dramatically change the overall design of all other mechanics, so it was an important distinction to make beforehand. As outlined in the previous log, I was also developing the game’s Super Mode system, which allows players to execute super moves or change gameplay speed once they have filled up a meter, with the intent of providing a change of dynamics in order to break up the flow of gameplay. Finally, I designed and tested a variety of Enemy types, as well as an overarching class system for them, to provide and support lessons and behaviours that players want to execute, such as button mashing, cooperation, etc. All of these mechanics were tested in combination and weighed against each other in order to determine which were most effective in establishing and conveying the type of gameplay experience that best fits our core dynamics and appealing to our target audience; teaching important lessons to players as to the cooperative nature of the game; the way that the core mechanics work; as well as which will create the most engaging experience to take to conventions such as GDC and Level Up.

Input Sequence/Directionally Contingent Enemy Schemes

This was an important distinction in our prototypes, and particularly for myself as lead of game design, as I wanted to determine which led to a better overall play experience. The original game used a directional system, wherein players would slap in the direction that an enemy was approaching from in order to kill it. I developed a new prototype to test the viability of this system in the new, horizontally scrolling design. In order to achieve this, enemies were designed that would jump, keep low to the ground, or attack from above or behind in order to facilitate the same directional focus, despite the fact that enemies were  mostly approaching from the right, rather than all directions, like in the original. 

Original_Gameplay.gif     Directional_Gameplay.gif

(left to right) Example of original enemy directions, and  new examples from the directional prototype. 

At the same time, I also felt that potentially adopting a more explicit means of instruction, like DDR, based around indicators on which direction to slap, could prove a more effective and direct way of varying gameplay. The system that I designed saw each enemy displaying a series of inputs that were required to be pressed in sequence in order to beat it, rather than having its required input being based solely on its direction of approach. The design goal for this prototype was to see if a simpler design, less dependent on enemy movements was possible, and could provide greater diversity of play while reducing the demands on the player in terms of inferring the correct input that is required of them. 

Ultimately, testing reflected that when all enemies were coming from the right, and without any other visual indication of their direction, players had a hard time grasping the input required for jumping/crawling enemies, etc. Meanwhile, the sequential input/DDR-inspired mode provided much clearer indication as to what was required of the player, and furthermore could be adapted to still incorporate elements of the directional mode – i.e. it could still be set up so that enemies approaching from the top required the player to hit up, etc. For reasons of clarity and flexibility, I decided that the Input Sequence mode best suited our design goals, and moved forward with it.

Super Mode

As elaborated in my previous log, the super mode system is inspired by mechanics such as “Star Power” in games like Guitar Hero. The general concept is that when the two players have successfully beaten enough enemies, they have the chance to gain an advantage through simultaneously pressing a pair of buttons (this is done to encourage cooperation and enforce the two-player nature of the game experience) to engage super mode. This will cause a shift in gameplay, whether that is through giving them a combat advantage, slowing things down in order to allow them to kill large clusters of enemies in a shorter amount of time, or speeding the game up and reducing the enemies’ health in order to allow them to be killed, etc.

Slow_Down.gif        Speed_Mode.gif

(Right to left) slowing down and speeding up combo modes.

Additional/ Different Super Modes

I have also been in the process of designing additional combo types, in the form of a mashing and combo mode. These were different in execution, as they did not actively change gameplay, rather, they presented a cut in of both characters, showcasing the two-player nature of the Super Power, and then asked players to complete a simple task within a short time limit. Mashing mode required both players to mash in order to fill a disco ball, and kill all enemies onscreen, while Combo mode required both players to quickly press a short sequence of inputs. The design goal for each of these was to test different cooperative challenges, and potentially solve some issues regarding the slower mode being tedious or the benefits of the speed mode not being understood.

Button Mashing Mode                                            Combo Mode

test.gif         Super_Combo.gif

(Left to Right) examples of Mashing mode and Combo mode.

When taken in for testing, the results showed that the indication that the super mode was available was not evident enough, as players did not even recognize the option was available. In the instances where players used the mode at all, it was one player pressing both buttons. To help resolve this design issue, our team worked on designing new UI to test at Game Dev Drinks, seen below, in order to encourage players to notice and utilize combo mode.


Most recent prototype, showing off the new UI.

Different Enemy Types 

In order test different means of adding variation to gameplay, I prototyped a variety of different enemy types in the game. Currently, we have been testing the gameplay that emerges from the following types of enemies, and seeing if it matches up with what was intended.

Basic Enemies – These lack any significant traits, and serve to make up the majority of enemies within the game, serving more as a rhythm-keeping mechanism than actual threat, they take 1-2 hits to kill, and spawn frequently. The design goal for these was to introduce the core mechanic of the game to players without overwhelming them, and after that, to use them as a means of filling out the bulk of levels button combos. Testing showed these were meeting their design goal.

Big Enemies – Like basic ones, only requiring more hits, and moving slightly slower. These are intended to be a challenge, and help the player understand the concept of inputting extended sequences to kill enemies. Testing showed that these were meeting their design goal.

Shield Enemies – These are built in to facilitate enemies that it is fun to button mash against – rather than needing to input a combo, you first need to break down their shield, after which point you can access their health bar. These are meant to provide players with a chance to cut loose and just mash away at a target, without concern for inputs, and try to capture some of the appeal of wanton chaos.

Dodging Enemies – Requiring a minimum of 2 hits to be killed, Dodging Enemies switch player lanes each time they are hit, forcing alternating hits from the two players. These enemies encourage player coordination, and are designed as a cooperative challenge to emphasize the cooperative basis of the game. These have been received well and are meeting most of their goals, but there are still some considerations on how to improve them.

Ninja Enemies – These warp behind the player they are advancing on when hit, forcing players to be prepared to finish the hit streak before they are struck. They were meant to be considerably challenging, but proved confusing in basic testing and were shelved for the time being.


Game Dev Drinks Feedback – New Game Design Conclusions and Direction:

Gameplay modes:

As a result of primary testing, our team decided to showcase the input-dependent enemy system (DDR) rather than the directional one. People were generally able to understand and appreciate the new design for the game, and beyond some minor initial confusion, which will be resolved through better instruction and a slower learning curve, the input symbols were clear indicators that allowed our players to easily understand the core gameplay. We did receive some feedback about the original game as well, and how the new design for gameplay may have been straying a bit far from some of our original design goals, such as in the bounce and juiciness of the experience, as well as the overall tone. These are mostly issues for the aesthetic side of the team to cover, but have convinced me to give more consideration to the design decisions made in the first game when moving forward in the design of this new iteration.

Super Modes:

Even with the efforts made to make the combo mode indicator more visible, players still overlooked it. However, through feedback, our team discovered that it was not an issue of UI design, but placement – with the most cited reason being that it was out of their general line of sight – with all action being focused towards the bottom of the screen, and players not bothering to look at the top. Feedback and suggestions that I received have led to the decision to design the combo meter in such a way that there is visual indication on or around the players/bottom of the screen, so that they will be able to immediately notice it. For example, players may start to glow or emit energy when the combo is ready and the indicator will be placed close to their heads, rather than at the top of the screen.

In terms of how the modes actually tested, players enjoyed them overall, but there were considerations for improvement. Mashing mode was not clearly explained, as most players were not initially able to understand that rotating the stick was required to fill the meter, although they did find it enjoyable once it was made apparent. Speed mode also tested well, although players were able to find an exploit that would allow them to keep it running indefinitely. Both of these are important considerations that I will be moving to fix/polish. Slow-motion mode was judged as boring, and players did not really understand its application, and from a design perspective, I think the issue is that it runs for too long without the option to use any less than all of it. In most games, “Bullet Time” is used in shorter bursts that players control the length of, ensuring it does not overstay its welcome. Finally, Combo mode did not really appeal to the players as a rule, as it was too simple, and generally overlooked.

Enemy Types:

Testers liked the different enemy types, particularly the Dodging Enemies that required player coordination to defeat. Shield enemies seemed problematic and difficult for players to tackle, as players were confused as to the shield’s purpose, and even after breaking the shield, often got hit by the enemy itself, due to the length of its health. Currently, I am considering whether shield enemies are worth keeping, and I think the first change should be to eliminate the hit combo that is required after breaking the shield. Instead, breaking the shield should constitute winning the fight to eliminate the confusion that can stem from first mashing and then suddenly being required to switch back to specific inputs to finish it off. There are also concerns about the Dodging Enemies, and that players were confused as to their purpose, often sending them into one another as they took them as a competitive element, rather than cooperative. In order to solve this issue, the enemies will be designed to pause after being hit, in order to allow the other player a moment to prepare for them. Another core issue surrounding not any particular type of enemy, but the whole enemy system, was that as we are testing enemies that run at differing speeds, as well as the enemy that swaps lanes, they would occasionally overlap, confusing our players. This is a somewhat more tricky design issue to solve, and I will be testing several solutions for it, including making all enemies run at the same speed, forcing them to keep spaced out, etc.

Conclusion and Update to Progress Plan.

Based on the results, the current direction for progress is as follows: We will be moving forward with the input-based game mode, as opposed to the direction-dependent one, as testing showed that it was, as anticipated, far more accommodating for players and made for a more straightforward experience. In terms of the game’s super mode, the two modes that are currently under consideration for further development are Mashing and Speed mode, as those tested considerably better than the Combo and Slow-Motion ones, but the priority is to ensure that the UI is placed and developed so that it can be easily seen, and that players will want to activate it. Finally, our team will be engaging in a creative session to discuss enemy types that we want to see in the game, weed out any that are deemed unnecessary, and conduct further prototyping and testing to smooth out those that we have gotten feedback on.


Prototyping, Building On Mechanics, and Design Tests – Coulter Baker – Dev Log #2

Dev Log #1 – Design Goals and Ideation

Dev Log #1 – Design Goals for Disco is Dead: Slappy Seconds.

Coulter Baker

September, 2017


The original Disco is Dead was a rhythm-based arcade game that was designed over a period of four days. It was simple, designed to emulate the coin guzzling arcade games of the 80-90’s. Within the game, players took control of Mike and Mark, two disco stars who used the power of disco, and manly slapping, to fend off hordes of zombies. We hit our design targets dead center, and the game was very well received by our peers and institution.


Pictured, Left to right: Screenshot of digital prototype gameplay, live play session, live play session of Bonus round. People were very enthusiastic and excited to play our game, and that trend has continued even in current playtests.

Now, some ten months later, our capstone team has decided to take the idea forwards into a full scale design, focusing on expanding the mechanics, narrative and world of the game to make it a more fleshed out experience. I have the role of game design lead, and a core design target that I have identified through discussion with professors and consideration of our design targets is how to take the primary mechanic of the original game: rhythm-based slapping, and expand it out to fill a 20-30 Min experience, with enough variation to keep the gameplay fresh and provide a lot of diversity. The mechanic was well received, and proved to be highly entertaining. However, it was designed for a fast-paced, short arcade experience, and took only four days to develop. At its core, the mechanic is simple, which is a plus, but it can also get quite repetitive. Without further diversification, it is almost inevitable that the core mechanic will become tiresome during extended play sessions.

To this end, I conducted some gameplay prototyping to find new design opportunities. I conducted a test designing more competitive gameplay between two players, featuring enemies that needed combinations of inputs to defeat. These elements were very well received, and players enjoyed the competitive aspect as well as the greater complexity required to defeat their enemies, and how these elements help diversify the experience. In order to develop wider view of the application and diversification of simple mechanics, I have also been looking into other rhythm/reflex based games with simple core mechanics, and how they diversified their experience.


Dance Dance Revolution – Mechanic: Rhythm and Button Combinations

The archetypal example of a rhythm game, DDR showcases a lot of the most obvious mechanics that a rhythm game can use – combination key presses, adjusting tempo, and beats or game-play events that are synchronized with the soundtrack. Though considering these elements, and discussion with other designers, I have been considering their application in Disco is Dead: Slappy Seconds as well. During a recent paper prototyping session, we tested the validity of creating enemies that needed a sequence of particular button presses to be ousted, and players, after playing both this and the digital prototype, felt that the combination was stronger than the simple directional input alone. This was also coupled with competitive elements, another aspect that many rhythm games employ. Players responded positively to this as well, which has pushed development consideration strongly towards a two-player focus for our game, although we also want to retain single player functionality.


Pictured: DDR Gameplay.

Paper Prototype Examples:


Pictured: The prototype slapping sheet presented to the players, alongside the challenge/combination cards.

 To this end, we have been designing a system that will see both players running down two parallel paths, with a different line of enemies approaching each in turn. Score will be kept for both players, and the “Winner” will be announced at the end of each round.

Example Of Gameplay Layout: 

gameplayimg Pictured: Players each defend their own row – enemies are color coded with a glow around them to show who they are directed towards. 


Guitar Hero – Mechanic: Combo Rewards/Change of Tempo

One of the more famous rhythm games in modern times, Guitar Hero relies on a fairly simple core experience that is intrinsic to its nature.Mechanically, the interface of the guitar provides the game with intrinsic and unique mechanics – players need to strum while also pressing motes, certain notes are shorter, longer, need to be held, etc.

174044-guitar-hero-iii-gameplay 378071-guitar-hero-world-tour-windows-screenshot-star-power-is-active

Above: Guitar Hero UI and Gameplay(Left). Example of Star Power (Right).

Furthermore, mechanics such as “Star power” allow players to reap the benefits of skill by allowing them to score more points, but strips the colors from the notes, making them more visually obscure. This allows the player to try to score much higher while giving themselves a slight handicap, allowing experienced players challenge themselves for greater rewards. This kind of option could add another layer of depth to Disco is Dead: Slappy Seconds as well, allowing a fundamental change of pace to be instigated by the player after a certain point in time.

Furthermore, considering guitar Hero’s intrinsic control scheme, and how it would apply to Disco is Dead: Slappy Seconds, has lead us to consider the intrinsic mechanics of slapping, we could design a control system that prioritizes the physical nature of the player’s contact with the game’s buttons, based on such elements as the length of time a button is pressed, how quickly it was pressed, slapping intervals, etc. To this end, our team will be starting development with Rock Band drums as a control scheme in addition to controllers and keyboard, and will be looking into developing a custom control method using Makey Makey.


Elite Beat Agents – Mechanic: Combination and Pacing of Small Challenges/Existing Mechanics

Elite Beat Agents is different from the other rhythm games presented, not only in overall gameplay and mechanics, but how those mechanics tie into the narrative and presentation of the game. Whenever the player hits/misses a note in EBA, there is a measurable reaction on the top screen – the characters being shown jump/trip, catch a ball/drop it, etc. the game visually represents the player’s mechanical actions and translates them to a narrative action. This ties in to how we want slapping to work as a mechanic, allowing players to influence characters through slapping as well as enemies, and intertwining narrative and rhythm-based gameplay together.

elite-beat-agents-down-under-20070225071622224  eba-obs-screenshot_large

Above – Different types on interplay – sliding, tapping, etc. The circles indicate the time before the beat should be tapped, and numbers guide the order in which they should be tapped, giving further clarity.

Elite beat agents core gameplay consists of tapping areas of the screen as they become active – missing them will cost the player “Health” and make them lose their combo. It’s interesting to note that this simple mechanic is diverse enough to hold the overall experience, as the time given for any tap, along with the number that appear in a row, and the specific interplay that is needed to complete them – sliding, spinning, etc. these are design considerations that I intend to take forwards, regarding how to modify the mechanics and add diversity through the timing itself, and how the mechanics are visually diverse, rather than creating a huge scope of mechanics that overburdens the team and development of the project.

One example of how this could be implemented might be in the act of the kind of slaps required. there could be an enemy that would require a slap button to be held, in order to build up enough force to kill it, or an enemy that jumps from one player’s lane to the other when it is struck, etc. some enemies could approach quicker, or not reveal what inputs are needed to kill them until they are almost upon the player, etc. the player could see one slow moving enemy approaching, only to have three faster ones rush ahead of it, suddenly changing the required presses from what they were expecting. These kind of micro-mechanics can greatly diversify challenge and gameplay without requiring an actual change to the core mechanics that already exist.


Progress Plan:

Moving forwards, there are a variety of options that our team can take to try to develop and expand upon our core mechanic. For the time being, we will continue testing and begin digitally prototyping of the dual path competitive system to see how it works for players, and the kind of response we get through play-testing, and the multi-button inputs that are required to defeat enemies. For the time being, it is most important that we develop the two initial systems that integrate most cleanly into the game flow that exists, and will serve as a good starting point to branch out from. In the near future, we will be prototyping an testing a “combo” system that will build up a “funk” meter over time, which will allow players to activate a mode similar to star power, allowing them to more effectively score points and cut their enemies down. We have also already ordered a Makey Makey system, so that we can begin consideration of how to develop our own controller that will best support the game experience and provide the most enticing presentation at the job fairs/events we are aiming to take it t, such as Level Up, Etc. Finally, once we have some of the core mechanics in play – button inputs relating to enemies, variable enemy speeds, etc. I will be looking into how to combine and arrange them in order to create varied challenges and different threats, without actually requiring that more mechanics be added.


Picture Credits:

Dance Dance Revolution:

Guitar Hero:,378071/

Elite Beat Agents:


Dev Log #1 – Design Goals and Ideation