One year has passed since my participation at Ludum Dare 29, and it’s high time I wrote a post-mortem.
This was my second go at the competition, but also my first group experience, and thus a lot different. Both types – solo and group entries – pose a different challenge. I feel like the solo competition focuses on time-management and is psychologically more demanding (being solely responsible for both every achievement but also every setback results in greater ups and downs), whereas the group competition demands first and foremost a good co-operation and distribution of tasks, as well as good communication throughout.
How did my second Ludum Dare go? I’d deem it a success, despite not getting anywhere near a finished game. The two goals of a Ludum Dare are:
Having also finished a game is of course great, but it’s just a nice bonus to the two aforementioned goals – an excuse, if you will, to achieve the two “real” goals. After all, some months later we won’t remember the game itself as much, as the time spent making it, and the stuff we learned. At least, that’s how I like to view it.
And judging by my own, but also by the rest of the team’s feedback, we achieved both goals.
My role was that of the coordinator/”mentor”, since I happened to be the oldest and thus most experienced with game dev and Java (not by much, mind you). Here are some things that went right/wrong, from my point of view:
What went well:
- Motivation. I had the feeling like every member of the team was motivated throughout the competition. Even under harsh conditions and with the deadline approaching, we still kept going. Much of the initial enthusiasm lasted until the end.
- Cooperation. Everybody cooperated well in a friendly atmosphere. Confronting a non-cooperating team member had been one of my biggest fears, and thankfully it never came to that. I doubt that this is to my own credit; it just happened that every single team member was well-mannered and pleasant towards the others.
- Flexibility. Although we didn’t make it in the end, we still managed to overcome a lot of obstacles. We had to move 4-5 times to a different place during the competition, experienced flooded streets, power outages, the Internet going down, health-related issues, locking ourselves in, etc.. A less flexible team wouldn’t be robust enough to carry on after all those, yet we managed to stick to the end.
Our original artist (who’d also be our host) got sick one day before the competition started, yet another team member emerged as the “Joker”, taking her place in the artist department while teaching himself the tools as the competition was well underway. He was also able to offer us a place to stay during the first day.
Another member found us a place to stay during the second day, and continued working on the project even though it was his birthday.
Team members who’d learned new things about Java programming on the first day, taught them to other members during the second and third day. The overall teaching and learning culture that emerged was as I’d hoped it’d be, and were it not for the constant interruptions, we could’ve accelerated the learning and teaching rate even more.
What went bad:
- Coordination. The lack of a basic workflow was apparent. We only thought about our current task, and chose our next task based on what was needed at the time. Needless to say, that not following a concrete plan gave us a very bad estimate on the amount of work done/still needed.
- Time management. Regardless of the many obstacles, we were running out of time even during the afternoon of the first day. Things like setting up Git ought to have been dealt with before the competition even began, not in the middle of it. A “feature freeze” would’ve also helped us, as we tended to change basic gameplay features (tile-based vs. continuous movement) up to the last day. Sometimes a mediocre solution is better than no solution at all.
- Role distribution. This was my fault, and falls in the same category as a lot of things I didn’t do right in order to establish a thoroughly democratic model of communication.
We were switching roles as we pleased, from coder to artist to level designer to coder again – which obviously was detrimental to any kind of specialization, and also harmed our overall organization. Roles ought to be clearly defined and distributed among the team members. Below is a rough plan of what kind of roles one might expect at a Ludum Dare team.
As for the democracy part: Democracy is wonderful, but when time is of the essence, it shouldn’t be spent trying to get everyone’s explicit agreement before moving on. In those times, it’s much more efficient to designate a trusted person (or group of persons) once, and let it decide within a predefined set of restrictions. Hello, Indirect Democracy.
Here’s the rough role list/workflow I made based on my experience in last year’s Ludum Dare. Obviously, it’s doesn’t fit each project, and some roles might not even exist depending on the type of game. This is more of a template for anyone who wants to take it and adapt it to his/her game.
Roles:
I came up with 12 roles: 6 require coding, the other 6 don’t. Obviously, one person can have more than one role, as long as the roles don’t change too often during the competition.
- [GDsg] – Game Designer
- [LDsg] – Level Designer
- [Wrtr] – Writer
- [Artt] – Artist
- [Snd] – Sound
- [Blog] – Blogger
- [Core] – Core (Class Diagram, Game Loop)
- [Grph] – Graphics (Rendering,Animation)
- [AI] – AI (Pathfinding, AI Behaviour)
- [Phys] – Physics (Collision, Movement)
- [Inpt] – Input (Keyboard, Mouse)
- [Nctr] – Encounter (Battle/Puzzle system)
Workflow:
0. Before the LD starts:
[Blog] Write “We’re in” blog.
1. Settling on a gameplay idea:
[GDsg] Design general gameplay.
2. Determining the overall game/program structure:
[GDsg] Design details – \w [LDsg].
[LDsg] Think of level structure – \w [GDsg].
[Wrtr] Think of a story.
[Artt] Start making general art assets (like hearts for Player Health etc.)
[Snd] Record general sound samples (like a general sound that could be used for jumping, or opening a chest etc.)
[Blog] Maybe write about gameplay idea.
[Core] Make Class Diagram – w\ [GDsg],[LDsg].
[Grph] Talk about what approach to take about the graphics – \w [LDsg],[Artt].
[AI] Determine a world\level representation for AI purposes – \w [LDsg].
[Phys] Determine a world\level representation for physics purposes – \w [LDsg].
[Inpt] Determine types of input – \w [GDsg],[LDsg].
[Nctr] Think of battle/puzzle system – \w [GDsg],[LDsg].
3. Getting to work:
[GDsg] Feature freeze. Refine existing gameplay mechanics – \w [AI],[Phys],[Nctr].
[LDsg] Design levels.
[Wrtr] Write story/dialogs – \w [LDsg].
[Artt] Make art assets for the levels.
[Snd] Make the music/sounds.
[Blog] Blog about progress from time to time.
[Core] Make game loop, calling methods made by the rest of the team.
[Grph] Program renderer & animation.
[AI] Implement pathfinding and general AI Behaviour.
[Phys] Implement collision detection, movement etc..
[Inpt] Implement types of input.
[Nctr] Implement battle/puzzle system.
4. After the competition:
[Blog] Write post-mortem.
[Rest] Play games!
The future
We might not have finished the game, but we had a good time, and learned a lot. I’m looking forward to entering this year’s March competition, and so are a lot of the team’s members. Let’s hope that we learned our lessons and will be proud enough to show you our game, after 72 hours of fun and learning.
