Yes, a very good article, once you context it that he is talking more about mainstream 3D, FPS/RTS type games.
His first step is establishing the support routines for the accomplishment of the mundane. He misses a bit on those needing to be resuable, either as they stand or easily EXTENSIBLE. The idea is a good core library should be able to be used in titles 10 years from now.
His second step, build your art assets. Well, he's really talking about the level designs and video in FPS/RTS titles but it applies here, too. Alas, folks with good back end designs are usually not artists at all. Problem is artists are a touchy lot, and like to do stimulating work like anyone else. We heard from a Matrix GA here a while back claiming boredom at having to do WIN32 widget painting art.
Last step is where the time is supposed to be place. Not in mundane coding like playing sound files, calling drawing routines, capturing user input, saving games, handling mouse-clicks, etc....
In pitfall #1 he states :
"You need to get through technology development as quickly as possible. If you disagree with this statement, you care about something else besides finishing your game. "
What quicker way to get through the technology development quickly that use code somebody else a lot smarter, more experienced, and more highly tested than third party toolkits and class libraries to deal with such mundane crap as collecting data from the user via the UI. These kits are UBIQUITOUS. But, according to one of our friendly Matrix graphics guys, doing the graphical overlays for that is "boring". And he's entitled to have some fun on the job, too, right?
Pitfall #2 is the pipeline....collecting and developing the content. While he's talking about getting your music, artwork for your levels, level designers, etc...in this genre, in this game, in particular, he's probably talking about the OOB and accompanying component bitmaps... He calls it "pipeline bloat".
#3 is essentially a rant on how to make your lower level components RESUABLE by avoiding too much dependency. Nothing too cosmic there. If you are finding you are throwing away 80% of library code with each new game, well, you've skimped on Step 1 and proably fell into Pit #1 too much.
And #4 is why, if I ever get around to getting somewhere with my own efforts, it will be a re-make of something like North Atlantic '85 with 10-12 bases, a ahalf dozen aircraft types on each side and maybe a dozen or fewer ship classes, and no production, no visual or audio bells and whistles, bascially "not much".
About three years ago a two man team put out a very simplistic, bargain basement, WWII European theater turn based game. Used a basic WIN32 GUI not DirectX video or audio. Sold for something like $19.95 via download. Had an uncannily addictive game-play though. And you could play the entire main campaign in a weekend! Sold 75,000 copies in the first year.....got a 88 rating in PC gamer. I emailed the guys and asked them what they did and if they made any money, themselves off it. They used Visual C++ and MFC for the GUI, used "off-the-shelf" clip art for bitmaps and backgrounds, no digitized maps or anything, just played .wav files for sound, took only about 8 months to pump it out. They each claimed their take was over $100,000 EACH for 8 months of work.... (Is 10-15% of the gross a typcial "take" for the developers?....so ignorant about side of this business...) And they claim it more of hobby as each claimed to have a "day-job".
Don't know how truthful that was, but that's what I call an "Exploration Game"! Essentially they followed this article's formula to a "T". MFC was the Step1, technical foundation (someone else's expertise), public domain clipart the step 2 "art assets". And their efforts spent almost 100% on steo 3, a fun gameplay engine! And they avoid all the pitfals. And while almost everyone here would find that game "pathetic", it was a turnbase wargame, it sold a near six figure copy and actually made someone REAL money.
Lesson. Don't believe everything you are told.....on either side of an issue.
