over ambitious begginers.... who is guilty?

#61 Just out of curiousity, how many of you guys posting to this thread actually works in the game industry? I mean, have it as your full time job developing games that are funded and have a publisher waiting for it to be finished? It would be interesting to know, and I'm sure it would give people reading this a bit of perspective.

#62 Here's an intriquing conversation on the subject from last year. I found Jeff's response very interesting--especially in light of this thread.

I respectfully quote it here: :-) Kudos to Jeff for such an honest response.

Quote:Jeff Tunnell
Employee Posted: Mar 05, 2002 23:00 CST

At Dynamix we implemented an approach brought to us from Pat Cook, of FPS Football fame, who is now a PUM at Microsoft. We used a staged design approach.

Stage 1: 2-4 pages. This is a sales document that is used to get a green light to move to the next stage. Describes the high concept (elevator pitch) of the game. Usually accompanied by a mock up screen shot or sometimes even by a code demo. This document, along with a lot of expreience would determine a "grab your ass with both hands" budget guestimate and target ship date, i.e. 4Q 2004 (note- it's always 4Q, then work back from there, even though it never works out: People in the industry are laughing right now--- inside joke.)

Stage 2: 10-20 pages. Describes all sections of the game in much more detail. Discusses how the UI will be approached, the level of AI expected, etc. Still mostly a sales document, the S2 is accompanied by even more mock screen shots, and usually some form of demo. At this point an even more detailed budget and schedule is made. This document could be thought of as a movie script (which run approximately one page per minute or 120 pages for an average movie). Ti gets the point across, but does not tell how to do it.

Stage 3: As long as it needs to be. Nobody but the team uses this document. Some games need large documents, some small. Many games will get just in time design documents to fill out tables, weapons data etc. This document is also accompanied by a technical design review (TDR, in EA parlance) which describes how the project will be done, i.e. the tools, technologies, and techniques.

Some people feel the Dynamix approach was too lax, but I hold up the ship schedules during my tenure there to anybody's. A game, such as Tribes 1, that was heavy on the R side of the R&D equation, never had these formal processes. Other games, such as Pinball or Trophy Bass, were easier to schedule, so they had tighter specs and design documents.

Bottom line is this, "nobody knows nothing". There is no standard answer. The person that tells you they have the answer may believe it, but I call bullshit. I have seen teams that implemented design documents approaching one thousand pages. The poor designer spent all of his time updating an unmanagable document that was so large the team never read it more than once. You know what happened to these projects? They didn't ship.

The one thing that I notice here is the people that have done it before are much more lax in their design doc requirements. That's OK. When you are starting out, it is better to over design. That's also why we are indies. We want to do it "our way."

Jeff Tunnell GG

-Eric

#63 @Jarrod

Quote:I simply stated that espousing such an idea what "being indy is all about" is fundementally unsound advice in the context of this topic which is about OVERLY AMBITIOUS PROJECTS.

..and that is my point and you are not seeming to get it.

I find your advice on 'ambitious projects' to be unsound.

If the project has clear requirements and the developers know what they are doing, it can be done cheaper and faster with more planning. (I am going to ignore the fact that this will not necessarily make it good)

As people step out of their comfort zones and attempt projects that are possibly beyond the scope of what they now are capable of (i.e. ambitous) they must be willing to deal with the fact that they don't know what they don't know, they can't know what they don't know until they do it, and that this uncertainty is part of pushing the envelope.

So, to make it simple... The more ambitious the project, the more unknowns there are. The more unknowns, the less effective the planning. The less effective the planning, the less likely that more planning is going to result in effective risk reduction.

In the most extreme scenario of this (where everything is an unknown), any planning at all gives you nothing. In this extreme scenario (which I would definitely define as ambitious) you would indeed make more progress just starting and testing to gather data to make decisions about rather than thinking about it, spinning your wheels, and make yourself feel better that you are taking the right approach.

My opinion is that saying 'more planning is the solution' is questionable at best and in the particular case of ambitious projects, really bad advice.

An appropriate amount of planning is what all projects require. More is not always better. This is my opinion. I understand what you are saying, I just happen to disagree.

It appears that you either are not hearing what I am saying, don't understand it, or you are not willing to acknowledge it.

Either way, no sense continuing as it appears that you are not all that interested in discussing the subject at any level of depth. The is the last I am going to say about this, feel free to flame me, I will no longer respond.

@Corre

www.bravetree.com/Bios.html


Closing thoughts:

I am more interested in process that produces fun games than a process that produces software the fastest and cheapest way possible. We can make it faster and cheaper, but that does not necessarily make it 'better' when using 'fun' as a metric for success.

#64 My most over-amitious game project
was writing a Rouge-Like in 100% assembly for the amiga,
from trapping the keyboard and vertical refresh interrupts on up.

it had its advantages,
like a console w/ text reflected in rippling water and such,
but man.

#65 Guilty as charged. I knew I was being overambitious when I picked up the Torque engine a couple days ago when I took a look at the outline I had put together for the ideas I wanted to try and implement in my game and realized that they were almost all based on complex AI programming. And I've never dabbled in AI programming. Heck, I'm not even a programmer! :p

#66 This thread is a couple months old, but I'll bite...

"The first casualty in war is the battle plan." - Or something along those lines... ;)

