In today's Gamasutra feature, following his initial take
, EA veteran and Emergent VP David Gregory completes his look at rapid iteration by examining methods for seeing asset change swiftly in your games.
As Gregory explains, one trick commonly used by developers is to create a viewer application to plan asset changes without having to reload an entire game. But, he warns, this can frequently lead to bigger problems down the road when game changes don't make it into the viewer:
The closer you get to WYSIWYG across your entire range of tools, pipeline and runtime combined, the better off you'll be. That is for sure.
However, some teams have introduced workflows that have created an untenable situation, resulting in loss of productivity rather than gain.
For instance, in some cases, to shorten iteration time, teams have tried to recreate much of the look of the game in an environment outside the game, typically some sort of viewer application.
They do this for what seems like a good reason: the time to load the game and advance to a place where the content can be seen is dreadful, especially during development.
But there will be no way they will be able to keep up -- the game will introduce a new feature, and that same feature will be missing from the viewer application. It will always lag, and will always be a source of frustration and pain.
Build your tools, pipeline, and engine so that they can work together to carry the change into the target environment as quickly as possible, in a form useful for the person making the change, following all the principles above.
Each tool and each person on the team is a potential contributor to -- or improvement of -- the overall project iteration rate. By focusing on the factors that add time to your pipeline, you can increase your efficiency and more quickly and reliably produce a fun game.
For more rapid iteration dos-and-don'ts, you can now read Gregory's full feature