crush. Post-mortem

Posted by (twitter: @oatsbarley)
April 29th, 2013 1:43 am

Phew! That went a heck of a lot better than the last LD I took part in, but it was still a lot of work. I got it all finished within a few hours of the deadline — except for an uncooperative timelapse video — so overall it was definitely less stressful. I thought I’d write up a post-mortem for the process. Hopefully somebody else will find it useful or interesting but, at the very least, it’ll help me get stuff straight in my head.

What happened

I live in England, so I found out about the theme around 6 or 7 hours after it was revealed. I wasn’t particularly inspired by it so I did what I’m guessing almost everybody else did and looked at the Wikipedia article for “minimalism.” After about half an hour of looking around, I decided to focus more on minimalist music than art, since I never really understand art and I’d end up just copying an art style and not thinking about the game.  Minimalism in music is about building up really simple phrases so that they make something, which led me to the idea of building up the player’s obstacles over time. At first they’d be really easy, but then as more of them started appearing at once it’d get harder and harder.

A wall was an obvious obstacle and putting gaps in the wall was an obvious way to overcome the obstacle, so that didn’t take much to come up with. There had to be some way for the obstacles to appear, and I couldn’t really control it very well if I had the player moving through a level at their own pace, so I made the level just an arena the size of the screen and had the obstacles approach the player instead of the other way round. The lose condition was another obvious one: if you get caught in between two walls, you lose.

And that was that! It took about 5 minutes after I’d finished reading up on minimalism for me to come up with the idea (due in no small part to how simple (minimalist!) they were), which meant I was about 35-40 minutes into my time and I’d already come up with the mechanics. I took a quick break to get breakfast and then came back and made a mock-up in photoshop of what the game was going to look like.

It looked sort of like this, except not broken. This is actually a very early screenshot.

I made some quick assets from my mock-up and started coding the game. I used AS3 and Flixel and I didn’t really have any issues with either of them. I only used Flixel initially because the Flashpunk website was down, but I didn’t miss it too much when I really got into coding. Once I’d got the mechanics down it was about midday and I was about 4 hours in. I took a lunch break and then decided to work on some music (I used Ableton Live and the Nexus2 VST); obviously the idea was to have the music be in a minimalist style, so I stuck with a single instrument and a droning bassline with a melody plinking away over the top.

When I tried the music out with the game to see how it fit in, I accidentally lined up the timings of the first few walls with the beat of the music. It had a really nice effect, so I worked on syncing up the entire game with the music and it instantly felt a lot more atmospheric. At this point it was about 5PM and I’d been working on difficult stuff for most of the day, so since I felt as if I had a lot of time to spare I spent the rest of the night polishing aspects of the movement and the graphics. I’d been having a lot of trouble with collisions for a few hours, and it turned out that I’d just forgot to call super.update() when I overrode it, so I kicked myself for the rest of the night.

A shot from the final game. It actually gets kind of zen-like when the pace picks up and you have to be in the zone otherwise it gets a bit stressful.

The second day was polish day! I added nice colour schemes, coded a background fader that faded between colours, cut the music up into instrument tracks and made a rudimentary tracker which looped instruments at the right times (and halved the filesize of the game), spent 3 hours fixing the wall-generation algorithm, then made a win/lose screen, a title/instruction screen (with nifty little keyboard keys that light up when you press the actual keyboard keys) and set them up to fade between each other. Half-way through the day I’d come up with the name “Minima,” and I’m sure I don’t need to explain where it came from, but after a few hours I was getting sick of it and just ran through the tags on colourlovers.com palettes for inspiration. “Crush” came up and it fit perfectly. At first I was searching for another word to pair with it, but I remembered the theme and just went with a one word title. I added the full-stop after the title because it’s final; when you get crushed, it’s the end. It’s very gimmicky but I think it looks nice.

I tried to make the title screen as minimal as possible. Originally it just said “SPACE” underneath the title, but my playtesters (thanks mam and dad!) thought it was part of the title and weren’t sure how to get to the next screen.

After all of that was done, I was pretty much finished. There were some eleventh-hour bugs to fix, but they went away with some hackish fixes, and then I was done. I compiled a SWF, hastily made an AIR installer just in case anybody wanted it, uploaded the background music (the track I’d been using before I cut it up to use with the tracker) to soundcloud, committed the code to a github repo, filled in the submission page and… then sat for about an hour trying to get my timelapse video to render. At one point I restarted my PC, forgetting that I still had the submission page filled out, and had to retype and relink everything. Eventually I gave up on the timelapse and just submitted everything else. Ludum Dare 26 accomplished!

What went right

Okay, so here are the things that I’m glad I did and that I think contributed to me being happy with the end result:

  • I didn’t stay up for the theme announcement – if I had, it would have been 2AM for me and then I probably wouldn’t have gotten to sleep for worrying about ideas. I would have woken up later, been more tired, and I probably wouldn’t have had a good start to the first day.
  • I focused on the mechanics first – every time I caught myself doing something that wasn’t mechanics-related in the first few hours, I quit it instantly and got back to coding the core game. It meant that I had the actual “game” done by midday on the first day, and left a day and a half for making it a good game.
  • I came up with a really simple idea – my typical game ideas are overly ambitious, so I’m proud of myself for come up with something appropriate for the time-scale. The could have come up with something more complicated and barely got it done in 48 hours, but being able to get the game done in 3-4 hours and then having the rest of the time for polish meant that I was actually happy with the end result and not just pleased that I’d done something.
  • I didn’t tweak until near the end – so I wasn’t fiddling with optimisations or better sounds or neater graphics or neater mechanics until I’d got the core game (with music and graphics) done. This meant I didn’t get lost in the details without actually making any progress.
  • Got some second opinions – I had people try my game out, and they found some big bugs that I had never seen before, and also threw up some UI/UX issues that I’d thought were complete non-issues. There’s a world of difference between the game before playtesting and the game afterwards, and it was all new stuff.

There were lots more little things that went right, but those were the main things that really had a big impact.

What I wish I’d done, or not done (and will, or won’t, be doing next time)

And here are the main things that didn’t go so well:

  • I didn’t have any version control – I did have a backup though, since my stuff was on Google Drive. What a lack of version control meant for me was that when I made a big change to the code and then decided I didn’t like it, I had to rewrite it the old way based on memory, and it almost never worked out right.
  • I wasn’t totally familiar with the libary I was using – this didn’t turn out to be a huge problem, but it did mean that the majority of my time spent coding involved reading through the Flixel documentation. It’s similar to Flashpunk (which I know really well) but just minutely different enough to cause a lot of hidden problems when I assume something works a certain way and it doesn’t. If I could do it again I’d get some practice in with Flixel in the couple of days before the compo.

I think that’s actually all that went wrong. It went surprisingly smoothly, which is great! I would maybe do a stream next time, although it would make me very self-conscious which could really affect my productivity. I could see myself pandering to whatever audience I had instead of getting work done, so… maybe not.

So that’s another LD down. I’m going to be free from university life when the next one comes around, and hopefully I’ll be making progress as a full-time indie developer, so I’ll definitely take part in LD27. Now I need to grab some breakfast and start playing everybody else’s games. There’s no way I’m getting 1700 done in 3 weeks, so I think my target is going to be 500+ so that I can give each of them a fair amount of time.

Good luck in the voting, everybody!


One Response to “crush. Post-mortem”

  1. naughtyloose says:

    as a tip: you can always edit/add more links after you’ve submitted your game. :)

Leave a Reply

You must be logged in to post a comment.

[cache: storing page]