Hello every one, I'm glad to be back
after the holiday. I also apologize for the delay in making a new
post. It's been pretty hectic here and I also have a special topic
today that I wanted to prepare for.
Before the holiday a fan suggested that
I make a post about how to effectively manage a team. He – and many
other people I'm sure – have issues keeping a team together and
moving forward. I too struggle with this and only recently have been
doing better at keeping a team together and on track. So today I will
cover a few practices I have discovered or read about to help you
manage your team better.
Communication:
The biggest and probably most obvious
aspect of effectively managing a team is communication. This is even
more important if your team is scattered across the globe.
Communication is key to everything from giving feedback, setting up
due dates, explaining your project and the more.
For me I like to have a set day every
week where the team all gets together and discusses the project. We
talk about what we did for the past week, what needs to be done for
the next week and also discuss any concerns, questions or ideas we
had during the week that we just didn't get around to fully
discussing in smaller chat sessions or meetings.
I try to keep my team in contact by
e-mail and skype. I personally prefer skype so that I can have a more
casual conversation with my team mates and I can also respond
quickly. With an e-mail you don't know when the person will even
check it so the turn around for the conversation could be much
longer.
Be prepared:
Communication also leads into being
ahead of your team. Hopefully you've done everything the blog has
discussed up until now and you have much of the game planned out and
most of the assets or programming done. This will help you a ton as
your team should never have to wait on you. Before I gathered my team
I created 80+ models and textured them all. I then made menus and GUI
for all the screens and menus I have planned. Now that I have a team
they don't have to wait on me, instead if they need a menu I have one
ready to go. Now I'm not saying there won't be rework. As team
members come on they will have a voice and want to change some things
and that isn't bad. Every one on the team wants to make the game as
strong as possible and so some tweaks may need to be done. But at
least you have something to work with and a jumping off point.
You also should have a playable game by
the time you look for a team. If you don't then you should hold up
and make something playable. Even if you aren't a programmer you
should have a physical prototype that you can play and win. This
early version should also have been tested over and over again to
knock out as much bugs as possible. (If you haven't made a prototype
check out my earlier post here)
That way when you gather a team and
they ask you about some interaction or “what would happen if I do
this” you'll have an answer and, if need be, an explanation for
that answer.
The goal here and with communication is
to limit the amount of time your team has to wait on you. The less
time your team waits on you the more confident they will be with you
and the faster they can work thus actually producing something.
Due dates:
You and your team should set realistic
due date goals for your tasks and mile stones. Talk with your team
and figure out about how long something will take to be done and
ensure the whole team knows about that due date. Keep in mind that
shit happens and not all due dates can be kept. This shouldn't be a
regular thing hopefully, but it does happen.
I enjoy due dates because then the team
can see that in X amount of time this much of the game will be done.
It also motivates people to actually make time and work on the
project.
If I'm looking for a team member and
they don't want to work with dead lines then I don't work with them.
That’s my personal stance on the matter, but I want a product I
can play and show to people which means work needs to be done. I'm
also trying to make a business, not just enjoying a hobby. I aim to
make revenue from my games and I can't do that unless I have a
finished game on the market. I also don't want to have one team
member waiting on another and holding up the whole project which
harms motivation.
If you don't like dead lines that's
fine and I know many people who don’t like em'. But I work with
them and I ensure my team does too.
Motivation:
Make sure your game is small. I can't
stress this enough! For your first game or first couple of games keep
it small. I mean really small! Ideally you should have something
playable and testable within one or two weeks. If you don't then your
game might be a bit too big.
Having a small game, and thus a product
you can actually play, test and show to people, is huge! This You and
your team will easily see progress being made and thus get more
motivated to keep going. Also if you have something playable early on
you can show it to friends, family and random people online to create
buzz for your game. This buzz will in turn help motivate your team
even more.
Keeping your team hungry for more is
huge, especially if you can't currently pay them. People also are
visual creatures and thus need to see progress. They need to see the
project grow and branch out. The faster you can do this the better
off you'll be. If your team can't see any real progress happening for
a week or more they may feel the project is going no where and not be
as excited to keep working on it. A big part of these low budget
teams is the hope that one day the game they created will produce
some kind of profit. But if the project moves slowly that hope starts
to fade as they can't see the light at the end of the tunnel.
So keep your game small and your goals
easily obtainable!
-As a side note going fast doesn't mean
cutting corners. Don't release something that you don't feel meets
your standards. Your game should look amazing and finished. The
design should be solid and the program shouldn't have bugs. Again
this is why you want a small game. You can keep a high standard or
polish and still get something done fast. Just don't mistake speed
for compromise.
Team size:
I used to only hire on 1 programmer at
a time in my early ventures into the game industry. I'd find a
programmer and show them all that I've accomplished and I'd keep in
contact with them regularly. We'd be motivated, keeping on time and
making the game just as intended until suddenly the programmer would
come across something they didn't know how to do. I of course am not
a programmer so I couldn't effectively help them. I'd attempt to send
links and see if it helped, but often times the programmer would lose
motivation and eventually just stop working all together.
Now I hire 2 or 3 programmers. I try
not to hire more than 2 and keep the team small. This way the
programmers can help each other when they hit a wall. They can talk
it out and discuss possible solutions. This goes for you programmers
hiring artists too. When I model, texture, rig or what have you I
some times run into a problem I can't figure out. I ask the community
and try to solve it, but nothing beats having some one there and
asking them. 2 heads are better than one!
This also helps the project move along
faster and keeps people motivated. One programmer or artist can work
on one aspect while the other works on another. Also if one is
taking a break due to school, work or whatever the other can still be
making progress. When the first comes back they can see progress has
been made. They just might need to be brought up to speed.
Just be cautious of hiring on too many
people. It might sound great to have 10 programmers and 10 artists
all working to finish a game, but I assure you that you'll quickly
become over whelmed. With the more people you add on the more likely
communication will break down. Some people might work on the same
thing causing more confusion. Some might lose motivation if they
don't feel they are doing enough and some might miss dead lines which
effects much more people.
I once worked on team that attempted
to make an ambitious game (already a red flag). The project sounded
amazing and every one was motivated to work. I believe the team ended
up with 20 people (red flag no.2). Right off the bat the person who
organized the game started assigning tasks and roles which was done
by a vote. I ended up being the art director and I'd report to
another guy above me who then would report to the guy who organized
this whole thing. The next day when I checked in with the team we
found out that another 10 or so people had been trying to join, but
went to the wrong destination (another red flag). So now we had to
re-organize the team which took hours to do in the first place. Again
I had the same role and just a few more people to work with. Next we
had to start assigning tasks to our teams and getting the ball
rolling. Since there was no organization set in place every one could
write in the GDD to add whatever they wanted (yet another red flag).
Soon the GDD was a mess and had to constantly be re-organized and
we'd have to keep explaining the GDD to our teams, who then would
make more suggestions. There was no due date so this just kept going
on (what is this, the fifth red flag?). Mean while I'd assign tasks
to my team to get prepared for making the art assets, however the guy
above me would also tell them to do things without telling me, which
made them and myself very confused (we're going to six flags folks!)
I left the team shortly after this for
the reasons I expressed here and much much more. The project was a
disaster and fell apart very quickly. What started with about 30
eager people and dropped to a handful of skeptical people and then
dropped all together. Much of this could have been solved by keeping
it a small team to start with to lay out the basics of the game, then
grow a tiny bit to get the basic structure then further to fill out
the rest.
This story also leads us to the next
topic
Organization:
always keep organized! Keep naming
conventions and sort all your assets in a way that makes sense to the
whole team.
Have a task list so every one knows
what they should be working on and what others are working on. This
also helps the team know when due dates are for various aspects of
the game. It also helps for when a team member comes back from a
break they know where they left off, what tasks still need to be done
and what they should be doing next. I personally use Trello for this
and it has been very helpful so far.
Another good idea is saving your files
3 times. What I mean by this is make sure you save any given file in
3 different locations. For example one on your desk top, one on your
laptop and one on an external hard drive. That way if your computer
dies for whatever reason nothing will be lost.
Ensure that you and your team also have
a set way of dealing with version control. Talk with your team about
how you should handle version control without overwriting files and
recovering files if some one accidentally overwrites them.
I hope this helps you and your teams as
you move forward with your games. I'd also love to hear what has and
hasn't worked for you as far as managing team goes. Do you have any
horror stories you'd like to share?
Please share your experiences in the
comments and if you have any suggestions for future topics let me
know!
Take care everyone and I'll see you
next time!
