Ludum Dare 46 – “Tell a Fairy Tale” Postmortem
This past weekend I participated in Ludum Dare 46 with two people from the GameDev.tv community. Ludum dare is an event where teams (or solo developers) create a video game prototype over a weekend.
At the event’s start, the theme was announced: “Keep It Alive.” This reminded me of a quote I once heard:
When do fairy tales cease to be real? When people stop believing in them.
I presented this to my team and we decided to run with it, believing it would lead us to create a unique entry. And it did – there isn’t another submission like ours despite the event having over 10,000 participants.
We settled on a design where you play as Tinker Bell in an orphanage. You fly in front of children to inspire them while avoiding the staff – if they capture you, the game is over. This was to fit within the time constraints. The idea I originally had was a stealth dialogue (yes, you read that right) entry where you play as an elder employee secretly trying to tell fairy tales to the children while not getting caught by the other workers. The stealth dialogue idea still intrigues me as I haven’t played such a game before. Maybe I will create it someday – just need to find (or become) an experienced dialogue writer.
I’ve never worked with the cel shaded aesthetic before, but our fairy tale idea seemed like the perfect setting to try it. If you don’t know the difference between standard and cel shading (often called toon), see this:
Cel shading, as the name implies, comes from shaders, not the modeling of the objects themselves. Right now my 3D artistry consists of hard surface (no organics), so I had to get the characters from asset packs online.
I spent most of my time on the level design. I haven’t done an indoor environment before, so this was a major learning experience in architectural design and where to be structurally unrealistic in order to make indoor flying feel less cramped.
We used IK to create Tinker Bell’s animations. Our main character has 1 forward flight and 2 idle motions.
My time allocation looked approximately like this:
- Concepting: 2 hours
- Asset Production / Iteration: 36 hours
- Programming: 5 hours
- Ice Skating / Stretching: 4 hours
- Random Breaks: 6 hours
- Sleep: 16 hours (I didn’t sleep from Sunday to Monday)
- Testing / Tweaking / Building: 3 hours
I don’t know how many jams I’ve done, but I’m seeing a pattern with all of them: They barely get done within the timeframe and I don’t allocate enough hours to testing the gameplay. I believe it’s a scoping fault where I estimate (with good accuracy nowadays) what I can build within the timeframe, not what I can build and extensively test in that period. For my next Ludum Dare, I intend to mentally subtract 12 hours from the jam duration when planning. Hopefully this causes me to reduce my scope so I can iterate more.
As for our entry, here is some notable feedback we received:
I won’t be adding this game to my portfolio, though it is still searchable online. I learned a lot about cel shading and lighting this weekend, and I intend to implement this aesthetic again in a future entry with greater confidence. In the meantime, play the game if you haven’t, and share with me your harshest criticisms:
Next month, I’m hosting the GameDev.tv community jam. We have over 500 signed up so far, and I’m looking forward to the creative ideas participants come up with. If you’re a beginner gamedev, join us! We have many people in the forum looking for teammates 🙂