Macro Marines post-mortem

Posted by
May 10th, 2012 12:47 pm

This is our first time entering Ludum Dare!  We’re a group of programmers who used to make games together at university, while studying computer science.  We re-united for a fun weekend of game making!

We thoroughly enjoyed making Macro Marines, and thought we’d share with you some of the things that went well and not-so-well over the weekend!

Jonathan, Dunk and Ricky made a game in 72 hours


Unity is brilliant, and easy to use!  It dealt with all the low level fiddly bits that go wrong all the time, and made it easy to get a prototype up and running within minutes (although… more on that later).  Lots of 3D and game engine features are there and ready to use, cameras, lighting, shaders, physics, input, everything we needed.  Any questions we had were easily answered with a look in the documentation or a search on the internet.

We discussed our tools in good time before the competition, so we could decide what to use and practise with it beforehand.  We tried out a couple of game engines before settling on Unity (the first time two of us had used it).  The night before the start of the Jam we set up a SVN server and made sure we could commit and update a sample Unity project.  This meant we could spend all of our time during the Jam focused on making the game!

We got plenty of sleep and decent food!  The Jam started at 2AM UK time, so we decided to get an early night and wake up bright and early to discover the theme in the morning and think of ideas over breakfast.  Each night we slept enough to be refreshed the next day.  This is in contrast to how we’d do things at university, where some of us would try and go the whole weekend without sleep! (it didn’t end well)

Our time management was fairly good, prioritising what needed to be done for our game to be playable.  We reached our target of making a first submission 4 hours before the deadline, then expanded the content and graphics after that.  Of course, this is only true to a certain extent, we were having fun with shiny graphics and non-essential physics way before we got anything functional or any gameplay (see the bad points), but towards the end Ricky was good at keeping us focused on producing something playable and submitting it before the deadline.

A 3D tank model

The graphics were half decent, above and beyond our usual “programmer art” fare!  Practise with Blender was essential for this, and the excellent since I’d not used Blender for a long time.

Both single-player and multiplayer support are in the game!  It’s unfair to expect everyone rating the game to find someone with whom to play local multiplayer, but equally that option is available (and probably better)!  With this in mind we searched for “multiplayer” after the competition and rated a bunch of local multiplayer games while we were still in the same house.

Split-screen multiplayer

AI is TOO good, it’s beating a lot of people who try to play! (according to the comments)  Although this is a bad point too, it’s something we like.  The AI is probably less sophisticated than you’d imagine, but it was still quite a bit of work to get it to play the game strategically.  It’s amazing what you can do with smoke and mirrors 😉

Title screen – pwnz civ 4


Unity is TOO easy – the overconfidence it gave us with our simple prototypes led to a complicated game design that we couldn’t easily balance in the time.  The use of the theme in our game was to play on a looping play area – the surface of a small planet.  Having a tiny world opens up strategic opportunity by allowing attack from multiple directions.  But, even though Unity made it simple, it took more work than expected to fit everything onto a sphere.  This leads on to the next point…

Mapping objects onto a sphere

We didn’t get a working game until Monday afternoon, at which point it was too late to balance it or change the gameplay in any meaningful way.  Up to that point we had been playing with prototypes and working through the game on paper, including several redesigns (originally you could send units over the poles of the sphere, and rotate in any direction, but that got really confusing).  I think we needed to be playing the game, even with really simple gameplay and placeholders everywhere, as soon as possible so we could iterate on what we played.  There wasn’t much time to refine it or explore the concepts we were looking at.

Our game relies heavily on either a second player or a sophisticated AI.  We got AI working eventually, but it’s not balanced, and I’m not sure how fun it is to play against.  Perhaps we should keep this in mind when doing our next Jam, as it’s something we have a tendency to do when designing games – make them system-based and symmetrical.

Misuse of Unity – to begin with we didn’t understand the significance of GameObjects and Components, and tried to do everything using singleton classes and static methods.  Eventually we realised what we were doing wrong, and ended up with a prefab containing the planet, camera and game logic code which we could just drop into a new scene, then change the textures and building layout (using Dunk’s awesome level editor plugins) to make a new level.  Then playtest and balance it… oh wait no time left.

Editing a planet

No tutorial/horrible instructions screen, we left that too late.

There wasn’t enough time for music or silly amateur voice acting; I think those would have added a lot of character to the game!


Unity helped us make a good, complete and fairly polished game in the time we had, but we spent too much time on a complex design and not enough on playtesting.  However it was a lot of fun, and we can always improve :)

Play our game, and help us see what we can do better next time!

See how we made it!


Tags: , , ,

Leave a Reply

You must be logged in to post a comment.

[cache: storing page]