Tips for successful team projects.......

Anyone sane enough to run a game project must be mad!
If that doesn’t put you off:

1) Before you start:
You’ve come up with a great idea, here are a few things to keep in mind:

  • Don’t underestimate the time it will take to finish There is so much to do in a game, much more than just drawing up concepts. Most games that are good to play and re-play take even a professional studio a year or so. Don’t expect to produce a decent game in less time than that. Give it a year or two at least. Think you can keep up the commitment? Here is my time management planner in percentage of time to create:

[INDENT] 2% Planning and concepts
5% Modelling
5% Texturing
3% rigging
10% programming
20% AI programming (yes, more programming)
60% Level making
100% Blood, sweat and tears (bug fixes)
Even after you have “finished” the game there is still a lot more to do… Things like posters around the web, websites and so on. Get people to your game.
The success of many games can be measured through google images. Try googling Halo and you will receive millions of hits. Try “invasion of the mutant space bats of doom” (yes it is a game) and you will get very few, despite it being older. My project, although not even finished yet is already out there thanks to having a website and other “advertising” material around on the web. (try “Defender 6DOF”)
[/INDENT]

  • Pick an audience No-one will buy a completely out there game, but then your typical FPS might not succeed either, due to their being to many. A successful game will be in a popular style, but with something a little different, like having only one life (ever seen a FPS like that yet?). You have to chose a game that you have an audience for that you know will appreciate it. For my game Defender I have an audience of several hundred that pounce on anything I do, thanks to the remnants of Descent 1, 2 and 3, a similar game. I knew about them in advance, and asked their what they wanted in a new game (if descent was revised/remade sought of thing). That way I knew there would be people to play my game, even in the early stages.
  • If it’s your first project - Don’t expect your first project to be an instant winner, the new Crysis, the best game being downloaded millions of time within days of it’s first release. Your first serious game project (even if it isn’t a team project) will likely look pretty bad. That’s fine, your second one, building on the skill of your first will be much better.
  • spk englsh
    I am not intending to offend anyone here, but which are you more likely to join? A team with a leader that lays out ideas clearly and in an easy to read manner or a team who’s posts consist of text language that you have to struggle to make out every second word, let alone a complete sentence. If you read aloud each post before you post it then you will find many errors. If you don’t speak English as your first language, then consider using a translation engine, or getting someone else to check your posts. While this may be a bother it will help.
  • None of this copyright nonsense.
    People will not join a project that they can’t at least try playing. It simply isn’t worth the effort to join and then quit if you don’t like it. For this reason, keep things open source, people on mac and Linux don’t like people who release only .exe’s, and for some reason they seem to be the best programmers too.
    Also, make sure that you don’t infringe on someone else’s copyright.
2) Getting started: You've come up with a great idea, here are a few things to keep in mind:
  • Don’t expect others to do work for you. If you expect everyone else to do the work while you direct it, forget the whole idea. It simply doesn’t work that way. It might if you pay them, but then you may as well start up your own game studio. Be prepared to model, texture, rig, animate and program for at least the first 2 months. Also, if you are prepared to do everything yourself then you won’t be discouraged when people pull out or don’t do things correctly and such.
  • Only present your game when you have something to show for it. People are much more likely to join a game that shows some actual progress already than to join one that is starting from zero. %99 of games that start with “I have the best idea ever” die within a week, where-as projects that start with “For the past 2 months I have been working on ### idea, and here’s how far I have got” are far more likely to get team members and also more likely to be finished
  • Show off your progress. When you first post no-one will take any interest what-so-ever. They just think “Oh, another newbies project, it will die soon.” If you show that you can keep going for a month or two then people will start joining.
  • Size of Team A big teams better, right? Wrong. The bigger the team, the more confusion, and the bigger the mess (in many cases). A smaller team that communicates well is more likely to get a project with objects that look they belong together.
3) Now you have a project started: So you have a project running well, so keep it running well by:
  • Not changing your ideas hugely mid-production. A game that starts off as an FPS, then moves to RTS and ends up being 3rd person will never happen. If you change your mind half way your project will fail. Not only will the programmers kill you, but the other team members who wanted to make a FPS will leave. Changing details is fine (specifics in the story line, level order etc)

  • Don’t make promises you aren’t absolutely certain you can keep. If you promise to release content on a particular date and don’t, it gives you a bad reputation. You will suffer no disrepute for sticking to a policy of ‘It’ll be done when it’s done’. Good work takes time.

  • Ignore the “Hanger Ons” There are many people out there who will join a project, and then never contribute. You can just ignore them, no use bugging them to do anything, as they likely never will. If you really want you could remove them from the shared folder, but I can’t be bothered with them myself.

  • Take Breaks Please don’t kill me for this, but it is important. If you keep on at your project every day of the week for a month, you will run out of motivation very quickly, and the project will die. Instead take breaks, switch what you are doing. Instead of programming, do some modeling, or take a break entirely, and make a quick scene for a week long contest. You will come back full of enthusiasm, ready to continue where you left off.

  • Keep contact with your members. IRC is the best way, as it allows conversation. Emailing is just too slow. If someone asks a question, and has to wait 3 hours for the answer he is likely to give up after a short while. communication helps:

  • Keep up morale - encouragement goes a long way

  • Co-ordination - When people communicate they are much more likely to work together to create something good. Without good communication people naturally (for some reason) start working cross-purposes.

