Prototyping the Gameplay

Introduction to Game

Disco is Dead: Slappy Seconds is the sequel to the Winner of the Summer 2016 Sprint Week Game: Disco is Dead. The core gameplay of both the original and the sequel is an arcade style fighting game that centers around a rhythm-inspired system where players “slap” an enemy when they enter a trigger area. The team agreed to expand upon this concept to make it more fleshed out and still be exciting after playing it a few times. The sequel will expand upon the mechanics by including a narrative mode. The method in which narrative would be told would be through interactive cutscenes where the player can slap whenever they want; these slaps will either impact the environment of the current moment or impact the path in which the narrative will take. In terms of aesthetics, the game will revolve around the 70’s disco scene (including having the player avatar be two men in 70’s disco clothes) along with zombies (the enemies of the game).

Screenshot of the original Disco is Dead

My Role

My main priorities in this project are revolved around being a Creative Director and a Technical Director. As Technical Director, I got started on a few prototypes (digital and non-digital) to help solve some confusions and debates with our group.

The first prototype I made was a non-digital prototype to see how the narrative mechanic would work. A script for a fake scene was created for sake of testing how the “slapping at any time” would work; after the script was written, another group member put it in a Twine story. How the prototype was set up was that we left a paper for the tester to slap (using a paper used in the paper prototype for the main game mechanics made by another group member) and we would read the story to the tester. We told the tester that they could slap the paper at any time and their slap would impact the story.

The result from the test appeared to show a positive reception from the testers; they had fun seeing their slap or lack of slap would impact the experience. In terms of conflicts, there were a few notes taken down on what to keep into consideration for when making the game in terms of when to slap and when not to slap. The first note is that the three testers we tested with had a different reaction towards the idea of slapping during the story: one tester didn’t slap at all, one tester slapped at every moment, and one tester slapped when they felt it was necessary. We want more of a reaction like the third tester so we’d have to playtest our narrative with people to see what can we do to encourage slapping from the pacifist players and to discourage slapping from the constant-slapping players. Another note to keep in mind is that all of the players had trouble understanding at first that they could slap whenever they want while the story’s being told: the lesson from that to keep in mind is that the game must have a clear method of saying that the player can slap whenever they wish.

Sample of the Narrative Prototype Twine

The second prototype was a digital prototype to test a few different perspectives discussed by the group. During one of the meetings, we were discussing perspectives and how it would impact gameplay. To help make a decision in the group, I made three prototypes to showcase three different perspectives: a side-scrolling view, a front-view with a rotating ground, and an isometric view. Upon testing all three perspectives, the group decided on using two of the perspectives: the side-scrolling view and the front-view. The group felt that the side-scrolling view worked best for the main levels while the front-view would be used for a boss level since the front-view felt more dramatic and large. The isometric view was tossed out due to the difficulty in 2D art that would arise from the view and the confusion of what button would hit which trigger (for example: to hit the up-left trigger, does the player press up or left? While the player would eventually figure it out, it doesn’t come naturally and adds unnecessary complications to the gameplay).

Sample Images of the Perspective Prototypes

While making the digital prototype, I started the project into a direction that wasn’t considered for the original Disco is Dead: optimized code. Due to the fact the original was made during a sprint week, optimization wasn’t considered and the game was coded in a way that, if we wanted to optimize the game, we would have to start the code back from the beginning. Since the sequel will be a bigger game than the original, we wanted the game to be well optimized. This means, instead of instantiating and destroying enemies, we would pull enemies from a list of inactive enemies and make it active instead.

We would also make sure the SendMessage would not be used to make the game more optimized. Whenever it’s possible, I would use GetComponent of the script of the object to skip the SendMessage function. I did run into the problem when trying to do this with slapping enemies though; since every enemy would have a different script, it seemed like if I wanted to access a function on every enemy script, I would have to use SendMessage. In this case, I received the advice to use Interface code; this would allow the slapping code to access every enemy code through GetComponent instead of using SendMessage by accessing the Interface code instead of the Enemy Code.

Sample of the Interface Scripts

In terms of moving forwards, the team is discussing whether the game would be more fun with directional slaps (much like the original) with enemies that would constantly switch between the directions or with enemies that come in at all the same direction but requires different types of slaps to defeat. To see which one works best, a prototype will be made for both versions. The work will be split between another group member and I. I will be focusing on the directional slap prototype with a variety of enemies to encounter.