Keine Ergebnisse gefunden
Finding a team as an indie developer can be challenging. And, once you have found one, keeping it together and working efficiently is even harder. Over the years, I’ve had good and bad experiences with teams and projects, but that’s part of the process. The bright side is that I've learned a few tips and tricks that can help you easily find and manage a team.
For reference, the most complicated team to manage that I’ve been on had people living in Brazil, Japan, Seattle, and Michigan. That’s four time zones!
This section is the one that can have the most variation, so your experience may differ vastly from mine. However, I will list the ways I use to find people and the qualities I look for when considering people for my teams.
While most of these are not 100% necessary at the early stages of development, doing them will prevent future headaches and conflicts. Believe me.
In most cases, when you hear about a game that did not launch or got canceled, the issue can be tracked down to bad management. Whether you are working on a team of two, or two hundred, managing teams and getting people to work together to achieve the same goal is very complicated. Luckily, some smart people have created, tested, and improved a bunch of techniques that can be used to more consistently avoid these situations from happening.
I will list a few of the tools I use in my teams, a lot of them I took from from agile, a production methodology that encourages fluidity and adaptability. Agile is a huge topic that is out of the scope of this article, but I encourage you to delve deeper into it if you find the next few practices and tools useful.
1. Pick someone to act as producer
Several of the points I will cover later in this article will mention the producer. This person is NOT the team leader (though it can be), and in an indie team, is usually not only the producer, but has another role, such as a programmer or artist. The person who will take on the producer role needs to be organized and understand that this will add a ton of work and responsibilities on their plate, but will benefit the team in the long run.
2. Communicate as much as possible
The most important aspect of working in any team environment is communication. Having an easy way for everyone to discuss game ideas, ask questions, and show their work is essential. This is especially true when working with people in different time zones, where they may miss a conversation that happened while they were away. Don’t use a program that only has a single conversation thread, as it’s hard to recap what’s going on, especially when there are multiple conversations going on at once.
Instead, use a service that allows you to set up channels for each topic (art, programming, design, etc). This helps members find information that is relevant to them, as it is contained in one or two places. Also, I recommend you have a channel for general banter. It’s always good when teams just hang out and talk for fun, as it strengthens their bonds!
3. Schedule meetings
Part of the job of the producer is to keep the team informed and the project on track. The best way to achieve this is to have consistent team meetings. These are different from your day-to-day chats, and they are most effective when done through a call or video call, not text. I’d say if you are all working full time on the game, having weekly meetings is reasonable, but if it’s more of a hobby project, having meetings every two weeks, or once a month, is fine too. During these meetings, you can check the status of your project, how your milestone is going, do a milestone review, and update your task board (which I’ll talk about in a bit). The producer should always have a plan for the meeting so it stays on topic, covers all the information that is relevant, and makes the meeting short and concise. No one likes long meetings where not much is said.
4. Have a task board
When working on a game with hundreds, if not thousands, of moving parts, it is essential that the team has a way of tracking tasks that need to be done, are finished, or are in the backburner. There’s a few online resources that facilitate these sort of task boards for your team. Choose one that fits your team and use it! It can be a pain in the beginning to get used to the workflow, but after a while, you’ll wonder how you ever worked without one.
The producer is usually responsible for assigning tasks, adding new tasks to the board, and prioritizing them. A big check and update of your board can be done once a week, but small updates will happen throughout the week. This way, everyone in the team can wake up every morning, check the board, pick a task to complete, and do it. After they are done, they can mark it as finished, pick another task, and work away. Good tasks are preferably split into small pieces that can be completed in a single seating. It is still okay to have larger tasks in the board, but it’s a good idea to break them down into smaller pieces once it reaches the point in the queue where people will work on it
5. Daily check-ins
In agile, there’s a useful tool called “stand-up meetings,” which are basically small five to 10-minute chat that happen at the beginning of the day between teams. It consists of people standing around in a circle and saying three things:
What they worked on the day before
What they’ll be working on today
If there’s anything blocking them from completing their tasks
These simple questions are great because it informs the entire team of everyone else is doing and helps them solve any issues before they happen (such as two people working on the same task or on a feature that is already implemented). I adapted this idea and called it “check-ins." The idea is that your communication server has a channel dedicated to check-ins, where everyone will answer these three questions as soon as they sit down to work every day. The answers should be short, but concrete.
Try to avoid being too broad (working on gameplay today) and be specific about what you are doing, referencing specific tasks you will tackle from your task board. Going into this channel to write your answers also encourages each member to read everyone else’s answers and know what’s going on in the project. It’s also a great way to make sure everyone is working and pulling their weight within the team. Last, make sure to be honest. If possible, the days you are not going to be working, hop into the channel and post: “Not working on anything today, I’m taking a break for the day." The team will understand and it relieves the pressure off your shoulders knowing the team is aware of what’s going on.
6. Set milestones
Planning too far ahead into the future is almost impossible, especially in games where the design is constantly changing. Having a goal to “finish the game” can feel like a goalpost that is ever-moving and unobtainable, which negatively affects the motivation of the entire team.
Instead, have short-term achievable goals and try your best to meet them on time. This will help with team morale and will take you from a small prototype to a released game more consistently. Remember those meetings we talked about earlier? Those are a great place to plan and talk about milestones. I’d suggest having a milestone every month, or maybe every two months. These should be stuff like: all movement mechanics implemented, art for world one is complete, 50% of character sound effects done.
Time estimation is an area we all have trouble with, but it can be trained and your estimates will get better and better the more you work on it. However, try to meet milestones, so if you need to get creative or cut content to meet it, then do it. Games small and large cut content constantly in order to meet milestones, and they are all the better for it. Just make sure you are in constant communication with your team and keeping them informed on your progress so you can all make the decision on cutting content.
7. Use source control
The use of source control in any project is extremely important, and it is essential when your team has more than one programmer. It’s a great way to backup your game, use it to pinpoint when a certain bug was created, and keep resources up to date. This is why I encourage teams to teach their artists and sound designers to use source control. This way, they can always have the latest build working on their computers for testing (test your game constantly please!) and they can add or tweak their assets without the help of a programmer or designer, which improves the team’s workflow. If you don’t know much about source control, I wrote a couple of articles about it. It is focused on GameMaker, but some of the basic concepts are the same, and there are lots of resources out there to learn how to use it in your project. Here are the articles:
Git Started with Source Control and GameMaker Studio 2 (Part 1)
Git Started with Source Control and GameMaker Studio 2 (Part 2)
I hope these tips help you find a team and improve your communication, teamwork, and workflow. Remember that this list isn’t exhaustive and that you should only use what works for your team, but I definitely encourage you to try some of these tools for a few weeks. You may be surprised at how effective some are even if they sound silly at first. If you have any questions, feel free to contact me through Twitter at @AleHitti.