For the 42nd Ludum Dare we were a group of seven people. For such a short project that is a rather large group and the organizational tasks thus took up considerable effort. That’s why I want to talk a bit about how we did it and where there might be room for improvement.
Get the game I am talking about here: https://ldjam.com/events/ludum-dare/42/comfort-zone
For every part of the creation process there were benefits as well as problems in working in a larger group. For the brainstorming phase the obvious benefit is a larger pool of ideas. The immediate downside is in reducing this pool to a single concept that should be implemented.
Before we even knew the topic we talked about our expectations and wishes for the game we wanted to create. We quickly came to the consensus that we wanted to create a game with some political content and that we would favor fun gameplay over strict adherence to the theme of the gamejam (to not repeat the mistake from the 41st Ludum Dare…). For graphics we decided to either do a 2d game or work with voxels. This best represented the capability we had in the group.
As we had good expiriences with the method from the 41st Ludum Dare, we started with a silent brainstorming. We took a large piece of paper, one pen per person, and spent the next 15 minutes writing down any ideas we had for the given topic – without talking to each other. This ensured that all the initial ideas were out there and could be referenced.
In the following discussion we quickly spiraled towards three concrete ideas:
- to address gentrification and rising rents, most likely in a shared-flat simulator
- to address global warming and other catastrophies and their influence on migration in a world-population-manager
- to address and depict social anxiety, for example in a party setting
It took us two hours to finally decide to do the last of these three options. And by then it was too late to work out all the details before going to sleep – so the discussion inadvertently continued in the morning, before everybody could join in…
Work in Parallel
The different fields of work (story, audio, graphics, programming) were done in smaller groups of 1-3 people. They met independently and divided up their tasks. Every 4-6 hours we would then meet up in a full plenum to talk about the process and about things that came up in the individual groups that needed a consensus decision.
Outside of the plena, some aspekts of the game were decided in small groups or even by individuals. There is not enough time to find a consensus with the whole group for everything, so this is of course desired to some extend – but unfortunate at times when these decisions contradict each other or what another person imagined the game to be like.
Putting Things Together
The ideal would have been to create regular vertical slices that include everything that was already done by the art team, the story team and the programming team. And we had hoped to have the first playable version of the game some time Saturday…
In reality only the programmers could add content – and they were busy implementing the many features we wanted to have. So Monday was the first day we actually started to add in all the content. Only to realize (of course) that that took more time than we had anticipated. In the end we were thus never able to add all of the content we had planned.
We were still happy with the result of our efforts. At 7pm on Monday we were finally able to do our first test playthroughs. The firewall of our git server blocked us due to too many requests two hours before the deadline, but we could at least fix most major bugs and try some balancing of the stress level etc…
The Monday was unnecessarily stressful (in particular for the programmers), and too much effort (of the story and art teams) was wasted because we were not able to implement everything.
Next time I would try to address both of these problems by aiming to remove “adding content” from the programming tasks. A dialog system? It’s only done once everybody else can add their own dialogs.
A bit more specific to this project: When we implemented the autonomous party guests the answer to the question “What is the most urgent task right now?” should have been: creating a system to easily create timetables for individual guests. Even if we then would have to create all party guests behaviour by hand it would have been faster than the one-script-per-story-NPC solution we had to stick to in the end. Ideally it would have again been simple enough that the others could also implement the NPC behaviour – but even if this were still a task for the programmers, it would have been a better cost-to-usage ratio…
In the beginning there were still some problems with finding a common vision for the game. Even after the plena we would not always know what everyone else imagines the game to be like at the moment.
The issue board we had was a help (and could have been a much larger help if we had used it more) to know what the others were working on and in making sure we would talk about everything that was done at the plena. What it did not represent is the decisions that were either already done by the individual teams – or that would have to be done by the group.
Next time we should try some other methods to alleviate this.