Yeah... thanks, but I'm not going to do that. I don't need to define all the behavior through mathematics. I encountered formalism in university and I found it incredibly time consuming and unproductive to boil everything down to equations, especially for non deterministic systems or systems with emergent behavior.

What I want is an architecture, not a notation, which should have been made clear by my original post.

Uh... wow. You start off asking about a "fuzzy controller" and yet you don't want to use math? So if your FSM transition logic said, "if health < 10..." you would eschew it because it contains math? How the hell else are you going to define behavior logic other than bland if/then statements on boolean criteria?

If I offered you three prizes: A is worth $10, B is worth $7, and C is worth $4 and asked you to pick the most valuable prize, all other things being equal you would pick A. That is math. You have just defined your own behavior through math... namely the utility that each prize represented in monetary value. In a nutshell, that's all a utility system is. In this case, it would be executed simply by picking the greatest value... hardly rocket science.

Methinks you should read the book before dismissing the single most important concept in decision theory. There is surprisingly little complicated math.

Reading back through your posts, I saw this:

... and the top layer would be a fuzzy controller which selects, based on what is happening, what the priorities are, from a list which is different for each entity.

That, sir, is a utility system. Read my book.

[font=arial, verdana, tahoma, sans-serif][size=2]In that case, I'm not entirely sure what you mean by "defining the behavior through mathematics" because to me, this sounds like I have to use some kind of math notation, such as ITL, to define the behavior of the entire system. I've done this in the past for highly deterministic systems, and it worked OK there for the most part, but only if I made a lot of assumptions about the input data.

For my degree I learned a language called anatempura which is an executable form of ITL. It was fun, but not productive - what you said set my mind back to when I was told that one could define the entire system using mathematical notation, and test the notation using tempura. Needless to say, I wasn't very impressed by the results. For the most part, it seemed be just academic masturbation with little practical application. Your signature also caused me to think you were saying the same thing - "reducing the world to mathematical equations".

[/font]
OK so here's what I plan to do: my FSM will be controlled by a controller which has one function for each task, the output being a single numerical score. I'll average the scores over a number of frames to avoid sudden spikes, and ill switch to the task with the highest score on the list. To simplify things, I won't try to execute more than one task at a time, or else the tasks would fight over the state of the entity.

Does this make sense, or do I need to buy a book to find out?

Sounds like a pretty vanilla utility architecture.

Where the mathematics comes into play is in generating the scores (typically normalized to [0,1] or [0,100] or whatnot) for various actions. You do need to do some equation modeling to come up with good metrics for this, but it's a far cry from "express everything in greek letters" style formalism. Really it just boils down to questions like "how do I generate a score value to decide when to run away from an overwhelming enemy force?" and stuff along those lines. Having some good mathematics experience is very helpful here; for instance, you might want to use different types of interpolation (linear, piecewise linear, cubic, logistic, etc.) to get the score to ramp up in urgency when certain factors come into play, and so on. One good example is "run away from 10 guys with machine guns or 2 guys with rocket launchers" - you need to do some math to blend these numbers onto a normalized output.

That's really all we're saying here.


For the record - I haven't personally read Dave's book, but if you have any uncertainties about tricks or techniques for generating/tuning the equations involved for modeling your scores, it's a fantastic starting point.

"They need to keep close to a formation relative to the boss vehicle, dodge projectiles, and attack the player."

these are things that happen after decidsion are made -- flocking behavior and pathfinding, influence mapping to effect pathfinding
(network nodes adjusted with how risky areas are within range/boresites of enemies or close to supporting units)


Some of these methods make micro decisions (pathfinding decide next step of best path) but the high level decision are as to what targets and
what overall action/tactic (attack/retreat/digin/scout/delay etc...) the units/groups of units are to attempt.


Long ago I looked at planners (hierarchical solutions to decide) between options (strategies/tactics) and how to unify metrics of judging situational factors
(how to calculate the priorities of solutions->actions and how to estimate especially with alot of unknowns). Cost and risk versus rewards and how the
different factors changed these. Much was just observation within the game mechanics and adjusting the decision calculatons - there are AI factoring techniques
to do this while playtesting scenarios (LOTS of scenarios).

Many decision factors go into curve functions that escalate importance before being summed to the
single value that is to be compared between competing solutions (also may be a vector of a few summary values that are further adjusted by overriding
functions (like a damaged unit might be 'cautious' and thus exagerate the negative aspect of risk or an overall 'do or die' order might minimize it and likewise
a payoff of attaining a target might be minimized in importance if there is little value to what is gained)

It gets even better when you start projecting possible actions of the enemy in the near future and how to not necessarily take the optimal
action for the current situation but often the position with the highest utility for the future (ie- setting up an ambush in a pass that you see the
enemy is moving towards (expending resources on a strong defensive position instead of a risky frontal charge)

Sounds like a pretty vanilla utility architecture.

Where the mathematics comes into play is in generating the scores (typically normalized to [0,1] or [0,100] or whatnot) for various actions. You do need to do some equation modeling to come up with good metrics for this, but it's a far cry from "express everything in greek letters" style formalism. Really it just boils down to questions like "how do I generate a score value to decide when to run away from an overwhelming enemy force?" and stuff along those lines. Having some good mathematics experience is very helpful here; for instance, you might want to use different types of interpolation (linear, piecewise linear, cubic, logistic, etc.) to get the score to ramp up in urgency when certain factors come into play, and so on. One good example is "run away from 10 guys with machine guns or 2 guys with rocket launchers" - you need to do some math to blend these numbers onto a normalized output.

That's really all we're saying here.


For the record - I haven't personally read Dave's book, but if you have any uncertainties about tricks or techniques for generating/tuning the equations involved for modeling your scores, it's a fantastic starting point.

The equations frequently have to be 'modal' with if then logic to select which equations apply depending of situational factors AND to eliminate use of irrelevant factors to
specific situations.

Sounds like a pretty vanilla utility architecture.

Yep... he's on the right track.

...but it's a far cry from "express everything in greek letters" style formalism. [/quote]
Which I'm well-documented as finding distasteful anyway.

One good example is "run away from 10 guys with machine guns or 2 guys with rocket launchers" - you need to do some math to blend these numbers onto a normalized output.[/quote]

Almost exactly the example from chapter 14... which brings me to...

For the record - I haven't personally read Dave's book
[/quote]

After all the quality time we've spent together? Of course, you've seen my GDC lectures on the subject... *shrug*

I'm sure if a complimentary copy mysteriously arrived in my mailbox I'd jump at the chance

I used such a system on a project at work, but it wasn't really typical AI. We used a state machine where each node had one or more fuzzy logic controllers built in to simulate interaction of complex machinery. So for example, Widget A would have a state machine and each node of Widget A's state machine had fuzzy logic graphs for tank Level, oil pressure, coolant level, input pressure, output pressure, etc.

Similar. The difference is that you were using actual concrete values. Utility is often a measure of something intangible -- i.e. what it means to us. Often converting a concrete value to a utility value is a good idea. For example, the number of bullets in our gun can be mapped onto the "desire to reload". And its not necessarily linear.