After making two post-compo releases of my Ludum Dare 26 entry, I think time has come to take a step back and have a long, hard look at the fruits of my labour. It’s kinda hard for me to be sure what went right or not and where, so I’m just going to list some stuff I did and didn’t do and let you be the judge!

What I did

ihavenoideawhatimdoing_dog.jpg

Use familiar tools

This is my second game jam. First one was Global Game Jam, where my team made a puzzle platformer about E.T. type of dude who could suck the energy out of things and use it elsewhere and there were dead animals… Oh, just check it out if you’re least bit interested, I’ll wait. It’s pretty short and ends in a cliffhanger. I was the programmer, and with no game making experience of any kind I quickly decided to use the program I had heard was friendly to beginners: Game Maker.

It really was an eye opener. Suddenly the little JavaScript and C I had teached myself over the years (but never enough to start a career in web development) became immensely useful, since GML is pretty much based around them. The finished product has it’s quirks, but it mostly works as intended and I was incredibly proud of managing to program it.

So there really was no competition. I’ve dabbled with Unity, but found it dense and since I was going to make 2D game anyway, I thought that time spent learning it’s ins and outs could be better spent elsewhere.

Looks like city building to me!

Have a set of goals

They were simple, but they were there:

1. Finish the game.
2. Have AI that interacts with the world somewhat immersively independent of player input
3. Some kind of city builder would be nice!

It’s pretty debatable if I achieved any of these goals, but they shaped the decisions I made during the compo from the start.

The key

Work with what I got

So, about those goals. It became clear pretty quickly (about that time when I had spent six hours trying to get little dudes to stay inside their huts at night) that I wouldn’t be able to make an engaging strategy experience in the timeframe given. That goal had to go. But I had no time to start from scratch, so I had to do something with the stuff I already had – somewhat working villager AI, handful of sprites depicting said villagers and their environments. There was some element missing.

It was only when I first drew that crude monster sprite I realized what this game could be about: stalking villagers and snatching them in the night. That felt… right. Like I had worked towards it all the time. All design became about making that experience more true, more fun, more varied: bigger levels, staying still (and later moving slowly) to be invisible, speed boost for panicking villagers, towns springing up overnight, hunters and their traps…

This is truly a game that wouldn’t exist if it weren’t for Ludum Dare. The idea didn’t even occur to me until I was halfway through building another game!

“If you ask me, this game could do with a bit more pant pant grr woof”

Get feedback early

I’m privileged to have a friend (not pictured, though you can see the actual chat window on the screen!) that tirelessly tests and gives feedback on anything I might be working on. The game would most likely be unplayable, unoptimized mess if they hadn’t pointed my attention towards stuff that simply didn’t work.

Also I am lousy at naming projects. Current title was my friend’s suggestion, and it stuck. Still, now I’m kind of vexed that I didn’t think of using the classic Finnish shareware game naming practice. Mörkö Metsä (Spook Forest) would have been a glorious title.

Alas, poor Yorick!

Kill my darlings

This goes hand in hand with previous item. In it’s earlier incarnations game featured wind, which changed the speed of tree animations, and tracks, which villagers left behind everywhere they went. Both were poison to performance.

I think the original idea with the tracks was that you could follow them back to the villager’s home and go full fox-in-the-hen-house, but since it was already pretty fast to scout the whole level, it became purely cosmetic. Wind was also just fancy way of adding some variety to visuals but it was so pretty! Yet when my tester started to complain about frequent slowdowns they both went. I miss them dearly.

What I didn’t do

Text file where you try to decipher the code you wrote a couple of hours ago probably doesn’t count.

Have programming planned beforehand

Making AI is hard. It’s especially hard if you have no idea what your long term plan with it is. Currently villager needs a host of functions, alarms and other objects to make it behave as intended. I feel that this is needlessly complicated and could be written exponentially simpler, if planned ahead. This is where I feel that making a simple map of all actions any given NPC can take could have saved time and made the game run much smoother in the long run.

Then again… when I started making the AI I really had no concrete idea where I was going with the game. Some stuff became apparent only when I thought I had finished it and started on working with other aspects of the game. It’s a feedback loop. Perhaps the only way to make a good AI is to make a full game featuring a shitty AI, and then rewrite the AI.

Bonus points if you can make out what songs I skip outright.

Set priorities and schedules

Towards the end of compo I chose the way I spent the time poorly. I implemented ambient wind sounds for the latest release without much effort and what a difference it made for the mood! I could have easily made them during the compo and leave the still hopelessly broken villager AI as is.

They are completely right, of course.

Have variables exposed to player

Balancing the difficulty is a daunting task, and it cannot be done without a large amount of varied player feedback. The few testers that I could muster did their best, but the real trial by fire only came when submissions ended and rating started. The game was way too easy, and by then it was too late to do anything about it. However… if I had left a players some way to change the variables that controlled the aspects contributing to game’s difficulty (enemy spawning rate, health, amount of healing, day length, villager speed…) maybe they would have found it a bit more engaging?

Next time I’m participating in a game jam I’ll put all the variables that make any sense to modify into an ini-file that can be adjusted to suit player’s needs.

Conclusion

Wow, word count totally spiraled out of control! I didn’t plan at all to write this long post. I’ll at least end it quickly: I’m still planning on expanding the game, but for the next update I’m writing the AI system completely from scratch. It can take a while! I’ll be posting any updates on Ginnungagap’s Game Jolt page and my twitter, so if you’re at all interested on seeing how this develops, check them out once in a while.

And if you have not yet rated my entry, please do!

Tags: ginnungagap, post-mortem, postmortem