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.

10 hours ago, Fulcrum.013 said:

If you speaking as expirienced programmer you have to know that computer is universal digit mill. Computer able to mill digits only. Illusion that computer able to do something else, comes from properly orginized process of digits milling. It is imposible to mill digits properly without exactly knowledge of mathematical background of process. Also it is what you can hear on your first day on any computing related university course.

I'm simply pointing out that in the context of gameplay development, that "exact knowledge" isn't possible because a lot of the time when you start a task, you don't have a complete picture of what the designers want from the code side. Oftentimes what a designer is asking for is a certain feel, and that's not really something you can mathematically calculate. 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. Sometimes in the middle of implementing it! I think I can count on one hand the number of times I've implemented a feature, given it to the designer, and they've gone "yep, that's exactly what I wanted, ship it." Not to mention that some beloved gameplay features started out as bugs or implementation quirks that people turned out to like.

I seem to recall that Diablo started out as a turn-based game and only became the real-time, visceral experience that defined the series when someone cranked the turn rate way up just for the hell of it. The game that shipped wasn't at all the game in the initial vision...

We are inventors making art, not engineers making Yet Another Enterprise Automation App that models an existing business process. The processes we're creating don't exist until we make them. There is a lot of experimentation and iteration involved here. There is constant feedback going between designers and programmers. If your university taught you that you can't implement software without knowing exactly what it's going to do, before you even write a single line of code, then I'm afraid your university was ignorant of how video games are made.

8 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.

This claim is a nice idea, but it doesn't actually match reality. Now, admittedly, my perspective may well be skewed by the fact that I'm in the game industry, working directly with designers, but I've never seen anything like what you're describing. There are no "complete descriptions of process rules" in gameplay development as it is done today, in any place I have ever worked. Yet, we seem to be delivering working software that satisfies our customers (designers/gamers) just fine.

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.

Anyway, the "working software over comprehensive documentation" point comes from the observation that in an evolving codebase (and video games are very much evolving codebases even before release - see my points on "big design up front"), it is very easy for the code to get out of sync with the documentation. Oftentimes one ends up in a situation where there is documentation, but it is so far out of date that it is misleading at best and outright lies at worst. Given the choice between undocumented, complicated code, and code that is "documented" with outright lies, I think I'll take the undocumented code. As a programmer, I can read code and figure out for myself what it does. 

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.

1 hour ago, Fulcrum.013 said:

I never seen a gameplay features that can not be changed data-driven way by designer.

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. 

If I'm working on a Minecraft clone and some designer wants me to place blocks in a circle around the player, rather than along the voxel grid, I'll almost certainly have to make a code change to make that happen, because everything else in the code previously assumed that blocks are put along a voxel grid and nobody anticipated that a designer would want to put blocks in arbitrary places. And, frankly, nobody should have anticipated that, because in this example we're building a Minecraft clone.

Excessive future-proofing is pathological behavior. It's how you get massively-overengineered codebases that are difficult to maintain and use.

I would add that what you seem to be suggesting would eventually lead to the https://en.wikipedia.org/wiki/Inner-platform_effect if followed religiously.

34 minutes ago, Fulcrum.013 said:

Games usualy models a huge set of real world technical objects that have to work automaticaly.

This is not generally the case. Video game objects are often coded in a way such that they work very little like their real-world equivalents. Some games don't even have any equivalent to real-world objects - what "real world technical object" does a tetramino represent, for instance? Again, not every game is a hardcore simulation (or Dwarf Fortress). Most gameplay is abstract to some degree.

34 minutes ago, Fulcrum.013 said:

Basics of Teory of automatical caontrol

So far as I'm aware, the only place control theory is used in most video games is in some AI systems for steering. I don't see how it would apply to much else, eg. a simulation of a weapon magazine or a healthpack. Granted, I've never studied control theory. I'm not sure I even took the prerequisite courses in university - differential equations wasn't a part of the curriculum for computer scientists where I studied. I'm not confident that a majority of game programmers have, either.

In short, gameplay programming is not nearly as mathematical as you are making it out to be, with the exception of some niche games that are heavily simulation-focused.

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.