Defendy Rocket: Development Update #7

Defendy Rocket continues to come along, although at a much slower rate now that we've moved away from building new gameplay systems and are concentrating on balancing, polishing and optimising the existing ones. We've had some significant issues with Unreal 4 (mostly involving lack of support for Android phones), which has slowed us down a lot, although we've slowly been overcoming most of them.  We intend to cover this topic in a future blog post, but the short version of the story is that it turns out Unreal 4 was a bad choice of engine for developing light-weight games on Android phones.


Early last week, we were hoping to put out our second BETA test. We had hoped that this would basically amount to a nearly finished game and that we would release it to a larger group of people, who could provide feedback for everything from gameplay improvements, the rate at which everything unlocks and - something that we felt was really important - the advertising systems. But we hit a snag.


The reason we wanted to put in new advertising systems is because the ones that are provided in UE4 by default (AdMob for Android; iAD for IOS) are both, well, a bit naff. We've had several people tell us as much and we've seen the results of AdMob running in the game to know it's not going to paint an ideal picture when we do release the game. Not to mention the implementation of these advertising solutions limits us to banners ads and nothing more, and we'd like to be able to use interstitial video ads occasionally.

So we decided to replace Epic's implementation and use our own. We figured this would mean downloading an SDK, hooking it up into native code, creating some blueprint nodes to display the adverts and off we'd go. But that's not the case. Not at all. We downloaded the UnityADs SDK and, to cut a long story short, found there's no direct, easy way to get the thing hooked up into the engine. At this point we're still not exactly sure what it's going to take, but it appears to involve wrapping it in a plug-in, finding a way to push that plug-in into the engine and... some sort of other voodoo magic? We spent almost a day looking into this, found there's almost no help available anywhere (no tutorials or anything, just vague references to people trying to do this elsewhere) and had to move on (for now at least - we absolutely have to return to this and solve it at some point in the future).


At that point, we decided that we were going to roll out our second BETA out in two stages: We'd first roll it out to the people who'd already played it (plus two additional people to get some initial feedback again) and then, later, once we'd implemented the advertising systems, roll out a much larger BETA as originally planned. We sent out some invites to the selected few and planned to release it to them last Friday.


But we hit another serious problem: Somewhere along the line, the game's performance (on Android anyway, we still haven't gotten around to setting up the Mac and building the IOS code yet) had taken a serious performance hit (on a top end Android phone the game was now running at 20-40hz most of the time instead of 55-60hz). And we had no idea why. So instead of polishing up the last few features we'd aimed to get into the game for the BETA release, we started optimising:

We spent most of Thursday, all of Friday and all of yesterday optimising everything we could think of. We've literally tweaked and refined everything we thought might make a difference to the game including (but limited to):

  • Making sure nothing gets spawned in the game. Ever. That includes audio components, particle systems, actors etc. Everything is pre-loaded and cached into pools. We re-use everything. This practically let us remove the garbage collection from the game.
  • Completely overhauled all of the collision systems in the game and streamlined them all out using custom collision channels.
  • Reworked blueprint functionality making sure no additional work is being performed.
  • Reduced the quantity of particle systems and optimised them all heavily.
  • Reduced the quality of materials, making sure everything is mobile optimised.
  • Tweaked all of the static meshes in the game to make sure no un-needed functionality is being used in the game.
  • Tweaked the project settings, removing anything that we absolutely didn't need.
  • Rewrote the music system, greatly reducing the amount of data being accessed / created at runtime.
  • Removed a lot of redundant assets from the game and made sure we're re-using whatever we can.

And although all of this stuff helped a lot, the game STILL runs inconsistently on Android phones! We've even been back to old builds to try and work out how and when the game's performance went to hell, but there's just no obvious answer (again, we have a lot of thoughts on this subject, but it's too much for this blog post, so we'll talk about it in a future one instead).

As I write this, we've got the game running at 55-60hz most of the time, although we're seeing significant drops to 30-45hz when a lot of stuff happens. We're pretty sure the big culprit at this point is a combination of draw calls and material transparency, but we've already butchered the quality of most of the systems responsible for these and there's not much more we can do to streamline this further. (short of replacing everything with flat, particle system-less cubes anyway) 


Right now we're now returning to do the work we were planning to do early last week, with the goal of putting out the initial BETA #2 on Wednesday/Thursday. For those interested, we've created a new gameplay video, showing off some of the game as it looks right now:

Since the last development update, we've:

  • Re-worked the large rocket's shield (you can now attack them directly from the behind, mitigating the shield).
  • Continued working on and improving the cosmetics screen and upgrades screen.
  • Tidied up a lot of the frontend flow.
  • Reworked the core game, moving everything to a central class, allowing us to stream everything in during the splash screen sequence.
  • Improved some of the particle effects in the game.
  • Added additional cosmetic items.
  • Added a system for managing the game's sound effects, fixing an issue where too many concurrent sounds would cancel the game's music.


As an exercise in project management, this morning we also decided to work out approximately how long it's going to take us to finish this game and get it out of the door. We came up with this very rough timeline:

  • 6th August: Initial release of BETA #2. Medium difficulty implemented and first pass balanced. Hard/Endless modes not ready for testing at this time.
  • 17th August:  Hard mode implemented. Systems for endless mode complete and endless mode implemented. All game assets, UI, audio, music etc complete and polished. Core game is finished and mostly balanced (balancing will continue until the end). 
  • 24 August: IOS code built, IOS achievements/leaderboards implemented.
  • 7th September: Advertising systems fully implemented. IOS submission. Extend BETA #2 to more people to get final feedback.
  • 21st September: Game released to the public.

We consider this to be our worst case scenario. With any luck, for example, we'll solve the advertising issues much quicker than expected and we can pull everything forwards.

Posted on August 4, 2015 .