Cosmic Crescendo

The Process

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.

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

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.

The Team