26 minutes ago, Fulcrum.013 said:

any algo can not be developed properly without complete research of field. 

The problem is that product managers don't pay their development team to do research, they pay them to create a product that makes money.  So the agile development process is a way to perform that research while creating the actual product, which makes managers feel less bad about funding research.

While doing research, you discover "there is no way this will work" and try something else.

Where do you store your research before writing software?  In your head?  What if you forget?  On paper?  Then why not in code right away?  It's inefficient to make one copy of it first when it's going to be incarnated as software.  Just start with the software and save half the time.

Why spend time looking for logical flaws in your ideas on paper when you can just test it directly on a computer and know for a fact what the results will be, and then immediately use your successful algorithms because you've already written them?

If you know everything you need to do ahead of time, you either have a very big brain or a very simple problem.

59 minutes ago, Nypyren said:

 While doing research, you discover "there is no way this will work" and try something else.

Or the code does work just fine, and performs exactly the way the designers requested, but then the designers look at what they requested and go, "no, now that I've seen this actually working, it doesn't feel right. I don't think I want this anymore. I actually want something else now that's similar to this." And then it turns out that the new thing requires completely different code or at least a substantial rework of the old code. What would you have us do? Tell the designer "no, that wasn't what you asked for originally, you're not going to get it?"

If you had waited until the end of the project to have that conversation, you would have wasted a lot of time.

And there's no way that they could have known that the mechanic they originally wanted wasn't fun, because they needed an actual game prototype in front of them that they could play with in order to determine that.

Sometimes you have to do research at the same time as production. I would wager that large commercial video games are mostly cases like that. Innovative games (rather than yet another first person shooter of the year) even more so.

1 hour ago, Oberon_Command said:

Or the code does work just fine,

Code works fine only when it implement fine math that have be researched prior to code implementation. Mathematicaly proven that resriction of it rule causes wasting of time and budget money.

1 hour ago, Oberon_Command said:

And then it turns out that the new thing requires completely different code or at least a substantial rework of the old code.

Properly designed architecture not require to modify a existing code to add new features. Also in case field good researched before implementation, most of your complete new features affect datapack changes only, and only features that involve conceptually new behavior require some additions to code. Really target of researches is to find common universal rules of field that  allow to make a flexible data-driven implementations and avoid common pitfails so significantly  shorten development cycle.  

7 minutes ago, Fulcrum.013 said:

ally target of researches is to find common universal rules of field

In the video game industry, there is no such thing.

Please engage with the actual point we're trying to teach you. What do you have to say about Nypyren's post? I think he summed it up rather well.

2 hours ago, Nypyren said:

Where do you store your research before writing software?  In your head?  What if you forget?  On paper?

It depends from  team and project size. 

2 hours ago, Nypyren said:

hen why not in code right away?

For first becouse it is just very uncomfortable to transform equation into code editor. And for main to not waste a time for try to debug code that will never work properly. Only final proven math have to be coded.

9 minutes ago, Oberon_Command said:

n the video game industry, there is no such thing.

Common pitfail.  At least required to determine abstract entities, his zones of responsebility and relations betvin entities. It require to eliminate unnesesary code dependences and decomposite code to set of universal simple data-adjustable mechanisms, that significantly reduse complexiti of code and improve it flexibility. And it is applicable to any field.

2 hours ago, Nypyren said:

The problem is that product managers don't pay their development team to do research,

Stupid managers not pays for researches and as result fire his bussines.  Just for example review history of one researcher. 1983. As result of his researches he develop a turbo pascal language and as result give Borland a monopoly on pascal market. 1994.As result of researches he developt a Delphy language and as result give Borland a monopoly of RAD tools field.  2000 as result of researches he developt C# and as result give Microsoft a monopoly on tiny low and middle complexity software developments tools intended for low-grade devlopers field and also it used as scripting lenguages of some modern engies. Now he researches next-gen Java Script improvement and be sure he on really true way. 

Is AGILE Alliance members has bring his employers ever a single penny?

37 minutes ago, Fulcrum.013 said:

Is AGILE Alliance members has bring his employers ever a single penny?

Some very successful development  (examples) is AGILE, yes.

Your experience and methods are valid sometimes, but you really need to accept that sometimes alternatives work just as well or even better.

3 hours ago, Nypyren said:

While doing research, you discover "there is no way this will work" and try something else.

At least you has save time and resources avoiding implementing and endless debuging of something that  bever will work. As maximum you has find a proper waymany times cheaper than with coding without analizing way.  Generaly it related to some really innovative.

To shooter of the year generally aplicable researching of abstract entities. Any code directly or indirectly implement a state machine. So now just a very simple math. For example we have 2 state machines one have N states and other have M ststes. Two machines together have N+M states.  But single machine that have equalent action of both machines have a N*M states. So it have sence to decomposite anything to smalest possible bricks and construct game mechanic from its bricks, it significantly reduce implementation complexity and eliminate code duplication. Also it significantly increases flexibility. So it have a big chance that by just driving some data about fresh cannon meat to data pack you will have shooter of the next year by the way with minor or ever without game mechanics code change.