The Indie Development Process blog - justinvh

The Quick-to-Impress Route

People focus on visuals. It's a huge part of developing a community and getting people to see your vision of the game or mod. So, it would make the most sense to create models, right? That's exciting. People want to feel like their is something there to show for the game -- And nothing says "Update" more than a 2-minute render of a weapon model.

Well, sometimes it's not practical to take that route.

The Tactical Route

Laying out a plan for development is always the best route. It creates a sense of organization and structure. It helps micromanage each stage of the development for the game. It may not be the most appealing decision for the people watching the progress of the game, but it is the most beneficial to meeting deadlines.

It allows the project to shift its development process while giving team members time to prepare for their parts of the game/mod.

It seems to relieve a bunch of stress as well.

Rogue Reborn

Rogue Reborn follows this concept -- It also follows a few guidelines:

1. Develop key concepts
   Create a document -- anything -- and jot down some basic ideas of what you want to accomplish.
   Ask yourself: "What do I absolutely need?" Dismiss the ideas of models, textures, and sounds. They're steps that come after. Look at the core of your idea.
2. Don't be generic when requesting jobs
   You need weapons -- Wrong. If you laid out your development process then you would know exactly what you need.
   You need a MP5K-PDW with a folding stock. Good. Look for someone that can do exactly that. Saying "I need a weapon modeller" is about as good as saying, "I need a engineer."
3. Except disagreements
   People will hate your game. They will make ridiculous comments. Take those comments with a grain of salt. The people that actually give feedback such as: "I noticed your demo didn't show X. Why not?" expect replies. So, give it to them.
4. Don't gather all your resources at once
   Putting together a dream team all at once is impractical.  Just try to avoid it. Gather team members as the development goes along -- And don't be afraid to just utilize someone's talent for a particular something rather than try to "hire them".

There you have it. A quick breakdown of two development processes. Enjoy.