Skip to main content
GameDev.net gamedev.net
🔒 Locked

I'm on a roll - Might as well keep going.

Started by linternet Jan 28, 2004 at 4:26 PM 16 replies 3.3k views
Original Post
linternet
linternet
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 Development by 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 documentation Let'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]
locutus
locutus
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.
bzroom
bzroom
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.
Ademan555
Ademan555
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
When General Patton died after World War 2 he went to the gates of Heaven to talk to St. Peter. The first thing he asked is if there were any Marines in heaven. St. Peter told him no, Marines are too rowdy for heaven. He then asked why Patton wanted to know. Patton told him he was sick of the Marines overshadowing the Army because they did more with less and were all hard-core sons of bitches. St. Peter reassured him there were no Marines so Patton went into Heaven. As he was checking out hi
bastardos
bastardos

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
.basprintf ( "And for the %dth time, I'm not American!", ++lIdiots );My homepage
Stan100
Stan100
So wait (not that I didn''t like your post)...

Gamedev didn''t want your article so you''re posting forcively?
-----If you thought I was helpful, rate me down.If you thought I wasn't helpful, rate me down as well.This idiot didn't read my signature and tried to insult me.
linternet
linternet
quote:

So wait (not that I didn''t like your post)...

Gamedev didn''t want your article so you''re posting forcively?



Yes .
OOCCO
OOCCO
But why should anyone listen to you? Stop posting in here like you own the place.
"The Holocaust was an obscene period in our nation's history. I mean in this century's history. But we all lived in this century. I didn't live in this century."...Governor George W. Bush, 9/15/95
Webbster
Webbster
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...
AJirenius
AJirenius
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!
OOCCO
OOCCO
quote:
Instead of showing us your ignorance and lack of knowledge try to encourage these kind of posts
Well, that''s pretty insulting. Kids are always going to have their delusions of grandeur no matter what you tell them. They have to learn for themselves - if everyone starts posting basest, pseudo enlightenment without any jurisdiction then this forum will degenerate even further into shit.
"The Holocaust was an obscene period in our nation's history. I mean in this century's history. But we all lived in this century. I didn't live in this century."...Governor George W. Bush, 9/15/95
linternet
linternet
quote:

But why should anyone listen to you? Stop posting in here like you own the place.



Honestly, the content of the article should be enough for you to read and decide whether or not to heed the advice or disregard it. I will, however, give you the context in which I wrote the article:

I have been working on Starflight 3 (<-- shameless plug) since July of 1999. In February of 2002, with about 40,000 lines of code written, we realized that every new feature we added to the game took almost an exponetial amount of time more than the last one.

We looked over the code and narrowed the problem down to some serious design flaws in the code. The three programmers (including me) working on the game at the time met and decided that the fastest way to get the game done would be to redesign the code-base from scratch.

I don''t know if you have ever done something like that, but, I can hardly imagine something more disheartening. I seriously thought about ending my dreams of working in game development right there. My choices were:

1. Quit and end my dreams of working in game development (I SERIOUSLY considered this).
2. Start creating a new game.
3. Join another project and hope that the leader of that one was better than I was.
4. Redesign the code and pick up where I left off with Starflight 3.

I spent a couple of weeks thinking about what I had done wrong and wrote out my mistakes on paper. Those thoughts became an article and I posted it in a few places for people to read.

Suffice it to say that I decided to follow the redesign through. We had a redesigned codebase by June of 2002 and by the end of the year we were back where we were code-wise and in much better shape design-wise. Now we''re a few months from beta and will be submitting the game to the IGF contest this year.

You''re right in that the sum total of my game development achievements (DOS video poker and sports trivia game) do not give me the qualifications to lend weight to my article. I have however been doing this for a long time and see nothing wrong with sharing my experiences with others who might be able to avoid the mistakes I have made, especially on a public forum where everyone has a right to post.
cbenoi1
cbenoi1
If you want another example of a group of people getting together to build a game and move on to building the company, check this one out:

http://www.capybaragames.com/profile.html

-cb
xegoth
xegoth
Hey, nice article. One of my pet peeves is ridiculous game development ''teams'' that form online with no chance of success and no clue about game development and what is/isn''t realistic (I say this because I made the mistake of joining one of those once). Your article was right on about some of the problems that make 95% of ''indie'' teams fall apart before they finish a game. Well, maybe 99.9%.

Being a programmer, I''m curious... What was the problem with your code base that led to starting over? I''d be more interested in an article about that than anything else. Anyhow, I hope more people flame you so your post stays near the top and people can benefit from reading it.
anist
anist
want my advice? 1)prototype, 2)prototype, 3)prototype. you can write design documents, draw UML diagrams, and draw storyboards until you are blue in the face. this in no way will replace having the factual knowledge that X feature is not going to work.
i just personally won this argument with my Software Engineering professor. with nothing written on paper, i single handedly designed a professional looking flight analysis program for a major aircraft company.
how''d i do it? i did my homework, prototyped each step of the phase to ensure i KNEW what the problems were and most importantly wrote everything in self contained modules.
here''s my two cents:

