Churn and Rework

#1 It is a fact of life, but there are things you can do to minimize it. Prototyping is especially important. Demos as well. They give you generally the whole game (give or take) in a smaller scale so you don't need as many art resources.

It also isn't always compltely parallel. Of course, every company is goign to do things a little different, and I can only recount how we do it.

Code is always ahead of art for us. This is done intentionally. Generally our first step once the design document is finished, or at least 90% complete, is to work up a feasability stufy, or protoype. This is extremely small scale, often using programmer art or very quick artist art. It involves what I like to call "highlight" code. Basically key gameplay features coded to at least a skelton stage for testing. This lets us see if the idea will work.

The second stage for us is an internal demo. Basically an internal demo is take the game, scale it down, put in all the code for your gameplay but not neccesarly poilished or with the right UI. For example, in Mayhem 2090 which we are working on right now there is an overall gameplay concept of capturing and controlling bases. Well for our internal demo we "capture" a base by pressing a button :p This lets us test the feature with minimal code.

Since the internal demo is scaled down, you don't waste a lot of art assets. For example if your game calls for a total of 20 different player models, the internal demo might only have 3. Enough to test the features, but thats it. When you end up having to make changes it isn't so bad.

The internal demo should get you about 90% of the way through this "churn and reowrk" as you call it. Next would be your public demo. This is more heavily dependant on the programmers than the artists. Generally your demo art is locked down from the internal demo. Now its up to the programmers to fully flesh out all those gameplay features that they "cheated" on earlier.

This is how we do it, and it works well for us. Others i'm sure do it different. This is one industry that is amazing in that there are very few consistancies from company to company. It is a lot better no than it used to be though.

In the end its what ever you find works for you.

Hope this gives you some ideas though.

#2 Brad - this has been an issue with the two major retail game development studios I've worked for, and it has been an issue as an indie as well. You are not alone. It's a major issue, and largely a fact of life, but it can be minimized.

I find that even "fully detailed" design documents don't help that much. I'm a fan of rapid prototype models of software development, which might scare some folks because rather than trying to avoid the "churn and rework" phases, it pretty much assumes its going to happen and just rides it out. It's pretty much as John said - you develop a minimal set of content to work with while you are in the early stages of prototyping.

The problem is, of course, your content people may be lift twiddling their fingers during this stage. I know at some companies they handle this by having games in concurrent development - while one team is in the "early" stages, another is in full-on final development. This is risky because if schedules get messed up (and they always do), you get double the impact.

