What I learned while working on a team

  • Red_Nova
  • 11/26/2014 05:45 PM
Teamwork and You

This is part two of a two part Article. To read the first part, CLICK HERE.

Now that you have a team together, it's time to start talking about WORKING on a team. First, let's glance over two different styles of leadership that you'll see out on the field of professional developers: the Boss and the Leader. Here is the difference between the two:

When working online with a team, you DON'T want to be a boss. You want to be a leader. Which means that you need to get down in the ditches with the rest of your team. If anything, you will have MORE work than the entire team has. It's your job not just to lead, but to have the vision needed to see this project through to the end. If you followed the advice of the previous article, you will know exactly what you can do to put together a team that already has some decent chemistry. So what happens now that you have a team and are ready to work on the project?

Like last time, let's start by dispelling a few more myths:

1: More Myths:

They are helping me with my project

No they are not. The moment you bring another person on board with your game, the game ceases to be YOUR project. It is now THE TEAM'S project. Your teammates are not working FOR you. They are working WITH you.

With more people comes a bigger scale, right?

Not necessarily. Just because you have a team doesn't mean you can make a 50 hour long RPG with 100+ side quests and your very own OST. It's important to start small, especially if this is your first time working with a team. Make a short game, about 2-3 hours. This allows you to really get a feel for each other's styles of development and how you work with each other.

We're in this for the long haul!

Maybe YOU are, but you don't know your team’s daily personal schedule. They may only have an hour a day to devote to working with you. Maybe even less! Don't assume that, even if you do get someone on your team, that they will be willing to completely devote their time and effort to your cause. Remember, nothing is certain.

2: Management:

As the leader, you have a lot more to do than just handing out tasks. You need to be the most involved person in the group! You have to do not only your share of the work, but handle situations at an administrative level, as well. Here are some tips and warnings to help you along your way:

Set Deadlines.

Procrastination is the worst enemy of mankind. When you're in a leadership role, your procrastination affects more than just yourself. It will affect your entire team's effort. Prevent this by setting some deadlines for yourself and your team. When you do, the outline of the whole game can be laid out. Having a clear endpoint also gives you motivation to get things done.


Chances are, you brought a certain person onto your team because that person has one or more specific skill(s). Make use of those skills by giving them direction at the beginning. When everyone has their own defined role, there is a much smaller chance of work overlap.

That doesn’t mean that each member should dig his or her nose into the ground and not look up outside of their role. Far from it! If anything, talking with your team members constantly is exactly what you should be doing!

3: Getting Down in the Ditches

With the management out of the way, let's talk a little about your day-to-day activities. Again, as a leader, you cannot just sit back and let others do work for you. You have to take the reins of the project. Lead, don't direct!

Don’t ever shut up!

A game is a single entity, while a team is a collection of entities. In order to get the multiple entities to produce a single entity, the team has to be on the same mental wavelength. How do you do this? By talking, talking, and talking some more! Talk about your ideas, and listen to what your team has to say. Staying in communication with your team is the best way to understand why they make certain design decisions. This enables you to piggyback off their creativity with your own, allowing your development styles to complement each other, rather than contradict each other. This will be made easier if you followed the advice in the previous article and have an understanding and trust between you and your teammates.

Give your team creative freedom

Despite the earnest urging to keep talking in the previous point, there's an easy trap that talking will get you into: being too demanding. Game making is, at its heart, a creative endeavor. As such, it's pretty easy to want to fine-tune every single little detail until you’re satisfied.

The thing is: That’s kinda hard to do on a team.

I mean sure, you can playtest it to a stable, glitch-free build, but you need to remember that you brought certain people into your team because you wanted to make use of THEIR creativity. I can tell you with confidence that there is no faster way to piss of a creative person than invading their territory, as I have been on both the giving and receiving end of this practice.

Take your personal preferences out of the equation. As stated previously, this is no longer YOUR project. Your likes and dislikes don't mean squat anymore. If your mapper wants to have a large, circular center with multiple hallways extending outward, then that's what’s going to happen whether you like it or not. Besides, chances are (extremely high) that your team will have ideas that you didn't think of before that are actually BETTER than what you had in mind! Have an open mind.

However, there are a few times where you will need to put your foot down. The first time is when the creativity of the others is blatantly departing from the themes of the game. The second part is when a team member's creativity is running over someone else's work and interfering with their job. It's great to be creative, but not at the expence of the project.

Know when to give ground

I think I can safely assume that this is the hardest lesson anyone has to learn. "Give ground? That sounds like a defeatist thing to say! I know what I'm doing; I just need my team to have faith in me!"

Of course your team has faith in you! That's why they joined up in the first place! But giving ground is VERY different from giving up, and it's important to know the difference.

Make no mistake: You and your team WILL have disagreements. No matter how accommodating you can be, there will be points on your game that you will not want to change that your partner(s) will, and vice versa. It's important to recognize when a major disagreement is happening and be able to settle it amicably. Because we're online, it's very easy to accidentally cross a line that should not be crossed, pissing off your team and putting the entire project at risk.

Thankfully, there is a short and simple rule that you should follow that can make 90% of all disagreements easier to handle:


Don’t just dismiss other people’s ideas simply because they’re not yours or they don’t make sense to you at first. Take a moment to see things from their perspective. If you have that all important TRUST that I talked about in the previous article, it should be easy for you to see why they thought their suggestion was good. Maybe, just MAYBE, their suggestions might actually be more effective than your original idea!

... But don't be a doormat

That being said, always giving in when others are insisting on their own ideas is just as bad. As well-meaning as they can be, they're not right 100% of the time. The previous mentioned tip about being respectful applies here as well. In fact, it might be even MORE important here!

