Jelly Tracks Postmortem

Postmortems by tdressen

Prompt: How can we create a rhythm puzzle game?

Play It!

Prototype Goals

  • We wanted to explore an example of a rhythm puzzle game
  • We found the concept of building a rhythm with a partner to be very intriguing.

Details

Platform: PC

Players: 1

Controllers: Keyboard

Description

Jelly Tracks is a co-op rhythm puzzle game where two players work together to clear a board of enemies. Each enemy is associated with a beat within the “square per beat” track, as well as a color. Guests must communicate with each other to time their actions to ultimately eliminate all of the colored obstacles.

Instructions

Clear the board of enemies within the time limit by sending projectiles from the left and right sides of the screen. Projectiles move to the beat. Red projectiles destroy red enemies and blue projectiles destroy blue enemies, but purple enemies must be hit by red and blue projectiles on the same beat to be destroyed. Try to complete the level with as few projectiles as possible!

Iteration Thoughts

Music

  • A main theme that we wanted to explore was the ability to have player feedback be musically related. We exported different chord inversions for each tonal section within the soundtrack into FMOD so that each player input made sense with the key of the music.
  • Some guests wanted more of a metronome to help with their timing and coordination. The soundtrack had a steady tuba base that followed the main beat of the music, but at low volumes (or in a busy area or poor speakers), it wasn’t as apparent. We also experimented with each projectile bounce having a sound effect to further help.
  • There was a constant battle with delay, as player inputs were ¼-½ beat off from the downbeat. 
    • This delay/latency was solved by separating the Music track and Cue/Action track. This allowed programmers to code in the necessary offsets for better sync.
  • The soundtrack was intended to be catchy, but for some less-skilled guests it added another layer of frustration during their attempts to complete the puzzle. An expansion of the musical theme could help.
  • When the timing factor was added, players wanted a “lead-in” before/at the reset point as a brief break, as well as a stronger start for gameplay.

Design

  • While we initially wanted to design a puzzle game, introducing a co-op element early on so that the game became more accessible, ended up making it less of a rhythm puzzle game and more of a coordination or communication challenge.
  • We played around with multiple ways to make the puzzle element of the game more robust — with no goal or limitations, the puzzles wouldn’t have true solutions, and players could exploit gameplay mechanics (sending out a projectile on every beat) to complete the puzzles with no consequence.
    • We ended up deciding to force players to complete the puzzle within a time limit, respawning all enemies if players didn’t succeed.
    • We kept track of the number of projectiles players have sent during the course of the level. A lower number of projectiles used = better score.

Art

  • Projectiles originally moved in a straight line; to clarify their beat-responsive nature, we made them bounce to the beat.

Lessons Learned

  • There is great debate about whether or not this game was an example of either a rhythm game, or a puzzle game.
  • Visual feedback was important!
  • This game became a stronger rhythm game AND a stronger puzzle game when we removed the co-op element. Before, players were focusing less on the music and more on coordinating their button presses with their partner. Now, players have to rely more on the music and their own hand-eye coordination when executing the solution to the puzzle.
  • For timed levels: players disliked the fact that the timers started immediately on the next beat after they timed out. They wanted to use the time to plan their next move, but would often have to wait for the timer to start again from the top so they had enough time to execute the whole solution.

Future Iterations

  • Start counting down the timer only when the player sends out a projectile. If the timer times out, only restart it when the player next makes an input.
    • Also reset the number of projectiles sent.
  • How can we make the player more motivated to get a high score (i.e., the lowest possible # of projectiles)? 
  • Are there other ways we can limit or discourage the player from mashing the buttons to complete the level?