Another good thing to note is keeping everyone in the team up to date. This is always a challenge. For this reason forums are good. Also worthy to mention is file collaboration software. Pick something that the team members don’t have to download every single update (Google Docs is an example of this). A far better system is one where it auto-updates the files as they are changed. My favorite is dropbox, and it even has 2 gigabytes free space.

4) When you're done: (Speculation alert, not many have made it to this point to give information) Woo Hoo. You've finished!
  • Be Proud. Go back to the first section and look at my time planner. See the last entry? the one that goes “100% blood sweat and tears” Well, look at what you’ve pushed through. Be proud. Show off. Get your project advertised, available to the public and so on. If you had fun, then start another. It will likely be even better!
  • Bug Fixes. You thought it was finished? Nope, a game is never finished. You can make more levels, improve on bugs, extend game play. Of course, you could just all it quits and leave the users to experiment.
  • Release for multiple platforms. Call your friends on Mac, Linux, and windows to make binaries for as many systems as possible. This lets non blender users play your game. But release the blend too, people love to experiment, and try their hand at making things “cooler” You may wish to add headers to your script or other such things to inform people about the license.

Well, what do you think. Post below and I’ll add any sensible suggestions to this post.

  1. Keep Team Size small
  2. The few Team Members should naturally match their Ideas.

It makes no Sense if a Dozen of People has a Pandemonium of different Thoughts, Ideas and Wishes. The Ideas must work, Individuals differing too widely cannot cooperate properly. A small Teamsize increases the Probability of Understandment among the Team Members when the right Ones are picked.

Few more tips(or may be an observation):
1.If you are making a game for the first time do not expect it to compete “Assassins creed”.
Moral:Your first game may not be as good as you have imagined. So anyway its your first attempt.

  1. You can ask people to do your work, but don’t expect it to be as good as you have thought of. You might have to tweak it further or worst you might have to make it your self.

  2. You might deal with artist that would say: " I am in your project" and they dont work and then they say " I am out of your project". And then when you say “as you wish” , they would say “I am part of this project”.
    Moral : They going to frustrate you and going to make your project chaos. Their is no solution to them.

  3. make a solid planning , and all the concept art ready before starting the project. If you going to develop the plot mean while your game is in development, result is CHAOS…

That all I can remember right now.

Hi Geoff howz u doin ?

One of the most useful posts on the team projects forum, although I doubt many people will actually follow this. :frowning: I think this should be sticky.

Yep. I vote for a sticky. :smiley:

Also, I think planning is a very big part in video game production. If you have the beginning of the story, a couple models you have thought of and you think you know that it will take place in the future. That isn’t good enough. You should have most of the story figured out (or at least a basic story from start to finish) so that you know what models need to be modeled ahead of time. :stuck_out_tongue: This kind of goes along with number 4. Concept art should be drawn. Even if you aren’t any good at drawing, you can still draw out how everything will look and go. (Like storyboarding.)

  1. Or have progress at the start to show off. “I would like to make an MMORPG” doesn’t sound so bad if you’ve got a working client-server setup, a player, a monster or two to fight and get items from, a shop and inn to use, and NPCs to man them. Now, it sounds like something that you’ve gotten working pretty well - something that, if another competent person were to help with, would be a great game. Otherwise, you’re kind of being, for lack of a better term, dead weight (i.e. you want to make a complex game but don’t want to help with the complex parts). :confused:

Also, nothing speaks as well as gameplay and visuals. If you know Python and implement it into your game, it will most likely be far more likely to attract people, as the game will look and play more professionally, even with very simple models and animations. Logic brick games have a definite (usually unpolished) look that Python can do wonders on. Videos of your game progress thus far can motivate people to join, as well.

Also, I, too, vote for a sticky.

