Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

The 6 Indie Mistakes

By Chris Canfield in Media
Sat Jul 30, 2005 at 01:42:02 PM EST
Tags: Technology (all tags)

If you spend much time in the game development industry, you start to see patterns. I was browsing around the David Perry designer forums, and came across quite a few interesting people bursting with designs. One particular one caught my eye, though. It sounded interesting. It sounded exciting. It sounded like an epic so grand it would put Cleopatra to shame. And it sounded utterly, utterly impossible to make. I won't single out the budding designer here for ridicule, but he had created a story so grand, a world so rich, that it would take a team of thousands several years to create. He, of course, had only himself, and no idea what to do to start.

This will not be an article on how to make games. Nobody knows how to make games... being in the game industry has made that abundantly clear. This will be an article on how to fail to make a game. Or, rather, the 6 most common reasons why people who are about to embark on the great journey for the first time fall flat on their face with their first step. While these may contain the extremes of archetypes, chances are they all, in one way or another, apply to your project.

"I'm going to make an RPG with 3,000 enemy types, real-time combat, and a first-person shooter mode. And dancing, lots of dancing."

You have 2 designers, one coder, and a part time artist. You have the staff, in other words, to make Tetris. Be realistic about how much you can accomplish. Take your most basic game ideas, and make them smaller and smaller until they can't physically get any smaller. 3,000 enemy types? More like 3. An FPS RPG with an all-new engine? Make a top-down shooter in Flash. 100 hours of content? How about a game you can beat in 30 minutes?

These "kitchen sink" game designers don't take into account that the reason current games don't do those things is largely because any single genre game is amazingly time intensive to make. Making 4 different games simultaneously, and making them all integrated together, is a task so Herculean as to be Sisyphean. Multi-genre games almost always come out like The Adventures of Bayou Billy: three main courses so totally undercooked as to be inedible.

The fact of the matter is it takes a team of 50 people working full-time for a year to make the average game. The really stand out games, like Half-Life or Zelda, take teams of a hundred people 3 years to make. Anything remotely close to that, or beyond that, is way out of scope for your first project.

There are a few things you have to watch out for in a design. Any time a story is being told in a non-linear fashion with a multitude of possible outcomes, a red flag should go up. Any time two or more genres are being mixed, consider cutting large portions of one or both. If you ever want to see sunlight again, and you will, make one game instead of three.

"I've got my design in my head, and now I just have to make it."

Believe it or not, Game developers don't make games. We don't slave away for 10 months so that a game can pop into existence. No, what game develoers make is milestones. The first milestone might just be some little code for a salmon swimming around in the water, the next milestone might add a player-controlled rod and reel, and the third milestone might have the fish biting the bait off the rod and reel if you wiggle the joystick just right.

No game gets out the door without this series of plateaus, the last of which happens to be something a publisher can sell (sometimes). People have said that game development is the process of hacking out a demo to entice a publisher, polishing the demo for E3, then polishing the E3 demo for sale. It's a series of little and big milestones, and deadlines where everything has to work perfectly.

If you don't set your milestones, and you don't develop your system, you just aren't going to get anywhere. You're not making a game. That's too big of a hurdle for any team. You're making a 5 - 10 pre-determined steps, all of which lead up to whatever want to make. Take the time to figure out how long each part of your development will take, breaking it down further and further until you are at about week-sized chunks. Your development map may be completely wrong, but if you don't have a map of some sort you can't know if you're making progress.

"It'll be finished when it's done."

There have been two games this has famously been said about... Warcraft 3, and Daikatana. Guess which one you're developing?

The fact of the matter is that sometimes games just don't work out. You plan a great story, you designed great gameplay, the artists created great artwork, the programmers wrote great code, and when everything comes together somehow it's far, far less than the sum of it's parts. It's ok, but not as great as it should be. Or maybe you feel your game will be finished when it's done because it's so truly bad, and the development so messed up, that nobody can realistically say when your team will be out of the bog you found yourself in.

There is a saying in the industry. "Ship it!" You can tweak and adjust a game forever, slightly improving graphics and creating more gameplay, but at some point you really need to put whatever you have in a box and shove it out the door. You have to move onto other projects, and the only way you can do that is if you finish the one you're on, or salvage what you can of it. I've never shipped a game that I didn't still want to work on and make changes to. I've never shipped a game that was perfect. Nobody has ever done such a thing, and nobody every will.

Your first game most certainly won't be perfect. But what are your goals? When I ship a game, my goal usually is to entertain people, and maybe get them thinking about gaming in a new way. Your goal for your first game is probably to get street cred in the game development industry, a feather-in-your-cap if you will. Always keep that goal in mind when developing your game. You needent make a 100 hour monstrosity if your target is going to be someone who is reading your resume and will have a grand total of 10 minutes to play. A single-level tech demo will more than suffice. You don't need to write a cinematic engine if you only have one cinematic in the game. Can you cut the cinematic, or is it key to how you are trying to get your cred? Can you cut the network multiplayer, or is it key to your cred? Always keep your goals in mind when developing your game, and always be thinking about what your next project will be.

It's better to have a good finished game than a great game that will never be done. This will not be your magnum opus, nor the only project you ever make. Get it done.

"I don't understand this. I'll figure this part out as I go along."

Some things are self-evident. Some things are so self-evident that you feel you needn't describe them ahead of time... How your revolutionary natural-language parser is going to work, how "getting an education" will effect your character's stats, or how role playing elements in a multiplayer game will affect actual gameplay. "Clearly it will work." Yes, but how exactly? If you can't answer that question about fundamental or key gameplay properties, you're not ready to start making your game.

