LD40 Postmortem

A new quarter, a new Ludum Dare. They seem to sneak up on me these days, with how hectic the world is. Luckily I follow quite a few gamedevs and past Ludum Dare participants, so eventually the word broke through about Wednesday of last week.

# Framework

I had been going back through Programming in Lua, 3rd Edition, because I really wanted to look into creating my own little engine. Even though I probably could have rushed to put some simple API together, the thought of having to debug both the game logic and the engine logic in the middle of the competition was terrifying, so I juggled a few different options:

• pixi.js: used it in the past with Harvest for LD34 (http://mkosler.github.io/ld34/). I really think having a no download HTML5 game is your best bet at getting eyes on your game, especially when it's middling quality - because even if it's not going to win the competition people will play it because you can just pick it up and go. I mainly didn't want to deal with the setup hassle of modern JavaScript development these days (webpack, babel, etc.).
• phaser.io: another JavaScript framework, but it's in the middle of a major transition to help facilitate using it with modern JavaScript practices, so I'll wait until the next version hits an official release.
• LÖVE: my rock. It's the first framework I used and it's remained rock solid for years. Still my recommendation for anyone wanting to get started in gamedev. The documentation is tremendous.
• PICO-8: I love this mini-console so much, but I cannot stand the text editor. I've used it before for Trireme for LD36 (https://mkosler.itch.io/trireme). My whole impetus for writing my own game engine is making something similar to PICO-8 that allows an external editor. I understand you can write your code directly in the .p8 file, but you still are organizing a single file.

I ended up using LÖVE simply because of familiarity.

# Idea

I loved the theme this time, and pretty quickly got together my idea. It started off as paint mixing. You were given an order for a certain color, and you had some amounts of primary colors to mix together to try and get that color. I ran into a couple of problems with this.

• The orders would need to be hand crafted. I couldn't determine a reliable way to procedurally generated orders without it being simply "dump all your primary colors and its perfect!" I considered having the player look at more than one order at a time, so they would need to be vigilant about how much of each color to distribute, but then it would be more of a puzzle game, where the player would have to restart because they used up all their red.
• I initially wanted something where as they poured more primary colors in, the other colors would fade away, but this also lead to needing hand crafted orders, because sometimes the levels would be impossible.

So, even though I had cool idea, the actual game behind the idea wasn't panning out. So, at about 8 AM Saturday, I switched out some key pieces. Rather than something so abstract as colors, how about you are a cook in a soup kitchen? I've been eating a lot of phở (Vietnamese noodle soup) lately, and you end up adding your own accouterments to the soup after it comes to your table. Drop in a few basil leaves, some bean sprouts, a splash of lime, some Sriracha and hoisin sauce. It takes the same concept of the paint/colors idea, but makes it more relatable. Additionally, the balancing colors mechanic was proving too difficult to nail down, and impossible to generate on the fly, so I switched it for levels that would decay over time rather than by use of other seasonings.

I ended up settling on a few other things about halfway into Saturday: I had with the colors idea six different primary and secondary colors: red (0xff0000), green (0x00ff00), blue (0x0000ff), yellow (0xffff00), fuchisa (0xff00ff), and aqua (0x00ffff), and was going to translate that to my soup idea, but I ran into a snag. I only wanted to choose 3 out of that selection, but ran into issues getting the generator to guarantee full representation of the spice categories (spicy (red), salty (green), and acidic (blue)). Even when I fixed the generator, the secondary options (yellow, fuchisa, and aqua) felt unnecessary. So I scrapped the secondary options and just went with the primaries.

# Development

Once I settled on the idea, it ended up being incredibly simple to implement. Mouse movement for controls. Point in polygon detection. Super simple. So I decided to spend more time working one of the things I always neglect: a proper tutorial. It makes sense most of the time. You need all of the weekend just to develop and put together art for the game, and at the end of the competition, you slap a few screenshots together, write some controls in your submission post, and hope that does the trick. But if the game concept isn't immediately apparent (a platformer, a shooter, something like that), your game suffers greatly. People just give it about 10 seconds and then move on because there's so many games to rate.

I wanted the tutorial to actually walk you through the game, so I ended up integrating it heavily with the actual Play game state. Luckily, there's a fantastic set of libraries for Lua called Hump (http://hump.readthedocs.io/en/latest/) that has a stack-like gamestate. So basically would push the Tutorial gamestate on top of the Play gamestate, register a bunch of Tutorial signals to replace the normal Play signals, and then work from there.

# Conclusion

I really think I made a nice, simple, but fun, game this weekend, and hope you all enjoy it.