If you have some comments or other points to add to the ones I made, lemme know. DevGames is gonna add a discussion forum RSN, so hopefully we'll be able to eventually have a threaded discussion on these topics. Until then, however, I'd like to hear if you've got any red bullet-points of your own to add. While I've worked on a dozen small game projects, I've never been on one of those large-scale games. If something I wrote applies differently to a bigger project, lemme know.
Here are a couple more points that came to mind. If I get enough of these, I probably ought to put 'em together into an article. We'll see.
One-man games can still be done, but not huge stuff. Know the limits (not just your limits).
This is something I used to see in rec.games.programmer. It seemed like every other thread was something akin to "I'm wanting to start writing games. I was planning to start out with". . .followed by a description of a StarCraft or Quake clone, only bigger in scope.
As an analogy, imagine for a second that you are a builder who wants to build something that's uniquely yours, so you decide to build the entire project yourself. No matter how talented and hardworking you are, you cannot build a shopping mall --it's simply too much for a single person. If you're good enough, however, you might be able to build a house. If you do manage to build a house by yourself, that's a feat which deserves respect, even if it's not a shopping mall.
If you're planning to do a game by yourself, keep your sights lower than the top-shelf stuff. For my games, I do all of the design, programming, graphics, animation, sound, and documentation. My games, however, are MS Game Pack class stuff, not StarCraft class stuff. Large-scale stuff requires the effort of dozens, if not hundreds of people. You can't do all that yourself.
Look outside your genre.
If you're reading this, you're probably an 18-40 year old male, as that's the general profile of game programmers. Interestingly, it's also the intended audience for most of the top-shelf game titles. Computers owners, however, are not all 18-40 year old males. Computers are being used by 12 year-old girls, 60 year-old grandfathers, 30 year-old housewives, and toddlers. If you decide to write only games that you like to play, you might be missing a very good opportunity to sell some games in a more receptive market.
Imagine for a second that there was very little variety in available cars --all cars are 4-door sedans. Everybody could certainly use them, but not everybody would be happy with such a limited choice. Parents with several children would rather have something with more seats. A student might want something smaller with better mileage. A builder might want something that could haul a load of lumber. Unfortunately, there aren't many cars like that, because the engineers design 4-door sedans. After all, that's the kind of car they like.
Of course, that's not how things work in the car market. Engineers design cars that aren't necessarily made with them in mind.
Take an honest assessment of your skills. Know where you suck and where you're good.
If you can't draw your way out of a paper bag, hire out your art. If you have the grammar skills of a chimp, hire out the documentation or get a proofreader. If you don't have any QA skills, hire someone with QA skills to break your games. Cheesy art, bad grammar, or bugs will make an otherwise professional-looking title look like bad shareware.
Conversely, if you're a terrific artist, make your game graphics heavy. If your language skills are top-notch, go for something with a lot of story. If you have a knack for writing stuff with zero bugs, consider writing libraries for other people.
If you add these points to the list on 1/14, that makes 8 points. Maybe I'll write just two more, so I can make one of those trite "Ten Commandments of Game Development" articles. Either that, or I continue until I hit 75,000 words and then submit the whole mess to a book publisher :)
