over ambitious begginers.... who is guilty?

#21 Ben, that is totally not true. I know of many, many games that were not done using that method, including Marble Blast and Think Tanks. Nobody wants to do that. That's a pain in the ass, that's not what being indy is about.

#22 I think I should probably point out here that while we all did make the first project over ambitious, I think at least I can say that it was a great learning experience. I dont know if I'd want to learn all the lessons I learned from that project form a class.

In other words, failure at your first over ambitious project is probably a good thing, and we shouldnt be dissapointed or ashamed of it. It's just part of the process to becoming a decent game developer. :)

#23 Pat: I don't mean to come off as rude (as written words are often mistaken), but, "tomato, tomatto." Whatever works.

#24 Yeah, that is true. I do know people who like to be very organized, I just don't think it's required to make a game.

You are right, though, whatever works.

#25 Then how come EVERY postmortem of any game that Game Developer does lists "lack of planning and sticking to the plan" as the number one "things we did wrong". I am sorry but Marble Blast and Think Tanks don't seem to qualify into the discussion of "ambitious".

For any kind of "ambitious" project, planning and on going project management is a key to success.

I an don't agree that your flying by the seat of your pants hacking blissfully away at code and content has anything to do with about what it means to be "indy" if there even is such as thing, it would be more about not having to follow some moronic corporate marketing facisist about what the content and gameplay is about.

#26 Im guilty of it also. I dont think there would be a person using GG that isnt guilty of 1 offence of this :p

#27 Jarrod,

Probably should watch the condescending-sounding way you are using the word ambitious. Any game that gets made and people are willing to plunk down their hard-earned money for in my opinion should be considered ambitious.

I can tell you that for Orbz we had ongoing planning and project management - we weren't flying by the seat of our pants hacking away at code and content. Nor were we spending an hour every day tweaking a MS Project document or tweaking that 200 page functional requirements document. We were something in-between, and it worked pretty well.

#28 First game: A clone of Tailgunner entirely in green screen character graphics on a Commodore PET. Wow, that was a long time ago.

#29 First game: Berzerk clone on the Commodore 64. Hey, I hear people are making money off from Berzerk clones lately...

#30 From what I've read in Game Dev, here, and the "Game Secrets of the Mages" book there are two main trains of thought on game development. One is the well planned version; the other more fly-by-the-seat-of-your-pants

The general consensus was to do what ever works best for you. For some, too much order is chaos. :-)

-Eric

#31 Guilty right now. My real first game project (discarding early Sinclair and MSX days) is over-ambitious, an adventure in four episodes with cutscenes, melee combat, physics and all.

But it's not our fault only: I think Torque raised our ambitions real good.

Then, what did we do? Our game will be just the first episode, so we don't cut the story at all (*fingers crossed*).

#32 Eric Risser, I like your project very much. It's just I'm too busy with my own uber-mega-ambitious one.

Some of our projects at GG can fail for lack of programming or art. But we can save our projects exchanging abilities: I program for you and you model for me, I build levels for you and you give me some models, and so on.

If we GG members were a single big team driving many projects, things would be easier. Or at least trade our skills between two or three teams at a time.

What do you guys think?

#33

Quote:Then how come EVERY postmortem of any game that Game Developer does lists "lack of planning and sticking to the plan" as the number one "things we did wrong".

Most of these postmortems are filled with comments that seem to suggest that more up-front design would have solved the problem.

I personally do not share this assemssment, as I think it is based in the assumption that using a more rigid approach would have solved the problem by allowing the developers to know what they could not possibly have known at the outset of the project.

Anyone who says they can design an entire game on paper and implement it according to a super granular plan is full of it.

Quote:From what I've read in Game Dev, here, and the "Game Secrets of the Mages" book there are two main trains of thought on game development. One is the well planned version; the other more fly-by-the-seat-of-your-pants

Development: Empirical or Planned?

One could say there are the planning "dinosaurs" and a few enlightened individuals who gave up pretending they could control everything and adopted methods that allowed for sane development in the face of changing or unclear requirements.

While the 'cowboys' move into the 21st century, the dinosaurs hold onto the notion that you can have a plan and hack away blissfully pretending that sticking to the plan will make everything peachy (if only marketing, managment, insert favorite target of ire, would give us more resources, more time, and get off our backs...)

I am not actually that gung-ho as this on the Agile approaches, but I though I'd present it like this to add some balance to the planning/ empirical debate.

Neither approach is the way as far as I am concnerned. Every project requires a different approach, and no one methodology will work for all teams and all projects.

There is a a balance that must be struck in all projects. I have said it before and I will say it again, there is no magic bullet.

As for ThinkTanks, we chose a project that was appropriately sized for the team.

#34 @David - you are the one that is putting all the weight into what I posted. For one I did not even mention Orbz, nor did I mention anything about MS Project or 200 page requirements documents. It really makes be curious why some people seem to take posts on a public forum like this so personally, especially when they and their project are not even referenced.

Overly ambitious projects are the topic of discussion, not Orbz, if you did not read the entire thread from the beginning.

@Joe - I don't think that planning to the n'th degree is an answer it leads to analysis paralysis, bloat and scope creep. But other than the Blair Witch project which was a complete anomoly, no one goes out rents camera's, people and actors and then says, lets see what we get in the end. They have a PLAN, and they stick to it for the most part. Why???

