5 hours ago, Fulcrum.013 said:

Any software intended to simulate/control some kind of  process (bussines/industrial/informational). So really key is determining of target process rules and required tools, of course by contacting of individuals that making process himself currently and individuals that have to implement process automation.

Individuals that making process is one kind of customer. Usually this person is someone who paid the developer to work on this item. 

5 hours ago, Fulcrum.013 said:

Working software can not be implemented without complete description of target process rules in form of mathematical/logical description or/and information schemes.

While this is true, quite often the requirements is completed. Documents are quite often up to interpretations. Most developer cannot read the most complex financial business rule or confusing law (trust me, I'm in this area of business). It's then the customer chime in to help evaluating whether or not the implementation is correct and precise. In this case it's the legal department or a head of business unit requesting IT to help implementing business rule in the enterprise application.

Again, customer does not necessarily mean the end user. This is especially true in game development (most of the time it's game designer in this context).

Of course, getting the end-users in would help in the user-experience area. 

5 hours ago, Fulcrum.013 said:

Customer is not able to determine rules of target process himself and have no ideas how to implement automation of process. It is just not his field of competence. Otherwice he just don't need to involve third parties for software creation.

Most of the time, the customer have an idea on the end product. They might not really knowledgeable in terms of implementation, but at least they know what they want. And if they don't really know what to make, we can work with them continuously until we come up with the product they really want in the end. 

5 hours ago, Fulcrum.013 said:

Professionaly made software do not require any changes until task field universal rules changed. Changes that fit into field rules, have to be implemented by a data-driven, end-user ajustable way. It is must have option for any algo.

The exception here is the universal rules is not always well known at the beginning of the project. The customer might have a vague idea (as I mentioned above), but they might not be able to state clearly what they want. It's up to the developer to work with them until we reach the point.

I think, the 'working with customer' idea is actually happening in game development all the time. When I was a game programmer I often ask the game designer to sit right next to me (he is the customer, I work for him, in this case), playing with the 'just-implemented' feature (most of the time... with bugs and mock-ups). He'd had feedback, and I change the code to accommodate them. We work together until we satisfy with the outcome, then move on to bug hunting and getting in the assets, and of course then retry again (yes the artists'd have to reiterate his assets to fit well with the game too). It's not like I have to complete the feature before I ask him to try.

With that said, I'm no expert in the field (although I'm wearing Agile66 shirt ATM). Experts in this area might say something else entirely. Who knows.

And, as far as I know, Agile methodology emerged from Extreme Programming practice. Some might find the XP interesting to read, although XP is entirely technical.

3 hours ago, Oberon_Command said:

I could see this happening with something like graphics or physics where the math and processes are coming out of academic journals, but in gameplay development it's usually being made up on the fly, based on vague concepts of what the designers want the game to feel like.

Actually, from the very little academic papers I was involved in it is even less planned than this.

You have a hypothesis: This method will look awesome in graphics.

Then you do it, and it only looks "meh" (or it renders much slower than you thought)

So you improve it, modify it, or even scratch it as a bad idea and switch to a completely different research subject.

When you start an academic research project there is no obligation to make any money, starting over is totally acceptable.

4 hours ago, Oberon_Command said:

In addition to that, I cannot think of a single instance where I worked on a game where the requirements for a particular feature didn't change in the middle of the project

I never seen a gameplay features that can not be changed data-driven way by designer.Any game object has his mathematical model that consists of set of parameters and proceses/events that can affect parameters. Types of events/processes is very similar, or even battay say have only difference is event affect parameter/set of parmeters instantly or start process that affect parameters some time continuosly. It just can be different set of parameters, that describe different objects into different games, but anything of it works similar, so can be coded once at engine level and than adjusted on game design by data-driwen way. 

4 hours ago, Oberon_Command said:

We are inventors making art, not engineers making Yet Another Enterprise Automation App that models an existing business process.

Games usualy models a huge set of real world technical objects that have to work automaticaly. Basics of Teory of automatical caontrol describe a wery simple ways how to get it working easy, data-driven ajustable and without any bugs.  Really tech objects can not be painted by artists, it have to be drowed by engineers to work smoothly. 

5 hours ago, Oberon_Command said:

We are inventors making art, not engineers making Yet Another Enterprise Automation App that models an existing business process.

Games usualy models a huge set of real world technical objects that have to work automaticaly. Basics of Teory of automatical caontrol describe a wery simple ways how to get it working easy, data-driven ajustable and without any bugs.  Really tech objects can not be painted by artists, it have to be drowed by engineers to work smoothly. It is consider both external look and internal behavior model.

3 minutes ago, Oberon_Command said:

the only place control theory is used in most video games is in some AI systems for steering

Anything that controlled by sensors can use it. Like as anything that have to change value withing time according to other values change.

4 minutes ago, Oberon_Command said:

or a healthpack

Of cource most of  health pack works instantly. But for any healthpac that works continuosly same regulations rules applicable.

7 minutes ago, Oberon_Command said:

Some games don't even have any equivalent to real-world objects

Really most of real-word objects work by more simplier way than coded into games. Especially auto aiming/stearing.

21 minutes ago, Oberon_Command said:

eg. a simulation of a weapon magazine

For example you can control a chance of cartridge wedging according to weapon standing and slope to the horizont.

37 minutes ago, Oberon_Command said:

There are limitations on how much a gameplay feature can be tweaked without it being a totally different feature. And someone still has to implement the feature in the first place. 

Those limits are 100% data-driven too. It is only difference on wich stage of logic/concepts development limits have be tweaked and on wich stage value have to be tweaked betwin limits.