(Cross-posted from the Ludum Dare blog)

Hi! @LiaSae here. For background’s sake, I’m a AAA game coder currently taking a break to fix her brain. LD34 was the perfect chance to make something, feel good about it and fall in love with game-making again.

My game’s called Thunder On, and was made in 48h (~16h of work) even though it’s a Jam entry. I initially wanted to call it Thunder Down, but… Well, you google that and tell me what you find. Possibly not at work.

The idea had been bouncing through my head for a good while now: “being” a lightning bolt, going down, losing energy as you go and having to create new branches, to see the final result once you touch ground. The LD themes gave me the constraints I needed to make a workable implementation.

WARNING: Coder lingo ahead. Artists beware, though I’ll try to have some snippets for you as well.

What went wrong

1: “WTF is going on?”

This was the general reaction from the bulk of the players (thanks all for your feedback, it’s very valuable!). I purposefully left the initial instructions vague, because I was going for whimsy / eerie. But combined with the lack of altitude indication of any sort, this means that what is obvious to me – “well of course the camera’s looking down and you’re going down, it’s like that in the Scene view!” – is cryptic to players.

2: Check the compo rules beforehand next time

I was aiming for a compo entry, but had forgotten even sounds had to be made from scratch. As I checked when getting ready to upload my entry, I facepalmed hard and ticked the Jam box instead. On the bright side, that means it sounds decent instead of terrible.

3: Unity 5.3

I don’t know what on earth was going on with viewport rendering, but a quarter of it routinely turned black for no apparent reason. Getting my alpha blended shader for the cloud layer to work was a matter of one hour of copy-pasting and tweaking the built-in shader to get a version that didn’t break. I can’t say I’m not used to randomly breaking tools, but generally that has been because I’m on a dev branch! I should have stayed on 5.2 for the jam and upgraded afterwards.

4: Responsiveness

I went with a coroutine-based easing animation for the movement, but that also meant blocking inputs until the easing is done. Unfortunately the end of it is virtually infinite, so I added a cutoff. But it was not tweaked well enough, and the game feels frustrating as a result, because you expect to be able to provide new input earlier that you’re allowed to.

5: Too easy

No time means little tweaking, randomness means impredictability, and as a result it’s way too easy to reach the ground. It would not be hard to add a system that analyses possible paths to decide how far up you should go for the best difficulty, but it would take time!

What went right

1: Hell yeah, I made a thing

It’s finished. It works. It feels and sounds and looks better (suppress banding rant) than anything I’ve ever made by myself. It’s complete, people like it overall, they get the point, and that makes it an excellent proof of concept for that idea. I’m happy and proud, and this does wonders for Broken Brain.

2: No crunch!

I live in Sweden, and that meant waiting until 3AM for the themes to be announced. Then to bed, let my brain work it, takes notes, sleep. The next day we had to go borrow the car, buy moving boxes for my partner’s family, drive to IKEA, survive IKEA, come back (this is all very Swedish). Then I had to go buy yarn Because Reasons, head off to an exhibit, go back home, head off again to dump some stuff, then drop off the car. THEN I was able to start on the game, at 5PM past. Between breaks and meals, I put in about 8h that day. The next day I had to go have lunch with a friend leaving the country, run an errand halfway across town, come back, which once again meant starting work at 5PM. Again I put in about 8h total, completing the last tweak to the feel of it all at 2:58AM and doing the submission afterwards. All of this to say: the week-end was packed, which forced me to put in normal work hours instead of Jam Crunch Hours, and I still made it. If life gets in the way, just slash scope massively.

3: Procedural techniques

The bolt is a binary tree (made simple by the two button controls). From there, I generate a mesh that represents the final bolt. The clouds are based on Simplex Value noise from an excellent tutorial at CatLikeCoding. This all adds up to something that feels more complicated and rich than it really is, and was fun to code.

4: Infrastructure

I typically use Assembla for projects like this. The repos have a size limit IIRC, but otherwise they’re free and you can create tons of them. So I created a SVN repo and off I went. Then I made sure to commit quite often, keep things running at all times, and added debug draw as early as I could. It helped immensely, because I didn’t have to guess whether things worked: I could just test, at all times.

5: Coroutines

I had never used coroutines. On related news, I positively hated gameplay and procedural animation programming for its heavy reliance on a crapton of flags. I don’t know how well coroutines-based systems will scale to bigger projects, but for this it was an absolute delight to chain per-frame callbacks instead of keeping track of all that state. It taught me a new way to think and that makes me immensely happy.

Conclusion

I’m happy with it, as I’ve mentioned. It’s far from perfect, but it was never going to be, and I had to finish, package and ship it off. It looks good because I went with something simple and cheap with glow. I learned stuff. I’m getting excellent feedback, and pondering whether to bring this further eventually. I’m taking the time to play and rate some games this time around too, and discovering a lot of fun things. So long live the Ludum Dare, and congratulations to everyone who made a thing, or tried to make a thing. It’s worth it.