Ludum Dare 23 – Nanofault

So I promised blogging during the event, and I didn’t deliver.  Turns out that during these things you end up either sleeping, or working on the project and not spending as much time working on blogging about the project.  Until afterwards.

For those interested (you should be), check out the main blog for the game entry (as well as updates post competition) over at the NoDisassemble blog page.  If you’re interested in the music in the game (shameless plug) check it out.  All in all, before we get started on dissecting the event from my perspective I want to give a shout out to everyone that was involved.

Sean’s art is really fantastic, even given the limited time constraints I was really impressed with the level of detail and how all of the stuff he designed worked well together.  He’s also highly organized and good at getting solid game designs and ideas down on paper.  Without this skill I think we would have had many more hangups than we did.

Jason cranked away on some solid AI code, enemy spawns, player movement, and lots of Unity tweaking.  He was also responsible for fixing quite a few of the early bugs that were holding some of the progress back and was able to iterate on the design enough to keep the scope small, allowing us to get where we did.

Brandon did a lot of the collision code, player respawn / health / damage as well as the individual scenes for setting up scene transitions.  This includes: Lose Screen, Win Screen, Title screen and moving in and out of the Main World scene.  He also spent quite a bit of time in the late hours on improving some of the reliability and adding level/room transitions.

I did the music and sound as mentioned, and some small implementation details.  I’d liked to have done more coding but the unfamiliarity with Unity and some of the other problems listed below eventually slowed down my help in that category.  It was definitely a fun project, and I’m still happy with the progress we made considering the entire thing was from scratch with no previously working game code.

What went well

I think everyone learned, had fun, and is pretty proud of Nanofault.  That in and of itself is what I’d consider a success.  After all, the real goal of the competition is to get people working with a deadline and really focusing on a project to have fun with it.

Our team worked well together, during some of our meet-ups and gatherings at Brandon’s we had a lot of collaboration going on the ideas and everyone was well engaged.  Well all gained valuable experience, and ended up with a playable game too (it’s quite hard though, so it’s a difficult sell).

What went… not so well

Our lack of experience with the engine I think ended up being a little more of an issue than we had anticipated.  Often changes on one machine when checked in, would fail on another.  This would be caused by anything from metadata files that weren’t checked out or in at the appropriate times, to corrupt project files, and the fact that Unity stores a lot of data in binary files (which don’t merge very well and forced us to have serial checkouts very frequently).

I’m sure there’s a proper way to do collaboration between multiple team members on a single scene in Unity, but we weren’t doing it.  This was frustrating to be able to iterate quickly, when adding files or tweaking files in the scene had to be done by taking turns.

I’ve seen this problem before with “scripted” game engines.  Most of your work on these engines is done through an editor, and less from a coding standpoint.  I tend to favor engines that are almost 100% code driven, and where possible use text representations of level data and other objects.  Everyone hates it, but XML or clearly tagged text files are pretty easy to merge in source control and will allow developers to modify different parts of them fairly easily without much problem.

Our second issue (partly to blame for the above issue) was that we didn’t do enough stubbing.  Looking back, we could have benefited from some “gratuitous” stubbing of code.  This is often a problem you’ll see at work as well when trying to get multiple developers to swarm or work in parallel on a task.  Without appropriate stubbing, there’s not enough code to tie together and developers end up waiting on each other anyway (hopefully deadlock can be avoided!).

I think if we spent friday night going through, even on a single machine, and just stubbing out everything we could think of, we’d have had much more granular things for people to work on and most tasks wouldn’t even have to touch the scene at all.

One more thing, scope.  Our design was too large for the time restriction.  A lot of the things we were considering for the game would be fine for the next version, or a “beyond LD23″ update to the game. We probably should have streamlined it down to something like: “a level with a fixed number of enemies, single weapon types.  Destroy all enemies and move to the next room that has more enemies.”  Had we gotten this working first, I think we might have still had time at the end to implement enemy types, or then add dynamic spawning to the game.  Some of the things we did were a little more complicated than they had to be and thus slowed debugging down.  It’s hard to see in the moment how any of these tiny improvements really affect anything, but every little extra bit of complexity increasing the debugging burden (for lack of a better term).  With a constrained timeline, steel thread solutions are always favored.  Get the bare minimum working, and then extend it until you run out of time (with a little polish buffer at the end, if you really want things to tighten up).

To summarize, I think the most important things to do next time are:

  • Find a steel thread in the original design
  • Stub out everything you think you’ll need for it to increase efficiency among developers
  • Spend some time up front working out your collaboration / repository plans, so you know your system
  • Choose a framework that allows maximum flexibility wherever possible

I highly recommend everyone try one of these competitions, you’ll learn a lot about your own skills and gain a new perspective on constrained development.  I think next time I might try to enter the solo competition and see what I can produce using JMonkey.  The whole time I was always spouting off nonsense about how we should be using JMonkey, obviously it would have been worse because we’d be going from 2 devs with engine experience and 1 without to… the opposite.  Still I want to see what I’m able to come up with in JMonkey next time, so I can see if I end up just eating my words.

Thanks to the whole team, it was fun, and was quite refreshing to be able to put some of my best music to a game that’s actually out there and playable!  Next project I’ll hopefully be a lot more involved with the code.

Leave a Reply

Your email address will not be published. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>