Purpose of Prototyping

Almost as soon as we began ideating how we wanted our game to look, sound, and feel, we also began to work on creating a playable prototype. The purpose of the prototype is to help bring all of our ideas together, which exist in a shared but abstract space, and turn it to something tangible to others outside of our development team. This makes sharing our ideas a lot easier, as this provides us with a visual means to explain our ideas. It also provides us with valuable feedback, since playtesting can reveal potential issues or concerns that we did not anticipate. 

Goals for Prototype 1

Since this is our first prototype of the game and it was developed in a week's time, there were specific key features and aspects of the gameplay that we wanted to capture. The first thing was regarding the space of the play area, the player's position, the boss' position, and the camera's position. The way we design the game space plays a crucial role in the feel of a game, and our prototype is able to capture a rough depiction of how we want our game to look and feel. Since there is a lot of emphasis on the boss, we felt it was necessary for the camera to focus primarily on the front face of the boss, while also capturing the entire player area on the screen so that the player can dodge attacks effectively. We chose a third-person perspective for a similar reason, because we want the player to be able to see the entire play space. 

The other main element we wanted to capture in our prototype were the mechanics of the game.  The main button inputs we want for the game are WASD for moving around the space, using the JKL keys for basic attacks, starting combos, and taking reduced damage respectively. Once the K button is pressed to initiate a combo, the player then has to press a specific sequence of the J K and L letters to perform a combo, which triggers special moves that impact gameplay. The JKL keys are what we call the combat keys, since they are involved in the combat system of the game. These keys must at all times be pressed on beat with the song. The movement keys (WASD) are not bound to the beat of the song, allowing free movement. 

In our first prototype, we were able to add the full functionality of the movement keys, as well as the J key, which triggers basic attacks. K and L have yet to be coded in and will be added in future prototypes. Since we are developing a rhythm game, adding a soundtrack felt necessary in the prototype. A simple beat tracker was also added to the scene in the form of a simple cylinder. This is purely for testing purposes, and will later be replaced by UI. 

Process of Developing Prototype 1

The first step was to create the play space, the boss, and the player. I created a plane to act as the floor of the play space and added a simple grid material. I then added a larger red capsule to represent the boss and a smaller green capsule to represent the player. I added a script component to the player to allow for the WASD key inputs to move the player capsule. 

Next, I created a prefab of a sphere that acts as a placeholder for would be projectiles the boss could fire. The prefab has a script component that causes it to destroy itself upon colliding with another game object. The prefab is instantiated when the space bar key is pressed. This is temporary to confirm that instantiating the prefab worked as intended. The sizes of the play area, the player, and the boss were also adjusted. Boundaries were also added around the play area so that the player cannot move outside of the player area. Their mesh renderers were disabled so that they cannot be seen in game. 

Boss projectiles prefabs now instantiate consistently and their position is set to a random value within a constrained area so that the projectile lands within the play area. 

Pressing the J key now instantiates player attacks that move forward in the direction of the boss. The color of boss attacks were changed to red for visual clarity. 

Player attacks now move towards the boss' position regardless of where the attack was instantiated. This is because we do not intend for our game to have a way of missing attacks. We want the basic attacks created from J to auto-path towards the boss. During this step, we discovered that because the instantiated attack prefabs were coded to destroy itself upon collision with another game object, player attacks would interact with boss attacks and delete each other. This is an unintended feature that is not a major priority at this point, but will be addressed later.

A sample soundtrack was added into the game and a conductor game object was added with a song manager script. This keeps track of the time the song starts and takes a bpm value to create set positions with the song. This is a way of tracking the beats within a song. The boss attacks were then changed to instantiated with the beat of the song. 

Player attacks can now only be fired when the J key is pressed on beat with the song. To help with visualizing when the player may attack, a "beat tracker" was added into the scene. This is a cylinder that changes to cyan whenever the "onBeat" boolean is true, and changes to black whenever it is false. An ignore collision script was also created, which causes specific game object colliders to not interact based on the ID of the layer they are set to. A custom layer was created to distinguish the boss game object, the player game object, boss attacks, and player attacks. Ignore collisions were then created for boss attacks and player attacks, boss attacks and the boss, and player attacks and the player. This prevents boss attacks and player attacks from deleting each other, but it also prevents boss attacks from "glitching" in the boss and deleting itself before it even moves. The same applies to the player and player attacks.

The player can also only fire one attack per beat. Before, the player could attack indefinitely as long as the attack window was on. The boss attacks and music no longer starts as soon as the game is started. Instead, they start when any key is pressed. 

To add visual clarity when a beat is missed, a "Missed" text mesh prefab is set to instantiate whenever the player presses the J key while the "onBeat" boolean is false. The prefab has an animator to decrease in size and has a script to destroy itself after one second of being instantiated. Additionally, the floor plane's grid material was replaced with a solid dark blue color for improved visual clarity.

At this point, we felt that we had created a sufficiently detailed and playable prototype. The prototype was built and labeled as Prototype 1. It is available for download in the Downloads section of our home page.

Findings from our Prototype

Since we have yet to gather feedback from player testers on our prototype, our gathered insights thus far are based on our own experience with the prototype and what we've learned. 

Beat Timing - There seems to be some issues with the beat being displayed and the actual beat of the song. It is not entirely synced and while it seems like they are initially, as the song progresses, the beat goes out of sync with the song. At this moment, it is unclear at which point in the code this issue stems from. This will have to be investigated and resolved moving forward with further prototyping. 

Pause/Ending - While there does not need to be distinct UI elements to show when the game is not in an active state, there is currently no way to pause or even end the game. Obviously, this was not something that was planned to be in this prototype given the time restraints and the small developing team. However, it can feel overwhelming and irritating that the player cannot seem to opt out of the game once it starts, other than closing the game entirely. 

Feel of Movement - The movement physics of the player feels a bit clunky and slow. This is a minor nitpick and we won't know for sure how it'll play out in the grand scheme of things, but it is something that is on our radar for now. When a more developed prototype is created, we may revisit the actual movement of the player to see if it smooth enough in the gameplay to create satisfying gameplay and a feeling of "lightness". 

As we gather more feedback from player testers, the list of our findings will be updated.