Beat, Heart, Beat is a psychedelic, indie rock rhythm-platformer about slashing demons in pursuit of your heart. Slash enemies to extend your airtime and unleash massive air combos, then use that momentum to traverse the psyche!
Embedded Files
Gameplay Footage
Gameplay Footage
Contributions
Contributions
Programming - Key Contributions
Programming - Key Contributions
Beat Management System
Beat Management System
As a rhythm-platformer hybrid, Beat, Heart, Beat presents the unique challenge of being both synced to the music and requiring physics, collision, and spatial movement. Early concepts of the game saw one of these core features "faked" in service of the other - we tried collision-only enemy detection without timing windows, and we tried basing the jump length on the song bpm.
Solutions like these didn't feel nearly as responsive or satisfying as I'd liked, so I explored a way to create a system that could:
Sync every rhythm-based action to the BPM of the song
Handle the playback information of the current audio track
Translate between physical, world space position and the song's playback position
Initialization with Wwise
Initialization with Wwise
When an audio track is prepared, the Beat Manager sets the MusicSyncBeat callback flag, which I used to invoke a global UnityEvent called OnBeat(). This allowed me to create highly reusable listener functions among any features that needed to be consistently synced to the beat.
Initialize the Wwise Event with a MusicSyncBeat callback, which invokes the OnBeat UnityEvent
The OnBeat event ensures all listeners are ALWAYS synced to the beat and can perform custom functionality like pulsing or animating sprites:
Beat Manager helper functions that convert worldspace to song playback
Playback
Playback
Since the player moves through physical space during play, every level needs a method to be converted from a song's playback position to world space.
The Beat Manager contains helper functions that convert these values, which is the basis for functionality such as scrubbing through the Level Editor or respawning the player at checkpoints.
The custom level editor slider scrubs through the playback position of the audio event, which is then converted to the world space position that the player should move to.
Timing Logic
Timing Logic
While directional slashes do use hitboxes to collide with enemies, they act as a "trigger" to check the accuracy of the hit compared to the enemy's actual playback position.
This is most notable for the Cue Enemies, which are a unique enemy type that must be hit multiple times to the beat. Every time a Cue Enemy is encountered, the Beat Manager calculates each of the timing windows, ensuring responsive, music-synced feedback.
2.5D Camera System
2.5D Camera System
Beat, Heart, Beat contains both 2D and 3D elements, separated between the play space and backgrounds respectively. The primary benefits of this system include:
Artist and designer-friendly 3D backgrounds with dynamic camera movements
Camera actions like pulses, zooms, and pans can be controlled on each camera independently for finer control
Creation of stylized, perspective-based UI elements
Camera Stacking
Camera Stacking
The Camera System utilizes Unity Camera Stacking to overlay the orthographic 2D camera over the perspective 3D camera.
The background camera can pan, pulse, and zoom independently of the gameplay camera
Perspective-Based Canvases
Perspective-Based Canvases
One of the most satisfying uses of the overlay system is the 3D, perspective-based UI used in the level select.
The biggest challenge here was getting the world space canvas to render on top of certain UI elements. Since UI elements are always rendered over other elements on the same camera, this was another great place to implement camera stacking:
The level select carousel exists in physical space, but is rendered nicely into the UI using camera stacking
Workflow Improvements
Workflow Improvements
Persistent Song Data
Persistent Song Data
Throughout early development, designers had to manually input each field for a level file's data, even if it was a difficulty variation of an existing song. This meant there was a large risk for inconsistent data, as well as the time cost of manual entry.
Solution:
I created a persistent ScriptableObject list that stores all information related to each song in a serializable list. Whenever a new difficulty file is created, it syncs the shared information if a level file with the same song name exists.
Additional benefits:
Curate the level select based on the persistent list
Seek new files in directories or in the level editor and automatically add them to the list
Minimize the cost of finding files at runtime
Managing Large File Sizes
Managing Large File Sizes
While GitHub works great for most project files, large files such as .wavs, .mp4s, and generated audio banks are unfeasible for version control. This led to the additional workflow issue of requiring every contributor to generate their own banks through Wwise.
Solution:
Using the open source software Syncthing, I created a system to share large file sizes between contributors without risking the bandwidth limit of Git LFS or a manual download from a cloud-based service.
Once contributors have synced their directories to Syncthing, it will automatically add new files, including the generated audio banks.
Syncthing setup for Wwise project files
Misc. Front-End + Polish Contributions
Misc. Front-End + Polish Contributions
Results Screen animation using LeanTween routines
Gameplay showcasing a few things I've worked on, including:
TextMeshPro-based Hit Text materials
Visual aids for hit timing
Beat-synced background animations
Unique enemy behaviors (pogo, launcher enemies)
Page updated
Google Sites
Report abuse