- "what are your techniques?"
* Write re-useable code. Say it 100, no 1000 times.. Virtually all my DB projects use the same collection of libraries, regardless of style. These libraries are completely self encapsulated. This approach can be overkill initially, but will simplifying all of your projects in the long run. As new programs can be written in a fraction of the time. So being lazy is a good thing
* Design software that suits your libraries and your know how. The biggest risk to development stalls are the lack of technical knowledge. So avoid projects where your constantly doing research/development in order to progress. Nobody likes banging their head against the wall all of the time. So why do it ?
* Proof Of Concept first. Before you get the artists/sound guys churning out content, at least establish a demo that shows the raw "GAME" is within your grasp. This means, the player, some actors, basic environment/scene with interactions. Once you've established it's a goer, and if your still into it, then jump in.
* Limitations. From the proof work, you should be able to see out what the game is and isn't going to be capable of. Knowing your limitations is vastly import from an art / sound, and program design standpoint. So your content / environments / Character interactions in the game are designed to fit the evolved proof, not the other way around.
* Tools. Find as many off the self tools as you can to create/edit your raw content. For the game content, write an editor that can edit the levels (import/convert the various content) from stand alone program. The tool doesn't have to be fancy, or even remotely attractive. Just enough so it's easy to use. Then your artists/designers can rapidly flesh out / tweak worlds, while you write the game core. Make as many of game settings external as possible, so the game can be tweaked by anybody in the team and not just the main programmer.
* Communication. Make sure those who are involved know what their doing, how their to do it, when etc. The clearer everybody an communicate the faster the process becomes. Don't be afraid to make executive decisions. If you the buck stops with you, and the art/designers want to include feature ABC, and it's beyond the projects scope. Then say no. There's always room for a sequel
* Avoid Feature Creep. The worst thing you can do while in the middle of your project is continually add new ideas to the feature list. This is death. First write your program to your specs/initials features. Then evaluate if any extra features are in fact needed. The focus in on finishing..
Kevin Picone
Play Basic - Visible Worlds - Kyruss II
[url]www.underwaredesign.com[/url]