1) design a VERY basic engine and artwork (if you have script writers, game designers, etc. tell them they are not needed yet).

2) after the basic engine, add features one at a time.

3) if features seem to not work together consult your diagrams and design documents (no wait, i already said that was all bs), how about this: fix them.

4) if you have to start all over it''s not because a lack of planning. it''s that you didn''t know how a feature was going to work out. this is were prototyping would have saved the day.

to my knowledge: a basic direction should be shared but NEVER completely designed. there is no way of representing how complex systems will react through diagrams unless they exsist on a pseudocode level (ie, you mine as well actually write the code).
As your leader, I encourage you from time to time, and always in a respectful manner, to question my logic. If you're unconvinced that a particular plan of action I've decided is the wisest, tell me so, but allow me to convince you and I promise you right here and now, no subject will ever be taboo. Except, of course, the subject that was just under discussion. The price you pay for bringing up either my Chinese or American heritage as a negative is - I collect your f***ing head.
coderx75
coderx75
quote:
Original post by anist
you can write design documents, draw UML diagrams, and draw storyboards until you are blue in the face. this in no way will replace having the factual knowledge that X feature is not going to work.

You''re saying that you shouldn''t document? It''s great that you have knowledge that X feature works but how do other developers know that it works... and how? Even if you aren''t working with other programmers how do you know what you''re intensions were 6 months down the road?

I can agree with you that you shouldn''t try developing something that you don''t understand. That''s just experience. I always try to have working models of everything I need before I design my application but those working models are just conceptual works and rarely fit the application perfectly (yes, I can MAKE it fit but it''s a kluge). Once the concepts are fully understood, the application architecture could be fleshed out. This is where you begin getting ideas to better implement all those concepts and those ideas should be documented. Organize the notes, make changes, etc., etc. until you have a design document that "feels" complete.
quote:
Original post by anist
there is no way of representing how complex systems will react through diagrams unless they exsist on a pseudocode level (ie, you mine as well actually write the code).

If you''re representing complex systems with diagrams alone, then that is the flaw in your method. A complex system CAN be represented through complete documentation. If you cannot do this, than you need to either a)practice your technique or b)stick to coding and let the analysts handle it.
Quit screwin' around! - Brock Samson
anist
anist
i am a coder and NOT an analyst. my real aim was: a lot of people who''ve played video games, but have little/no programming skills are sitting around writing 60 page design documents and then asking for programmers to implement them.
i''m not against software engineering, it obviously has earned it''s place. but i have seen people know UML and not know C++, and the documents they draw up usually (and by usaully i mean every experience i''ve had) will have to be changed completely to accurately model the system. so leaving things up to "analyst" really depends on how experienced they are, not me. all my sh%t smells like roses when i write it ;P
As your leader, I encourage you from time to time, and always in a respectful manner, to question my logic. If you're unconvinced that a particular plan of action I've decided is the wisest, tell me so, but allow me to convince you and I promise you right here and now, no subject will ever be taboo. Except, of course, the subject that was just under discussion. The price you pay for bringing up either my Chinese or American heritage as a negative is - I collect your f***ing head.
linternet
linternet
quote:

i am a coder and NOT an analyst. my real aim was: a lot of people who''ve played video games, but have little/no programming skills are sitting around writing 60 page design documents and then asking for programmers to implement them.
i''m not against software engineering, it obviously has earned it''s place. but i have seen people know UML and not know C++, and the documents they draw up usually (and by usaully i mean every experience i''ve had) will have to be changed completely to accurately model the system. so leaving things up to "analyst" really depends on how experienced they are, not me. all my sh%t smells like roses when i write it ;P



No offense intened here but I think your ego is talking. A game designer tends to direct a project - hence leading it and I think you''re saying to yourself "How dare this person who doesn''t know how to code tell ME - who can write flight simulation software on his own - what to do".

Honestly, the it would be great if the game designer/project leader is probably one who has 3D-modeled, written creatively, programmed, composed music, generated sound effects, and created 2D art. That way they can work competently on any aspect of the game and nobody feels that an idiot is leading them.

As you can imagine there aren''t many people like that, fewer still who will work on an indie project, and even fewer who will design/lead.

What I believe is that what you really need for a solid designer is someone who is willing to work knows how games work and, most importantly, knows what makes games fun. You don''t NEED to be a programmer to do this - you just need to be willing to listen to programmers when your lack of knowledge trips you up and they need to be willing to listen to you.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.