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
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
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.