Project Management in an indie team on the case of Crush Link TD
This is a part of a series of articles about the first experience in game development of the indie team 4TEAMGB working on Crush Link TD game. In my previous article I talked about game balance in Tower Defense genre.
In this article I will share how the project management in our indie game was organized.
Stepping away from theoretical definitions and concept of quality-cost-time PM triangle, I will keep it as simple as possible and say that project management consists of the creation and further management of three parts: the team, the working infrastructure, and the processes.
The team
Initially, our team was assembled to participate in a one-month game jam. After the jam, two people left the team. The project stood still for a couple of months, as the team did not have a concept artist and an interface artist. I had to search for the missing team members.
The recruitment process went like this: I created and posted job descriptions and tests. We’d get feedback from applicants, we’d screen out the tests, and then we’d have interviews. On the interview I outlined who we are, what we do and why, what are the rules, and what we expect from a newcomer. In addition to the test and professional qualities, human qualities were important to me: what drives a person, how well they fit into the team, how much time they are ready to devote to the project. If a person was hired, I conducted onboarding. When hiring developers, our lead developer checked and evaluated the code of the applicants.
In this format, a team of five people increased to ten. The team recruited two more developers, a concept artist, an interface artist, a 3D artist, and a narrative designer.
For the team to work smoothly, it is necessary to have a clear understanding of personal and project goals, delineation of responsibilities, open communication and free access to information, create an atmosphere of involvement and ownership of the project, keep the team informed of project news or decisions, celebrate achievements, and publicly praise for good work.
I originally proposed that the team do not do a student craft, but a professional project. So our expectations of ourselves were pretty high, we celebrated serious milestones in the process of creating the game, but small victories also helped us not to slip into the “valley of despair”.
The infrastructure
For team development of the game you need to organize a working infrastructure and give the team access.
The diagram shows the software that we used in the work on the project. The software in which the artists and the sound designer worked are not indicated, because I did not choose it and I did not need it in my work. Unity and GIT were organized by our lead developer.
What was used and for what:
MIRO — creating logic diagrams, interface sketches and level design
FIGMA — creation of interfaces
EXCEL — Gantt chart project plan, game balance calculation
GIT — version control system
TRELLO — a task tracker. I used to work with JIRA and Redmine, but in my opinion TRELLO is easier to use. And it was perfect for our goals
CONFLUENCE — a knowledge base and information hub of the project where game design documentation (GDD) is organized into thematic articles
GOOGLE DRIVE — cloud storage of work files and press kit
PINTEREST — visual references for creating concepts of game entities and locations
DISCORD — a channel for team communication. Divided into chats by block of work to easily find discussion of thematic topics
ITCH — hosting for our demos
SOCIAL MEDIA — a full range of social networks for project news announcements and pre-release promotions. By the way, subscribe to our social networks (https://linktr.ee/4teamgb)
Creating the infrastructure is not as difficult as updating and maintaining it.
On the first team call, I offered myself as team leader and my concept as the basis for the game we would develop. On the one hand I was used to being responsible for projects, on the other hand I needed all this mess to understand and go through the process from idea to publication on my own.
After the game prototype received positive feedback, I offered the team a vision for the future of the project and we continued development.
In a nutshell, the project management process looked like this:
1. For the project, I created a work schedule in Excel in the form of a Gantt chart. I divided the work by blocks into tasks and subtasks, added logical links and dependencies between tasks and dates. We went through the tasks with each team member and set an estimated deadline. Thus, the deadlines for the implementation of the project were outlined, and in the course of development, we adjusted the previously set deadlines in accordance with reality. Any change updated all dependencies and rebuilt the graph automatically
2. In Confluence, I divided the GDD and general information into thematic articles, which I supplemented and updated
3. I collected visual references for game elements and entities in folders on Pinterest
4. We went in sprints in development. On weekly calls with the team, we went over the protocol, in which I recorded and adjusted the status on active tasks and added tasks for everyone for the next week.
5. After the calls, I entered the tasks into Trello. Each task, in addition to the responsible person and deadlines, had a description and links to an article in Confluence or a folder with refs in Pinterest, or diagrams and interfaces in Miro and Figma, respectively. When project information is structured, it makes it easy to set SMART tasks for the team. Everyone tracked their tasks and moved them by status. The rules for working with tasks in Trello were written in one of the articles in Confluence.
6. Work with tasks followed a standard cycle: I set the task with a detailed description, the appropriate team member performs the task and shows the result, iterations of comments and revisions take place, I agree on the final version. This applies to everything from concepts and palettes to music and implementation of every detail in the engine. At the same time, this process was in full view of the team, and everyone could comment. There were questions that were brought up for discussion by the team or for voting.
7. Testing the game took place in several stages: first I tested it myself, then the developers cleaned up bugs and errors. When I found nothing else, the build was sent to the team for testing. Shortly before the release we did some external testing to see technically how the game behaves on different devices, and practically how interesting it is for the players, how the difficulty curve works etc.
The work schedule and team call protocols served mainly for me in terms of planning and monitoring tasks, while Trello was more for the team. Nevertheless, all information was in the public domain and anyone could see what was going on with the project on a micro and macro level, as well as track the development history.
The system described above was not difficult for new team members because, first, they learned about it briefly during the interview and in detail during onboarding, second, because all the rules of work were described in Confluence, and third, because of open communication in the team: anyone could ask anything at any time.
The pitfalls
There was open communication in the team and we agreed on the goals and format of participation in the project on the shore. This was also clearly communicated to newcomers. There were two cases where people thought it was okay to disappear for weeks, not respond to messages, or delay some of the work, which led to delays for other guys and project delays. I adopted the “one month” rule for myself: if a person disappeared for a month and didn’t respond through any channels, they were pulled from the project. This is how we said goodbye to people twice, but without any negativity or resentment. We had to move on, find a replacement and onboard a new team member.
There were difficulties in terms of project management because of the different amount of time that the guys could devote to the project, and because everything was for the first time, so there was no clear understanding for how long this or that task could take. If someone did not work during the week, and went to barbecue on the weekend, then on the one hand this negatively affected the project, on the other hand it annoyed me, but it was part of the setup and emotions had to be restrained. I knew why I got involved in this project, and I wanted to see it through to the end. Now I have a feeling that I will never be engaged in a project where people work “in their free time” or “when they can”, but those were the rules of the game.
There were no technical difficulties, as problems were quickly solved by the team, everyone understood the responsibility and proactively solved the problems. I have already mentioned several times that I was very lucky with my team, the guys took the project seriously. The “I don’t know how to do it, but I’ll quickly figure it out and do it” approach was especially inspiring.
On a personal level, there were two difficulties. The first is to take on multiple roles. In addition to being the lead game designer, I was also a project manager, producer, I dealt with publishing, promotion, marketing and SMM.
The second is time. I dedicated a year of my life to this project.
The project
In conclusion, I want to note the goal of the project was to create and publish a quality game for the portfolio. It was the first game for each of us, and we achieved our goal. I am not afraid to say that Crush Link TD is not a student project, Crush Link TD is a professional project made by students. One person on the team got promoted because of the project, and those who were looking for work found or started receiving more responses to applications. The guys continue to participate in other projects and game jams. My guys are great, I thank them for their work and wish them success on their professional path.
My only regret is that there was no advice, help, or expertise on premium projects from any side. There was a lot of advice on how to make an F2P game, but in our case it was irrelevant.
As a result of participating in several game development conferences, several F2P publishers have noticed the game. We had a good chat, but for obvious reasons it didn’t lead anywhere. Immediately after the release of the game on Google Play, I sent the final version to several of the largest indie publishers working with premium games. Some ignored it, others said no. Suddenly a reply came from Raw Fury; they replied that the scouting team was interested and would analyze the game. Raw Fury are known for such games as Sable, Bad North, Call of the see, etc. Unfortunately, in the end they answered that Crush Link TD was not quite their format and wished us luck.
We never looked for investors. Investments in advertising, participation in events and conferences, infrastructure fees, etc. are my personal expenses.
Today the project is published and closed.
Conclusion
- Gather a team and agree on the rules, goals and format of the project on the shore
- Maintain a culture of open communication, encourage discussion and exchange of ideas
- Create an infrastructure for teamwork on the project
- Make information accessible, open, understandable, and relevant
- Use task management tools at the micro and macro level
- Don’t skip expert advice and appreciate feedback
It will be interesting to hear from the experienced project managers how different my approach is from what happens in the studios, what could be improved and what could be simplified. On the other hand, I hope it will be an interesting case study for those who are new to gamedev in terms of approach to organization and project management.
Thank you for reading to the end. If you have any questions, please write in the comments.
