Children of the Pillar, the team that I made DREAD IT alongside, was the first team I had the opportunity to do production for. As it was my first time, I learned a lot of great lessons on what makes a good team that I have been able to carry over to new projects.
Before we started hiring for this project, we started as a team of four: three developers from Tugboat Terror alongside one more engineer. From there, we hired another two engineers and three designers, putting the team at 9 total.
Since most of the founders for this team came from Tugboat Terror, a project where admittedly everything somehow went perfectly according to plan, we decided to replicate everything we did again with our new team.
The biggest part of this was our game idea. On Tugboat Terror, we did not decide what game we were making until we had our whole team together, since it felt important to all of us that everyone have a hand in the creative process from the game's very inception. This worked just fine on TT, since we had a small team of just five, but on this new, larger team, this approach proved to be much less effective.
Throughout our pre-production phase, which lasted four months, we were very unfocused. Our game idea shifted significantly several times, and nobody was ever quite on the same page as to what we wanted to make.
Our pre-production process was also heavily focused on building our custom game engine, which kept all our engineers constantly busy and left our designers with no suitable environment to work in, and a lack of communication.
Additionally, our weekly meetings were very unproductive, since the strategy of round tabling with no agenda that worked just fine on the previous team of 5 led to never-ending discussions where nothing productive was ever able to get completely finished.
Once these problems started to become apparent, we were lucky enough to be able to reach out to Rachel Rutherford, a production and team dynamics expert and have her assist us in getting on track. With her, we had two "team-on-ones," which are four-hour sessions where she sat down with the entire team and helped guide us through our issues over some food. In these, we were able to find the focus to really nail down our game idea and find common ground so that we could actually move forward and build our first functioning prototype.
After finishing our pre-production proof-of-concept, the whole team took a month-long break. Over it, I took time to meet with Gryphon, my associate producer, and we made a strategy to help guide the team better this time around. We set up task tracking on Trello, made a roadmap for our game and its content, and discussed our plans to implement agendas to keep our meetings on track.
Once we were back from break, I got the team together for our first meeting and we discussed our way forward. Our main goal was to get our game to Steam, but in order to do so, we needed to make sure we were organized and on the same page. I laid out the new plan for everyone, as well as our plan for implementing Agile development, and took the discussion towards getting buy-in from everyone.
From there, we got to work. Every two weeks was a dedicated sprint, where everyone would have specific tasks organized in our Trello board, and at the end of each sprint, we had a meeting to review, realign, and start our next sprint.
Another great change we made heading into production was adjusting our seating in our workspace. originally, we had all our designers sitting on one side, and all our engineers sitting on the other. This led to a massive divide in communication, so this time around, we had our different specialties evenly distributed, working closely with the people working on related parts of the game. This led to significantly more synergy and allowed for important collaboration to be able to happen easily. For example, I was working on our game's level streaming, and sitting right next to our dedicated level designer allowed me to quickly resolve bugs that he found and implement new features that he needed.
Over the course of our four months of production, the game came together in a really big way. We had our gameplay working, with several great mechanics, and a full-fledged level to show for it.
Heading into post-production, our team composition changed quite a bit. We hired an artist, and the composer that produced the track for our first level took up a more official role, expanding the game's soundtrack by about 4x. (listen to the full OST here! credit to zeNate!)
On the other side, though, a large amount of the team had their commitment to the game end with production, as working on the game was no longer a part of a course credit, and many of our developers had other, more important commitments to tend to.
This left our team smaller, more agile, and working remotely, which made it easy to do pretty major overhauls, including refactoring the entire engine and doing an art pass over the entire game. This, alongside the existence of all our core systems also allowed us to expand the gameplay rather easily, pushing our arsenal of traps from 1 to 3, and our level count from 1 to 4.
As we got to the final two months before release, we shifted almost exclusively to QA and polish, running many rounds of playtests and using the information that we got from them to dramatically improve the game. I found this to be easily the most fruitful part of development, and the largest factor in the final game's quality. We could have easily done another several months of polish before we ran out of things to do, but what we were able to complete massively benefit the game.
Looking back now, there is a lot to learn from working on this game. The biggest take away I got about running a good team is to start on the right foot: start with an idea that your core members love and then bring people onto the team by rallying them around it. This ensures that everyone has some part of the game that they are excited about and has buy-in about the project, which allows everyone to hit the ground running.
Another impactful thing I learned from this project is what makes a good meeting and how to run one. For one, agendas and action items are very helpful for keeping meetings on track and allowing everyone to be sufficiently prepared. Beyond that, I also found that less is usually more. People's development time is important, so meetings should be considered carefully to be a good use of time for everyone that comes, which can often be in the form of structuring meetings specifically for smaller, more focused groups.
One thing that we did an amazing job of on this team that I carry forth to my future projects was the bonding we did. Everyone on the team got a matching cloak that we wore to all of our important meetings, which really made everyone feel like they belonged to something fun and special. We also took care to have team outings, going to karaoke and having game nights at people's houses, which did a lot of good for not just the game but also us as people.
Overall, despite the challenges, I am extremely proud of the Children of the Pillar and the game we made. It was an extremely informative journey that truly shaped all of us as game developers and gave us a pretty great portfolio piece up on Steam.