12 minutes ago, Fulcrum.013 said:

Determined rules is constant  becouse it universal. So it have no any sence to code until complete set of process rules determined. It is how scientific-driven software development works into any fields including bussines, factory automation,  scientific software and anything else.

But this isn't a scientific-driven software industry. We are neither automating factories nor writing autopilots. This is the video game industry - an artist-driven industry. We don't work the way other software engineers do. Our rules are neither constant nor universal. There are only the whims of the designers, marketers, and producers (especially producers!), and those whims are fickle indeed.

What you are saying simply does not apply to the world that I live and work in.

Consider the following hypothetical story:

You're working on a tank game, something like a sci-fi, futuristic World of Tanks. In one of your playtests, a designer says, "It would be awesome if this tank could have some sort of rapid fire mode where they spew a bunch of projectiles really fast each time you fire! Like in a burst!" The other designers all hear this and agree that this does sound awesome. This wasn't in the original plan - there was no plan to support any such tank originally, but now the designers want it, and they want it fast. Like, by tomorrow morning fast.

It's pretty easy to modify the game to support this - the tank's cannon has a "cooldown" timer that you can just ignore for the first 6 shots (for example), with the number of shots per burst being data-driven (because of course the designers didn't tell you how many shots per burst they wanted :P). You wire up some logic quickly and get a build out to the designers. They playtest with it for a few hours, and then (rather glumly) decide that it isn't as awesome as they thought it was, please remove it. This is easy, because you made the whole thing data-driven, true enough. But furthermore, what would be more awesome, they decide, is if your tank could have an extra, smaller gun that behaved this way. So you go back and move your mods from the main gun logic to the auxiliary gun logic, get a build to the designers for them to fuss with... And round and round it goes.

A year later, an executive finds out about the old "burst shot on main cannon" mechanic and demands that you bring it back because "that other tank game we're competing with has it." And he's an executive, so of course you have to do it...

There is no constant, universal description of the tank game I just described. The designers just made shit up during a playtest and wanted to see how it would feel. The only specification of the game is a combination of what is already there, coupled with what work remaining is currently planned. Any of that work might be cancelled or deferred or new work created at any moment, at the whims of the people in charge. There is no fixed specification for this tank game. 

This is the kind of environment agile development evolved to serve. Which development methodology do you think is more suited for this kind of environment? I couldn't imagine doing this with waterfall. "Big design up front" is obviously impossible, because the specification wasn't known at the beginning. Or are you trying to argue that the designers shouldn't get to say anything more about the design once the programmers start? Or that programmers should have anticipated that the designers would want burst fire and implement support for it in advance? That definitely wouldn't happen - that time would be allocated to implementing stuff that designers want now.

22 minutes ago, Fulcrum.013 said:

"Snils" (Ganja Interactive) uses even more advanced technicue where most of vhechie parameters calculated from geometry model.

That's real neat and all, but in the example I gave, that technology is not only not available, it isn't necessarily relevant. This could (and probably would) happen in the prototyping stage - at this point, the tanks could be grey boxes driving around in obviously fake grass because the concept art team hasn't figured out what they're going to look like yet. The designer just wants to be able to do burst fire, to see how it feels, and the engine doesn't support that because, when you were doing the initial implementation, they didn't ask to be able to adjust that. So, the requirements for the software have changed from when you started. Without warning.

Imagine you don't have access to any of the technology you're talking about. What development methodology do you use to handle an environment where this happens? And don't just handwave "I ask the designers at the start of the project" or "I make everything tweakble" because, as I have repeatedly said, that isn't generally feasible. There simply isn't time to make everything tweakable in the kind of environment I'm talking about and there are always cases where they ask you for something that you didn't think of even if you do try to make all the things tweakable.

How do you handle cases where requirements change in the middle of the project with your methodology?

I think I'm going to stop responding to your posts in this thread now. You clearly don't have any desire to engage with my actual points and that is profoundly frustrating. Good day, sir.