Despite my sarcasm, some things really are self-evident. You'll figure out about how many power-ups to sprinkle around a level. You can design side-scroller boss mosters once you hammer out how many levels you are going to have. But never let a thorny issue of an original design sit unexplored. How are you going to give phone conversations gameplay value? How do you get the board game to interact with the videogame component? If you can't figure out how to make the "revolutionary" component of your design work as a game, maybe that's why nobody else has either.

We fell into this trap on a little side project I helped out with called The Story Game Initiative. Our revolutionary aspect was to give story gameplay value. it wasn't until a three months into the project that we had to push everything aside and think long and hard about exactly what it was this meant. Years later we're still sitting and thinking, and one of us has since gone off to get his masters degree in figuring it out.

"I have a binder full of 300 pages of design documentation meticulously pieced together over many, many years."

Ironically, one of the worst things you can do to a design is to get too detailed too quickly. There is a flexibility of design that you really need to create an experience as parts of it come online. "The hero is a heavily armed mouse" is a good one-line description for the beginning of a project. "The hero is a mouse with a shotgun, rocket launcher, and whip, who gets 5 shots of ammo per pack" is not. Until you have your gameplay more fleshed out, you won't know exactly what weaponry you will need to balance play, and you certainly won't know how much ammuntion your player will need. A lot of what goes into the game does so based on good ideas from across the length of the project.

You may think this is harmless, but the fact is that besides wasting time you're creating a structure that won't fit the final game, and anything built on that structure won't fit the final game. Design may be king, but a king has to dynamically respond to the situation he finds himself in. Your design too must be flexible enough not just to change and adapt, but to grow in the proper direction. And to do that it needs to be a little amorphous and undefined in places.

Keep your initial design doc a skeleton framework. As your team grows, add walls and a celing. Try not to design everything too early, or you will be left with a design that doesn't fit your game. Anything that is "Fun" (or whatever emotion you're attempting to evoke) gets attention and expanded upon. Anthing that isn't gets cut. Have your programmers create general systems for movement, rather than specific systems for moving characters whose designs aren't final. Have your artists start by sketching out "visions" of the world, rather than specific power-ups. Try not to throw final polish onto things that haven't been tried in-game: nothing discourages like throwing out weeks of work.

"I'll just do the music for the game myself. And the art. And the programming. I'll schedule it. I'll then promote it, I'll do bug fixes, I'll handle customer support..."

Laboring alone, or with the wrong people, is the greatest killer of independent projects. You might be OK with a compiler, a midi synth, and a pen and piece of paper, but it will take you forever to do everything yourself. Not only will it take you much longer to do something than someone who specializes, you won't be as happy with the results. A competent artist might churn out a 3D object every day in their spare time, while a week later you're still trying to make a chair using the lathe tool. You may be able to use a compiler, but you may spend two weeks writing and optimizing a custom binary search tree while a programmer might just call a prewritten hash table function and be done in five minutes.

The only commercial art form that has a single author anymore is books. Everything else is a team effort. Games are no exception.

People management, especially in small projects, is an interesting thing. You don't want to bring people in too soon, or their enthusiasm will wane with nothing to do. You don't want to bring people in on an emergency basis, because they'll still need time to ramp up. The key is geting a good, clear overview of your project's lifespan, and building from there. Since it's your project, it's your responsibility to find people and let them know what you're relying on them to do to make the project work. Don't be afraid to tell people what needs to get done.

Game development is a fun and interesting adventure, but it is a much bigger mountain to climb than many people realize. It involves a lot of factors that need to come together just right to be successful. Build your plan, build your team, and build your game. Just be aware of the paths treaded before you, and the reasons why people wound up skeletons by the side of the road.

To you budding indie developers: I salute you. Good Luck! ...You're gonna need it.

(Chris Canfield is a game designer at Harmonix Music Systems)


Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure


Related Links
o David Perry
o abundantly clear.
o The Adventures of Bayou Billy
o Daikatana
o The Story Game Initiative
o Chris Canfield
o Harmonix Music Systems
o Also by Chris Canfield

