BombFall was designed to be a fast-paced game where you play as a bomb, collecting power-ups and bouncing on enemies to destroy them. Except just falling through the sky was more problematic than I ever thought possible.

Project info

BombFall is the second game I've released on to the Switch and so I thought I knew what to expect. Using cellular regeneration code and a desire to keep a relatively constant fast pace with simple controls and objectives, I started in June 2018 while Loot Monkey: Bling Palace was in LotCheck.

The bulk of the work was completed in October and first submitted for LotCheck around the end of the month. And it was only the first submission of many.

Timeline milestones (simplified)

• Weeks 1 to 2 - concept, initial art style
• Weeks 3 to 6 - cellular generation and art for player and key UI
• Weeks 7 to 10 - power ups, augments, and associated art
• Weeks 11 to 13 - enemies, final art, sound effects
• Weeks 13 to 16 - clean ups, tweaks, final UI and all text.
• Weeks 17 to 35 - submissions to LotCheck (yes 18 weeks, really).
• Week 32 - BombFall released for PC/Mac on Itch.io
• Week 36 - LotCheck passed.
• Week 40 - BombFall released on Nintendo Switch.

(Not mentioned in the above timeline is the fact that the start of the project was during the summer and not as much happened as you think during weeks 3 to 10 :-))

Tech used

• Unity C# (versatile, flexible, beautiful, brilliant)
• Photoshop/Illustrator (other image programs are available but they are crap)
• Audacity (great audio tool and free)
• CXFR (great for loop based music and free)
• Parallels (because I'm on Mac)

What went well

Concept

I think the concept was unique and not something I'm aware of seeing before. Coupled with the pace of the game and sense of humour about a game built around playing a bomb falling towards a city I'm very pleased with how it turned out.

Dual Development

This was the second project I've dual developed for PC/Mac and Nintendo Switch at the same time. Nailed it.

Coding

I am pleasently surprised that the cellular generation was as easy to code as it was and how effective it was for the creation of cloud blocks. BombFall contains a lot of code efficiencies as a result of wanting so many of those cloud blocks on screen and led to some benefits such as the rainbow line (think of it as a check point) and using a common enemy controller that kept the number of pooled objects down to a minimum.

Also this was the first game where I used online text editors for notes but also kept a proper pen and notebook with me. This really helped for lots of things, including art ideas obviously, but was equally as useful for sketching code concepts and organising the breakdown of say the rainbow line into what needs to happen and when and how.

What went ok

Animated vs Static Art

Early on in the project I discovered that because of the falling nature of the game the art cannot be too busy or animated. I decided on a clean line, sharp colour art style with bold outlines and very limited animations so that readability was crucial throughout the game. That also meant judicious use of Unity's particle system and careful colour considerations.

I'm not sure I still achieved everything I could. One problem was the changing colour of the sky as you fell to earth (from space) and incorporating subtle weather effects, er, effectively. Another problem was the fact that a lot of real world man-made objects present in the sky are boringly grey in colour, like the player character, and distinguishing those was tough.

I like the art style because it's striking and a good blend of vector/line based art and soft sprite particle system art. I am pleased with the expressions on the player object, simple facial traits that work. It could be better, perhaps an even more limited colour palette, better use of shading and texture.

Marketing

The art style meant the marketing doesn't look that exciting because it's not meant to be viewed in freeze frame. GIFs worked really though and the trailer video was amazing. I should have done a lot more GIFs (makes note for current and all future projects).

Also, on the plus side I didn't release my game close to any big releases or events. On the down side because of the long delay in LotCheck I found maintaining marketing near possible - there are only so may ways to say "Coming Soon" without sounding like a stuck record that won't deliver. I think my frustration is part of the reason why I released on PC/Mac first and possibly diluted the potential impact of all platforms at once - by mid-January I had had enough and wanted the project done.

What went badly

That Physics Engine

I love Unity and during this project I hated it for the first time since installing it 4 years prior. I went through a hellish perpetual LotCheck cycle of cleaning up code, simplifying colliders, reducing objects on screen and pre-calculating enemy paths etc, before being rejected again for a slow frame rate on the latter stages of the game.

The Nintendo Elves were absolutely brilliant and they certainly helped me to make the game a lot more efficient and sharper. (Although they did mistake the joke error codes I put into the game that appear at the log phase as real error codes!) They also gave me their own log of what was going wrong and pointed me towards key functions being flagged as what they considered over-called. A quick search and after reading a couple of deep tech pages later and the penny dropped.

Unity's physics engine is terrific, except that the default FixedTimeStep and MaximumAllowedTimeStep values combined with the number of colliders I had on screen to reduce the frame rate to about 7 FPS. Seven. I changed those stupid default values to something more practical. Also the engine currently has no way to throttle to number of calls, it has to be done manually in FixedUpdate (a simple counter to only call it half or a third of time is more than enough for my purposes and is also a really great way to make a slow down effect).

Unity's physics engine REALLY hates it when you have two colliders touching, even if they are disabled and on separate layers. You would think that disabled and/or separate NON-COLLIDING layer would not cause a call on the engine. WRONG! Because I have a lot of clouds with a lot of colliders the improvement was almost comic - I shrank the collider slightly on each cloud so it wasn't touching any of the neighbouring clouds. With all those changes made - I flew through LotCheck.

I am starting to love Unity again.

Future

Onwards to the next game.