Treble Theft Postmortem

Prompt: How can we create a rhythm game in which rhythm is not the main objective?


Prototype Goals

  • We wanted to see what a game might look like if acting to the rhythm isn’t the primary goal, but still following the rhythm is necessary for success.

Details

Platform: PC

Players: 1

Controllers: Keyboard


Description

In this game, players must sneak through a building and collect treasure, all while hiding from both security cameras and guards. The cameras turn on with the beat, giving players a chance to react accordingly.


Mechanics

Hiding

While sneaking through the level, players will hear an audio cue that alerts them that the cameras will soon turn on. At this point, players must press and hold ‘Enter’ as well as remain still. If the player is moving or isn’t holding ‘Enter’.

Treasure

As players explore the space, they come across several pink jewels. The player’s goal is to pick up as many of these as possible without being caught or seen.


Iteration Thoughts

Design

  • The game was easy to understand by players.
  • The game was very unforgiving, as any movement whatsoever would cause players to lose.
  • Players wanted to act on the beat, when the best way to play was to actually act before the beat.

Music

  • Sneaking is typically associated with certain Jazz arrangements, so an instrumentation that focused on that association was chosen
    • This helped give a layer of context to the player.
  • Music vs Cue
    • The main melody of the soundtrack was designed to be its own entity, as was the cue/cue announce 
      • This separation between “background music” and “frontline action cue” helped the players solidify when and where they should be doing an action.
      • Keeping the Cue/cue announce noticable and identical with each trigger repetition was important for building player understanding and prediction of future actions.
  • We ran into an issue where the normal cue was too infrequent, and doubling the cue was too fast. Subdividing by 3 offered a nice balance, however the final length of the music track was affected. The current unity looping integration did not allow for music tracks of a different length to loop nicely with each other, particularly when switching between the different cue speeds. A different implementation will be tested using audio middleware.
    • Fmod allowed for different length loops to be integrated together into a cohesive soundtrack, with parameters used to switch between different versions
    • The switching of cue types was not easily apparent and was not apparent.
      • An additional sound effect and visual cue would be necessary to provide player the necessary feedback to play the game without feeling taken advantage of.
      • Regularity and repeatability are staples of maintaining good flow for rhythm games. It is unclear at this time whether random or sequential changing of cue types is best.

Lessons Learned

  • The context of the game has to make sense for the player. A recognizable concept can make a game much more easy to understand for players.