(Originally posted to ViNull.com)
The twenty-ninth Ludum Dare was my third and the second time the Knoxville Game Design (KGD) meetup participated as a location. The last time the KGD took part there was much press coverage that still seems a little surreal. Less press this time, but five games were made by members over the course of a weekend. (Hey, now is a good time to sign up for the KGD mailing list to get meetup reminders!)
Meet #TeamNeel
Instead of entering the solo “compo” I choose to enter the “jam” with a team (if that sounds confusing read the FAQ). The team was comprised of myself, my oldest daughter Rachel (13) and my second daughter Hannah (11). Both Hannah and Rachel have experience making games with Scratch and App Inventor as well as knowledge of Inkscape and Gimp. I offer experience in Unity, Audacity, Reaper, and Paint.Net and together our powers combined to form #TeamNeel. The hash tag is required, as is making the finger sign when said aloud.
The Good
In the early DFA backer videos, Tim Shafer explains his process for designing a game. I’ve used his process multiple times with great success (in short, spend a good chunk of time free writing and after a bit you’ll have a game design). This was the first time I went through the process with someone else (Rachel – Hannah was on a school trip Friday night). The results did not disappoint – we met the theme “beneath the surface” with a hidden object game mixed with a film noir plot in a jungle setting.
I set up a Kanban board on Trello and gave a brief explanation of the process to Hannah and Rachel. I was surprised by how efficiently this made everything. I’m a big believer in agile but I didn’t expect it to work so well with two team members that had never used any project management system before. The girls got the concept of a pull flow, breaking up tasks into small self contained units, and working on one task at a time until it’s completed so well they even told me when I hadn’t updated my own tickets. I fear the day they learn about code reviews!
I’ve always wanted to make a game with voice acting, for fun and for the experience. In the alternate reality where I make games for my indie studio full time we always include voice acting. In this reality it’s a bit harder to pull off. On Sunday we were sufficiently along in development that we could record lines for all the characters (with special guest Cicelie reading for the Sexy Toucan). We’re not going to win any awards with our voice talents, but in context of a game jam I think we did a really good job.
Having a game with this much dialog and voice acting meant a script had to be written. This was another first for me, and I used a table layout in Word that I saw Tim use in a DFA video. I transferred this data to XML and the bulk of the game’s code was reading and rendering the dialog (and playing the audio dialog at the same time). The table system I used was a simple three column layout with a column for the speaker, the dialog, and what characters should be on screen when the line is seen. I had some issues (mentioned below) but overall this was a helpful process that I’ll use again.
Rachel created all of the objects and scene art in Inkscape and Hannah created all of the character art Gimp. When it came time to create the credits screen they collaborated, but not without an argument of which tool was better. I wonder if Gimp vs Inkscape will be as big as Vi vs Emacs. Probably not – both Gimp and Inkscape are useful whereas Emacs is just taking up hard drive space.
The Bad
I mentioned the script above, and the problem I had most was keeping the XML and Word file in sync. I initially assumed I wouldn’t need to keep them in sync, that once I converted all the dialog to XML I would no longer need the Word file. In reality the Word file was printed out for reading during the recording session and needed to match the game exactly. There may be a tool out there that exists to solve this problem and I plan to find it or write it before I do another game dialog script.
The plan was to create a click and point adventure game, which quickly became an hidden object game, which almost became a visual novel. We had to cut some puzzle scenes to fit in the voice acting but if I’m being honest those scenes were not worth keeping. Designing actual puzzles takes a lot of time, and I think you could only do it well in a game jam if you had a team member who did that part full time. Still, I would have liked to have more interaction in the game than what we ended with.
The Ugly
I don’t have anything for this section. Nothing went wildly off the rails, we never lost hours to a bug or gameplay issue, and no road blocks ever shut down progress. This will ever happen again in my lifetime.
Closing Thoughts
I really enjoyed sharing my passion for game development with my daughters and look forward to doing it again. To all the parents, siblings, and friends I highly recommend making a team and entering a game jam. Game design combines so many different disciplines everyone has something to offer to the process and there is something to learn for everyone as well. Not to mention it’s a lot of fun!
I’ve noticed something from my game jam games – I tend to create “experience” games rather than “mechanic” games. Each of my Ludum Dare games have been designed to complete in a single play session of 5-10 minutes long, with no intent of replay value. Several of my game ideas are either for a similar games, or designed around key moments. I don’t think this is a good or bad thing, but I think it’s good that I can identify a design bias. Not sure if I will lean into this bias more or force myself to create a mechanics driven game next.
You can play Jungle Noir at http://www.ludumdare.com/compo/ludum-dare-29/?action=preview&uid=19362
As I’ve done for my prior games, here is a time-lapse of the development:
