Category Archives: Project management

Project management deals with issues like scheduling, planning game and going through the plan.

They’ve Brainwashed Us

Yep. That happened. We all have been brainwashed. You, me and the other people on this planet. Your team members, teachers, mentors, parents, friends – they’ve all been brainwashed. Pretty much only cats and dogs have survived – rest of us have got a heavy amount of influence from surrounding environment, events, people.

Basically this means that as a game producer it’s useful to realize that your thoughts, opinions, working habits are most likely given to you. You might have ignored some ideas, but rest assured there’s something that gone through your filters without you even realizing it. Let’s try to get some examples. Word “Microsoft” is most likely to get your nerve cells moving. You might feel disgusted about their policies, laugh at their “secure” software and think that Gates should go to a very warm place with demons. Or… you might think that Windows is good, Word is a nice software for making documents and appreciate that Gates has donated really much money to charity. I’m not saying “which side to take”, but I’m saying that whatever “side” you take – something has influenced that.

The point is: something or somebody in your past has affected how you think today and feel about things. If a new game developer announces “we have a new MMORPG project and need lots of people to work with us” you might laugh or join the crew depending how things have gone in your life.

The reason why I think it’s important to understand that you (like me and others) have been “brainwashed” is that you can start questioning your own thinking and opinions. If for example you feel really frustrated about why the team doesn’t function as you would want it to work, then you can start looking in the mirror first: why am I feeling frustrated? Why would the team really need to work as I want? When one realizes that there’s great amount of influence from external sources, you will be able to question even yourself.

It’s quite easy to question everybody else – but it’s heck lot of work to question yourself. But, if you keep in mind that “your current habit might be useless” you’ll open doors to opportunities. If you’ve accepted that Microsoft is bad, you have just closed door to accepting that there might be something good in them – and vice versa. If you think you are right – and that your management style is right – then your way of leading your team won’t be flexible and your options to get your team to function will diminish.

Questioning your own ideas and opinions will help you solve problems and deal with situations far more effectively than being stuck on being right.

How to Find Artist For Your Game Project

Many teams struggle on finding artists for their game project. I think indie producers should go through 4 major steps that will help you find artist for your game.

[1] Do you really need an artist, yet?
Ask yourself: do you really need an artist for your project right now? Or could you use placeholders? Usually you don’t need game art in the beginning of the project. Try survive without real art before you really need it – because if you start getting art in the beginning there’s always the chance that you change plans, artist leaves or something else happens. If you have just started out the project, I really recommend to do a some sort of prototype before even thinking about getting artist into your team.

Get artist when you really need one.

[2] Don’t get as many people as possible in the team
Some teams start gathering “anybody that’s willing to contribute to the project”. While that might sound like a good idea, there’s two major problems with bigger teams:

  • Bigger teams means more management. More management means less time for actual development. That’s a big disadvantage.
  • Bigger teams means lesser royalties. The more people there are to share the cake, the smaller pieces is left for individuals. When doing serious projects that need to generate income, this can be a serious problem.

Be sure to find artist for a specific need, not “because it’s cool to have 20 people in the team”.

[3] Don’t try to find artists from a pool of programmers
If you’ve gone through steps 1 and 2 and decided to get an artist to the team, then be sure to know what places to check out. Some people post on programming forums and wonder why no artists respond. Consider this example: would you go to a bank to get a haircut?

Probably not. If you want to get a haircut you go to a barber. If you want to get programmers to your team, you go to programmer forums. If you want to get artists for your team you…

… naturally go to a place where artists are: artist forums rather than programming forums.

Probably some of the best places to go are CGTalk.com and ConceptArt.org. CGtalk is a website where all types of artist meet: 2D, 3D, concepts, etc. and with great variety of styles. There’s even a sub-forum for WIP/Critique: Game Art Design. ConceptArt.org is a great place filled with beautiful art and skilled artists. You can post your job postings to other forums as well, but be sure to mention about your project in art forums – since these are the best places to find artist in your team.

[4] Be open and give as much details about the project as possible
It’s very important to give lots of details and information about your project and your company or team. Tell people what kind of person you are after and what needs to be done. Tell about compensation. Tell if you want a project specific artist, or somebody to work also in the future. Put links to your game website. Show images or gameplay movies. If your post starts to get really big, then cut some parts and add links to external documents (such as a design document or project road map).

Here’s a checklist of items you could put in your post.

  • A headline, title or sentence where you describe what you are looking for (for example: “Wanted: 2D pixel artist to do 6 characters, paid position”)
  • Company or team name with a website URL
  • Game project name with a website URL
  • Brief 2-3 description about the game project – what’s the game project in a nutshell
  • More details about the game (genre, theme, main idea, snippets story, design, screenshots, gameplay movies)
  • Possibly link to game design document
  • Current team structure
  • Compensation (paid position? royalties?)
  • Description about the work that needs to be done
  • Qualities and skills that applicants should have
  • Mention that you want work examples (either links or attachments)
  • Mention if you need CV/Resume from applicants
  • Proof or past work (mention if you have finished projects earlier)
  • Technology
  • Target platforms
  • Contact info

In a nutshell: think about if you really need an artist yet, pick the artist for a specific need, go to a place where artists are and finally – make a proper announcement about what you are looking for.

3 Efficient Ways to Deal With People

Assume they want to do their best
Game producers should expect people to do their best. When you focus on trusting people to do their best, you start to see how they are willing to go extra mile to actually do a good job. When people are given responsibility and freedom to do things on their way, they are more eager to make things better. When they know that game producer trusts them, they want to show they are capable of handling whatever challenges they might face. Assuming people to do their best is an attitude that brings winning mood to everybody in the team.

Trust people until proven otherwise
I don’t see a reason why I shouldn’t trust people. If one approaches new potential team members with attitude “I have this great game project and need people, but I’m not showing you any documents because I don’t trust you”, how many team members is he likely to find? If one goes to a negotiation trying to win the deal for himself and thinking that negotiations are “against” somebody, he has already lost. Better approach would be to have a deal where both win. And when both win, it means nobody loses.

Does trusting others mean that you should accept everything they say or that there wouldn’t be people who aren’t trustworthy? No. I’m not saying that you should accept everything that people say – definitely not – but I’m saying that being open and trusting people has opened me so many doors of opportunities that I can’t even count. If I wouldn’t trust anyone – and some people think this is a valid path to choose – I believe I would be keeping these doors shut. I wouldn’t even bother to open them as I wouldn’t trust that something good might happen. “Fear of bad might happen” shouldn’t overcome “all the good things that are likely happen”.

There are people who say how every teen in a gaming forum is trolling everything and how kids write useless junk. That is partially true – but it is same for adults: there are also elder people who are behaving badly. Then there are much more people with better attitudes. People who focus on the bad sides (and especially those who counter or get into verbal fight with these people) aren’t really doing any better, they are feeding the bad material with their own behavior. When I’m writing this blog I’m thinking that the readers are intelligent, open-minded, friendly and basically trustworthy people. The great majority of comments, emails and people whom I’m talked with are like I just said: intelligent, open-minded and friendly. Many people are very helpful when you start focusing on that.

Remember that everybody has bad days in their life
Remember that people might have bad days in their life. If a programmer is really pissed off and shouts something bad to producer it sometimes might be simpler to let things cool off a while. Often the guy who got upset might later apologize and tell that he has worked too much overtime and is simply tired. Everybody has bad days in their life, so I think it’s better to forget little incidents rather than make a big issue about them. This piece of advice is good to remember not just in game production – where this happens – but also in other aspects of life.

One of Those Annoyances You Don’t Want to See…

Game production is filled of “little annoying things that take lots of time to fix”. I’ve just experienced one of them. I’m making a prototype level to experiment how “triggers” or “special points” (such as “player spawn” or “special item”) can be placed to the game using 3D World Studio. I have “bases” in the level and I’ve painted some textures on terrain to also learn the level building tool.

Look how neat everything looks in 3D World Studio…

(You can click the images to view full sizes)

… and see how it looks in game (Blitz3D).

Uh… this is bad. I hope that I’m doing something terribly wrong or that somebody at Leadwerks support forums knows how to deal with this.

These type of small problems are quite typical in game production, and usually there’s a solution for every problem. Some take more time to solve, but in the end there’s usually some clever way to handle things. At least I have high hopes for it…

Why Everybody Else But You Does a Poor Job in The Team?

I have heard game producers, project managers and other team leaders telling and pondering how “everybody else in the team does a poor job, even when I’ve told them what to do”.

Days and weeks pass and some people just not seem to get anything done.

The first obvious choice might be blaming those people and thinking about monitoring the team members or give more guidelines on what needs done. Some might even use threats or remind these guys as often as possible (using cell phone, emails, instant messaging, and other methods ranging from smoke signals to car horns).

More months pass and nothing might happen – besides that you’ve now buried yourself into a pile of endless reports – and the tension might grow even more.

The other option for monitoring, guidelines and reports could be asking. First ask yourself: “Have I’ve done everything well? Is there absolutely nothing in my actions or behaviour I couldn’t improve?” Sometimes by merely asking yourself what you could do better might help. You might realize that you’ve been silent when the team member has asked for help. Because you were too busy in the past – why should he listen to you in the future?

Before blaming or accusing you might also ask the team member: “I know you are a hard worked and have done a great job in the past, but recently you seem to need much more time to finish your tasks and the quality is below what you usually do. Is there anything I or we both could do to make things better?” Perhaps he has been too busy with handling other tasks or helping his co-workers. Perhaps he would like to take more part in the planning and design phase instead of simply acting like a computer that gets input and prints output. Perhaps he would like to get more responsibility. Perhaps he has just been too busy or lacked motivation and needs a break.

There are lots of reasons that might explain his behaviour. Say clearly what you expect and simply ask how you could improve the situation. It might be all that you need.

Virtual Team Management

Question:

I want to ask you to write an article about your experiences with team management via the internet. How do you deal with people, what channels do you use to communicate (e-mail, IRC?) and how does it differ from working with people in real life on a game?

Answer:
The main tools we use to communicate are:
- MSN (for live chat)
- Skype (to talk)
- Forums (although currently I haven’t set up one, used in the past)
- Emails

Use of Skype is very limited in projects where I’ve been, but it can be used. It’s especially good if you need to test something and need your hands free. Forums can be efficiently used to assign tasks, report progress and get the team together more efficiently. Email still is the very useful tool for virtual communication. It’s something everybody uses & reads, and it’s cheap. We exchange lots of emails all the time, although the use of forums might reduce the need for emails. MSN is a good for meetings and for explaining some tasks in greater detail.

In my opinion, team management is much similar virtually than it is in an office. The major differences I’ve experienced are:

[1] Different times of work & timezones. For example: I’ve worked with people that come from USA, UK, Hungary, Finland etc. and they all have different timezones. When I wake up and start working, the guys might be about to go sleeping on the other side of the planet. This limits the live chat options & meetings, but on the other hand: it (theoretically) makes it possible to build product 24 hour each day – when one guy goes to sleep, other guy continues. In theory, but not much in the practise. The best ones have been the cases where I’ve (for example) programmed all day, given artist a job to do, gone to bed and wake up next morning with a finished 3D model to use next day. This way timezones can help production.

[2] Need to use more formal ways to assign tasks: in an office, you can use non-formal ways to assign tasks, but in virtual workplace you need to write down everything, draw & scan papers, email more details, pictures etc. to make sure the team member understands the task correctly. In fact – I think this is something that [i]should[/i] be done anyway – whether we are at the office or not. Too many times I’ve heard verbal instructions that get forgotten the moment after manager leaves the room. Virtual working place kind of forces team leaders to give written instructions, and that’s a good thing.

There are other differences also: such as less chit chat, working in your own separate office, using more English but these are – at least for me – minor issues compared to the 2 previously mentioned ones. Technical requirements are pretty much the same (instead of intranets you can have similar system in the Internet, version control software work well across the Internet), same problems (how to motivate people, how to hire the right persons, how to be on schedule etc.) stay.

For a person who likes to be among people, virtual team management can be tough – but for those who like to work from home and can handle timezones this method of working suits very well I think.

7 Risks in Indie Games Production

Indie game production contains risks. The size and the odds of risks vary, and as a game producer, your job is to identify the potential risks and plan for the risks.

#1 – You
The most crucial part of the indie game production is you. This risk might have low propability to actually happen, but if this risk comes true then the consequences can be enormous. If you get a burn out, then the production will stop. There are at least three different ways to prepare and avoid the risk. First one is taking care of your health. Exercising and eating healthy food (pizza & coke are for programmers, not for game producers…) can have great impact. Besides getting in good shape it also can improve your motivation to work. One hour break walking outdoors can improve your energy to work inside. Another way to avoid risks is to remember to rest. Taking a day off, having breaks are good ways to charge your batteries. The third option is to take an insurance. If something happens at least you know you can get proper medication for illness.

#2 – Funding
The second risk is money: if you run out of money, then your business will die. Besides trying to sell more there are other ways to prepare for this risk. Part time jobs, or freelance jobs can generate some income. Saving and living frugally (but not in the expense of healthy food) are good ways to get better surviving propabilities. I also recommend checking out what governments can offer. There are programs that can help you to fund your international business. I’ve checked 2-3 programs and some of them can offer several hundreds euros each month while others can be bigger one-time funding opportunities – without need to pay the money back.

#3 – Team member leaves
This risk always exists. Even though the team member might be very trustworthy the external conditions might force him to discontinue working with you. This happened to me in Edoiki production and I managed the risk with good relationship with the programmer and simply adjusting the game time line. Contracts and NDAs can be useful in preparing for this risk.

#4 – Data losses
Data losses can be tremendous problem and making backups is essential to avoid the risk.

#5 – Time
One of the biggest factors in games production is time. What happens if the game comes out after the specified deadline? Will competitors get ahead of you? Preparing to the time risk can be difficult, but scheduling the game properly and planning the project properly can help in defeating the risk. Sometimes you might need to leave away some planned features just to make sure the project gets finished on time.

#6 – Quality
Besides time, the quality of the game is important. If you drop away some features to save time then you might avoid one risk, and get another one instead. Your project must have extra high quality. The game should be the best in its field. If your game is not good enough, then you might need to polish the game more to make it a really top notch product. This might mean balancing the quality with time and costs. Prototyping, internal and external testing and getting player feedback can help you to produce a high quality game.

#7 – Costs
Costs are the third parameter in the time-quality-costs triangle. In games production avoiding one risk might mean problems in some other factor. Plan for what you really need to buy and don’t purchase anyhing if you can survive without it. Of course purchasing equipment that adds yours and team’s productivity can be good a investment, but consider carefully on what to purchase. Project budget can get very high in little time.

There are risks in indie games production. Some of them might require planning, while some can be transferred or ignored without much effort. It’s game producer’s job to manage the risks.

Fundamentals of Game Project Duration Estimation

Indie game projects easily miss their deadlines. Planned milestones pass, and patches don’t come on time. This article points out 15 reasons for missed deadlines this and gives a clear guidance on how to estimate your game projects duration. Getting better estimates will not lower costs but will help you estimate the time scale and costs related to the project.

#1 – Avoid Over Optimistic Estimations About Your Skills and Energy Level
It’s quite common for people to over estimate on what they are capable of. There might be times when your skills are simply not enough and you need either help from others or time to learn new skills. It’s also notable that your level of energy might change during the project – on some days your diligence and motivation could spike while on other days they might be really low. Estimating projects and believing that you will have 110% energy level every day is over optimistic way to approach.

#2 – Avoid Over Optimistic Estimations About Your Time
How much time you spend on chatting, emails, eating, breaks, phone calls, and organizing daily? You must notice that if your typical work day lasts for 8 hours, you propably use some time for general issues. You propably receive interruptions in different ways. It’s not realistic to assume that you could use 100% of your time for the project. Depending on your assignments it will propably be something like 60-80%.

#3 – Estimating Too Large and Abstract Components
This is propably the key reason why projects estimates miss their targets. If you try to estimate how much would a new multiplayer FPS game would make you would need to list the components/objects. The first list might contain only big components like:
1. “Network”
2. “Server”
3. “Client”
4. “Players”
5. “World”
There’s no way to estimate durations for these. You’ll have to break your big projects into hierarchical list of smaller tasks.

For example: “Players” could be divided into several tasks:
4.1. “Player Design”
4.2. “Player Graphics and Animation”
4.3. “Player Sounds”
4.4. “Player Network Code”
4.5. “Player Scores & Ranks”
Etc.

After you have listed these taskyou would need to divide them into smaller actions: “Player Sounds” for example could have actions like:
4.3.1.”Create death sound #1: ‘aaargh’” – 2 hours,
4.3.2. “Create mock sound #1: ‘you lose’” – 2 hours.
4.3.3. “Create footsteps sounds”, 3 hours
And so on.

Now you could total the hours for each task and you would have a much better idea on how much time your project could roughly take. Breaking large units into small manageable task is essential for you to make realistic estimations. It’s up to you how detailed plans you want to have. Sometimes 2 levels is enough, sometimes 3rd level is needed.

#4 – Fixing Errors & Bugs & Other Problems
Don’t assume everything will right in the first time. There will be always errors and bugs in your program. You will need to revise your code. Putting a 10-30% time buffer for “unknown bugs/problems” is a good way to make a better estimation.

#5 – Remember To Estimate Also the Integration of Different Modules
Besides bug fixes you must notice that integration of several modules will take time. If one programmer codes the server and another one the client then you must also estimate the integration – the time it will take for server and client to work together.

#6 – The Feature Creep
Game developers – whether they are artist or programmers want to make the game perfect. They want the textures to be perfect. The code must be perfectly optimized. The rendering must be perfect. The details must be perfect. It’s very hard to make a decision when something is considered finished, but there are times when you must make sure the project goes forward. Polishing over and over will eventually lead to a non-finished product. There are times when you must make a tough decision – and accept some level of quality. It doesn’t have to mean that there couldn’t be many areas where the perfection is done – it just means making a conscious decision about where polishing is really needed and where you can survive with lesser quality. To make better estimations, be sure to add ‘feature creep’ extra time for some parts of the game.

#7 – Producer Tasks Has to Be Noticed
Meetings, project planning, estimations, project management, design document updates all are tasks which aren’t usually noticed when making game project estimations. All these take time and should be somehow taken into account.

#8 – Unclear Goals and Task Objectives
This is another huge problem in project planning. If your goals or objectives are vague, there’s no way to estimate them. If your goal for making the graphical user interface is listed as “Make a better GUI” it’s not possible to estimate duration that. What does “better” mean anyway? Does the GUI mean also designing the graphical user interface? Does it mean coding it – or is it only making the pixel graphics for it? Make sure you state and write your goals and objectives clearly.

#9 – Wrong Person Is Doing the Estimations
If you are a coder and try to estimate hours for modeling without any relevant past experience there’s no way you can do it. If you don’t have any idea on what a making of MMORPG would take then you shouldn’t do the estimation. You should either find the people who can help you to estimate or learn more about the subject. Use designers and programmers to estimate – let your team participate in the process if necessary.

#10 – If You Cannot Find Answers From the Team Members, Ask Outside
Estimating a massive game project without previous experience is a difficult process. Consider asking other game developers. Go to some game development forum and ask what people would estimate about your project. You propably won’t find exact answers, but you’ll most likely will get some rough ideas about the duration. This might help you to make a better evaluation by yourself.

#11 – Estimations Are Not Updated When the Project Gets More Content
One quite strange phenomena is to create huge timetables and large estimations for the game project and then forget these estimations. If you are going to estimate your project then you should update the estimation when you add significant changes into it. Otherwise it’s no use.

#12 – Time is Not Tracked
Without tracking your time spent on different tasks you won’t learn. You’ll estimations will remain on the level they are now – and if you don’t track your time you propably will live in a dream house believing your estimations are always correct.

#13 � Nothing is Learnt From the Earlier Projects
If you have completed or progressed in some previous projects you should store the estimations and actual durations. If you have past experience about estimating a project it can come handy when doing new estimations.

#14 – Quick Estimations
One of the worst ways to estimate projects is to do it in haste. If estimating a project takes 30 seconds you can bet that person is not doing a good job. I’ve asked many people “How much time will that take?” and listened them to answer right away: “It’s 90% complete, will be finished in two weeks.” After two weeks the same person is in the same point giving exactly the same answer. If you make estimations – don’t make them quick.

#15 – Don’t be Afraid to Be Wrong
Bad estimation that is tracked and learned from is much better than no estimation at all. If you want to make better estimations, start tracking time and making your guesses. Note how much time it took, and what changed during the project. If you want to learn, you must accept to make mistakes. Start learning, and get better on making estimations.

The Best Project Planning Tools

The best tools for project planning are: pencil and some paper. Okay, almost the best. Quite good at least. In some cases.

I’ve been doing years of project work and I believe some things like (parts of game design, preliminary project plan, graphics concept art etc.) are best done in paper. It might sound bit strange… but pencil & paper have some very good benefits:

  • They are available all the time – you don’t have to turn on your computer and wait for the programs load.
  • They are available anywhere – you don’t have to design in front of your computer… you can be out in a forest and draw lines. (I prefer sofa)
  • It won’t crash. I have never seen an memory error while planning on paper
  • It’s darn a cheap! Pencil & paper doesn’t cost anything compared to almost any professional tool (of course there are very good free tools available, but still – they are very cheap)
  • It’s flexible: drawing something in pencil is much easier than using mouse and trying to use freehand tool (even those ‘draw boards’ aren’t so good in my opinion)
  • It’s all in one package: whether you do budget, project plan, or concept art – you can use the same tool (pencil & paper) for all of those.

Use pencil & paper in design – and put finished paperwork on computer when needed.