Let me begin by explaining the team situation. Mango Protocol started as a couple project between Mariona (artist) and Javi (programmer). Later, just after the publishing of their first game, Jordi (game designer), that's me, joined the team and the three of us have been working our asses off through an incubation program and an acceleration one lately. But acceleration means some funding and funding means bigger games to fulfill bigger expectations (and pay the acceleration debts). So about four months ago we started a recruitment process to be able to accomplish our third game, the largest project we've tackled so far. After some weeks, we tricked Èric (programmer) and Carmen (character designer and animator) into joining Mango Protocol. We had a long road ahead, but we knew that the first weeks are critical to a team formation.
We were struggling finding a way to kickstart things production-wise, so, being big time fans of game jams, we thought it could be a good idea to create a studio game jam as a tool to integrate new members into the newborn small dev team. That's how the first MangoJam happened. That's how Hell Snails was created during our first week as a team, and these are the good and the bad things we've learnt from it. I’m not gonna write about specific bugs or problems we faced during development, but my impressions on what we learned from the experience that helped us to work as a team faster than with the usual method of “welcome, that’s your seat, that’s the project we’ve been working on for some time, you’ll catch up soon enough… I hope”.
Let me explain some things about the game itself before we jump to the post-mortem.
First of all, the theme. We like this random factor that jam themes imbue into the games. So what we did was fill in the gaps of a sentence I proposed. Every member chose one filling word.
The sentence was this:
We live in a very (adjective) (noun) that (adverb) tries to (verb).
And the resulting theme was this:
We live in a very infernal snail that constantly tries to spin.
So that was the theme. It didn’t make much sense, but I’d say we managed to get some fun ideas out of it. And here you can see a gameplay video to see the results.
The tools we meant to integrate into the pipeline were mainly Unity, Spine, HacknPlan, BitBucket and SourceTree. Now let's see how all this developed.
What went right
- I think the general idea was successful. We aimed to create a comfortable space. Using brainstorming as an icebreaker, we wanted to encourage the newcomers to be creative and spontaneous. I think sometimes is difficult to express your own ideas or suggest changes when you deal with a project that’s already been started by others. Sometimes is hard to fight the feeling that you may be stepping into somebody else’s ground. Starting a small project from scratch is a good way to tackle this, as you can feel it your own from the beginning and take part in every decision, which makes the process of suggesting changes or even opposing an idea much easier.
- Another task that’s really time consuming is getting someone to get used to a pipeline which they are not familiar to. We tried to use the MangoJam to help us on this one too. If you work on a small game, almost all production tasks are small too. Small tasks mean short timings and going through the pipeline several times a day. This helps settling down methodologies and routines. And it also lets people who comes from a different environment to spot possible flaws or suggest improvements that can be implemented rapidly due to the dynamic nature of the jam.
- There are new tools to be learned too. Due to the mandatory game jam rush, there's no time to dig deep into tool mechanics. But the basics are quickly learnt through repetition and fast corrections can be applied and early mistakes are easier to tackle. This has to do with the fact that assets, documentation and code don’t need to have industry polish level, so you can practice with a tool and become better from one task to the next without the need to discard work, which can lead to loss of motivation sometimes.
- This may sound redundant, but the jam fast pace makes for a quickly evolving communication environment. That means that people who had never worked together will learn fast who to ask for advice, when is it OK to interrupt someone’s flow or when and how express concerns about your own work or some else’s.
- Well, Javi, our producer now, came up with an idea to teach the newcomers the basics of agile methodologies. We basically did one day sprints with a meeting at the end of each day where we reviewed what had been done, we discussed problems, tried to find solutions and planned the next day/sprint tasks. This was the first time to work with agile for some of us and we embraced it quite well, so we can say it was really useful but also exhausting, we’ll talk about it later on the wrongs section.
- Last but not least, in just one week you’ll have developed an in-house game that everyone in the studio will be able to relate to. And you can even write a post-mortem out of it! But seriously, I think that’s one of the most important things that we got from the jam. We have a game made by all the members of the studio, the new and the old blood, and that is a great foundation to start building bigger things.
What went wrong
- Pressure. It is an awesome experience to tackle a task like that with a bunch of people that love to do what they do for a living. But what it isn’t as awesome is to know that if the experiment fails, you’ll have lost one production week and will have to invest another week or more, trying to find other ways to consolidate the team, the pipeline and working on relationships and making everybody feel comfortable at work. I’d probably would suggest a longer jam, 2 weeks if possible, if we have the chance to try this again in the future with new people. Fingers crossed.
- It was an exhausting process. I’ve taken part in several game jams. Typical 2 - 3 day structures where the real challenge is to have fun and fight falling asleep at the same time. This time was different. We would go home at 7 p.m. every day, but each day was packed with a restless combo of your own tasks, learning tools, learning how the way you produce can make your partner’s work easier, production meetings where you had to learn to estimate task times and many other agile related things and being aware of every team member to see if everyone is getting along and what things can be adjusted to make everything run smoother on the long term. As I said, exhausting.
- I personally had a rough time using a VCS for the first time. The art department doesn’t have to worry about versioning their assets in our current pipeline, but the design (that’s me!) and the programming teams do. Having worked for micro studios where the development was almost a one-man-army thing, I was never in need of a VCS before. Considering the amount of things we had to learn in one week, I think it’s OK that I wasn’t especially good at one of them. I can say that I handle it much better at this moment, but I still slip sometimes.
- The meetings took too much time. That’s simple. The agile methodologies rely heavily on meetings. But the long meetings are held once a week or biweekly. That means we condensed these long meetings at the end of the day and we would spend 1-2 hours analysing what had gone wrong, thinking about ways to fix the problems and planning the next day “sprint”.
That was too much time and we ended up feeling that we wouldn’t finish in time, which lead us to the last couple of points.
- Some parts had to be left out. I guess any of us could have predicted that. We decided to tackle a lot of different tasks in a short time and this, of course, affected the development. We had a working thing and implemented the main mechanics. I must applaud the art team, as they were the only ones that completed all the tasks, even assets that couldn’t be used. But the important thing is that we loved the result and we were all convinced that we could polish it and make it more enjoyable with a minimum amount of time.
- But we have polished and published the game!! That’s it! We have been investing some free time lately and improved mechanics, menus and game balance until it was fun for us to play. I’m counting this as a wrong thing, because I don’t think anyone should spend their free time working, but that’s something we were really excited to do and we wanted to share it with everyone.
So that’s it! You can download and play Hell Snails for free from itch.io. Itch.io is so awesome!
I hope someone finds this post-mortem interesting. Even maybe someone will feel like running their own version of the experiment and give their newcomers an original and motivational welcome to their studio.