Hello A1. Haven’t seen you in a while!
Your points are excellent. I can see your project experience in there, and some that defiantly would have helped with mine.
Number 3 is a very good point. I have a good 15 people “in” the project, but only 4 that ever actually do any work.
Number 4 (and Sonic14’s point) is also a very good one, that I missed completely for my game, but have developed it all out now (thankfully).

Solarlune, you have a very interesting and debatable point that you have brought up, one that I have considered putting in for a while now.
I have this sneaking suspicion you see, that programmers are the people most likely to be able to run a game project to completion. They set realistic goals for what they want to achieve, and then go about putting them in. The thing is, that people look for graphics and visual effects.
So a game run by a programmer (from the outside) looks like nothing happens for several months (as the basic programming is put in place) and then suddenly you see a boost in graphics, levels and such (COS is an example of this. Nothing visual at all now, but there is a lot of the programming work done).
A game run by a modeler/texturer on the other hand starts off with great graphics, and has a steady growth of graphics and models, but, for some reason will rarely be assembled into an actual game. There is little motivation left after making all the models to actually do the programming. For this reason it is necessary to program in objects as you get them. So either have a programmer working with you right from the start, or learn programming while you are at it (what I did).

I may consider making this a separate document attached to the first post, simple because it’s hard to organize a lot of text with the phBB tools.

I’m discussing with the other mods to update the sticky list. This post is a good candidate.
@sdfgsdfg: you would need to keep your first post clean and up-to-date.

@sdfgsdfg - You make a good point. Programmers will finish games more often, or at least get further than pure modelers / texture artists, as they get a game up and running (professionally, moreso) before the modelers do. I agree with you, and would highly recommend learning how to program, or at least getting someone to help you out with the programming if you don’t already know.

*** moderation ***
This thread is a sticky now.

@sdfgsdfg: Please keep your top posts up-to-date. That shouldn’t be to difficult as the tips will not expire soon ;). Please follow any ongoing discussion.

@all: You can add your own thoughts regarding the topic (and only the topic).
If you have a tip you should post a reason. It will show you have experience with it and you learn’t from it.
If you can’t add a reason for the tip it looks like wild guessing which is not really helpful.

Please do not start any discussion what is right or what is wrong. Simply present your perspective (with your reasons).

It is up to the reader what tip to use and what tip to drop.

Thanks
Monster
*** end of moderation ***

#) Don’t make promises you can’t keep or that you aren’t absolutely certain you can keep. If you promise to release content on a particular date and don’t, it gives you a bad reputation. You will suffer no disrepute for sticking to a policy of ‘It’ll be done when it’s done’. Good work takes time.

yeah i’m totally not talking from experience I SWEAR I’LL UPDATE THE FPS TEMPLATE ONE OF THESE LONG, LONELY DAYS =cries inconsolably =

sdfgsdfg these are great tips!

my thoughts r this first, group needs a base file with a grid and charecter to base all objects on in the way of scales so every one is on same page this way if objects r created according to grid then game perspective of objects look as though they were made in same file and they r in perspective to each other. Also all modelers should have the same texture files to work with and texturing of models should be created with same method especially if using ambiants in an environment , and also if uv unrap. If using animations for objects then when creating objects, "for example, animated doors then create one door animate and if using blender game engine, program that one door to player then duplicate door. Cuts time in programing this is where append and link comes in handy for animated objects if using logic bricks. As for story and peramiters of game “fps,3rd person,or 2d” that should be desided before u start game creation ,modeling objects in different files is possible with same scale, is possible provided every one involved has a base file
to work with and then at end of object creation then main file has to have objects append and link into it to create over all file for final game also if things r done this way then u could have several games being made at once and over time u would have one heck of a data base full of usable abjects that could be appended into different games that could be used “WOW”

i have recently realized that this also applys to animations…can we add a thread similar that is stickied in the animation sector?

Evil Moon MOose:
Why don’t you start one? It isn’t hard. I imagine much of it is copy/paste from this one!

Raderium:
Brilliant. I’ll add it right away.

And thanks for the sticky

Start small, use a cube or cube(s) as the player and people (just put you own textures to them to make them better than just white boxes . full personalized characters (need texture art and modeling etc) are one of the hardest parts of the game. so using cubes will help and you can learn everything else with out adding to a already :ba: project.

next once you get used to everything move to quake quality. it’s not the best but it is some what easy compared to halo, gears of war or anything else. (this is where i am) your characters are squarish but more advanced than a block and they have better weapons.

next: comes you super video game game with halo, gears of war and RAGE quality.

Really helpful!

What you wrote was almost exactly what I wrote for the Blender Brasil Forum users as a sticky two months ago(thought I hadn’t seen this thread). Our thinking seem to be very similar.

The same basic rules apply for any major project I think.

thanks for the tips man