| ||||||||||||||||||||||||||||
|
(Page 1/4) Next 
[Following his initial take, EA veteran and Emergent VP Gregory completes his look at rapid iteration by examining patterns that can help development teams rapidly make game changes and see them reflected in the playable product.] In Part 1 of this series, we discussed the reasons why rapid iteration is so critical to your chances of success in building fun into your game, and some of the contributors to increasing iteration rates as teams, projects and toolsets grow ever larger. Content transformation "expense" was defined as time elapsed before the change can be seen in the appropriate medium, usually a game engine or an engine-derived viewer. With the goal of increasing efficiency on a game project, we started by looking at content transformations as the first optimization point. Now let's dive into the details of where you can squeeze significant time out of your processes: the development team's tools and practices. Patterns to Follow If the whole is equal to the sum of the parts, then the iteration rate for each individual developer on the team makes a big difference in your overall iteration rate. Make sure that each developer is working in the most optimal environment possible. Get a Handle on Your Development Workspace(s)Maximizing productivity is a lot about the details of a developer's day. Minimizing disruptions is important, be they attendance at unnecessary meetings, or just interruptions that break the flow of concentration in the middle of a task. For example, you need to be able to Context Switch between development workspaces quickly, on the same machine. You may be asked to work on a feature, and at a moment's notice, fix a bug you aren't set up for. How do you minimize the interruption?
Your artist workspace includes digital content creation tools, the last known good pipeline tools for your game team, and the last known good target environment for you to check out your work in. A lot of workspaces are set up as global singletons, making it impossible to switch workspaces on a single machine. This makes it very hard to set up your machine to debug a problem from another branch, and it makes it very hard to keep your build process the same on both your local machine and the build farm. Notorious "problem child" software includes anything requiring an installation procedure, or anything setting up registry entries or global environment variables. This includes anything installing itself in the global assembly cache. Any configuration with hardcoded drive letters, or absolute paths, is generally a no-no. The best configurations are usually file-based and script-based, and can easily be moved around from base directory to base directory, and can be distributed simply by syncing from a source or content control repository, or from another distribution mechanism if required. (Page 1/4) Next
|
||||||||||||||||||||||
The
development workspace is the collection of data, software, tools and utilities
that achieve a number of transformations on data. For instance, your compile
workspace includes source code, compiler, linker, environment variables,
registry entries, project files, solution files, etc.
|
|
Comments
"If the whole is equal to the sum of the parts, then the iteration rate for each individual developer on the team makes a big difference in your overall iteration rate."
I'd guess the whole is not equal to the sum of its parts. It rarely is. Well, there's two parts left to get to what I hoping to read.
Login to Comment