A very good question was posed at the forums: how to deal with a slacker:
“I am a student enrolled in a game design degree program. About 7 months ago a very good friend of mine and myself took it upon ourselves to create a game concept. Things since then have progressed to the point where we have begun creating a demo for the game in which we could use to pitch the idea to potential publishers/developers.
Problem: We have a team of now 10 people comprised of artists, programmers, designers who all work very hard…and an individual brought on to assist in project management to support my friend and myself in managing the project and its time as well as its limited resources. However, the individual we recruited to assist in our project management has produced little results. The individual has now been on board for 5 of the 7 months and has never produced a single document, even though claiming that he has been working on “stuff”.
Long story short, It’s to the point where myself and some other project leads are ready to let him go from the project, however one of the project leads still has faith that our project manager will step up and start producing work and supporting the Project Leads.
Any suggestions on ways to “Motivate” him?”
If you are sure that the guy cannot finish the tasks you give to him, then get rid of the slacker
That’s pretty much it. It doesn’t make sense to keep people who cannot finish anything in the team. I remember working with one guy who was constantly saying how many hours he has done for the project. When I tried to find out what exactly he had done – he couldn’t give me a proper answer. At some point he left the project, and that’s the last I’ve seen of him.
Often there’s emotional reasons why you might keep somebody in the project: you think it “feels bad to let somebody go”. There’s one thing to consider. Others will feel bad if you let the guy continue. You cannot put one slacker higher than others: you must also think the rest of the team.
I would also like to point out that one shouldn’t judge (or say that somebody is a slacker without clear “evidence”). A slacker constantly keeps saying that he will do something, but he never gets anything done. If you think you have a slacker in the team, then (before firing him) you might consider making it really clear for him what he needs to do. Perhaps you haven’t been clear enough for him to perform optimally – so don’t make the mistake to fire somebody based on what you feel. Make it clear that you have a project that must progress, and that he needs to help with the project (and give specific tasks) – or your paths must go to different direction.
Whatever you are going to do, make sure you don’t let one guy to ruin your project. Make sure people get the stuff done what you expect from them – and make darn sure they know what you expect from them.
Feel free to comment the slacker issue at the forums.
The new game producer forums have been online for about a month and the membership count is now close to 300. There’s 20 banned users already. We are taking the rules seriously, and want to keep things civil. If somebody tries to just register to spam something (without reading rules – nor using common sense) he will be banned, and that’s it.
So far the strategy has worked fine and the discussion has been civil. I want to ensure that the forums are place for great discussion. I want quality over quantity.
And that’s why we have set limits. The rules are quite simple and rely on one major guideline: use your common sense. That goes far away. There’s alternative for whining. Instead of blaming for everybody, suggest a solution. master complainers are kept away.
We set limits in the very beginning. I know from experience that if you don’t set some limits right from the beginning, it will be much more difficult later. Anyone who has trained dogs (or has children) knows how difficult it can be to get the dog (or a child for that matter) to stop doing something he could have done earlier. If you allow dog to sleep on the sofa for two years, you’ll face lots of resistance if you try to change that rule when the dog is 3 years old. If you allow child to decide what he eats when he is 2 years old, rest assured you’ll face lots of resistance if you try to change that habit when the child is 6 years old.
See in the future, and set the limits according to what you want.
The new game producer forums launch has gone smoothly so far and within some days we already have close to 200 members and new members registering as we speak. Users have also found the new thread and reply buttons as there’s several hundreds of posts already at the public areas at the forums.
Recently Russell – one of the moderators – posed a question about how to handle artist and producer communications. The full forum entry can be seen here: artist and producer communications, and there’s already some answers from registered users, Insiders, moderators and AAA producers.
Check it out.
I might be exaggerating a bit here, but if I’d had to list the three factors that have caused most of the problems (and also have made the project possible!) during the Edoiki game development I’d say: people, people and people. It’s not so much other people, but the balance that team (including stubborn producers) must find and the things that happen in people’s lives.
Pretty much every technical problem can be solved one way or another (since they aren’t emotional problems) but the moment you put more than one developer in the same room, you can rest assured that there will be problems to solve.
I say “problems”, but I must point out that while people are perhaps one of the main reason for problems – they are also pretty much the main reason for solutions. I’ve been working with a great Edoiki team from where everything has been solved so far. This couldn’t have happened without great people (I’m not referring to myself here).
Indie game teams face the risk of losing team members (I’m referring to what happened yesterday) that can have big impact on the project, and since indies often cannot work with limited budget (we do this because of passion, not only for the profit) it’s a risk one should take care of. I didn’t see this coming, but I’m thankful for Michael for letting me know at this point. It would have made things even worse if I hadn’t heard about his situation now but months later.
I’ve been praising that producers won’t need game art in the beginning of the project, and I believe that’s still true today. You may easily use placeholders to prototype. What I would like to add is that even though you don’t need game art in the beginning, you have to find the right people in the very beginning who are going to work as long as possible: hopefully the whole project. Hiring and “firing” people takes time and effort, and would need to be minimized.
It’s the people factor that counts most.
I’ve mentioned our issues with game animations a few times in the past, and to be honest: I didn’t except animations to cause us that much work in the project. I’m glad we’ve found a professional animator in the team, but there’s still problems to solve before characters are done.
In fact, now we have finally managed to export animations in the project – but there’s another problem. Now the animations work when run alone. When we combine two different set of animations to one character, it won’t work. We are checking out the Max hierarchy and trying to find out what might be causing the problem when the game engine loads the additional animations. Since two files aren’t working, next we are going to put all the character animations in one file – and let the engine splice them properly.
There are unexpected moments in game production, and while it’s almost impossible to know what might unexpected might happen – it’s good to expect that something won’t work as planned.
Expect the unexpected, and when that happens – find the solution.
One of the mistakes in game production I’ve done is to require excellent quality for all the tiny details. This has happened years ago, and hopefully I’ve learned from the past. While the habit of making things work perfect can be fine in certain situations (polishing the core gameplay for example), that doesn’t mean you should follow the same guideline everywhere.
Here’s a practical example: Our Edoiki game characters. First when the characters were textured it was good to remind that they won’t be seen very close, and making very tiny details in the texture simply is not a good idea. While it might be cool to have detailed Japanese symbols, it doesn’t make much sense since nobody is going to see them anyway. Same goes with the animations that are currently in progress. There’s no point perfecting how the chin (for example) needs to move since the game camera won’t see it anyway. Making certain small details in the animations simply would be waste of time – some of them are good, some of them might be waste of resources.
That’s where you need to set a limit for the quality. For some artists who demand to create perfect characters this might be a tough issue, but it’s the producer’s job to explain that they won’t be seen anyway (don’t count on them to believe this – some people will continue doing the work anyway explaining “but I *know* it’s there”).
Some professionals simply won’t accept low level of quality, but it’s the producer’s job to set the limits. Even if it seems “low quality” for the team member, it might mean “the best possible quality” for the project.
Set the limits for quality, and you’ll do a favor for your project.
One of the most important things producer’s need to deal with are the people. Today I got bit “bad news” since two of our artists are doing work for other projects as well. They get paid well for these tasks so it’s understandable for them to do other contract work. These type of stuff happens when you deal with people.
For me, this means couple of things:
- Put in detail the rest of the graphical elements: I wasn’t expecting the level modeler taking other contract work at this point, so it’s crucial to list all the elements we need to finish the game. This will give us better picture about what we need from the artists.
- Cut unnecessary features or elements: While I revise what’s need to be done, I’m also going to take a very close look at all the planned features and think tough what will be done. This will help getting the whole project finished sooner.
- Communicate more: Both of the artist will still be working with our project, but I need to be sure that the guys share openly about their plans – and how much they can do for the project. By this, I hope to ensure that there won’t be surprises.
While currently it feels bit difficult to keep all the balls in the air simultaneously, I’ve learned from the past that the difficulties are where you really learn.
This is a place for growth – and place to take steps forward faster.
There’s a well known truth when choosing a web hosting provider: you get what you pay for. Many people (I’ve done this too in the distant past) go from webhost to webhost to save $50 for a yearly price (like instead of paying $100 or $150 per year – which can get you a reasonable host for starters – they pay $50 per year). If you think about that businesswise… it’s like 2-3 sold copies of a game. And if one cannot afford to pay little extra to get a decent host, one could ask why bother at all.
The same wisdom is working on other areas as well. In business, I was after animator just to find out that 3-4 guys who tried eventually didn’t finish the animations. It was not their fault, and there were some external factors causing problems (like the fact that one guy got an animator job from major company which offered better rates) but anyway I couldn’t find the right person. I believe in the end the reason was simple: I had too small budget for the animations, and I got what I paid for.
Now I finally found the guy, by the help of our other artist Ben (which is a lesson in itself: if you need to hire somebody, ask if your own contacts would know a suitable person). The new animator costs more than the other animators, and with an indie budget it can sometimes be a bit of a problem to make it a good deal that everybody is happy about. Luckily we got it, and the guy has already done some good animations.
Strangely enough… it took me several months to find this animator.
As I was trying to save some hundreds of dollars (which can sound sensible for indies), I actually was doing false savings. If I would have raised the animation budget right from the beginning, I could have spent the time lost to do some contract work – which would have paid well over the costs of the new animator.
Strangely enough, my decision to save dollars actually cost me more time and money than it would have if I’d just raised the budget right in the beginning.
You live and learn – and you get what you pay for.
If we look at average people, most people want things such as “security”, “money”, “fame” among very many things. But here’s the problem: your team members are individuals, not average people. There’s no such person as “average person”. Sure, some of them probably will say they want “make great games” or “enough money to pay the bills”. That still doesn’t mean they wouldn’t be individuals who want different things.
As a producer, it’s your job to find out what motivates your team members. If one has need to see his ideas in the final game – then you’ve just found a great way to motivate that person: simply use some of his best ideas and implement them in the game. If one guy has need for fame, then showing his name in the credit list and mentioning him in public is great way to motivate that guy. I’m not saying this as a way to “trick” others to get them motivated. Trying to be cheap and cunning shows. I’m simply telling you that different people are motivated by different factors – and it’s your job to find the way to motivate everybody in the team. Sure, you can pick ideas on how to inspire your team members, but don’t just randomly try everything to everybody. Instead, treat people individually – and the way they’d like to be treated – and inspired.
Motivating yourself is important, but equally important is to inspire and motivate your team members. Here are 7 ideas that you might want to try.
#1 – Show progress
Quite obvious one, but can be easily forgotten. Make sure you show progress and tell openly where your project is going. Even if programmers don’t know how to rig or animate, it will inspire them to see artists doing their magic. Keeping project visible and showing progress helps everybody.
#2 – Bring good news
This is a great motivator for everybody in the team. The fact that today I found an animator (finally) and announced it to other guys in the team will certainly be inspiring for them. Bring good news – it’s good for morale.
#3 – Show success stories
Successful people are hungry for success stories. Tell about other teams who have done a good job making and selling games and it will motivate your team members to do a good job. Tip: check out game sales statistics for detailed information about how much different games have sold and share them with your team.
#4 – Cash rewards
Pretty simple, yet efficient way to motivate. If you have a tight budget, you can still sometimes give additional bonuses and rewards for the whole team when a milestone is reached or a job well done.
#5 – Give credit
Give credit for those who deserve it: everybody likes to be famous and see their names in public. Make sure to let your team members share the fame. (I have promised to share more about our team members and will do that “soon”).
#6 – Use their design ideas
One of the most motivating things is to see your own work in the actual game. Not only code or art assets, but to see design ideas. (Be careful with this though: somebody might suggest pigs to be included in the game – see #10 point on that blog post).
#7 – Share your inspiration
If you are inspired to work, make sure it shows. Talk in inspiring and motivating way and it will be catched by others.
Your inspiration can spread like a virus.