Directing a Large Game Jam Team: a Tamanegi Collective Study
This is a Ludum Dare blog post from 2022 and does not necessarily reflect our commercial work pipeline
One of the most common things I’ve had pointed out to me recently is the size of my Ludum Dare team. We started as a small team of 4 (An artist, UI designer, Musician, and Programmer) and over the last two years we’ve expanded threefold as friends see what we’re doing and want to get involved themselves, so I figured I’d drop some insights into how we run things that may help others out as their own teams expand just so you don’t end up with a “Too many cooks” situation!
The Team
Our team structure is simple. We have three key directors; a creative director, an art director, and an audio director. These three directors take charge of key aspects of the project and manage several team members all at once. This ensures the people with the least experience all know who they can ask questions to and nobody is having to worry about work being done outside of their own sub-team.
Our skill levels vary wildly across the team. Some of us have several years of industry experience, while others are exclusively indie at around a graduate level. We want this to be a fun 0 pressure learning environment for everybody involved, and it’s a great way for people to get hands-on game development experience in fields they’ve wanted to experiment with.
The Project
Step 1: The lead-up
We plan our next jams ahead the MOMENT one finishes. This ensures we can all book time off work and align with eachother to ensure everybody that wants to take part will definitely be taking part. I encourage a process of iteration and improvement, so we discuss where the pain points of the project were and make a plan of action to offset these in the future. This has so far taken the form of bringing new people into the team, shuffling the team roles around, changing elements of our workflow, and finding educational resources to help improve skills that caused a block in the project workflow previously.
Generally the next few months are quite quiet in the project Discord. A few posts here and there on our non-LDJam projects, but we try not to stress about the next jam.
This changes when the final month approaches. This is a month of steady planning and preparation where we decide which tools we’ll be using, and doing a double check on the full team make-up to ensure we DEFINITELY have the full team aligned and we can mitigate if key players are missing. Calendar events are set, source control is set up, a OneDrive folder is shared to the team, a whiteboard template is created, a Trello board is prepared, an empty Unity project is templated with our usual tools (LeanTween, Peek, UModeler) and a scene for each Unity developer to build their components in isolation, and everybody ensures they’re on the same version of Unity. Strong preparation means the moment you have your idea in placed, you can all get to work.
Finally, a wishlist is put together of all the things people would LIKE to end up making with the hopes we can align our final game idea to match. This very rarely pans out, but it’s nice to know where everybody’s passions or worries lie.
Step 2: Ideation
In my opinion this is absolutely the most important part of any game jam project, so getting a process down that encourages creativity and speaking up from every member of the team to lock in an idea as soon as possible is key. We all hop on Discord and Figma on the morning of the jam, nice and refreshed (This time the jam started at 2am, so we all got to work planning at 7am instead of staying up). We handle our ideation in several steps, and try to keep these steps within a time limit:
Locking in an initial idea, 30 minutes - 1 hour: Depending on the theme, this idea can be locked in either straight away, or a best possible idea from the pool of pitched ideas will be selected after an hour has passed so we don’t waste too much time trying to come up with a PERFECT idea
Pillars Discussion, 15 minutes: What IS our game? What ISN’T our game? By selecting 5 pillars and 5 anti-pillars, we keep Gameplay, Music, and Art discussions on track without introducing too many chaotic elements or feature creep.
Finalise Music, Art Style, Gameplay Features, 1 hour: A choice of direction for all of our teams is locked in, as well as any stretch goals being marked as a middle or low priority task that we can pull from if we run out of work that needs doing early.
Task allocation & Greyboxing Plan, 15 minutes: The directors hand out tasks to the team, populating the Trello board and assigning people to each card. A plan is set in place for how we can have a full Greybox complete by the end of Day 1
Here’s a look at our Figma whiteboard from the LD50 session so you can get a look at how we landed on Stone Sabbath. I think we did a great job sticking to the pillars for the most part!
Step 3: Development
I’m pleased to say that development mostly goes off smoothly. People know who to talk to, problems are isolated and ironed out quickly, and communication remains a constant. There are often 5+ people in a discord channel working together at any given time, so emergent problems are quickly known to the whole team. We try to hop on for a 9am meeting on the next two days of the jam to discuss the day’s plan and mitigate if problems are foreseen. Our plan is always to go:
Day 1: Greyboxing: Barebones art, levels, and gameplay
Day 2: Minimum Viable Product: Ending the day with a game we would be happy to submit, even if it’s janky and messy
Day 3: Polish: A whole day dedicated to cleaning up rough edges, making things look nicer, adding features from the stretch goals, and getting things ready so we have a game we can say we’re proud of.
Of course, things don’t always turn out this way. With our previous games Burst Vein and MIFFED there was absolutely no time for polish, as getting those games across the finishing line took our all in the first place. I’m pleased to say that our process finally seems to be refined enough to get the polish day we’ve always wanted with Stone Sabbath, and I like to think that the final result really shows the fruits of that day.
Step 4: Wrapping up
Once the game is submitted we all take part in Play+Rate as a unit, sharing the coolest games we find with each other in the Discord and just having a really fun time with it. I encourage the team to drop a post-mortem report of:
What they enjoyed
What they found challenging
What they disliked
What they felt they did well
Where they think they could improve
What they would do differently next time
What they would like to change about our process next time
This information all helps to smooth out the edges and makes sure we don’t repeat the same mistakes. There’s also an optional step where people will ask me for a personalised performance review, which helps them to isolate their own weak points they might not be aware of. The improvement from jam to jam is absolutely undeniable, and I’m extremely proud of every member of the team. With how well Stone Sabbath went I truly believe that the team is ready as ever to make a full-scale game outside of a jam environment.
Step 5: Conclusion
A look at how many Discord channels we use for organisation
When managing a team for a game jam, no matter how professionally you attempt to run it, it’s absolutely imperative that things stay fun for your team. Remove pressure wherever you can, design the project around people’s strengths, and don’t force people aggressively outside their comfort zones. Don’t encourage all-nighters, make sure people are well rested and getting sleep, breaks, and support when they need them, and overall just be nice to be around. If you’re the main organiser of a full team of people it can be very easy to let things get on top of you, but you need to maintain perspective and remember that this should be fun for YOU as well. If you’re not having a good time with your friends you’re just making a dry professional portfolio piece, and there’s no joy in that whatsoever.
