   I'm on a roll - Might as well keep going.
  I've gotten such a positive response from  this  that I figured I might as well post an article I wrote about a year ago.  I submitted it to a number of sites (including here) but gamedev did not see fit to post it :-(.*****10 Tips for Successful Independent Game Developmentby Brian "linternet" Linton The desire to work in the gaming industry is very common among gamers.  If you look around the industry you will find a plethora of players who have successfully used a combination of their fame and knowledge to enter the highly rewarding field of game development. I have not yet attained the attention of industry insiders.  I do, however, have a passion for creating games and have been attempting to create my own game (www.starflight3.net) with a group of people on the Internet for over three years now.   Throughout the journey, I have observed many teams, made and learned from a number (ok, a lot) of mistakes, and have collected my thoughts regarding what I believe makes for a successful virtual game project. Below, you will find the results of my pondering. 1. Design your game first.It's very tempting to come up with a loose idea for a game, and then dive right in and come up with the specifics as you program the game. Don't do it! I have made this mistake and I'm still paying for it. Come up with a clear idea for a game and flesh it out completely. Nothing is 100% cast in stone, but what you end up with should be more or less what you designed at the beginning. 2. Make a full-time designer a part of your team.Often times, I'll browse the Help Wanted forums of sites like www.gamedev.net and I'll see posts from people offering their services as a game designer. The posts are usually followed by a series of flames about how an exclusive designer "doesn't do any work" and how the person should "do something else" in addition to designing the game. The reasoning is that the person offering their services has no experience as a designer or programmer, has no artistic or musical abilities, and is seen as simply another "kid with an idea for a game". I'll say right now that my project has such a person as a designer and the project would have been long dead without him. The designer is ESSENTIAL, and it's too much work for you or another team member to double up on design and [xxxxx]. You should, of course, look for an experienced designer (if you're not the designer) but they are VERY hard to come by online.  oosing a poor designer is a fatal mistake, but don't dismiss people so quickly. A creative, intelligent, and articulate individual with good leadership skills and an insatiable passion for creating games will likely suffice when you discover that Fred Ford isn't willing to work for your team. One example is Ethermoon Entertainment. A group of six people managed to create a commercial quality RTS game. Ethermoon is great example of how to create a game with very few resources (by comparison, look in the back of a Starcraft or Command and Conquer manual - you'll notice about fifty names in the credits). You'll notice that one of the six people is exclusively a designer. It's the best argument I can think of to show how critical a designer is to game development. 3. Pick your talent carefully.Another major game development mistake of mine was to take on people that I've never heard from, before their application, with x years of [insert skill here] experience. Not ONE of them worked out, they all left shortly after joining, and the vast majority of them did not contribute any work at all. The few people who HAVE worked out for me all showed an active interest in the game AND sent me samples of what they could do. Basically, there comes a time where the initial euphoria of creating a game wears off and there's nothing left but a TON of hard work. Certain people can make it over that hump, most can't. Unless you pick your talent carefully, you're going to get very frustrated. Also, don't put too many people on the project. Simply putting you and twenty one friends on the task of creating a game isn't likely to get it done. If you followed step 1 and designed your game first, you should have a good idea of exactly what you need. You want the exact number of people you need, and you want them to be the best possible choices. They aren't necessarily your friends. Don't be afraid to look online for talent, there's lots of it out there. 4. Don't try to do everything.Even if you're absolutely amazing at art, programming, design, writing, music, etc, don't do them all. Pick one. Any single aspect of the game development process is an overwhelming task and you risk reducing overall quality by dividing your attention across the board. If you're multi-talented it's best to focus on what you do best or enjoy the most. 5. Don't give up.If you've never done it before, game development, is more work than you think it is. I know what you're thinking, "I realize that it's a lot of work that will likely take years". Nope, you're wrong, it's more than that. To paraphrase Andre Lamothè (Super amazing game author) "The difference between talk and game development is finishing what you start". The heart to finish is tough to come by, and there will be many times where you just don't see the light at the end of the tunnel. Push through it. Giving up is one mistake that I don't plan to make. 6. Don't let your ego get in the way.Everyone wants to create a 3D engine that blows Quake III's away and then develop a game on top of it that they'll talk about for the next 20 years. Well, very few people have John Carmack's skills and chances are, you don't either. This is ok, there is always someone better than you, and it doesn't mean that you can't make games. It does mean that you should be realistic about what you can and cannot finish. Your most ambitious idea means nothing until you have a completed product, and if you never get there, you've wasted a lot of time and effort. Set a realistic goal, and go for it. 7. Keep good documentationLet's face it documentation is BORING to write. Everyone is impatient at the beginning of a game project and wants to get code written so that they can become entranced by the killer soundtrack and see the breathtaking graphics start moving around on the screen. Besides, everyone's on the same page and knows what they're doing, there's no need for documentation. Wrong! Calm down, take a step back and write out well-organized and consistent documentation. Understand that with virtual projects especially, people come and go, and the goals and ideas that were so clear at the beginning of the project get fuzzy and distorted a year or two down the road. It's also very important to keep your documentation updated as the project progresses. Making a game is not an absolute process. Keeping thing up to date will allow new team members to acclimate quickly and everyone will benefit by having a central repository of project information. This is yet another of the "linternet shot himself in the foot and delayed his game" mistakes. Please learn from me -- WRITE DOCUMETNATION. Tim Lee (one of the creators of Starflight I - the best game EVER IMHO) wrote two wonderful documents on how to create and organize design documents. They can be found here: http://www.geocities.com/TimesSquare/Maze/4979/HowToMakeDesignDocs.pdf and here: http://www.geocities.com/TimesSquare/Maze/4979/HowToOrganizeDocs.pdf respectively. 8. Be consistent.Nothing hurts a game project more than working for two months,taking three off, coming back for a week, breaking for another month etc… I realize that many aspiring game developers are students, and development time varies widely with access to hardware and other team members (read: is school in session or not). Try to avoid breaking from game development simply because school let out for the semester. You lose momentum, you lose focus, and inconsistency is probably the leading cause of teams breaking apart. Set aside a certain amount of time each day and stick to it. Don't get me wrong, your game project isn't going to fail because you took a day off or went on vacation, but try to keep a schedule around 85-90% of the time. The consistency of a few core team members is what has kept my project alive all this time. 9. Maintain contact with your team.In the "project killing mistakes" category, lack of communication ranks close, if not as high as a lack of consistency. Instant messaging programs like AIM and ICQ are amazing. They let you work very closely with one another (ex: share files, discuss game issues, and have meetings regardless of physical distance. However, virtual teams do tend to be spread across the globe (my team has, or has had, members living in The United States, Israel, England, Australia and Sweden, and Germany) and this can play havoc with time zones preventing you from talking interactively. Don't let this happen. Use a forum for project members and e-mail if necessary, but DON'T lose contact with your team. People work better when they feel like they're part of the group, and isolated people tend to be very unproductive. 10. Have fun."Linternet! Don't just fill space with a have fun topic just to get 10 items." I'm really not. Game development is an exhausting process filled with frustration, tedium, pitfalls and immense rewards. If you're not having fun though, it'll reflect in your game. You'll start to rush just to "get things done", you'll take the easy road when a more complicated algorithm would substantially increase game play, and the frustration of game development will become amplified and you'll be less enthusiastic about the rewards. If you find at some point that the process has become a chore as opposed to an adventure, take a hard look at what you're doing, game development isn't for everyone, and it just might not be for you. That's about all I have. As a final note, I will stress that Ethermoon is an amazing example of the right way to create a game. If you're starting a game project, please learn from my mistakes, I know I will the next time around. Thanks for reading, check out www.starflight3.net, and contact me at compbril@hotmail.com if you have any questions. Good luck!!!!![edited by - linternet on January 28, 2004 5:31:38 PM]
  Hey, great post. In my experience however, I have found its best to do everything by yourself and not even look for help. Also the design game first point I think is important, but its also important to constantly prototype your game in a working but unfinished form at every stage of the game. For example, in trying to decide what game I am going to make next, I have created about 6 different prototype games to try out new gameplay and graphic techniques. This is better then getting pretty far and realizing your game isnt fun. ;  Yea about over designing it. In my current project I didnt plan much at all. It realllly sucked at first (it still does) but i''ve found that its pritty fun and I think its fun because its intuitive(sp) to control. The controls developed from one button to rotate my test model into the controls for the player and since i didnt cram my brain to think of the best way to control them i just created them as i felt i needed them its working out really good. ;  GREAT!!  I really needed someone to tell me i wasnt gonna complete my fps anytime soon... actually just yesterday i decided to move on, thanx for re-enforcing that ;quote:1. Design your game first...is good advice in that you should design the project before starting to create it, but you probably wouldn''t want to finish the designs without consulting your team. They''re hobbyists, they want to have fun, and get their input into the game as well.quote:6. Don''t let your ego get in the way.Should be at the top of the list. Three important things I''d like to add:1) Leadership and team-working are skills that should be considered as important or more important than programming/artistic ability.2) While a team will eventually become better than the sum of its parts, initially most teams will perform much poorer than the sum of its parts.3) Don''t be afraid to dump people who are of little use or hamper the project..bas   [sPiKie] mmorpg isnt hard in vb;  So wait (not that I didn''t like your post)...Gamedev didn''t want your article so you''re posting forcively? ;quote:So wait (not that I didn''t like your post)...Gamedev didn''t want your article so you''re posting forcively? Yes . ;  But why should anyone listen to you? Stop posting in here like you own the place. ;  It seems like everyone had already forgot the post anyway, seeing as the last post was 3 years ago!By complaining you''ve just brought it back into light again!Besides the post is good, it''s not saying you MUST listen to it. It''s advice...;  Please OCCOO:Anyone with the least professional thinking and development experience know that these are good advices and I would gladly write them myself. Instead of showing us your ignorance and lack of knowledge try to encourage these kind of posts. Maybe we will have less problems with this forum and even see a more professional angle.(Webbster: the thread started a few days ago, it was the OCCOSS registered date you saw)It''s a good post overall.I encourage everyone to read it and even if you decide to follow it blindly you will probably fall into some of these traps after all.Experience is the best way to learn. My team is now ripping up big parts of the original design due to one of these mistakes. Now after a lot of teammembers are kicked, designdocument are rewritten we are again moving forward towards an unknown future. Still I have learned a lot more from the issues we had than from reading 100''s of threads.Experiment.Don''t be so harsh on other project even if you see them do the "newbie"-mistakes.Everyone WILL learn by mistakes. That''s the best way to go! 