Which metodolgy is the fastest and the most reliable for making games? Rational Unified Process? Extreme Programming? Tool based (.NET wizzards, templates, RAD, Game Makers)? Some Agile? Which guarantees a successful project termination?

This is an interesting question -- though I suspect it will really come down to a particular house's pre-defined ways of doing things. Depending on the job, it can be useful to jump into code straight away (So, extreme programming) -- say, if it is a well-defined problem.

But of course, so many problems are not well defined and thus are helped by a good design process. So, if you decide to write a 3D engine for a game -- you will probably end up making careful choices about what you will do in order to get things done on time...rather than jumping in the deep end and hoping things work out OK -- in an industry where time is money, I guess less caution at the beginning of a job mostly results in wasted time and money near delivery date.

~Shiny.

[edit] tools that aid efficiency are always good. I've worked with people who love to program in VIM -- and more power to them...just don't expect them to complete anything as fast as someone who has a good templating system and code completion :P

Seems to me that some of the agile methodologies are having some success in the realm of game development. I've never quite seen a hardcore "implementation" of any one specific methodology; it's always been a mix of different ones like scrum and xp (for example)

Ok...
About Metodologies, It seems that in general there are two tendencies:

If you tend to desing, then you'll obtain a more planed project.
If you tend to program and test, then you'll obtain more results.

So is needed a tecnology that equilibrates these two tendencies.

In the past, I was working on a 3D engine with a desing approach (UML and RUP), designing use cases, analisis, interaction diagrams and more diagrams. But what we've obtained with this is a totally mess and a lot of waste of time. At end we've noticed that all desing is wrong when making the implementation. Many of the design strategies were asumptions about the tecnology. Months of lot of thinking, but when we've tried to pull down all those diagrams to earth, all those pieces doesn't chase. So complex to implement, and its performance was the worst.

Many of the problems of any 3D Engine are their algorithms. But always exists unknown problems that concern to the compiler or system architecture. For 3D engines, you have to know the machine in depth, that is possible only with the experience. Writing and test all time. Design while you're coding is the key. Focus, and don't worry about the rest of the problems. Game making is more a scientific work.

Jonh Carmack wasn't follow a design metodology for his engines. Tecnology drives the work on ID software.

Don't think that I agree to jump into the code without thinking. Before of that, you'd need to identify all the patterns concern to the problem, and make a system that parametrices all the solutions. Make it Flexible, and simple.

RUP seems to work on database projects. But for gaming ?

Off topic: I don't mean to be mean, but the grammer in some of these posts makes them hard to follow :(

On topic:
Personally I'm going with the design first method. My ideology is as follows

1 - Start complex (list requirements, goals, go into detail) and stay abstract (Class resposibilities are defined but the methods are not. Inheritiance and responisibilities are diagrahmed.)
2 - Then simplify (cut unnessary classes/methods, refactor design)
3 - Then implement (code/test)
4 - Adjust design as needed and repeat from the first step.

I never tried UML but the idea of a modeling language seems silly to me (lines + boxes = enough = common sense) unless you are using a tool like Alloy to aid in your design phase.

Quote:Original post by leoptimus
Which [methodology] guarantees a successful project termination?

No methodology in the world can guarantee a successful project delivery!

It seems that many of the game developers doesn't want to make full documented game architectures, as John Carmack:
http://www.gamedev.net/community/forums/topic.asp?topic_id=394912

Also OGRE3D, while Simbad claims that his engine is fully documented and object oriented, it only has a few class diagrams, but doesn't have any of the other diagrams : such interaction diagrams, Use Cases, Analisis, states, deployment etc. All OGRE3D documentation is doxygen made, and it is totally understandable, and well designed. So, notice that OGRE3D is big enough for make it serius project. All the time, OGRE3D development was driven by features as software requirements.

Many times, for practical reasons, developers prefer to understand a system architecture from its interface documentation like Java Docs or Doxygen, instead of tons of UML diagrams. And many of advantages of documenting from code with doxygen is that you don't waste time making redundant diagrams that comunicate the same. You'll save time for programming and getting more results.

And the stakeholders(users), those uml documents mean something to them? experience says that they prefer stories in natural language.

So, the main goals of UML and Unified Process doesn't have fulfilled, while this design aproach is designed for big projects like game development.

Fully detailed project management doesn't have sense in this century, because is impossible to predict everything that will occur!!