For a first attempt at Ludum Dare, it was a very pleasant surprise to wake up to votes, comments, and attention. Thanks to everyone who took a look and played the game!
It was an intense process, and a great adventure. By the end of it, the house looked something like this:
If you haven't yet, please take a look and tell us what you think!
https://ldjam.com/events/ludum-dare/45/warp-trash-flotilla
Can you build your tower of ill-advised power generation solutions Three Miles High?
Please give it a shot, and tell us what you think!
And don't worry too much if it doesn't quite work out the first few times.
Good luck!
On conception, Flickerlight was a much larger game. Here's a short list of things that didn't make it in: - combat and swords. - teleportation network. - three times as much dialogue as we ended up actually getting done. - an entire audio track that we didn't have time to write the music triggers for. - these cuties (thanks to Valintone for pulling off the extra work, and sorry they didn't get used!):
This one is clearly scheming something:
LOOK AT THIS ONE HE'S PERFECT
I'M SO SORRY YOU DIED OF SCOPE CREEP
YOU DESERVED BETTER
We'd never done a game with dialogue before, and I think that was our main - well, I hesitate to say 'downfall' as I'm pretty happy with the end result given the time constraints. But we definitely had less experience in scoping this sort of thing than we do our usual offerings, which tend to be 2D physics sims with scaling-difficulty-based game loops and some emergent behaviour. This was a whole different category of beast.
The biggest difference was in...let's call it prototyping. With a physics sim, you usually have a playable game loop by the end of day 1 and the rest is balancing and polish. Here, the core game loop didn't really become playable until well into day 3, at which point all the art and dialogue and resource management logic finally started clicking into a cohesive whole.
Having dedicated artists on the team made a big difference - but again (sensing a theme here) it was something we weren't used to and didn't really know how to make the most of. As much as Flickerlight isn't really what you'd expect of a 'game jam game', I'd love to try this sort of thing again.
Speaking personally, there were three problems with doing dialogue without prior experience. The first was learning the codebase and dialogue system (as I am not the main mechanics programmer on the team), and the second was estimating the time the work would take. The third problem is less directly relevant - as I am the team's jack of all trades, I often failed to account for how much of my allotted 'dialogue time' I would actually spend on other things, such as sound effects and minor mechanics tweaks.
Those who stumbled across the dialogue path pictured above may have noticed that there was a LOT of backstory, compared to the remainder of the dialogue. Judging optimal dialogue tree depth and levels of recursion was very much something I had to learn on the job, especially once the task management system was finished and every character with a 'complete' dialogue tree suddenly had to have job system compatibility edited in.
The one good decision I made this time around was to do the music first, rather than at 6AM on the last day (Australian time - AEST). This took the pressure off - but it also gave us a moody audio track to use as basis for the theme and mood of the whole game. Personally, immune as I am to listening to the same thing for hours on repeat, I played the main track for the game in the background throughout most of the rest of the jam.
Other than this, there's not much else to say. I worked with some new people, who were a lot of fun to build and cooperate with, and some established teammates, who pulled their weight admirably. I wouldn't have it any other way.
Looking forward to the next one :)
Our Ludum Dare group has a proud tradition.
The events tend to span 8AM Saturday to 8AM Tuesday AEST - or sometimes 9AM on Tuesday if Daylight Savings kicks in during the event, which always makes it exciting to try to figure out whether we're in Submission Hour yet and how much we should be panicking. Regardless - Day 1 is high level design and gameplay loop first pass, Day 2 is polish and playtesting, and Day 3 is EVERYTHING ELSE.
EVERYTHING ELSE usually starts at 10AM Monday or so, and goes right through the night until submission time the next morning.
It's a time of stress and frustration, but it's also a time of tightly-coupled teamwork and amused camaraderie. Some of my best LD memories tend to happen during the last 24 hours - be it banging out an entire soundtrack in the pitch black of the night, or finally seeing that dialogue tree come together three hours before deadline.
So imagine my surprise when, around 3AM on Tuesday morning, we agreed to fold up and go to bed.
We weren't giving up, or dying of exhaustion or frustration. We weren't preparing to pick back up in a few hours, after catching an eye-blink of rest.
We were just...done.
Preparing for Ludum Dare 51
We didn't have a high turnout this time around. We only got any concrete commitment the day before the event, with two and a half people participating; I could only commit for one day due to other obligations. This was...not a lot, in comparison to our past projects. Nevertheless, we went ahead, and within a few hours of brainstorming we had a workable concept.
This is the first Ludum Dare where we've had clearly assigned responsibilities from the start. It was clear up-front that all the coding and UI work would be with @googlefrog, as I didn't have time to contribute outside of audio work. @istaera had no supporting artists this time, and had to go it alone. And I had a very clearly defined timeframe to sort out background music and the handful of sound effects we ended up going with.
(To lessen the load on the coding side of things, I went with one 5 minute track rather than a bunch of programmatically assembled sections, like I have in the past. Strangely enough, the workload doing this was about the same as usual.)
The Game Loop and Playtesting
We love our high scores.
Once the core components had been ironed out, we slapped on a bunch of scoring systems and started playtesting. A few mutual friends were kind enough to run the game through the gauntlet for us. We had towns, raw material repositories, trains, and a way to tell how well you were doing. We were eager to see how we had done.
We found this resulted in-
Well, to be frank, a huge mess.
Rather than a cohesive experience, this setup led to something like the anatomy of a chess game. - The opening, where you set up all your track and start routing resources through towns. - The middlegame, where the whole thing develops into an unrecognizable mess and none of your preparation makes any sense anymore. - There was no endgame because everything was on fire.
However, we pretty quickly discovered that the part where you tried to make your resource routing make sense was actually fun, and decided to prioritise this as the goal. Unfortunately, this discovery was made tending toward the end of Day 2.
We were very fortunate that at this point all the mechanics were in place, and most of the graphics were sorted. It became just a matter of polishing up the UI and rearranging some of the components.
Playtesting and Level Design
Day 3 brought with it the desperate need for content. @googlefrog had already considered making a level loader so that we could send levels to playtesters mid-playtest, to better test specific layouts and edge cases. Unfortunately, some technical issues got in the way of this, and the level loader wasn't finished early enough to be useful.
However, @googlefrog did create a rudimentary level editor. It involved setting global constants manually and copying generated tables from the console, but it did the trick.
Imagine doing this manually.
With the console output provided in a simple text format, @googlefrog and @aquanim were able to send each other levels and collaborate on them very efficiently, despite the time constraints. This allowed for the creation of over 10 polished levels in the last few hours of development - alongside some visual tweaks to solve issues made clear by the new levels, where some layouts could be confusing or unclear to the player.
Post-Jam
We published the game early Tuesday morning...and then just kept working on it. It started with more levels, which motivated @googlefrog to add a proper level editor - which led to a greater variety of scenarios and a better understanding of the game, which then led to mechanics tweaks and balance passes, etc. etc. Now, trains can reverse, towns can catch fire, and we've even put some thought into making levels less punishingly difficult than our usual standard.
We've listed the post-jam release as a separate version in the downloads section of our game page. If you liked the jam game, please consider giving the updated version a shot, and let us know if the additional tweaks made a difference!
If you're interested in things like balance issues and rapid level prototyping, I highly recommend you check out @googlefrog's post in the comments of our game, which goes into a bit more detail.
Conclusion
These things are...taxing. They're high stress and high output, and given most of us have professional lives outside of this, they can be difficult to plan for (or plan around, depending on who you ask). We saw that a third Ludum Dare was scheduled for next year, and thought as a group 'hm, we're not sure about this'.
However, a lot of this might come down to our approach to making Ludum Dare games. Most of our games have complex systems and some sort of resulting emergent behaviour. Many of these systems are broad and can barely be fit into three days of work, let alone playtesting and polish. The tradition of pulling an all-nighter on the last night isn't an artefact of poor planning - it's just become the way we scope our games.
However, that doesn't mean we'll sit out additional Ludum Dare events entirely. This may prove a good opportunity to try working outside of the box; perhaps on an art- or dialogue-heavy game with simpler mechanics. Who knows what trying something new might bring?
We'll see.
Thanks for reading this wall of text, and hope to see you next time :)
Credits