Doing professional film and video work proved on thing to me, 80% time and 20% money should be spent deciding on WHAT you were going to do, WHY you were doing it and HOW you were going to do it. It is much cheaper to to cater lunches for brainstorming sessions and decide that ideas are good or bad, or are good but just not feasible, than it is to spend the same amount of time coding something that would never work, if it it did work was a bad idea to begin with. This is a common theme of all the post-mortems, pet features or eye candy that ate up weeks or months just to be thrown out and the time could have been spent on things that actually made it into the game. Then your 80% of your money can get the job done quickly since you really know what to do.

I know I get a lot of negative feedback initially from people that I consult for, they are usually more interested in hacking and code over and over and over to make something that works already "more elegant or faster" than really try and solve a REAL problem. Because that would require thinking and thinking is hard work or more people would be willing to do it. In the end, the planning wins because it is a roadmap, to WHAT needs to be done, WHY it needs to be done and HOW it might possibly will be done.

There is no ONE RIGHT WAY, but there are LOTS of WRONG ways, and trying to seriously push the hack at it without any idea plan is one of the worse of the wrong ways, no matter how small the project.

#35

Quote:While the 'cowboys' move into the 21st century, the dinosaurs hold onto the notion that you can have a plan and hack away blissfully pretending that sticking to the plan will make everything peachy (if only marketing, managment, insert favorite target of ire, would give us more resources, more time, and get off our backs...)

I don't know, in my professional (non-game) life, the software the company develops generally gets the full design/planing 'works'. Requirements, Function Specification, Development Plan, QA Plan, etc, etc.

Seems to work very well, and almost everything comes in exactly on or a few days before schedule. If you have a group of like-minded people who know how to set up a good plan, the process works wonders and does save a lot of time.

#36

Quote:@David - you are the one that is putting all the weight into what I posted.

No, actually I didn't put much weight into your words at all.

Quote:For one I did not even mention Orbz, nor did I mention anything about MS Project or 200 page requirements documents.

The point I was trying to make in my second paragraph is that in order to tame a project, you do not necessarily have to micro-manage it down to the finest details, nor should you fly by the seat of your pants. We worked it somewhere in-between, and for us that worked pretty well.

Quote: It really makes be curious why some people seem to take posts on a public forum like this so personally, especially when they and their project are not even referenced.

You assume that I am taking your post personally, when in fact I am not. I just found it interesting that you described those two titles as the opposite of overly ambitious. Three guys working with no budget putting together a fun game isn't ambitious? What is the bar for an ambitious game then? If you didn't mean ambitious, what did you mean? Maybe you meant that the scale of those titles isn't large enough to necessitate much project management?

Quote:Overly ambitious projects are the topic of discussion, not Orbz, if you did not read the entire thread from the beginning.

And another example of what I felt you put in your first message - you being condescending. Perhaps I was wrong, but since we aren't in the same room having this discussion, it's hard to say. Based on this last apparently snide comment, however, I'd say that I was spot on the first time around.

#37 Well, since Marble Blast and Think Tanks were produced the wrong way, how many games have you produced the right way?

#38 I think a difference between creating a game and creating a non-game application is that the game appeals to the creative side--which also sparks emotional response. This thread has turned into a rather silly "right or wrong" argument, rather than what is more true: "Right for me, wrong for you."

Blair Witch had a plot lined out beforehand. It was very vague and general and worked well in that setting. Probably why it *seemed* more real than your normal Friday the 13th plot--it was spontaneous and we saw some raw emotions. While it is not going to go on any "Top 100 all time films" list, it still was entertaining and did pretty well for it's $25,000 budget.

And may I remind you that 'Blair Witch 2' actually had a script? lol err... talk about a rotten egg!

Rhetorical questions:

-Do you think well documented games are immune from feature creep?
-Is your game better off without the spontaneous aspects of artistic freedom (including programming)?
-Which is better: A well-rehearsed movie love scene or a never-rehearsed one?
-Do things always go as planned?

-Eric

#39 That's a great point Eric.

I come from an IT background and the most creative energies we had, when developing business applications, were in the technical solutions alone.

It's been an eye-opening experience watching artists of all different flavors, developers, audio engineers, and writers work together to create a new experience in a game.

Along with the challenge of throwing all of our different experience, backgrounds, and work ethics into the mix comes the amazing satisfaction of "getting it right". I've never quite experienced the pride I feel for Cyclone and Orbz at any point in my career.

I'll have to admit that I'm hooked - this job rocks.

#40 There is another point which is being missed contained in Joe's original post. Which is this:

Quote:
...is based in the assumption that using a more rigid approach would have solved the problem by allowing the developers to know what they could not possibly have known at the outset of the project.

People assume that with an up front plan wasted effort could have been avoided but this is a fallacy. Part of the planning of any large scale project is risk managment. In software development that risk usually takes the form of a lack of 100% detailed requirements. Saying that you could waste less time if you knew the requirements up front is true...but where are these requirements going to come from? Even for software projects that are *not* games (and I think games probably suffer even more due to uncertainty of what is "fun") it is not always possible to obtain those requirements at a reasonable cost and so they are not obtained. Real world software project management is very much about managing that lack of certainty.