Dev Log #1: Why Did We Ditch Belts for Musical Nodes?
[p]Hey DJs,
Last month, we revealed that Akupara Games is publishing our first automation game, Future Vibe Check. [/p][previewyoutube][/previewyoutube][p] I talked with Unwise, the solo developer of Future Vibe Check, about what they have been working on. [/p][p]Hey everyone—Unwise here with a quick peek under the hood of Future Vibe Check. Early prototypes pushed music “items” along conveyor belts to an endpoint to be played. The inspiration at the time were sequencers and tracks in a DAW (desktop audio workstation) where there is a linear progression of time and music is played left > right. This seemed like a great fit with the concept of conveyor belts in automation games. [/p][p]![]()
[/p][carousel]![]()
![]()
[/carousel][h2]This worked but there were two things missing. [/h2]
Last month, we revealed that Akupara Games is publishing our first automation game, Future Vibe Check. [/p][previewyoutube][/previewyoutube][p] I talked with Unwise, the solo developer of Future Vibe Check, about what they have been working on. [/p][p]Hey everyone—Unwise here with a quick peek under the hood of Future Vibe Check. Early prototypes pushed music “items” along conveyor belts to an endpoint to be played. The inspiration at the time were sequencers and tracks in a DAW (desktop audio workstation) where there is a linear progression of time and music is played left > right. This seemed like a great fit with the concept of conveyor belts in automation games. [/p][p]
- [p]Since items moved on a ‘belt’ (similar to a DAW Track) it was hard to modify as music was being played. Music happened to you once parts arrived vs you engaging with the creation at runtime.[/p]
- [p]The belt based system didn’t communicate music information outside the visual of the item itself which was hard to understand with 100s of items traversing a belt path. This needed to change so that more music information could be understood and visualized. Since items moved on a ‘belt’ (similar to a DAW Track) it was hard to modify as music was being played. Music happened to you once parts arrived vs you engaging with the creation at runtime. The belt based system didn’t communicate music information outside the visual of the item itself which was hard to understand with 100s of items traversing a belt path. This needed to change so that more music information could be understood and visualized.
[/p]
- [p]Rhythm = Distance: Players place nodes on a grid and each cell on the grid is a sixteenth-note. Drop a node four cells away and you’ve got a perfect quarter beat. Timing is something you place, not something you scroll through. Players already think in conveyor-belt lengths and tile counts, so binding rhythm to distance means they never leave that spatial reasoning loop. This condenses rhythm and routing into a single view—ideal for quick iteration during gameplay.[/p]
- [p]Signals, Not Items: Instead of shuttling physical notes, we moved to players creating an abstract “signal” that is sent to their node network and impacts the music played. That means zero belt congestion and instant branching—perfect for quickly modifying beats. [/p]
- [p]Probabilistic & Generative: One advantage of thinking in networks is that a signal can fork to any number of nodes; this then makes music creation probabilistic. You become the conductor, tweaking patterns on the fly.The switch turned composition in FVC from a destination into a creative building journey working in concert with the belt based automation loops. [/p]