If you don't agree with their ideas, by all that is good and holy EXPLAIN why you don't agree, and tell them why you think your idea is the best. Be as detailed and respectful as possible. Do not use responses like, "It's MY project," or, "I'M the leader!" This is a toxic attitude for one huge reason: The focus is taken AWAY from the game, and onto YOU. Now, your team's negativity is directed at YOU, and tension will rise dramatically.

If you're going to disagree with someone, make the point less about YOU and more about the GAME. How exactly does their suggestion hurt THE GAME? What flaw will their suggestions put in the GAME?

4: Final pieces of advice:

Now that you know how to recruit a team, and have some pointer on working with a team, let's take a moment to step back and look at things from a broader perspective.

Take care of yourself.

Don't go overboard and try to make this the best game ever. Trust me: it won't be. Why? Because there’s no such thing as the best game ever made. Remember, you're not doing this as a job. You're making a game with some friends. Don't overwork yourself, and don't overwork your team.

Follow through.

Here's a shocker: We all have lives outside of the internet. As such, we're all doing this in our spare time. It's very easy to set aside the game for a day to take care of personal matters, only to come back to it to the sudden realization that a WEEK has gone by! You need to accommodate for this when you make your plan!

I believe that a perfect leader will have given their team enough direction that the leader can take a step outside of the area and the team will be able to go on ahead. At least for a while.

Have fun.

...Okay, this is a bit of a generic answer, but it's no less true as time goes by! If you're not having fun working on the game and working with the team, you should seriously reevaluate what you're doing. I understand that not every aspect of development is fun. But if you're not excited for the overall project, perhaps it's time for a little heart-to-heart with your team. If YOU, the leader, are getting disheartened, I can promise you the team is feeling at least a LITTLE bit like you.

Just remember: if you don’t have fun making it, why will anyone have fun playing it!

Thanks for reading the article! I sincerely hope you learned something new!


Pages: 1
Got any Dexreth amulets?
Great article! These should be compulsory reading for anyone who considers working in a team. Should I ever find I want to start a project together with others, I will definitely read this again beforehand.

Don’t ever shut up!

I like this part.
Self-proclaimed Puzzle Snob
Good goodness this article is pure heavenly advice come straight from the clouds. For the next contest that comes up, I'm planning on doing a partnership effort so these words will be sooo useful. Thank you.
The all around prick
Thanks so much, you two. I'm glad my experiences can be of use!
Having had extreme teamwork experiences (one great, one awful) I can definitely relate to this.
Also glad to know that I'm more of the leader type ^^
Sound advice, very well-written, focused and down to earth article.
Worst enemy ever orz.
Procrastination is the worst enemy of mankind.
Im agree with this articles, thanks for share ^^b
Your teamwork articles are pure wisdom! A recent project I worked on demonstrated how accurate your articles are.

On the surface level, my initial recruitment post looked a lot like the "I've an idea, who wants to join me." But it mentioned I was able to program and was looking for an artist. By then my profile only had MinST to show what I could make. It got Avee's attention. The vague game idea crystallized while writing it to him. We gained confidence that this project fitted the one month Halloween event. Luiishu accepted to join and worked on the music.

Programming the game naturally put me in the role of gathering and using other member's creations. As I suggested the initial idea the team members considered me as the leader but I always considered myself equal to them. I was always referring to the game as "our game".

During the project, I had the following Extra Credits quote in mind:
"Everyone who touches a game influences it's design. Even if you don't intend for them to."
And apply the following approach to it:
"Then I must intend the team members influence our game design."

The game concept was not fully formed and grew with message exchanges in the team. While guiding the work to make the game coherent, I did my best to give as much freedom as possible to the artists.

The frequent progress updates gave our team a good momentum. It was really motivating to see everyone's new creations.

Near the end of the project, Luiishu suggested his friend Frogge for the voice acting. I trusted Luiishu. Frogge improved our game immersion a lot.

When you're lucky to work in a good team, the advices presented in the articles makes team projects go smoothly.

I think I've been very lucky to work in a great team and I discovered I'm a decent leader.
The all around prick
Man, I love hearing these kinds of experiences! Thanks for sharing, Irog!

Your initial recruitment post being on an event actually changes quite a few parameters than it would being a random thread on the forums for an unspecified project. Immediately, your odds of finding a team were raised thanks to making the request in an area of like-minded people. Plus, with a month long event, you were given a clear start and end date, which is a godsend, especially for new teams. A specific time frame to make a game really help you get a feel for your partners and an idea of what it's like to work together more than a project with no real schedule.

It's great to hear your time managing a team project! Good luck with your future partnerships!
Actually, all games I worked on started for an event. Events are really good to give the first impulse to a project and offer excellent opportunities to experience team work. My first project was a for a solo event then I tried a team event and finally the event of my previous post.

On my first team project, I teamed up with FlyingJester, a programmer who has much more experience than me. We met a lot of technical issues: one of us used a non-Windows OS and the other used Windows... that would probably cause minor inconveniences among artists be we are programmers and, being the least skilled, I got a lot of compilation errors and the associated frustration. FlyingJester help me a lot and we managed to overcome those technical issues.

We weren't well organized: we didn't make a plan to divide the work into tasks. Our project scope was probably too large even if we had no technical issues. In the end we managed to deliver a working game prototype. Thanks to FlyingJester, I discovered new useful tools and learned a lot.

For my second team project, I teamed up with people who have distinct fields of expertise. (Details in my previous post)

The contrast between the teams taught me a valuable lesson:
To work efficiently with more than one programmer in a team you need good software architecture skills.

I lack the software architecture skills but I'm going to learn it and restart team work on Wizard apprentice Lya. I'll also write a realistic plan to prevent the project from dragging.
Pages: 1