Prototyping, Building on Mechanics and Design Tests

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.

(Top to bottom) 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.

(Top to bottom) 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

(Top to bottom) 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.

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