Reality Panic

Maybe instead of just stating your opinion if you could find a company that followed the practices you mentioned and managed to put their game out on time and it was actually any good, both a market and critical success, then maybe people would take your idea seriously.

Unfortunately, most of the methods discussed for making game engineering more predictable generally ignore the fact that games do not have the same types of requirements for which those ideas actually fit.

<a href="http://www.joelonsoftware.com/articles/FiveWorlds.html">http://www.joelonsoftware.com/articles/FiveWorlds.html</a>

You can specify that a backend app is done when it completes the desired function. A game on the other hand is done when it's fun and looks like it will sell. One is definable, one is not.

There are things we could do. Nintendo claims to plan with a small team of 4 to 5 people for 1 to 2 years. I'm assuming that's 1 or 2 designers, 1 or 2 artists, and 1 or 2 programmers and that they use existing code to test out ideas and concepts to see what's fun, what works, then they plan in detail what the game will be and only when they finish do they put a full production team onto the project.

<a href="http://www.miyamotoshrine.com/theman/interviews/030703.php">http://www.miyamotoshrine.com/theman/interviews/030703.php</a>

Unfortunately I know of no publishers that would give any 4 or 5 people funding for 2 years to do such a thing even if it does seems like an awesome idea.

Of course maybe this is where independants come in. Someone with a lot of free time could spend their own 1 - 2 years playing around with concepts in say the Torque engine, DarkBasic or BlitzBasic and then make a detailed and proven design, show it to a publisher and actually possibly make something on time and on budget that was good. Sounds like a perfect opportunity.

True, I cannot point to any shining examples - but that does not mean they are not out there... Although the Gama XP article did point to some success stories. I suppose my "proof" is more anecdotal...

However, I still stand by the fact that a methodology such as XP that is based on short iteration cycles and quick testing is a good approach for hard-to-spec game development (ie, code, test, is it fun, code, test, is it fun, etc)...

Jason has asked me to comment. We've had some huge productivity gains in our projects so I'm not talking completely out of my butt.

I'm no fan of XP. Read McConnell's comments in that wired article. He's right. And even if XP was just right for a particular project, its not going to be the most efficient approach for all people, for example a competent, experienced software engineer. I know, I've often been the sole programmer on our projects and I've achieved very high productivity and very low bug levels.

One game developer I came to know well used XP religiously. After some 3.5 years of funded development (not counting an earlier 1.5 years of prototyping in their garage) their 4 programmers had something 70% finished that was entirely unmarketable. They had clean, bug free code but they'd failed to identify the big issues early on. For example their chosen middleware graphics API turned out to be way too slow. They'd used a bunch of STL inappropriately and it was also killing performance. While they'd put in cool bits of graphics features, they still hadn't implemented many of the gameplay features. So the level designers had been building complex, detailed levels all this time but had never tested gameplay on any of them. XP hadn't done for them what even a small amount of intelligent up front high level design, prototyping and planning would have. And even if they'd dealt with these issues properly, what they had for their 14 man years of programming didn't look like a productivity boost to me.

Its difficult to express my approaches to increasing productiviy, in part because each project needs its own approach. Here's some things that have worked well for me in the past, and yes much of it seems obvious.

* Strive to implement things right the first time. This is completely the opposite of code and fix (rapid or otherwise). In reality you can't achieve this but you can come close. To do this you need to be confident you can implement all components and you need to do some up front planning. Often on small tools I find its easy enough to plan things out in my head. Anywhere you don't have a clear understanding of how things will turn out, you need to do some research, tests or prototyping. Note that I'm not suggesting fully planning out the entire project. I don't need to figure out up front how I'm going to skin my characters, I only need to be confident that I can do it and that how I implement it won't screw up the high level design of the engine. However if I'm going to implement client side predicted networking and use third party physics middleware for the first time, all I really know is that it will affect my AI system. Since the AI system may affect other parts of the game I'd be a fool to jump in and start coding until I have at least a rough idea how the all these components will work together. This approach also needs to be applied to content/gameplay as best and early as you can.
* Don't over engineer.
* To meet the first goal, don't under engineer and then try and crutch it up later.
* Again to meet the first goal, always keep performance in mind. It requires little effort. Normally only a handful of very critical areas should require tuning at the end of the project and you should have a good idea of what those will be when you first create them. You can't just create dog slow crap all the way through with the intention of profiling and optimizing at the end of the project. I've seen it done several times and the end result is a dog slow game.
* Spend your time/money where they will be of most value in the finished product. Sometimes you get so caught up in some cool technology you don't realize that nobody is going to care.
* Don't over-invest into reuse or other forward looking strategies. In this industry you'll nearly always get it wrong anyway. I instead strive for ease of code salvage, an approach that requires little up front effort.
* Don't throw good time/money after bad. If you've gone down some avenue that isn't working out, sit back, put aside your attachment to your work and make a decision on whether to scrap it and start over.
* Strive to reduce bugs. If you can't write a fairly clean and bug free piece of code without side by side programming and a full suite of tests, so be it. Personally I've found that the right attitude, "todo's" and heavy use of assert works wonders. Note that content has bugs too and I write and lot of small tools and add verification code to reduce those.
* Fight feature creep. Instead set aside some fixed amount of time and money for things that were unexpected or seemed unimportant. You can then spend this where it will do the most good to ensure a quality, competitive product.
* I never follow any of the above 100% of the time. In particular I like to do a bit of over engineering or explore technology that is cool but probably not really necessary. But I do make sure I don't spend much time getting off track.

The above list is by no means exhaustive and I've made no mention of how to approach staffing or ideas for how technology might be used to increase output.

That's all awesome advice most or maybe all of which I personally follow but was any of that "established software development methodologies"

Another thought provoking article can be found here

<a href="http://www.poppendieck.com/construction.htm">http://www.poppendieck.com/construction.htm</a>