Cutting the scope anywhere we can, getting something that looks like a game by the end of Day 2… Hands hurt form coding, but we must press on!

https://www.youtube.com/watch?v=LOkfqMwNJ0c

Three days of crunch and we did it! Congrats to everyone who made it over the finish line!

Check out our crazy Apparatus here on ldjam!

Play the Apparatus in the browser

I am a software engineer by trade, and have always loved programming. Inspired by Zachtronics' games and niche esoteric programming languages, I've been tinkering with 2D Turing machines for a few years by now. There is a whole folder of unfinished ideas revolving around one concept - a 2D grid with a playhead, making something happen. A major struggle with these prototypes was that it was too mathematical - I couldn't come up with any challenges for the player that wouldn't directly ask them to solve some kind of a programming task - like sorting an array. Here is one of those prototypes:

When my teammate @erasemenot and I sat down to brainstorm ideas for the jam, a breakthrough happened. With jam constraints, we understood that we should be very careful about the scope of our game. I brought this 2D grid idea, and @erasemenot was open to it, even though it's not the typical kind of games for him. Communicating ideas to another human being is a great way to see holes and problems with your ideas - that often somehow stay hidden when the idea only lives inside your head. We both used to play a lot of Magic: the Gathering, and we both love deck-builders and turn-based games, so our initial idea was to make a kind of deck-builder, where your cards are blocks for the machine. You put together your combo play, and watch the machine fight the enemies, step by step. Enemies were supposed to have their own programs running in parallel. You were putting together a mana stack and spending it on various spells. There were like 5 themes that our game would match very well.

And then the theme was announced - tiny creatures. Damn! Not the theme we wanted. We gave ourselves 2 hours at most to make final decision on the game we're making. A radical pivot was proposed - let's replace our spells with summoning creatures, and have other creatures come and attack us. And make the whole thing real-time. It felt like a huge shift from game ideas we have been fleshing out for the last few days. But we decided to go with it - and we're so glad we did. @erasemenot went deep into the art - the machine, our creatues and all other elements of the game. And I went into Godot trying to code everything we have envisioned. Here is what we had by the end of day one:

At the same time, @erasemenot had great progress with art, so we ended the first day elated and excited about how smooth everything is gonna go on this jam and proud of ourselves how manageable of a scope we have chosen. Oh boy, how wrong we were. The next day we woke up and realized even though the fundamentals are in place, there is so much more we have planned for the game. We wanted to have more than 30 different blocks for the machine - various logic gates, turns, switches, buffs. And at that point we had only like 5. So the crunch began.

Creature behaviours, block logic, animations, arrows, so so many things to make it work. Time to cut the scope yet again. Begrudgingly, I agreed to leave out all the logic gates and switches. The machine was becoming too simplistic - no longer a Turing machine. Without logic and math operators - mana costs that we came up with became more confusing. Nonetheless, our sight was set on finishing the game no matter what. So I coded and coded and eventually had this on my hands:

Now, only a few things remained on the coding side, so I could take a break and make some music. We wanted 2 themes - one for when the machine is paused and you're thinking how to arrange the blocks, and another for the battle. Without much time for two different tracks, I decided to pick 80 bpm tempo for the slow part, and double it for the battle part, bringing a couple elements from one part to another to glue them together. I used Ableton and samples from Splice to make it happen, and both parts came together surprisingly quickly.

As you can see the final game looks much different. That was @erasemenot crunching his part, adding all his art to the game and making it look amazing in the very final hours of the jam. And here we had it. We made a game! It looks like a game, it quacks like a game, it is, indeed, a real game. Short, bugged, but real. What a feeling! We are super glad and thankful for all the wonderful feedback we're getting, and seriously considering taking this game further - with more logic, more creatures, more challenges. Your feedback is super valuable to us to better understand which direction should we go. We don't have anything set up yet where you could follow the game progress, but if you're interested to see where it goes you can follow me on twitter and itch. Thank you, Ludum Dare and all fellow jammers!

Art postmortem by my teammate

LDJAM rules page is unclear on this, but what are the rules regarding patching a jam game post submission? We've been holding out on any patches, besides posting on itch for fullscreen support and changing like 3 variables in itch version for a slightly better balance. Leaving the original submission on LDJAM completely unchanged. I am under the impression that it is fair to other participants to only present original 72 hours work and not add anything during the rating time. But I see other teams releasing patches for their games and began wondering if that is allowed and to what extent? Performance optimizations? Bug fixes? Adding a few missing UI elements we didn't have the time to add during the jam? If it is allowed we would love to continue improving our game for a better experience. That would be super helpful if anyone could clarify this! Thanks!