Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics

Zombie Bash - Post Development Debrief

A topic by evoelise created Sep 01, 2017 Views: 146
Viewing posts 1 to 1
Submitted (2 edits) (+1)

What We Set Out to Achieve

The main aim on this GameJam for us was to get my 15-year-old son some realistic experience of game development.

We also both wanted to learn to use Unity.

I also wanted a refresh on my C++ skills. 

What Worked Well

Getting Jack Experience

I really think Jack got a lot out of this and learn far more out of this than he gets in his Computer Science lessons at school. 

With deliberately no preparation up front and learning the tools as we develop, Jack and I were really pushed. We both learnt a lot of new stuff.

Whilst it may have hindered our GameJam submission we spent a lot of time making the experience as realistic as possible; setting up and using focus group, canvassing options on the design and game play, setting up customer surveys, doing brainstorming sessions, etc, etc. I think Jack really learnt a lot from “doing” rather than “listening”.

Most of all Jack really enjoyed it all. 

Separating Game “Guts” From Unity
We always planned to write the main guts of the game outside of Unity and just use Unity for presentation. This allows us to test the game outside Unity in a non-visual way that works well for unit tests so we can retest quickly and often. 

As always with unit testing, we ended up with more code in the unit tests than in the game code and writing this slowed us down. For a longer project the time saved on retesting would make this completely worthwhile. With such a short project – 5 days - it’s a toss-up if was worth it. 

In the main this worked as intended and we were able to turn around changes and fixes fully tested in no time at all.

Subversion and Tortoise
These were the stars and allowed us to work on the same files of code at the same time. Of 301 check-ins, probably 150 required a merge of Jack and my code changes – only about 5 times did the auto-merge fail and even then Tortoise’s conflict resolution tool made short work of it. 

MS Paint
Whilst the backdrops we created with MS Paint weren’t Mona Lisa standard they do have a real charm about them. There’s a lot of art you can do with MS Paint, I really hope MS reconsider and keep it as a core part of the Windows.

We were obsessive about using JIRA for everything – no “Remember to add X later” conversations or notes. Everything we had to do, change, fix, improve etc had a JIRA ticket raised for it. 

It meant we forgot nothing and had solid goals to aim for. 

I use this at work but it was so useful on this GameJam that I had now forked out for a personal copy, the only software we paid for in this Jam.

Excel, Level Design Macros.
This one came out of the blue, we hadn’t considered this until we needed it.

On the last day we had the last 20 levels to design. We started at 9 and had only 2 done by 11 and later levels have more zombies and take longer to design. 

It was taking too long to design and edit them in Visual Studio, just the typing (and typos) took ages. But the main problem was designing the “rhythm” of the levels, the zombies spawn in cycles; we also had to consider chain-reactions of killing zombies and making sure the player wasn’t placed in an unwinnable situation.  We were a bit stuck.

It just came to us to use Excel to design the levels; using cell validation to ensure that the data was correct (no typos or badly order spawning) and using  a few macros to ensure all was good. Then we could design a set of game play cycles we knew were good and just “glue” them together in Excel.

Without this there would be no chance we’d complete all 25 levels in time.

What Didn’t Work


I didn’t realise the free version of Unity was C# only. Experimenting showed we could call from Unity C# scripts to C++ but the work was taking too long and the marshalling was not “elegant”. 

So we decided just to stick to C# instead, so missed one of my goals for the project.


I’m still on the fence about Unity. I can’t decide if it’s too restrictive as it forces you to develop in the way it wants rather than you develop the way you want and use Unity as a tool. I can see the pros and cons of this and why Unity is like this. 

I think as I learn Unity more I will grow more favourable to it. 

We also had several issues with Unity crashing and locking up. On my PC Unity wouldn’t load the project at all for several days until I had time to reinstall it. 

Lessons Learned

Speed means Compromise

The 5 days deadline on the Jam was both a blessing and a curse. It put a lot of pressure on us on one hand – on the other it made sure we got things done. We enforced a 9am to 6pm work day and only broke that with a two hour "crunch" on the last but one day to ensure we have the game code complete ready to do level design only on the last day and a one hour "crunch" on the final day to get all levels designed and tested. 

Really we spend the first day on brainstorming, game design and focus groups etc and the last day on level design so only days 2, 3 & 4 were spent developing code.

Developing fast like this is so different to my day job where I need to ensure code is well-written and rock-solid and so takes longer. As we learn Unity as we went, there was plenty of code we should have gone back to and refactored, improved or otherwise cleaned up but we just didn’t have the time.


As expected we both learnt a lot about Unity – we both realise we really only scratched the surface though for this Jam and there’s lot more to learn.

Animate the Characters

We decided early on not to have animated sprites due to the time that would be taken to do this.

Looking at the finished game I think this is a mistake. If we had animated the sprites it would look so much better and would not have really taken that much longer to do.

Complete Game vs Demo

We developed a full game, with 25 levels, pause screens, alternate controls etc.  It may have been better to spend the time just doing one level and really polishing it.  

The game also starts the user off slow and “eases” them in to the game. It takes a while to get “good” at the game and learn the rhythms to play well. Given most people rating the game will only spend at most 15 minutes playing this may count against us. That said, any game should “grab” the player immediately though.

Tools We Used

  • Unity Editor - for the game engine.
  • Visual Studio 2017 - for writing the and unit testing
  • JIRA - for bug/issue/task tracking and Kanban boards
  • Subversion - for version control
  • TortoiseSVN – GUI front end to Subversion
  • Microsoft Paint - of course - for all art work
  • Notepad++ - for additional editing
  • Microsoft Word - for design documents and producing focus group & play testing questionnaires
  • Microsoft Excel – for level design,.

Websites We Used

  • Stack Exchange – indispensable for any programmer
  • – for sound assets
  • – of course


Whilst it was tough, pretty exhausting and a lot of work we both really enjoyed it. We both want to do another when I can arrange more time off work. It really got me out of my comfort zone code development wise. 

Thanks to TomDev for the inspired idea of an GameJam for MS Paint.

And Finally, Things I’m Really Proud Of

I’m really proud of Jack, I put him under a lot of pressure to learn new stuff and develop a game. He did really well. 

Tom our 11-year-old also drew 19 of the 25 level backdrops – personally I think they are fantastic.

Also, Fred, the 12-year-old games fiend of the family helped a lot in gameplay testing and proved that all the levels were doable. 

In the end, everyone in family was involved in producing the game, so thanks to Sarah and Seth too. 

And Finally, Finally, Something That We Are All Stupidly Proud Of

The last level, “Hell”, has 666 zombies 😊