#67 Thread-ophilia strikes again...

Torque is tailor made for over-ambitious projects. Then you realize doing anything more advanced than a fairly basic game requires absolutely massive coding life-support LOL.

#68 Do you feed thousands with fish and loaves? Cos u just did a resurection... :)

#69 Lol I'm still working on my over ambitious project.

#70 I've coded professionally for a few years now. I do game development different than I do business applications... why?

Because I find game programing to exercise my creative "legs". I like the flexibility to add or subtract features on the fly. The ability to let my emotions drive my decisions is such a refreashing feeling. ....and I don't care about deadlines with my game(s).

Design documents are necessary for me to complete projects on time. Without a DD I'm not focused in a business application.

However, I always approach these types of topics with caution. I have always believed in the motto: "To each thier own". Some people need a plan, others do not.

/peace

#71 Orion Elenzil's necromancy skill improves by 1. :)

#72 Orion leveled! Weeeeeeeeeeeeee! ;)

#73 Guilty as sin. My first game was making roads from clothes pegs in front of an open fire when aged five.. Computers weren't common then and I think Sputnik had just been launched...

#74 Hey, applies to me right now. I've been writing a series of 2d engines over the past year. Probably gone through a dozen of them now, and the most recent one is the only one that'll result in an actual game - reason being that I made the engine simple enough this time so that I could actually write the tools for it instead of quivering and wondering what to do next, and I started with the tools and built it up from there. The prospects are wide open for me now that I've gotten it completed, I just have to decide what I want to do....and I don't think I'll be doing so much planning ;)

#75 Remember now that over-ambitious can refer to either depth or breadth, or both. If you're making a standard FPS but with 100 enemies, that's an ambitious amount of breadth. If you're making a game where you are an electron and you have to navigate a sub-atomic particle world to create certain biochemical reactions (or something like that), that's an ambitious amount of depth.

Quote:As people ... attempt projects [that are ambitious] they must be willing to deal with the fact that they don't know what they don't know, they can't know what they don't know until they do it... The more ambitious the project, the more unknowns there are. The more unknowns, the less effective the planning. ... In the most extreme scenario of this (where everything is an unknown), any planning at all gives you nothing.

Damn, there are some absolute pure-gold nuggets of wisdom in these forums sometimes... I ran in to this exact problem with my game, which is of a genre never done before. I faithfully kept trying to pound out a design document, to plan the entire game from start to finish on paper before laying a single line of code or polygon of model... and it didn't work, due to the ambitious depth of the project. It was like I had to just dive in and do it, and I didn't like that at all. But the more diving in and the less on-paper-planning, the smoother it was working itself out. I thought this had to do with perhaps my dev style or some such, but I see now that it's because there's too many unknowns with this particular project.

On that note, the game I first wanted to develop was a typical fantasy/RPG with 100's of characters, but I soon realized that I couldn't possibly cover that much breadth... so I scaled back on ambitious breadth, and instead focused on ambitious depth (i.e. gameplay).