Display: Sort:
The 6 Indie Mistakes | 81 comments (51 topical, 30 editorial, 0 hidden)
LOL (2.00 / 4) (#1)
by Kasreyn on Thu Jul 28, 2005 at 11:56:38 PM EST

The only commercial art form that has a single author anymore is books. Everything else is a team effort. Games are no exception.

Have you ever heard of "editors"? Unless you're fucking King or Rowling, essentially a superstar, you don't have sole final say in your work.

"Extenuating circumstance to be mentioned on Judgement Day:
We never asked to be born in the first place."

R.I.P. Kurt. You will be missed.
Not the same thing, I think (2.75 / 4) (#8)
by nkyad on Fri Jul 29, 2005 at 02:18:23 AM EST

Having an editor revising your work, telling you this chapter is shit and that character is flat and useless is completely different what happens in a game development project.

The better analogy would have one or two "designers" having the "book idea", three or four "programmers" writing the actual book, some writing solely the plot related parts while others write the character related parts and one writes the scenario description parts. On the top of it you have a "graphic artist" choosing different fonts, font sizes and font and page colours for each part of the book. That's a game development setup.

Books, in comparison, are much, much more a one-person project and have been produced succesfully using the more or less the same process we have today since someone invented language.

Don't believe in anything you can't see, smell, touch or at the very least infer from a good particle accelerator run

[ Parent ]
Well, yes (2.50 / 2) (#10)
by Kasreyn on Fri Jul 29, 2005 at 02:30:14 AM EST

But there's still a big step between authorship and the sort of autonomy he was talking about. That sort of autonomy only exists for two types of writers: those who self-publish, and those who are famous and can dictate terms because they have a proven ability to deliver a book that will sell.

"Extenuating circumstance to be mentioned on Judgement Day:
We never asked to be born in the first place."

R.I.P. Kurt. You will be missed.
[ Parent ]
Yes and No (2.00 / 3) (#15)
by coder66 on Fri Jul 29, 2005 at 07:03:04 AM EST

A published book has had many more people work on it other than the author. Editors, copy editors, typesetters, and a cover artist at least. If you want to compare this to a game, then these are the people who burn the cds and make the box.

Big name authors do still get edited. No one is perfect and they will have changes that are needed no matter how talented they are. Granted big name authors will need less editing, but that is because they are more skilled and got more right to start with. Regardless, the author has total creative control over everything with the exception of cover art(big name authors are usually the only ones able to pick cover art). The author is offering his intellectual property for sale, he can reject out of hand any changes that he does not like. That said, any intelligent author will be able to work with an editor to make a better book. The editor has published more books than any except the most prolific author and will be able to make good suggestions for the most part. On the whole, editing is a negotiation between what the editor feels will sell better and what the author sees as his "art".

[ Parent ]
Yes and No (none / 0) (#54)
by bugmaster on Sat Jul 30, 2005 at 07:52:18 PM EST

I think that at least some books are produced in an analogous fashion to games. Last I heard (for example), Tom Clancy had a crack team of hack writers churning out titles in his name; I'm sure there are others.
[ Parent ]
Don't even fucking mention Net Force (none / 0) (#61)
by jeremyn on Sun Jul 31, 2005 at 05:34:48 AM EST

I've read every real Tom Clancy book but that series is a fucking joke. The writers are worse than Dan Brown.

[ Parent ]
Quote from Stephen King (none / 1) (#49)
by SocratesGhost on Sat Jul 30, 2005 at 03:42:53 PM EST

"To write is human. To edit, divine." No one is immune from the editing process.

I drank what?

[ Parent ]
Yes (none / 0) (#70)
by ucblockhead on Sun Jul 31, 2005 at 06:53:38 PM EST

But some authors think they are.
This is k5. We're all tools - duxup
[ Parent ]
games are for kids (1.26 / 15) (#2)
by fark is a piece of shit on Fri Jul 29, 2005 at 12:01:15 AM EST

stoners, and the unemployed

and public transport.. (2.00 / 3) (#16)
by QuantumG on Fri Jul 29, 2005 at 07:54:21 AM EST

is for jerks and lesbians. Why you gotta hate?

Gun fire is the sound of freedom.
[ Parent ]
Or jerking lesbians. (none / 0) (#75)
by Russell Dovey on Wed Aug 03, 2005 at 07:02:09 PM EST

Wait, I guess that misses the... Yeah. Damn.

"Blessed are the cracked, for they let in the light." - Spike Milligan
[ Parent ]

STOP H8IEZ :( [nt] (1.50 / 2) (#36)
by Pat Chalmers on Sat Jul 30, 2005 at 01:06:21 AM EST

[ Parent ]
Good article, (none / 1) (#3)
by AlwaysAnonymized on Fri Jul 29, 2005 at 12:15:56 AM EST

the first in this queue in well over a month.

me too! (none / 1) (#9)
by nkyad on Fri Jul 29, 2005 at 02:20:35 AM EST

I agree, probably the best article since "Fuck" and "Fuck-back".

Don't believe in anything you can't see, smell, touch or at the very least infer from a good particle accelerator run

[ Parent ]
My own idea for a game. (2.78 / 19) (#17)
by NoMoreNicksLeft on Fri Jul 29, 2005 at 09:14:18 AM EST

Since it sucks, I'll post it here and if someone steals it, I'll just be flattered it was made.

Title: Bull in a China Shop

Concept: Think Pacman but with interlevel cutscenes and 1992 graphics.

You're a bull. You can run up, down, left and right, grabbing powerups when they appear like "Mad Cow Disease" and "Bovine Growth Hormone". You run around trying to smash all the merchandise in the shop, which takes up the left 3/4s of the screen, while a gay shopowner chases you around with a broom. Every level he rebuilds, and you start over. New enemies chase you... level 2 adds cowboys. Level 5, matadors. Level 10, animal control officers.

There are other possibilities, such as two-story levels, perhaps we can even have animal rights protesters, vegetarians and hindus protest outside the store. You crash through the plate glass, gore them for bonus points when they appear.

And the theme music, gonna be hard to find the right band for it. Needs something like a country-western TMBG.

Finally have a decent machine to develop on, and I'm more than a little familiar with SDL now... only excuse for not making this has to be that I'm a loser. Even pure laziness doesn't explain it completely.

Do not look directly into laser with remaining good eye.

a country-western TMBG. (none / 1) (#22)
by wiredog on Fri Jul 29, 2005 at 10:51:38 AM EST

Big & Rich.

Wilford Brimley scares my chickens.
Phil the Canuck

[ Parent ]
That sounds pretty funny actually (3.00 / 4) (#24)
by LilDebbie on Fri Jul 29, 2005 at 01:57:49 PM EST

Might make for a good shitty flash game of the caliber seen on newgrounds.

My name is LilDebbie and I have a garden.
- hugin -

[ Parent ]
This gets rated 1.5? (2.00 / 4) (#29)
by NoMoreNicksLeft on Fri Jul 29, 2005 at 07:05:09 PM EST

It was a genuine concept, marginally on topic, and in no way offensive that I can see. Excepting of course, one of you being a gay china shop owner.

Which one of you assmonkeys zeroed me?

Do not look directly into laser with remaining good eye.
[ Parent ]

Meet our new random moderation script (3.00 / 4) (#33)
by nkyad on Sat Jul 30, 2005 at 12:26:14 AM EST

One get a new one each year - they usually get tired   just after Christmas. The main point is that you must not to pay attention to them. Other will correct its worst mistakes and this year's model even give occasional 3s and 2s - in the past years they only gave zeros.

Don't believe in anything you can't see, smell, touch or at the very least infer from a good particle accelerator run

[ Parent ]
I like it (3.00 / 2) (#53)
by smallstepforman on Sat Jul 30, 2005 at 07:39:20 PM EST

Hey, it's original, and sounds like FUN. Good idea, man. Even Grand Theft Auto sounded weird when it was first propesed, yet look at it now. And GTA **is** a fun game.

[ Parent ]
wesnoth is a successful open-source game (2.50 / 2) (#20)
by waxmop on Fri Jul 29, 2005 at 10:00:15 AM EST

Battle For Wesnoth is a hex map, turn-based strategy game that's got a pretty big group of fans. There's a whole bunch of community-submitted campaigns and units, and the developers interact on the forums with users all the time.
...if [outer-space trolls] did exist, SETI would be up to its arsehole in goatse jpegs. --
And the only reason it's successful (none / 1) (#55)
by X3nocide on Sat Jul 30, 2005 at 09:39:00 PM EST

is that it clones an old game called "Master of Monsters" or something.  And it's really not even that good compared to say Ogre Battle or Advance Wars.

About the only good open source games I know of are from Kenta Cho, and a lot of people think the graphics are stupid. I suppose it takes an analytical mind to appreciate the primitive geometry focus of openGL and his games.

[ Parent ]

Another possible reason (none / 1) (#71)
by Mathemagician on Sun Jul 31, 2005 at 10:28:09 PM EST

Actually, it does follow alot of the advice in this article.

[ Parent ]
Wesnoth isn't a 'clone' (3.00 / 3) (#74)
by Sirp on Tue Aug 02, 2005 at 10:23:14 PM EST

Wesnoth doesn't clone Master of Monsters. When I first designed it I took some ideas from Master of Monsters, and other games such as Langrisser.

However it doesn't 'clone' any game the way, for instance, FreeCiv clones Civilization II. It's a completely different game with a different setting, different game rules, and so forth.

If it's a clone of Master of Monsters then the entire Warcraft series is a clone of Herzog Zwei and Diablo is a clone of Rogue.


[ Parent ]

Good work (none / 0) (#79)
by coljac on Fri Aug 05, 2005 at 08:41:10 PM EST

Great stuff, dude. I really admire your "KISS" discipline, the results are a lot of fun.

Whether or not life is discovered there I think Jupiter should be declared an enemy planet. - Jack Handey
[ Parent ]

Great game (none / 1) (#78)
by coljac on Fri Aug 05, 2005 at 08:40:09 PM EST

I tried it based on your recommendation, and I'm hooked. It's simple enough that you can understand what's going on, complex enough for real tactical interest. Great! I'd happily have paid for this game.

Whether or not life is discovered there I think Jupiter should be declared an enemy planet. - Jack Handey
[ Parent ]

What about... (2.50 / 4) (#25)
by dasunt on Fri Jul 29, 2005 at 02:24:01 PM EST

Wouldn't games like ADOM and Dungeon Crawl (both by single developers, AFAIK), seem to discredit your ideas about big games being unworkable?

Unless you consider the lack of graphics to be a large enough time-saver that it doesn't matter. OTOH, I remember a few indie one-coder RPGs that seemed to have decent scope.

They started small (none / 0) (#66)
by jimrandomh on Sun Jul 31, 2005 at 02:27:01 PM EST

Both of those games started small, shipped, and incrementally grew bigger over a very long period of time. And that, really, is the only way to make a big, complex game: by making a small one first.
CalcRogue: TI-89, 92+, PalmOS, Windows and Linux.
[ Parent ]
-1 Author doesn't know what he's talking about (1.27 / 18) (#26)
by Tex Bigballs on Fri Jul 29, 2005 at 03:18:09 PM EST

...but you may spend two weeks writing and optimizing a custom binary search tree while a programmer might just call a prewritten hash table function and be done in five minutes.

5 minutes or 2 weeks you say???

+1FP, doesn't suck. (none / 1) (#35)
by Pat Chalmers on Sat Jul 30, 2005 at 01:05:39 AM EST

More of the same (3.00 / 3) (#39)
by bugmaster on Sat Jul 30, 2005 at 03:37:31 AM EST

I am not a game developer at all, but I do play games a lot. I think that your article will greatly help any budding game developer to become a pro, and to create games which will sell well. I won't play these games, however.

Yes, if you try something new, and/or something complex (such as, gasp !, a nonlinear adaptive story), you might fail miserably. But you might also make Planescape Torment. Most likely, though, you'll fail. It's a much safer bet to make some sort of Madden NFL ESPN Golfball 3000 N+1, and watch the cash pour in.

I think the biggest problem with the gaming industry today is that developers are too concerned with marketing and "getting cred"; in fact, the system has so much inertia that no serious game developer would ever take even the slightest amount of risk.

Which is why the only truly playable games come from indie developers, and one-off windfalls like TLJ 2, which actually got a grant from the Norwegian Film Fund to continue their work; basically, good games come from people who take risks. Most other games are cookie-cutter profit-generators; good for game developers, bad for gamers.

Let's hope that independent game developers don't read k5...

Be creative in what you do (none / 0) (#72)
by Chris Canfield on Mon Aug 01, 2005 at 08:34:37 AM EST

Until reading it on the front page, I didn't realize how much it looked like I was saying "don't be creative."

What I meant, was be creative within your means.  Savage is a tremendous game with a larger development house behind it than most first-time developers will ever see.  And it is a genre bending FPSRTS.  But as an RTS, it is a lot smaller than Warcraft, and as an FPS it is a lot smaller than Unreal Tournament.  It doesn't feel small because the game was incredibly rich and well executed, but the scope of the game was reduced over other games within the two genres to keep the design within reason.  Some of the most creative indie games out there are completely abstract to keep art resource times down on highly creative designs.  Other times things are cut out of single player, multi player, etc.

A lot of times people are creative by attempting to add things to a genre.  But ultimately, when you add things you also have to subtract things to stay within scope.  Even Half-Life 2, with grand vision and amazing artwork, had a tacked-on multiplayer mode.  Remember to cut unnecessary features when you're creating amazing new ones.

I should do an article on tips on how to be creative in the pressured, structured world of game development.

[ Parent ]

+1FP (2.50 / 4) (#47)
by What Good Is A 150K Salary When Living In NYC on Sat Jul 30, 2005 at 12:21:25 PM EST

I mean, I didn't even read the article or anything but I was scrolling through it and I saw a hyperlink about the Nintendo Entertainment System (NES) game The Adventures of Bayou Billy which features like, some of the most premier computer speech to ever grace the NES when you start up the game and the game logo flashes. The intro machine speech sounds like this basically "The Adventures of Bayou Birry!" because like, probably Japanese people programmed and wrote the game's story and all. Anyhow, I own this game and it is a steaming pile of shit that used to test my childhood temper as I would flip out when I would get my ass kicked in the game. The same phenomenon happened to me in Contra because I would always lose at Contra because I sucked at that game. Now that I think about it, most NES games tested my kiddie temper and threw me into mini-tantrums because I like fucking couldn't get past the third or fifth stage in Gradius. At least I think that's the furthest I ever got in Gradius.

Skulls, Bullets, and Gold
The solution to all lifes problems (1.50 / 2) (#48)
by fatbobsmith on Sat Jul 30, 2005 at 03:14:20 PM EST

Up, up, down, down, left, right, left, right B, A, Start

[ Parent ]
lol!!!!!!!!!!!!!!!!!! (none / 0) (#77)
by kbudha on Fri Aug 05, 2005 at 11:38:01 AM EST

[ Parent ]
Good indie game developer resource (none / 1) (#50)
by dustinQ on Sat Jul 30, 2005 at 03:49:23 PM EST

The IndieGamer forums are an excellent resource for anyone interested in making games.

I know this guy (none / 0) (#51)
by kallisti on Sat Jul 30, 2005 at 07:24:42 PM EST

It sounded interesting. It sounded exciting. It sounded like an epic so grand it would put Cleopatra to shame. And it sounded utterly, utterly impossible to make. I won't single out the budding designer here for ridicule, but he had created a story so grand, a world so rich, that it would take a team of thousands several years to create. He, of course, had only himself, and no idea what to do to start.

Isn't it time to stop picking on poor Dr. Derek Smart?

No, never. (3.00 / 2) (#56)
by cburke on Sat Jul 30, 2005 at 11:21:50 PM EST

It will never be time to stop picking on Dr. Smart.

[ Parent ]
Nice article (3.00 / 2) (#52)
by SeanReardon on Sat Jul 30, 2005 at 07:26:56 PM EST

Thank you for writing this.

I think it's interesting that you start off the article speaking to the person who is entirely outside the industry ("I'm going to make an RPG with 3,000 enemy types..") and end up making fairly subtle points to an audience that's basically a full start-up ("You don't want to bring people in on an emergency basis...").

You're absolutely right to suggest that the industry has no clue how to make games.  The company I work for has put out 7 games over the course of 6 years, and we still have no idea.  There is still just so much improvement
to be had...

I tend to be more involved in the end of our projects.. I'm the sort of guy who helps ship, or close, titles.  So I'm fairly in tune with the "Ship it" mentality.  I'd actually go a little further than this.. I'm now of the opinion that the act of shipping a game (perhaps the act of RTMing any creative work), is fundamentally the
act of putting down the work with disgust and saying "fuck it".  Which is a dramatic way of suggesting that you can't send anything out the door without utterly giving up on trying to improve it.

Case in point, we've shipped a good number of titles.  Some of them were received pretty well.  Not one of them have we ever really been truly happy with.  We've shipped titles that we thought would be really embarrassing and had them be hits.

The result of which is one of my philosophies toward game development:  Toward the end of the cycle, you need to stop making a game and start making a product.  It sounds really obvious, but truly it suggests very different mindsets.

Sorry, dude ... (3.00 / 10) (#57)
by dn on Sun Jul 31, 2005 at 03:22:32 AM EST

Take your most basic game ideas, and make them smaller and smaller until they can't physically get any smaller.
... but Progress Quest has already been written.

    I ♥

Oddly compelling. (none / 1) (#76)
by grendelkhan on Fri Aug 05, 2005 at 08:25:51 AM EST

Why is that so addictive? I'm not even doing anything, but I keep staring at it!

-- Laws do not persuade just because they threaten --Seneca
[ Parent ]

I'm going to have to disagree (3.00 / 2) (#58)
by Sap on Sun Jul 31, 2005 at 03:34:27 AM EST

As an indy game developer (Wolfire) I'd like to add a few things. Indy game programming is definitely doable - it is not as hard as many people think. Lugaru was made in about one year of intermittent work by my twin brother 100% by himself. If you know what you're doing, it's not really a big deal.

The reason why the vast majority of indy games fail can be simplified to the following reason: the developer ultimately sucks and does not have any real skill set to speak of. On gamedev.net and other sites, many of the psuedo-dev teams consist of 14 year old fan boys who have never programmed anything in their life.

Cool article... (3.00 / 1) (#62)
by skyknight on Sun Jul 31, 2005 at 08:23:17 AM EST

This is the kind of stuff that made me start reading K5 years ago and has been sadly lacking of recent. I'd love to do game development, but there are so many things that I want to do and only so many days in a month. Also, I've heard that most jobs at large game design shops can really suck. A friend of mine who has a friend working at (I think) EA described his experience as basically serving as a post-processor for code that is auto-generated by tools, and furthermore said that deadlines made the job a real death march. As such, if I ever were to go into games it would probably be to work on an independent project, and probably just as a part time hobby done in my spare time to learn new and interesting things, much the way some people do wood-working in their garage. I might end up making something that people would want to play, but I wouldn't be setting out with that as the main goal.

It's not much fun at the top. I envy the common people, their hearty meals and Bruce Springsteen and voting. --SIGNOR SPAGHETTI
Strongly disagree... (3.00 / 2) (#63)
by Bouzouki Mike on Sun Jul 31, 2005 at 10:36:38 AM EST

...on several counts. "It'll be finished when it's done." Freedom from publisher-imposed deadlines is a good thing that indies can use to their advantage. Obviously there's a trade off between development time/cost and the quality of the end result and yes, discipline is required to choose the right balance. That's no reason not to reevaluate how you balance this from time to time, as your game develops. If you don't have the disciple to make hard-headed decisions about this then you're probably not cut out for this line of work anyway. "I don't understand this. I'll figure this part out as I go along." Nothing wrong with that. Low production values give you a huge amount of freedom to experiment. This is a good thing.

Open Source Game Development (none / 1) (#64)
by ill on Sun Jul 31, 2005 at 01:08:59 PM EST

I think this is a great article, and should be of help to some budding indie game developers.

On another slightly different note, I know of some open source games, and feel working on an open source game (or starting one) could be a good step ladder to commercial game development, or finding a group of people to help with independant game development.

So you first game will be free (as in beer), but its a start (if your worried about profit).

Why Setting? (3.00 / 4) (#67)
by ChaosEmer on Sun Jul 31, 2005 at 03:37:09 PM EST

So many game designers start out with the setting and story, and then put in the controls and gameplay as an afterthought. Why is this? You're designing a video *game*, not a video movie. I can think of many games that were ruined because the actual actions the player does was put in as an afterthought. But I can't think of any games that were ruined because the setting and story was put in as an afterthought.

Depends on the people (3.00 / 2) (#68)
by ZorbaTHut on Sun Jul 31, 2005 at 04:52:25 PM EST

It doesn't necessarily take 50 people a year to make a game. I've been involved in a (commercial, PS2) game that had about 10 people for a year. It can be done - you just need very good people, of course.

How we did it and what we've learnt (3.00 / 9) (#69)
by Fuzzwah on Sun Jul 31, 2005 at 05:49:24 PM EST

I'm the project manager and PR pimp for a HL2 total conversion called Dystopia. It's a cyberpunk action FPS that promotes team play and tense situations. It's unique feature is the dual environments of the realworld and cyberspace.

We've been working on it for two years, we've had a team of 20 people contribute along the way but most of it's development has been driven by a group of 10 guys. We all work on the game in our spare time, along side real life jobs and real lives.

I'm about 50/50 agreeing and disagreeing with this article. The first 3 points I don't agree with, the last 3 I do.

1) "I'm going to make a big complex game"

I disagree with this. You need to make a game you love. Not only that, everyone on your team must love it. Being worried about biting off more than you can chew is such a defeatist attitude. Dystopia is complex and deep and packed full of features. If it wasn't then I wouldn't love the game enough to have dedicated 2 years of my life to it.

Indie game dev rocks because big professional game developers can't take risks. We can. But you need to use all the advantages open to you. Pro games take 5 years and US$10 million to make. But they make their own engines. Are you better than Carmack, Sweeney and Dassault? And you've given them nearly 10 years head start on coding a kick arse engine. Why on earth would you want to create your own engine?

I think a better point 1 is: Be realistic and understand how much work you're in for. Find ways to make it less work.

2) "I've got my design in my head, and now I just have to make it."

The article author is too stuck in the old publisher system. Why would you want to opt into a process like this:

People have said that game development is the process of hacking out a demo to entice a publisher, polishing the demo for E3, then polishing the E3 demo for sale. It's a series of little and big milestones, and deadlines where everything has to work perfectly.

Go read about the rant Warren Spector made during the "burning down the house" session at GDC. But then have a read about the various digital distribution systems which are available; such as Steam and GameXtreme. There's this whole yin yang, crissis / oppertunity thing about to happen. The games industry is dead. Long live the games industry.

But then I really agree with what is said in the article here:

Take the time to figure out how long each part of your development will take, breaking it down further and further until you are at about week-sized chunks. Your development map may be completely wrong, but if you don't have a map of some sort you can't know if you're making progress.

But if you're removed from the issue that these "milestones" are required so you can get some more cash from the publisher and feed yourself and your family, this is simply called "prototyping". I believe the single best piece of advice for wanna be game developers is quite simply; prototype, prototype, prototype.

3) "It'll be finished when it's done."

You use Daikatana as an example of something that it was not. Yes, at the beginning of the project Romero trumpeted "when it's done", but in the end it _was_ forced out the door by the publishers. Seriously, go and look at Romero's own timeline of Daikatana's development. There's a whole year he writes off as "Much griping and jackin' around; politics and poison are everywhere." Sounds like a bad acid trip not an indie game dev process.

To counter your point I could pull up any of the hundreds of games which have slipped past their estimated release date. As indie's our greatest freedom is not having a publisher leaning on us saying "we've got share holders to keep happy" and forcing you to ship an unfinished product.

We're set to release Dystopia "When it's done. Which is soon". I truly believe that there is simply no other way to run a project like this. Even professional game devs, who all go into an office and work for 8+ hours a day, slip on milestones. I'd much rather have whining from few fans who don't understand what "making a game in your spare time" means, than to piss off every one of your hardcore fans by slipping past a guessed release date. It's a simple rule; don't promise anything. Pimp when you have something, not about how cool it'll be when it's finished. Pimping > Hyping.

With this said, we have made the distinction between the normal development process we were in and the shipping process we are in now.

A better 3rd point: There's a human element to making a game; know your team and know what you can expect from them.

4) "I don't understand this. I'll figure this part out as I go along."

Every single person that has worked on our project has learnt things and picked up new skills. Our lead coder has learnt C++. One of our artist joined us as a modler who couldn't skin, but now is perhaps the best character texture artist I've seen.

Yes, people work on a game to make a game but they're also doing it to improve their skills. If someone doesn't want to continuously push themselves they're not going to be a driving force in your development. Sure they might do some good work for you, but it's only the guys who jump at every new challenge that will be a continuous driver right through the project.

A better 4th point: Know your strengths and focus on them, but don't be afraid to learn something new.

5) "I have a binder full of 300 pages of design documentation"

Gabe Newell taught me this. Valve flew us over to Seattle from AU to show them Dystopia and have a chat about possibilities. We stepped off 20 hours of flights to be met by Gabe in their offices. I had with me a 20 page design doc and had expected to hand this to Valve so they could understand our game. This never happened. Gabe sat us down and asked us a very simple question; Why am I going to play Dystopia?

You need to be able to answer this question. You need to be able to sum it all up in a nice little monologue. This isn't saying that your game can't have depth, just that from the overview and just the tip of the iceberg you've got to have hooked someone in on the idea.

You still need the design written down somewhere. You will need to point team members to it so they can get a deeper understand of what they're working on. Also realise that the design doc is a evolving thing.

A better point 5: Why will someone play your game?

6) "I'll just do it all myself."

Making a game is a team effort, I totally agree.

Our lead coder has done little bits of everything throughout the project. Infact, there is nothing like some dodgy "programming art" to spur the real artists to replace it with something good.

The project leaders _have_ to understand the work involved with every single part of the game. You don't need to be good at it, you don't need to plan to actually do the work yourself; but you've got to have a clue as to what's involved.

Fuzzy's point 6: You need to be aware of all the work involved with making a game.

As well as the advice above, based on my experience this is the list of tips I'd give to indie devs:

1) Prototype, prototype, prototype.

Your coolest most favourite idea could very well suck when you actually playtest it. If this feature has just taken you 6 months to make, it's obviously very hard to realise that it sucks and to scrap it.

2) Know your market.

There's no such thing as an original game idea. Every new game is influenced by games which have come before it. Learn from these games. What did they do well? What did they do badly. Learning from another developers mistake saves you from screwing the pooch in the same way.

3) Communicate.

You need someone on your team who is an excellent communicator. You need an external and internal spokesman. Someone who can make sure that everyone on the team has a clear picture of exactly what they're making. Someone who can make the fans wet with anticipation.

2ndary to this; use multiple mediums for staying in touch with your team. Get their phone numbers. Ring them up and ask them how their day was. Organise a BBQ. Drink beers together. Use IRC, email, IM, forums and online voice communications (like teamspeak or ventrillo). Talk. Lots.

Finally; if you've got a great idea for a game and the will power to see it through, make it. Download someone's SDK and make that first little change. Then another. Repeat this every day for as many days as it takes until it's done. The coolest thing is, you get to play test right the way through. If you've just read through this monster post then obviously you're damn keen on computer games. So I'll say this knowing that you should be on the edge of understanding it: you have not lived until you've beta tested your own computer game.

The best a human can do is to pick a delusion that helps him get through the day. - God's Debris

My tips... (3.00 / 5) (#73)
by Saggi on Tue Aug 02, 2005 at 05:10:05 AM EST

A very interesting article, that gets better with the comments of Fuzzwah.

I have been involved as lead programmer for several commercial games, and done some free games on my own as well. My most advanced piece of code is my Flight Simulator, build entirely by my self over a course of 6 months, using only my spare time. (It can be downloaded from my site (link above) - and includes some sourcecode and articles of how I work as well).

Now why did I make it? I love games, but usually when I have played for some time I become more interested in how they work, than the game it self. Just like someone who fixes their own car. This is called motivation. In my opinion you always need motivation in order to manage you projects.

When you are hired to do a job or when you work for free in a team or on your own, the quality of what you make depends on you motivation. If you (and your team) are not motivated, the game will become crap. Of cause the salary might be a motivation but in the game industry you get a better game if you are motivated because you love the game itself.

Roadmap and components
An other very important thing in my opinion that is left out of the article is in regards to breaking down the components of the game. The article briefly talks about the roadmap. I really agree to this concept, but my experiences has shown that the way to breaking down the single components may be done in several different ways. Some better than others. Ant the breaking down of the project is the core to success. Here I totally agree with the article. Not that you (only) need milestones to measure progress, but you need to be able to see the road to the goal! If there are parts that don't work or you can't figure out how should work, you really have a problem.

But here comes the clue. The components might be slightly changes to allow for an other road. The new road might be completely different than the old one, but might cut months of your trip to the goal. This is better than getting stuck in an impossible part of the game.

You need to minimize you development time or you will never finish. In the flight simulator I have an engine to draw "objects" and an engine for the "terrain". Now if you fly into the terrain you crash, but you might fly through objects (like towers and hangars). The reason for this is that it is fairly simple to make a rough estimate about when your plan goes beneath the ground, but objects don't necessarily have simple surfaces. So I left it out and used my time on some other stuff. So I skipped some realism (in the real world you can't fly through a hangar wall, you know) but could use my resources on some more interesting pieces.

It all comes down to Illusions. Your game is not a copy of the real world. It's an illusion. If you can make something that looks and feel like than real world, but is much more simple (in terms of coding etc.) you might succeed.

The Pearl
No two projects are the same. You'll probably need to find your own path. But these two articles give you some good clues about how to proceed. Fuzzwah's comments states you'll need to prototype, prototype and prototype. I'll totally agree. Think of you game as a pearl. It stats like a grain of sand, and then you add layer after layer to make the pearl. Your project needs quickly to get a grain of sand to add layers to. Make a simple core engine for the game. It's much easier to develop when you have something to look at, even thou its crude and simple. For me the most important milestone in any project is when the first crude parts can bee seen on the screen - even thou its only some simple lines and polygons - from there its going forward towards your goal.

-:) Oh no, not again.
I hate to burst your bubble but... (none / 0) (#80)
by qwertyuiopasdfghjkl on Fri Aug 12, 2005 at 06:18:25 PM EST

<rant> I havent read the source article you are refering to, but from the quotes you have included in your article, the game being described could easily be Guild Wars... And that game obviosuly didnt take 1000 years to make. Maybe you should take your head out of your arse, and figure out ways to make designs with large scope workable instead of spending all your energy shooting them down... and as for you and your friends that have been "studying" some sort of unified theory of game design, you're failing to realize one important point.. schools dont teach creativity, and imagination... and the game industry kills innovative thinking... </rant>

more tips (none / 0) (#81)
by dark ally on Wed Sep 14, 2005 at 11:41:12 AM EST

Some suggestion from a homebrew programmer for obsolete consoles:
  1. Know why you are doing this, and the answer better not be "for the money".

    Two of the great freedoms of indie/homebrew programming is you aren't on a release schedule and you're not trying to put food on the table. So do it to build your "cred" (and maybe get a paying job doing it), or to increase your skills, or simply because you have fun making a game.

  2. Top down design, bottom up programming. Start small with the most core, critical & unique parts, then layer, extend & add-on.

    Similar to the milestone, prototype & pearl suggestions you have to start somewhere & the packaging isn't it. You need to break down your game into it's critical path components (i.e. those parts which have to be there or it ain't gonna fly) which distinguish it from other games.

    Note: it may be that some of those components, like 3-D engines, may be obtained elsewhere. That doesn't make them any less critical. In fact, you have to ensure there is something which distinguishes your game from any other which uses the same "off the shelf" components. Otherwise you're just making a mod.

  3. Playtest the hell out of the game, both inside the creation team & outside.

    The game ain't nothin' unless it's fun to play. Your concept & vision may have called for something, but if no-one likes it then you should seriously consider changing it. You should always be looking for ways to make the game more enjoyable, though beware for the feeping creatures.

  4. One person can go it alone, you just have to set your sights a little lower.

    There's lots of homebrew games for older consoles & computers (think 8-bit generation) which have been done by one person. There are also lots of Flash games by a single person. You just have to accept that one person (or even a small team) can't compete with a fully funded commercial effort head on.

  5. Even if you are going it alone, find a support community.

    Although it may take some searching, find other people who are doing similar things. (i.e. same tools, engines, platform) Share your experiences, ask questions, and peer review.

  6. Don't forget the cost of your tools.

    Another place where older consoles & computers have the advantage is the tool chain is often no-cost. There may be cheap or free development kits & engines out there, but paying big bucks for an SDK is probably not a good idea.

The 6 Indie Mistakes | 81 comments (51 topical, 30 editorial, 0 hidden)
Display: Sort:


All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!