Very interesting read there. I am not so sure though that game development remains that dissimilar to business app development though. Waterfall is a pretty limited methodology, and frankly, I have found it rather constrictive in many of the business apps we try and develop. I have worked in IT as a business app developer/Analyst/PM for many years, and been in shops with everything from 2 man staffs, to 300+ developers across numerous continents. IN all those cases, I find that many projects defy the waterfall methodology, and that an iterative, prototyping approach is often required.

It seems to me, as the game industry continues to mature, that it is becoming more and more like the general business industry, not further diverging from it.

Sorry, a bit of an aside there I know, but I am just curious. Do you really feel the game and business IT industries are that dissimilar? And if so, do you feel they are headed toward further divergence, or not?

Game development to me seems like business app dev plus. Frederick Brooks told it like it is back in the 70's: waterfall falls apart once projects reach a certain size. Game development comes with all the trappings of general software engineering with the added bonus of not only having to be functional, but also fun. There's also the elements of art, audio, and story that we inherit from the film industry on top of all that.

So I would say game development is very much like IT, but in some ways even more necessitates the use of practices that reduce failure, show consistent progress, and make the product as good as the vision that gave birth to it.

Great article on some important issues! However, I'm a bit confused about the goal of this article series. It seems that you're focusing on rapid iteration during full-on production. Ie. iteration on the actual shipping bits. But you mention early on that ideally, you iterate and find the fun in your pre-production prototype. In pre-production, you can take a lot more short-cuts and can afford to ignore some of these issues. So, I just wanted to clarify, are you mainly talking about full-production iteration? (Which, by all means, is inevitable and extremely important).

As someone who has worked on a few major mmorpgs as well as a couple smaller prototype teams I'll say that based on my experiences this article rings true.

As a relatively clueless person reading this article, I have to ask: how often are the automated processes the bottleneck? Sure, waiting for compression, lighting, etc. could take minutes, maybe hours, but does it take days? The rest of the rapid iteration process - manually testing the game, discovering what's fun, putting together a list of what needs to change, assigning tasks, making the changes - there might be a way to streamline that too, but this article only focuses on what the machines do. Waiting on the machine can be annoying, but that doesn't mean that it's the only thing that's inefficient with time.

After reading the article title: "Building a Mindset for Rapid Iteration", it's a little disappointing to end on a list of software tasks that need optimizing. I expected a list of what's going on in the mind, not the CPU.

Thanks to all who have read and responded! A few answers to some of you.

Martin & Anon #1: I brought out waterfall to make a point, not so much to say that it is the methods we use today. I've never done business software development, and I admit these days that waterfall doesn't really work for most teams, across both business and entertainment software. But when I started game development, waterfall was the standard on the business side, and it never worked in games. There's also always been no off-the-shelf tools to develop the differentiating features in games - those tools need to be written specially by the team, for the team. That means that the team is building the software it needs to make the game, not just the game itself. You are bringing artists and engineers together in an amazing cauldron of creativity, something I don't believe the business software industry does anywhere near the same scale.

On the other hand, there is a LOT that game developers could learn from business software teams that have been working in larger numbers far longer than they have. There is an incredible cultural barrier to get past in bringing new techniques into the Game Industry - lots of NIH, and developers who want to "work like they always have". You really have to work to get individual developers to change their tune and optimize how they develop games so they CAN make it better. Hence the title for the article "Building a Mindset..." - you have to begin with individuals, and spread the mindset to the team, before you can change culture.

Steven: When your team is small, and you are keeping it lean and mean, the challenge is to find the fun as quickly as you can, and get ready to scale your team. What I've personally seen is -- once a team finds the fun, and have all the foundational tools they need to make the content required for the game, they scale the team - and then find out that all of their tools and processes do not scale to a larger team - they can no longer iterate like they could when they were small. And sometimes, pressures come from publishers to scale the team even further than they anticipated. It is a delicate balance. You don't want to over-engineer. But you also don't want to get caught with a process that doesn't let you continue to iterate when you get big.

Anon #2: With large worlds, if you haven't properly built your tools, baked lighting or global illumination builds can indeed take days. Full content builds from source can also take days. These days, teams that are doing it well distribute these builds across multiple machines and cut the time down to see results. But if you're the guy that needs to see lighting changes, you're still in a world of hurt if you have to wait for the lighting build to see your change in the engine. How do you see "enough" results to know if the change you just made worked? You need close approximations much more quickly that don't involved a large lighting build. You need to see a few still frames at different camera angles in the scene you modified rather than a fully interactive world. You need a quick path.

Machines are definitely not the only inefficient things. Poor tool interactivity workflows and lots of context switches on your desktop can really slow things down too (amongst lots of other things). It's just that its probably easier to hit the tools and processes than it is to effectively optimize every single tool workflow, including those off-the-shelf tools that game developers DO use, like DCC tools.

Anon #3: I hope I answered your concern in the response to Martin.

Again, thanks everyone for your questions, and you should see part 2 soon.

David: Ah I see. So during your prototyping stage, you should keep in mind these issues so that when you need to scale, you can make it happen. How do you feel about "throw away" prototyping in pre-production? For example, why not build a prototype as a mod for an engine that you have no commercial license for (if that's even legal?). But once you find the fun and figure some of the production quirks out, then you build full on scalable production tools for full-production. So nothing done in prototyping will ship, except the ideas that emerge from it. What do you think of such an approach? Could it be seen as "wasting effort"?

It's interesting that you bring up lighting-iteration as a significant bottleneck. I'm currently a graduate student in graphics, and there's a lot of research out there on rapid-iteration of scene lighting. A lot of it is focused on lighting-design for CG movies, but a lot of other techniques may be applicable to rapid iteration of environment lighting (anti-radiance comes to mind). It would be great if one small, isolated change in a map did not necessitate a complete re-computation of lighting.

Back in the old Quake days, their solution (god bless Carmack) was to make lighting optional. As a designer/level builder (back in the day when they were the same person), you didn't have to run the "light" or "vis" tools to play your map. It just meant that 1) your map would run slower (vis optimizes it) and 2) everything would be full-bright. Perfectly reasonable trade-off's in a development workflow.

Anyway, can't wait for Part 2.

This article seems more geared towards those who are already in a horrible build situation and a just fine with it. I would like to see more explanation on if a developer could do it right, what would the final picture look like? I'd like a description of the end goal of fast iteration, an exact workflow in an example situation. I'm sure everyone dreams their progress bar could go faster and then they try to "optimize" and just end up hittin the technical wall. I'd like more to see a workflow design based on fast iteration.

Steven: Throwaway prototypes during pre-production, or even afer it, can be critically important. They are an important shortcut in the game and technical design process. By the same token, be careful not to turn a prototype into a production tool (or runtime) without scheduling additional time to "beef it up" where required. Those tools can bite you later.

As far as using a commercial engine that you don't own a license to just for preproduction, I'd have to say that's not legal. You're getting a lot of benefit using an engine to get your ideas fleshed out, even if you don't ship with it (full disclosure: I work for a middleware company, so this is the expected response).

Anon #4: A great point, and I chose to write the article from the minimum state up, rather than showing a picture of a completed working system. Two reasons for this -

(a) I've tried to paint the full picture for teams before and ideas have been rejected wholesale because it seemed like too much investment.

(b) It's tough to have a one-size-fits-all solution for all teams. Every team has different requirements.

I still think that's its a worthwhile exercise, and I think i'll spend some time building a full picture of a system I think would work for most teams. People reading that type of article hopefully will be able to see the different parts and take the parts that work for them, and don't worry about the parts that won't.

Thanks for the comments.