The story in Cosmic Crescendo, like many other action games, is very straightforward. There’s a bunch of interdimensional octopus-like bosses invading the cosmos and you need to prevent everything from being chewed up by greediness.
As they feast, feed and breed inside planets, you need to dive into zero-gravity, collect planet-cracking bombs and fire lots of laser to defeat them. The game demands shooting, some planning ahead, proper circular moves, quick reactions and evasive maneuvers. Difficulty may vary depending on if you play alone or decide to save the cosmos cooperatively with friends.
Prototyping: The idea was kind of defolding (pun!) bit by bit. Jacob put together a foundational prototype after a period together in the sandbox, where a bunch of ideas and experiments were discarded. In an early phase, it looked like a circular version of Space Invaders, with a failed attempt at trying to push around bricks on a planet while being bombarded... but who has the time to solve puzzles while the whole universe is being invaded anyways?
Discarding: After discarding the puzzle elements and reducing platform mechanics to a bare minimum, the model was instead expanded from a single planet to a few more, which allowed the player to jump from planet to planet. However, other than players trying to hunt each other down and fire lasers, there wasn’t a great deal to do.
Finding a purpose: Since it is always nice to have a reason for doing something, inspiration came from the old game, Bomb Jack, essentially trying to pick up bombs before they explode. A concept which really doesn’t need any explanation (we thought), and a fair reason for time restricted levels.
“...inspiration came from the old game, Bomb Jack, essentially trying to pick up bombs before they explode.”
Expansion and retraction: Once the bomb logic was in place, the core gameplay mechanics of jumping from planet to planet proved too difficult for new players. Numerous attempts were made to assist players in making that perfect jump, but a stream of notes and points from Gustav eventually massaged the implementation to feature a free flight mode. Part of the compromise was the introduction of fuel, essentially forcing the players to spend quality time on the planets.
Wrapping it up: When you have a game with the main purpose of collecting bombs, it would be nice to know who put them there and exactly why. We found a previously discarded enemy who had to play the role of greedy boss (even though it resembled an octopus) – then from a galaxy far, far away came a mission briefing message from the bomb-providers.
Stuff began to fall into place, but we didn't know what to do with this space invader octopus while players were collecting bombs. We decided to hide him inside a planet – fortunately, that provided a solution for what to do with the collected bombs – and the game ended up near the space-fishing-with-dynamite genre.
Using Defold: Defold is manageable; it is neither overwhelming nor too little. With limited resources and time at our disposal, we like to focus on making games. We don’t care about how and where our code is stored, scouting for tools or managing cross-platform environments. Occasionally, we do cheat though, importing a bit of externally pre-calculated stuff. From an implementation point of view, we are probably pretty pragmatic. More or less everything related to gameplay is managed from one update context. Purists are welcome to claim we misunderstood the entire concept–- but it works for us. Obviously, we don’t mind sacrificing readability in favour of having a bit of a performance buffer (knowing you have the option to spawn a massive amount of enemies is a good feeling).
“As a collaborative tool, Defold really proved itself for us, supporting our shared game custody scenario.”
When the game is done, it’s done; we are not building an enterprise banking system – but instead, hopefully something that is fun. As a collaborative tool, Defold really proved itself for us, supporting our shared game custody scenario.
During the whole development cycle, we never met in person, only speaking to each other once. The entire dialogue around the game was based on check-in comments, Google chat log and the occasional “we need a document or drawing”. Work schedules would typically overlap on a random basis, effectively creating a division between creative anarchy and a more formal review process. Gustav likes to refer to it as “an iterative bottom-up process that is top-down when needed”– which, depending on interpretation, probably summarises it pretty well. It’s fair to admit this often resulted in very experimental and draft like conditions, probably because we both have a tendency to embrace chaos.
Our indie studio consists of Jacob Ulmert, who grew up during the Commodore era, and a younger counterpart, Gustav Björklind, who grew up during PC gaming’s resurgence. We are miles apart (Copenhagen and Stockholm), but share a common love for visual experience and the means of genuine, fun and core gameplay.
“We like to think of ourselves much like two children, trapped in adult bodies, still believing we can do anything and that everything is possible.”
We like to think of ourselves much like two children, trapped in adult bodies, still believing we can do anything and that everything is possible. Occasionally, we are right and sometimes, reality strikes, not always listening to advice and feedback, but we may get there. Typically, design just happens; Gustav usually takes care of the graphics while Jacob deals with the code. However, with an equal amount of synthesizer gear, we fight for volume - but in the interest of harmony and peace, let others pick the chords.