It sounds like you have some fairly game-specific issues that are making the impact more severe in your game. This is a flaw in your game design (I'm not trying to be harsh, just offering hopefully constructive criticism here... I hope it helps!). Without knowing more, it sounds to me like someone failed to do a risk analysis / assessment on the design. It also sounds like it needed to be made far more modular, so that any changes would have less impact on the whole game. The thing to remember is that a game design document is really just a "paper prototype" - it's a starting point. Particularly with games, it's going to change frequently and often substantially. A good design doc should be written with this flexibility built in, with all perceived risks flagged, and alternatives suggested for those risks that don't pan out.

Once you've done the risk analysis on the design, have your development team (content people AND programmers) address the high-risk areas as early as possible, before too much has been created that depends on them. Maybe they need to get new technology developed, or maybe you are implementing a new, experimental gameplay element that sounds great on paper but might suck. Have your content people crank out the minimum-

As to where you are RIGHT NOW with your current design - that really depends on you, your team, their motivation, and the project. Nobody can tell you what to do (unless they are funding you). If it's getting too ugly, it might be time to cut your losses and pull the plug. Or it might be time to go back and do a re-design, armed with better knowledge and hindsight. Or it may be very salvagable in its current state, but you may need to go back and do some risk-assessment and modularization of systems. You never want a design doc thats so fragile that completely falls apart if one high-risk area fails.

Then again, I broke that last rule myself with my current project... the focal point of the whole game was a particularly high-risk gameplay idea. But I was ready to scrap the whole thing a year ago after the early prototype was up and running. Fortunately we found a way to make it work.

#3 The easiest way to avoid this is to not create anything until you are ready to integrate it in and a proof-of-concept has been approved. Do as little as possible until you know 100% that you want to spend the time on the rest of the content.

The fundemental problem is your "Waterfall" development approach. This has NEVER worked and it is even worse with content creation.

Move to a more iterative / feature driven approach.

If you are going to have 25 characters in your game with dozens of animations, only do 1 and PROVE that concept before you build the rest. Only do the animations 1 at a time if at all possible.

It is much easier to cut things out before they are done, since everyone has a hard time 'throwing away' work that is already been done.

Never get married to a document. Use the planning stage as just that PLANNING. Plan everything out that you can to a reasonable extent. But no plan survies first contact right! So don't plan TOO MUCH and don't get married to the plan. Planning is to tell you want NOT to do or what to AVOID doing.

The planning should result in a really good dependacy chart of what needs to be done before what. And a timeline task list is the natural extension of your dependency list.

#4 PART I (split post due to size limits)

Thanks John, Jay and Jarrod.

After reading the responses and discussing this via email with one of the project's main contributors, I am going to try a new tact. In retrospect, I'd been effectively taking an iterative, proof-of-concept and prototyping approach with the code, but was trying to go from paper design to production quality work in one step on content. I'm confident that the design is sound, and the the design and code rework is incremental, but the different approach for content was generating the friction.

The new approach will phase in content in parallel with code, using the following guidelines.

Programmer Placeholders - Just visual props showing position, gross scale, speed, etc. using geometric primitives. Equivalent to stub code. Use until the content is stable enough to consider purchasing placeholders.

Demo Placeholders - Purchased assets that look acceptable enough to show externally and are at least a rough fit for the game's target visuals.

Proof-of-Concept - Produced only when specific attributes of the model must be validated against code and no placeholder art exists, for example to check a procedural animation technique.

Alpha Models - Approximate the geometry and skin texture of the production model. Try to have available by first integrated build after the code is feature complete. I find that thes are needed to check attributes like scale, because these can only be validated in-game, and mistakes often can't be fixed by simply modifying the production model (e.g. simply scaling up a model designed at another scale -- often the model needs more extensive rework to look good at a different scale).

Production Models - Refinement of the alpha model to final quality.

#5 PART II

The one concern I had was the one Jay mentions, that synchronizing work would be a problem, and as an indie developer we aren't attempting multiple overlapping projects (although at least some team members are involved in other unrelated projects). So while the code is in work, artists will do concept work, with a switchover occuring when the code is feature complete. The coder (note singular :) ) will go into test, debug and polish mode, and the artists will start to develop production quality content. My continued concern is adding some lag to the end of the project, but I'll see if that can be minimized.

The original strategy was to have up front content for visibility, that is, the team would have something to show on the Web site and IOTD, rather than working underground for months on end. There was some push back on rework, which I can understand because everyone has the typical royalty share agreement, and since our royalty shares are tied to percentages determined by line items in the design, rework doesn't increase royalty share percentages.

We've also changed that strategy, into emphasizing the concept art and playable 'early access' demos using stock placeholder content. In the future if a demo needs original content, the demo content will be broken out into separate line items. But such a demo would only be created for some specific business purpose.

The royalty scheme will also be modified. I'd used the piecework model to more equitably distribute royalty shares in the team, rather than having heartburn later about each member's level of contribution when royalties were arbitrarily split, and to support freelance contributions from people outside the core team. So the line items were rather detailed, as it was important to establish a baseline early, so that contributors didn't feel the value of their contributions was being eroded by feature creep (there was some padding to allow for some reasonable amount of changes and additions). Those will change to generic line items (e.g. a vehicle model is worth X percentage points) with some thumbnail estimate of the required amount of content (e.g. budget for N vehicles @ X % pts). Then as game concepts evolve and are refined, the design can be fleshed out and attached to the generic line items. It probably isn't even necessary to establish even all generic line items early if I can make a reasonable guess at a total budget for a game. But since I don't have any game development experience, the design was a good exercise at least in estimating.

Again, thanks to all those people whose names begin with J (coincidence? :) ) for the suggestions. This is a real learning experience for me, which is good because I was getting bored with the mainstream software engineering to which I'm accustomed.

Comments on the approach I've outlined are certainly welcome.

#6 Brad -
I created my own placeholder art for the first half of the games' development. It stank, though I did start learning a little about modeling (enough that I was able to do some simpler, final objects on my own.)

Then when I got modelers on-board, they started with untextured versions of the models which they could crank out quickly. I complained about their triangle counts, approved or disapproved the overall shape, and used the untextured, high-poly versions as placeholders until the more final versions arrived.

This staged approach mean YES, work is going to be thrown away, but very little that anyone has put a ton of time in on.

Anyway - sounds like you've got a solid handle on where you need to go from here. I think I may try and implement some of those steps you pointed out myself. Good luck!

#7 I often use models, sprites and other media from other games or from the internet for prototyping. Of course, you have to keep careful track, and make sure you've replaced all of these before you release or even show off the game to anyone.

#8 We purchased most all of the Bravetree content packs to use as placeholders. I highly recommend them.

#9 Content will ALWAYS take longer to do than code, and it will take 100 times longer to RE-DO.

always remember that!

#10 I don't know if I'd go so far as to say THAT, Jarrod. But code does have the advantage in that it's largely "behind the curtain" from the player's perspective, whereas they are looking right at (or listening to) the content all of the time. So the content requires an additional layer or three of polish that your code doesn't need.

#11 It would be nice I think to see indie Post Mortems. Can a category be created in the Resources section for this? I've seen some lessons-learned posts in the forums, but nothing as organized and analytical as the typical Post Mortem.

There's a lot of material on technology and even a fair bit on marketing for indies, but very little on business practises and processes. Post Mortems would be a great way to capture best practises and red flag the gotchas.