Can an internet team stick together?

#21 I do need to study up a bit on the iterative process. I may look into eXtreme dev, but I'd like to start with the simplest dev process possible. Waterfall design is definetely silly, and I want to create a team who has as much freedom as possible. My first game is essentially a Strategy RPG, and is very stripped down to the core essentials that make up the strategy gaming experience (in the most minimal sense :). It has almost no story, and no artistic plan. I want to give the artists as much freedom as possible in stage, character, and enemy design - with deadlines and technical requirements being the only constraints. I feel this freedom is essential to allow one's artists to maximise their potential - art requires creativity, and creativity requires (a reasonable amount of) freedom. As for the story, there is essentially none other than one big quest to overthrow the tyrants - just enough story to give the player motivation to win over the evil bad guy who sucks, is wrong... and is evil, etc. Unfortunately, involved story implementation (cutscenes, scriptwriting, etc) will bloat the dev time too much, and with a team as small as mine (4-5 peeps), there is no room for story. The plan, though, is to generate revenue to allow our "company" to grow, so that we can finally reach the point where story-telling becomes not only possible, but significant.

As I said, I'm doing only the absolute bare essentials to create a strategy game experience. I've also got another good 3D programmer ready to go, though he and I still finishing up his current game.

So basically, I plan on building the core engine (possibly with the help of the non-local programmer), and making just enough art and music myself to create a teeny playable demo to interest other developers. From that point, a team is formed, and we all work together to nail down the art and story plan. I want to give my teammates as much creative input as possible since this creates incentive for them. Wide-eyed and glorious is an artist who is working to fulfill *his* vision!!! After creating a very loose design, we iterate until we having something shippable. If the projects exceeds the allotted dev time (1 year), we cut the game short by removing planned stages, and make the last stage as well as finishing the current stage. This early cut-off possibility is a motivator for all involved to get as much done as possible if they want to see it in the game. This allows us to have a long game in theory (12+ hours playtime), and shorten it to meet the reality of projected dev-time. The lack of an involved story also helps to achieve this flexibility, though this is not the original intent, but a recognized side-benefit.

Phew! Well, there it is folks! Any critiques are welcome, and you have my thanks for your friendly responses!

#22 I actually had to look up what the Classic Waterfall Model was. I guess this is it?

Whether to do a game design doc or not is a good question in-of-itself. It seems that most devs are polarized on the subject (either for GDD or for sponataneous design).

Undoubtably, it's easy to use hindsight and say that a program would have fared better with a GDD. I can list many things for our Trajectory Zone that would have gone smoother or been better with a doc to base it off. The UI, model and texture continuity, gameplay (ie, how far the tank actually will shoot), overall game tone, feature creep... and so on.

However, TZ was never meant to be the production it turned into and probably would not be what it was today if we had to stick to a design doc--even if only vaguely. Ideas tend to spawn new ideas. Feature creep must still be controlled, but it can be if the game designer is able to say, "enough is enough". I promise that Davis never dreampt that the two-month-two-man project would turn into 15 months (and counting), and topping off at seven members at one point (most modelling player vehicles).

So, as I said, it is easy to say how TZ would have benefitted... but if it was beyond the original scope, how would he have written one in the first place?

Not that Davis didn't have the ability to look forward, mind you, but I'm sure he probably took into account time, the need for free (royalty based) work, and who knows just what you can end up with that. :-)

Just my opinion on the TZ development process. I'm sure others on the team have varying viewpoints.

I've also seen 50-100 page game design docs that still haven't been made. ;-)

-EricF
www.midnightryder.com

#23 The great thing about Indie Developing, is you can break the rules. I have never been a good person for rigid design. 90% of the good ideas are inspired/formed during development- we couldn't possibly have accounted for them ahead of time. The design begins to evolve, and the developers become inspired to try new things.

I prefer to work from inspiration, rather than a preset goal.

Luckily, our other team members are just as forgiving. You only need to know when to say "enough".

#24 @Randall - WELL SPOKEN!

That's the part about going indie that excited me as well - even though the time investment can be significant, you can afford to take a lot more risks.

I'm personally most fond of the "evolutionary prototype" model, particularly in game programming. It does run the risk of spinning in place forever, but it gives you a continually improving working model as a foundation.

#25 > I actually had to look up what the Classic Waterfall Model was. I guess this is it?

Actually thats not a classic waterfall. Notice the "additional iterations" part in the title.. ... In strict waterfall you are _never_ allowed to go back and fix things. As everyone knows its impossible to plan for details later on, so that fails - period.

A design document is also not a bible of thruth. Its only useful if constantly modified and should more be used as a "initial concept description" and then later record all changes to the gameplay.

You dont need to specify up front how far a tank can shoot. Just record that you got a tank and that it can shoot. Later when you sit down and design the "tank shooting" feature, you go back and record: "Tank cannon can shoot 100 meters" - or "Tank has 4 guns with ranges: 20, 50, 100, 500 meters"

So dont write 500 pages up front - start out with 2-3 pages that you can show ppl and say "This is the overall game I want to make - lets figure out the details as we go". I've found it to be very important to have a goal to go for (the initial idea). You dont want to start out making a puzzle game and ending up with a MMORPG :-)

#26 I think 2-3 pages might be a little small (though I could be wrong - many of the most successful games I'm aware of had only 2-3 page design docs, but a very active designer that people could go to for game decisions).

But 500 pages is WAY too big. I think about 20 - 30 pages is a pretty good design doc size overall for an average-sized game - enough to define and communicate the idea. An exception might be something like a wargame where tons of page space is devoted to tables & charts. For smaller games typically created as budget / indie projects, the design doc should probably be even smaller - I can't envision anything more than 10 or 15 pages for a game like Orbz.

#27 Don't go over 5-10 pages for a design document when you start out if you're doing some of the programming yourself. Only make a big design documents if you're only doing the design.

For instance, I'm working on an RPG. I didn't list the spells in the design document, but some people might. Those people are going to have problems because they're going to want to change some things about their spells later on.

Since I'm doing the programming, I just listed the spells in the game and made a program that outputs all the items, spells, etc. into an html file. This way when I need to change one of the spells (which I've done several times and plan to do again), I only need to change it in one place.