Week 1 – Radial Space Invaders

I decided to start simple with my first Game a Week by taking an old classic and putting my own twist on it. The result is this weird hybrid of Space Invaders and Super Hexagon, which you can play below (requires Unity Webplayer):

I included a God Mode functionality just in case you don’t have the patience to play the game cautiously, simply complete one run and start the next by pressing ‘G’ instead of the space bar. And there is a bug where sometimes the death animation doesn’t play, I don’t know why this happens yet, but if it does you’ll have to refresh the page. Sorry :(.

I decided to start this week as I knew I’d have a lot of spare time, without any university work or other commitments to worry about, but even so I ended up spending a lot longer on it per-day than I expected. I feel that it paid off, though, as I think the end result is a half decent experience.


There were a few things I set out to learn that I hadn’t had any experience with before this project, all of them features of Unity or C#:

  • Animation, by far the most time consuming thing I spent wrapping my head around. As you can see, the enemies have some rudimentary sprite animation, and the player’s transform is animated whenever hit. A lot of tutorials I found skipped out the information I needed, but this one goes into a great amount of detail.
  • Object pooling as an alternative to constant instantiation and destruction. I have a pool for bullets which is shared by all enemies and the player, and also a pool for enemies, which I planned on utilising if I had the time to implement enemy reinforcements. I learnt everything I needed from this tutorial.
  • Invoke functions; using these essentially allowed me to completely get rid of explicit and messy timer variables. The only disadvantage, in my eyes, is that in order to use CancelInvoke you must call Invoke using a string instead of a function; this could make refactoring a bit of a headache.
  • Coroutines, similar to invoke functions, allowing me to perform certain operations under certain conditions without tonnes of clunky ifs in my Update function.

Unfortunately I didn’t manage to work any sound into the game, so I’ll make that a priority next week. It’s another part of Unity I’m unfamiliar with so I imagine learning that could be quite time consuming.


When I first had the idea, I’d wanted to add in a bunch of control scheme options, for instance how would the current set up compare to playing with a gamepad where the ship zips to wherever you point the analog stick? I suspect that might play better, but I decided to prioritise working on other elements over sinking time into that.

As for the gameplay itself, I had hoped to include more enemy formations and enemy reinforcements to increase the playtime. However, as a little ‘try and get the highest score’ distraction I’m happy with the result.

My original concept also had some barriers between the player and the enemies, like the original Space Invaders, but again I chose not to work on these in favour of rounding out the game flow.

Even though it’s only been a day since I finished the game, I have already noticed a couple of regrettable goofs with regards to the game design. One of the first pieces of feedback I received was that the player expected the planet in the middle to act as a barrier to enemy shots. I added it in right at the end of development in the hopes of adding a bit of thread and purpose (to be the Earth’s last line of defence rather than a purposeless enactor of ruthless alien genocide), but all it does in the end is cause a little confusion and make enemy shots from behind more difficult to see. I still like the intention behind it though, and would probably make enemy shots bigger and easier to see to counter this.

Secondly, and again an addition I made on the last day, I have a function that reshuffles the enemies so that when they enter the first and second formations they spread themselves evenly. A side-effect of the way I did this means that enemies always place themselves on the front-line, regardless of whether or not the player just spent the entire game shooting all the enemies that were previously at the front. This removes any value from choosing one tactic over another; no matter which enemies are killed first, when they change formation they’ll still place themselves as close to the player as if they hadn’t bothered to kill any from the first rank. This is really evident in the final switch, and I feel it undermines the player. I can see the fix in my head, but unfortunately the rules of Game a Week mean I’m not allowed to touch the code now that the deadline is up. Oh well!

However, all in all, I’m very happy with this as a first-week effort. I learnt a bunch of new technical skills and enjoyed tuning the game to what I feel is a challenging but fun experience, and I’m looking forward to applying that experience to the next one.