Postmortem

[davidyu]

What went well? What went wrong? Where to improve?

[davidyu]

What went well?

• Prioritization/task management: mechanic over art over metrics over UI. At the time of submission, the core skeleton of the game was there. The edges were a bit rough, but that's (generally) okay for LD.
• Choosing a solid framework. This went better than I expected because I had no experience with Love2D going into mLD49. If anything, this is a testament to how well Love2D is designed. Everything made sense and there was very little boilerplate I had to write for automaton. Though it's commonly been said that you should know your toolchain going into a game jam, I feel there's also strong arguments for trying something new and different (within reason: for example, I knew a little bit about the syntax of Lua and felt comfortable with picking up the pieces prior to mLD49. It would have been a completely different story had I decided to use, say, Lisp) -- it makes writing boilerplate code a bit more tolerable, it gives you a fresh perspective if you are entering LD from another project, and you get a nice excuse to explore a whole new community, its culture and tools.
  • StackMachine also really made working with Love2D and Lua that much better. Since crashes are automatically logged along with stack traces, it was very easy to catch nasty bugs early in the dev cycle.
• Choosing a few challenging "reach" goals: dbs, client-side considerations for network requests (as of writing this, Lua doesn't seem to have a nonblocking HTTP request module). Focusing on these programming-heavy tasks meant other parts of the game had to suffer (art, UI, graphics).

What went poorly?

• Art and graphics: the art was downright crappy because I wanted to get them out of the way and work on tech as quickly as possible. I really regret this. Graphics is such an important part of doing well at LDs: those initial screenshots participants see have a huge impact on how many people end up playing your game. So you definitely need something eye-catching there, and to keep them playing when there's something fundamentally or relatively flawed about your core mechanic (as is usually the case, because you generally don't have enough time to polish all the rough edges and janky bits of the gameplay, or add enough features and levels to really show off every facet of your mechanic in 48/72 hours) you need to have cool graphical effects. In any case, I just think art and graphics are super-important to a saturated jam and I paid the price for not caring enough about it.
• Controls and tutorial. I assumed a lot of background knowledge and expected people to pick up the controls very quickly. I met some resistance with regards to that. Why can't I hold 3 and press ->? Why do I have to type 3 and type -> if I want to move right three times? What is q...actions...q and why do I care to remember it? That said, I don't think a game like automaton would ever be a casual-friendly game. So maybe the punishing and somewhat unintuitive controls do "make sense" after all; if you get deep enough into the game and the optimizing mindset you just really don't think about whether or not controls make sense.
• Sound. There was no SFX or music in automaton. I kind of give it a pass because there's no narrative or strong atmospheric concerns in automaton; it's very much mechanically based and you kind of don't really need good music for that. But the complete lack of it is still somewhat jarring.

In sum, I think the key takeaway is to be bold in exploring new frameworks and toolsets in LDs, and especially mini-LDs. It makes programming that much more fresh and interesting, and the risk-to-reward ratio is generally quite low if you're open to learning new programming languages. Art and graphics are extremely important, so if you want to do well in LDs and solo game jams, make sure you are reasonably comfortable with drawing good art or implementing neat post/graphical effects.