We wanted to write about our experience in our first Ludum Dare, and talk a bit about our entry, Disaster Theatre, and its development. So HERE-WE-GO!
I hear you say? Why, that’s a good question! We’re three teams and two freelancers, 10 people in all: three from a bonfire of souls, another three from Doce Brujos, and two from Moitapechá, plus Daniel Parejo and Christian Luque Hurtado. All in all, a rad bunch of people! You can find what each of us did in the game’s credits, plus follow us on the various twitter accounts right in this paragraph 😉
How it all started
From the start, our art direction was clear: our background artist, Christian Luque, is quite good with watercolor (as you can see 😉 ), and we always like the idea of making a game with this style. Conversely, finding a main mechanic which we all liked proved to be quite difficult, as we all had different ideas about what an “unconventional weapon” would be. Ultimately, the idea of a director having to give actors their appropriate script before they ruin the audience’s fun by acting a different part was created organically, stemming from all our different ideas.
- Art direction: Christian’s art is great, and everyone liked it from the start. Because of the medium it’s something that makes Disaster Theatre way more unique, distancing it from a lot of other entries.
- Coordination: we split into two somewhat independent groups (art and programming), as we all knew what had to be done, with periodic general meetings to talk about what we did, what we were doing, what problem we were having, etc. This worked extremely well insofar as it made us all aware of the others’ work and their progress, and we could help each other out if we had any problems.
- Specialization: the art team was very compartimentalized, as we had two people working on character art (Bruno & Cristina), one on backgrounds and items (Christian Luque), helped by Alvaro (who also provided complementary art), and one on animation (Christian Fratta). All in all, this helped immensely with our productivity, as we didn’t have to switch continuously between software and types of work.
- Experimenting: as will be mentioned in the “bad” section, the animator never worked with Spine before the jam started, and two of the programmers didn’t work much with Unity in the past. This proved to create a few problems, but in the end it was great experience for everyone, as it allowed us to take a vacation from the software we use daily, and of course learn lots of new things! Three days of full immersion are a lot of time to be spending with a piece of software, be it an animation package or a game engine, you will learn to use it, and use it fast.
- Coordination: while many organizational things went well, one of the biggest problems we had in the end was that two of our programmers had to work on the last day, and as yopu could expect all kinds of things started going wrong with code! We did solve most of them, but it took the third programmer an entire morning of code spelunking to understand why a few things didn’t work as expected. This is all time we could have used implementing other things, or fixing more bugs.
- Tutorializing: since the game’s concept is not completely straightforward, many players don’t “get it” right out of the box. This could be solved with a tutorial, which is what we tried to implement at the end of the jam, but given the time constraint we weren’t able to do it properly for launch (though we’re fixing it right now!).
- Art scanning and processing: Working with handmade art is a good idea. It looks interesting and attractive, especially if you have a great artist like Christian Luque. But it has a bad side: to scan and process all these illustrations tooks us an entire afternnon (backgrounds and UI elements), time we could have spend making more art.
- Bugs: one of the hardiest bugs in Disaster Theatre appeared a few hours before the end of the jam. With the programmers who created the system in question unavailable, we didn’t really know where to put our hands. In the end we did find a way, after much toiling and grinding of teeth, but it goes to show: always test stuff out before your programmers go home! Especially if the jam ends at 3AM local!
- Feature creep: since the game was developed by Spanish people and an Italian guy, all of whom know English fairly well, so we had the idea to make a multilingual game, why not! Truth be told, the translations were quick and didn’t take too much time, but in trying to implement xml file reading in unity’s webplayer we lost a lot of time for a feature that didn’t end up in the release. It’s great to experiment on jams (we do it all the time), just be aware of how much it could take from the game itself!
- Not testing the development software before the jam: the one who ended up doing all animation for Disaster Theatre never animated in Spine before, or even in 2D. Needless to say, this took a lot of time to correct at the beginning, as acquiring familiarity with his companion-to-be for the next three days took the better part of the first day.
If you didn’t already, you can play Disaster Theatre here! Go on, what are you waiting for!