What ever happened to...

Other talk that doesn't fit elsewhere.
This is for General Discussion, not General chat.
User avatar
Rman Virgil
Professional
Professional
Posts: 3812
Joined: 25 Sep 2006, 01:06
Location: USA

Re: What ever happened to...

Post by Rman Virgil » 20 Sep 2007, 00:47

2_Late wrote:
Clear as mud now?
* Heh... actually I think i'm tracking well what you mean. :)

* You've done a good job explaining. IMO, and, if i'm not mistaken on comparing the nuts 'n bolts, can appreciate the techique's effectiveness from a stellar implementation in an other genre game that has made quite a mark in the industry.

- RV :)
.

Impact = C x (R + E + A + T + E)

Contrast
Reach
Exposure
Articulation
Trust
Echo
.

User avatar
DevUrandom
Regular
Regular
Posts: 1690
Joined: 31 Jul 2006, 23:14

Re: What ever happened to...

Post by DevUrandom » 20 Sep 2007, 10:20

[me=DevUrandom]throws in: Responsibility [/me]zones.
Let the game-ai assign zones to each turret, which are the prefered locations to fire at. As soon as an E leaves that zone calculate whether we have a better target in the zone and only if not attack the former target further.

Comes similar to constant target evaluation. I don't know if this is done already, but the last time I really played, the turrets would fire on "their" target as long as possible (range-wise) and would ignore further incoming enemies.

User avatar
Rman Virgil
Professional
Professional
Posts: 3812
Joined: 25 Sep 2006, 01:06
Location: USA

Re: What ever happened to...

Post by Rman Virgil » 20 Sep 2007, 13:26

DevUrandom wrote: [me=DevUrandom]throws in: Responsibility [/me]zones.
Let the game-ai assign zones to each turret, which are the prefered locations to fire at. As soon as an E leaves that zone calculate whether we have a better target in the zone and only if not attack the former target further.

Comes similar to constant target evaluation. I don't know if this is done already, but the last time I really played, the turrets would fire on "their" target as long as possible (range-wise) and would ignore further incoming enemies.
* Good one, IMO. :)

* But why not allow the Player to "Paint" the Zones ?

* And why leave at emplacements - how about Commander led combat groups ?

* Reminds me of AI in American football sim called Madden - esp since 2003 with customizable "plays & playbook" (I explain that possible, & astonishing,  relationship to WZ in my "CAM Script Trigger" thread [url=index.php?topic=913.msg8726#new]HERE).

- RV :)
Last edited by Rman Virgil on 20 Sep 2007, 14:48, edited 1 time in total.
.

Impact = C x (R + E + A + T + E)

Contrast
Reach
Exposure
Articulation
Trust
Echo
.

User avatar
Rman Virgil
Professional
Professional
Posts: 3812
Joined: 25 Sep 2006, 01:06
Location: USA

Re: What ever happened to...

Post by Rman Virgil » 20 Sep 2007, 14:53

Troman wrote:
Sorry to be a party pooper, it sounds interesting, but I wouldn't be too excited about it now.

There were so many promising techniques: Bayesian Networks, Genetic Algotithms, Neural Networks (and synthesis of the last two), Fuzzy Logic, Goal Driven Behavior, Fuzzy State Machines, Decision Trees etc and tons of 'fancy' names of less generalized approaches used in weak AI, that do enrich AIs, but they just didn't managed a major breakthrough, at least not in game AI.

Whether Goal-Oriented Action Planning and Rete will managed it, time will show.


* It was implemented in the mega hit F.E.A.R. in '05 (you check it out and you'll get excited too - maybe, heh ;)) and will continue in the sequel F.E.A.R. 2 - which has evolved into being called "Project Origin".


* You can get "F.E.A.R." for bargin prices now because it's 2 years old and the sequel is in final dev stage. The A.I. will blow you away - this approach works phenomenally well and is considered a breakthrough by the game industry itself from everything i've seen.

* The central issue (or potential bottleneck in common place practice) has been the standarization of a useable and widely accepted game AI API (this began in earnest in 2002 and the latest published report is from 2006 werein you can see how GOAL fits into the game ai middleware scheme of things). 

* Because there is so much work involved with the GOAL/Rete approach, reuse & portability become really key economically speaking and can only be advanced by a game industry wide common reference standard. At least, that's  how interpret the evidence so far.


Cheers, RV :)

EDIT:
We could theoretically use something like that to deal with research in WZ ....., i'm not proposing it though, just absolutely not worth it in our case
* Heavens to Betsy, totally agree, that would be like retro-fitting a golf cart with a turbo diesel.

* Commander A.I. is, upon refelection here and now, where I see the fit in WZ.

* EDIT 2: Also.... Electronic Arts keeps their game tech close to the vest but if I had to make an educated guess (admittidly as an ai novice) I would say since 2003 and the introduction of customized plays and playbooks in Madden football - some use is being made of G.O.A.L. / Rete (full implementation with Justification and Rules support) in that games A.I. Modus.

* SideBar: (Now because "Madden" is a franchise going on 20 years old, the economies of scale and an established, built-in, market come into play when it comes to making the resource intensive investment in a full G.O.A.L./Rete A.I. implementation...... aka, REUSE of assets year to year is guaranteed unlike a first time, new game release which could just die after initial release and have NO sequels over which ammoritize overhead / investments in new SW tech like such formidible a.i. implementations..... The same economic strategy comes into play with movies - like in with sequels or trilogies that are shot simultaneously, recent ie. being "The Lord of the Rings" or "Pirates of the Caribbean')



* Now exactly HOW this Modus can relate to WZ I've explained [url=index.php?topic=913.msg8726#new]HERE
Last edited by Rman Virgil on 20 Sep 2007, 15:56, edited 1 time in total.
.

Impact = C x (R + E + A + T + E)

Contrast
Reach
Exposure
Articulation
Trust
Echo
.

2_Late
Rookie
Rookie
Posts: 29
Joined: 06 Sep 2007, 23:21

Re: What ever happened to...

Post by 2_Late » 20 Sep 2007, 23:12

Sorry, I'm being supper A.D.D. and leaving details out all over the place(and words, oddly, but that's neither nor there :P). That and each time I have to rethink it becomes more defined.
DevUrandom wrote: [me=DevUrandom]
....Let the game-ai assign zones to each turret, which are the prefered locations to fire at....
Rman Virgil wrote: ...
* But why not allow the Player to "Paint" the Zones ?
...
Because the zones are not like a city districting zone(you can build this there, but not this here). Neither are they randomly generated numbers. Each zone represents a possible outcome that the AI could choose. No matter how you arrive at that possibility, by a random roll of the dice, or a super powerful mathematical thing; In the end there are only a set number of outcomes. I suppose you could combine zones to simplify things, but you'd be making the AI dumber with each combination.

Image, the only thing that exists in the world are two turrets. One on the left, and one on the right. At some point in the middle the range that they can fire in overlaps. That gives you three zones.  If each turret is the same type of turret ,from these three zones there are I think there are nine outcomes.

1. Neither turret fires.
2. Just the left fires in it's own zone.
3. Just the left fire into the overlapping zone.
4. Just the right fires in it's own zone.
5. Just the right fires into the overlapping zone.
6. They both fire into the overlapping zone.
7. The left fires in it's own zone and the right fires into the overlapping zone.
8. The right fires in it's own zone and the left fires into the overlapping zone.
9. They both fire into their own zones.

What the idea would do is work though each possibility and resolve what would have to be in each zone, if anything, to make that outcome desirable. Which would make some huge, bloated table. This why we don't use 'Rules of Engagement' for anything practical, and why I remembered route summarization. Some thing can't happen at the same time, or the difference between firing a third or fourth turret to assist the first two is merely semantics. This simple example only has two identical turrets so it's not supper example of what could happen. I guess is some what like Rman Virgil's Rete.

From there each outcome would have some plan of attack attached to it. The zones being laid out by a mathematical function is somewhat critical.

From there we'd construct some kind of logical structure. I suggested a if/elseif/else tree, but things are a bit more complicated then it could easily handle. I's like to revise that to a set of, "nodes" I guess. Each node having a plan of attack attached, and a set of conditions needed to jump to another node. Not some thing as methodical as having a second turret start firing as soon as it's in range, but that turret also being needed. Then to simplify have each plan of attack that starts with only one turret firing be attached to the relevant turret.

In the end what all this would do, besides giving someone a headache :P , would keep the game from having to recompute each possibility and decide on a outcome. Instead it would just evaluate a threat, open the play book to page 23, and start blasting.

User avatar
Rman Virgil
Professional
Professional
Posts: 3812
Joined: 25 Sep 2006, 01:06
Location: USA

Re: What ever happened to...

Post by Rman Virgil » 21 Sep 2007, 10:31

.....................

* 2_Late:

* I see what you mean now. It's more sophisticated than what I was thinking when I said "paint" (I was actually stepping away from the complexity of the "G.O.A.L. / Rete" MO for a second to look at it differently, perhaps more K.I.S.S., more feasible.)

* When I said "paint"  I was suggesting emplacements utilize a command screen analogous to combat units with "painting" space akin to the extant "Guard" Command. That is - like a unit being assigned to guard a struct, other unit or emplacement...... the act of "painting" assigns map coordinates for the emplacement to "Guard" which puts decision-making back in the gamers hands & also by restricting the tracking rotation to discrete angular slices (instead of 360) somewhat deals with ordinance waste / stupidity: not just AA batterys but, by extention, Arty too esp.

* That said.... my preoccupation in this area right now is dealing with "MAV Drone Tech" relative to Threat Evaluation and "Fog of War" (FoW) as it is implemented.

* I cannot seem to ignore the existence of MAV - which renders FoW, IMHO as it is concieved, a mask or crutch for weak game design - as well it represents an opportunity to confront obsolete assumptions and create something both more interesting and robust - I hope. ;)

Cheers, RV :)
Last edited by Rman Virgil on 21 Sep 2007, 10:49, edited 1 time in total.
.

Impact = C x (R + E + A + T + E)

Contrast
Reach
Exposure
Articulation
Trust
Echo
.

Troman
Trained
Trained
Posts: 424
Joined: 12 Aug 2006, 15:40
Contact:

Re: What ever happened to...

Post by Troman » 22 Sep 2007, 18:08

2_Late, from what you described I would have never managed to implement the algorithm, at many places it is still puzzling me.
This way instead of spending valuable CPU time making one up as you go you've already worked out a very effective, very good, very deadly, very adaptive plan that would have taken you many nano-seconds to come up with before.
Well, the question is how to create such a "very effective, very good, very deadly, very adaptive plan". That's the heart of the matter. And some of the participants of this discussion seem to oversee this fact.

I will try to prove you that this is exactly what is needed and exactly when is missing in the description of your algorithm.

Let's clarify your word choices first.
To start you would have create every reasonable scenario.
What is a scenario? I understand you are not a native speaker, but without understanding the idea that stands behind the word I will never get the whole picture (no pun intended, I'm also not a native speaker, so it's harder for me to guess the meaning from the context).
That would require a whole set of rules to keep from computing every statistical possibility
What are rules and what possibilities do you mean?
As far the rest of this exercise is concernedly the only world that exists is a black and white list of angles and ranges that your turrets can fire at and where they overlap, Zones of Fire(ZoF) if you will.
Ok, I will not ask what algorithm you will use to create zones, only this operation alone might take more CPU time than some other alternative target acquiring algorithm. What I wonder is: how exectly do you want to save zones? What exactly will you be saving?
Then compile or update a list of possibles with each turret either not firing , firing in it's ZoF, or a ZoF that overlaps with its own.
What exactly will this list consist of? And how will you decide about firing/not firing?
Instead of counting each second by second as a senerio plays
Here you have in mind some alternative hypothetical algorithm you compare your own algorithm with. I don't know what assumptions you have about it, but in order to support your statement you'd theoretically have to explain that as well, otherwise it doesn't make much sense to compare the algorithm you describe and CPU time gain to some of countless possible algorithms that might count 'second by second'.
After that the list of possibles is finished, We'd need to compute what kind threat enemy each design represented.
What will you take into account when computing it? (the 'how' question again)
Then based on the likelihood[...]
How will you compute likelihood?
[...]of each threat being destroyed before it posed a threat to a defense, we'd then decide how threatened a ZoF would have to before a turret or set of turrets would open fire on a target.
Again, how? I don't expect the ready algorithm, just basic steps to get the idea.

Another issue: what if you decide not to open fire at it, will you just let it fire at your defenses without returning fire?
Then compute what the maximum threat value before a type of target is ignored("Ignore the lone big guns we're being over run by ants").
When I read "compute" I'm instantly asking myself "how?". And how will you defferenciate betwen big and small guns and between "ants" and bigger targets?
Finally we'd compute how big a threat in between overlapping ZoF would have to hold before redirecting a turret to concentrate fire on given target. ("It started out as only you had these ants to fire at. Now I do too. Hey! It takes two shots to kill these guys, lets two shot them together!")
How? If you have many defenses there will be a huge number of overlapping zones, would you store and consider all of them?

The enemy units can be constantly moving and the situation can change very fast (either defenses or enemy units get killed). This might make your defenses get new targets way to frequently, so they might end up in spending more time for turning around than shooting. Have you considered this?

Another question: how are you going to deal with microscopically small zones enemy units will drive though and the fact that the defenses get zones assigned and not the targets directly?
Now that is done the ZoF can be stored on the hard drive in case we need them later(a turret built or lost).
Not sure why you want to save it to the hard drive.
We can then start building a hierarchy of If/elseif/else statements using the computed threat ranges from the 'Rules of Engagement' table.
You can't really do this, unless you don't mean it literally.
Hopefully most of the needed CPU time is spent making the making a 'Rules of Engagement' table, and the if/ifelse/else tree.
From the way you described it I have a feeling this approach will not save any CPU time, to be honest.

I can't say anything about the "Rules of Engagement" table now, because I don't have a clear picture of it.
This table should also include the possibly that a turret is destroyed and adapt accordingly. It can then be rebuilt after the fight is over. The reason for this is we don't need to take a huge chunk of CPU time mid battle just because we lost a basic machine gun tower.
This is what you will be doing when you will have to recalculate the table when a new turret is created at a new position for the first time, no?
Each plan or possibility would also be tweaked based on what the turret was and it's proximity to other turrets. An example would be if a morter was in front of or behind a line of turrets. Though I'm not really sure how to make that absolute judgment based on relative positions.
That's where the real 'how' problems, that AI developer has to face, kick-in. ;)

Taking in account my current understanding of the algorithm you described I wouldn't call it a very good solution for the problem. It's clear that you put a lot of effort into your ideas, but I have a feeling you havn't discovered the true problems, especially those ones that become apparent only when you start dealing with the details of the algorithm as opposite of the rough "what-to-do" plan.

Even if your approach could save some nanoseconds, I wouldn't sacrific maintainability, complexity and especially effectiveness for little speed gain, especially when it comes to AI.
Sign Up for Beta-Testing:
?topic=1617.0

Troman
Trained
Trained
Posts: 424
Joined: 12 Aug 2006, 15:40
Contact:

Re: What ever happened to...

Post by Troman » 22 Sep 2007, 18:22

themousemaster wrote: This is what I get for making assumptions about the game without reading the actual code.

You mean the WZ target calculation algorithms are all structure-independent?  100 AA sites "controlled" by a single tower would requrie the same CPU overhead as 100 AA sites all independently targeting?
There is a little overhead created by sensor towers, but it is neglectable.
What I meant is that an additional sensor tower will not decrease the number of required computational steps, the sensor tower should be taken symbolically, it is actually only needed for the player, to demonstrate that his possibilities have widened.
themousemaster wrote: Oh, and as I mentioned, such a network WOULD have its weak point:  the tower.  Taking it out would be a suitable alternative to a Human Wave of planes ;p
Yep, that's why I liked the idea.
Sign Up for Beta-Testing:
?topic=1617.0

2_Late
Rookie
Rookie
Posts: 29
Joined: 06 Sep 2007, 23:21

Re: What ever happened to...

Post by 2_Late » 22 Sep 2007, 23:48

Sorry, I just keep babbling on. I am a native speaker I just don't do English very well. I don't even do non-English things very well because I have trouble staying focused(no duh, hu?) My plan as a whole is complicated, but it's made up of small steps. Each doing something simple over and over again to prepare some output for the next step. That does the same for the one after that. In the end covering every computation that should ever have to be done and storing it's output in some easy to use format.

I guess I'm drawing from how a router works again. It has little more power 133Mz PC has back when they where new, if that much. The actual routing part of a router takes a few simple inputs , uses that to build a few basic things. Then uses those basic things build it's routing table, what it uses to know what packets go where. The 'basic things' that is it is built from might take megs of memory, but the table it's self is always less then a single kilobyte, and that's a stretch. Maybe a ISP's backbone router(something that's responsible for a large portion of the Internet's traffic) has a routing table more then 150 bytes.

In the end the idea is just a gamble that I've covered everything ahead of time, and referencing what I found out about that thing is quicker then going over it again.

Ok, down the list:

The zones of fire.
As far the rest of this exercise is concernedly the only world that exists is a black and white list of angles and ranges that your turrets can fire at and where they overlap, Zones of Fire(ZoF) if you will.
Ok, I will not ask what algorithm you will use to create zones, only this operation alone might take more CPU time than some other alternative target acquiring algorithm. What I wonder is: how exectly do you want to save zones? What exactly will you be saving?
Your right this will take a large chunk of CPU time! That is the point, to take it all now and little to none later. Instead of taking little bits of time doing the same thing throughout the game we do it all at once. Either just once, or only more as needed. As for the how? err I still haven't had to spare time to read the source code. I can suggest a method though. Use polar coordinates to first find if one gun range over laps, from what angle to what angle they overlap at, and from what range to what range they overlap at. I can never keep I can never keep the formula's straight without a trigonometry book in front of me; However, once you figure out what pattern of angle and distances fit what formula(and find the formula) a computer makes trigonometry like connect the dots. Once you figure that you need the formula Delta=COS(X/Y) and what to plug into X or Y your zone the computer takes it from there.

After you figure every angle and range you can just feed that to another loop that will sort out and numbers each separate set of angles and ranges, Zones of Fire. What you end up with is every combination of every turret either firing on unspecified target by it's self or with one or more other turrets. Then either in another function or preferable the same one attach a turret can fire in what zones. This way we don't have to come back later and ask which turrets fire in which zones. Unless bits of information by it's self...
Then compile or update a list of possibles with each turret either not firing , firing in it's ZoF, or a ZoF that overlaps with its own.
What exactly will this list consist of? And how will you decide about firing/not firing?
To start you would have create every reasonable scenario.
What is a scenario? I understand you are not a native speaker, but without understanding the idea that stands behind the word I will never get the whole picture (no pun intended, I'm also not a native speaker, so it's harder for me to guess the meaning from the context).
How do we decide to fire or not?  We're not that far, but close. I'm working backwards so for now we just assume that if a turret is firing something needs to be shot  ;D .
Next we have to go though every combination of every turret either not firing or firing once into one of the connected ZoFs.
Instead of counting each second by second as a senerio plays
Here you have in mind some alternative hypothetical algorithm you compare your own algorithm with. I don't know what assumptions you have about it, but in order to support your statement you'd theoretically have to explain that as well, otherwise it doesn't make much sense to compare the algorithm you describe and CPU time gain to some of countless possible algorithms that might count 'second by second'.
You make a very good point, thanks! The idea was it was possible for a machine gun to fire a few dozen times in the same time it takes a Hellfire artillery site to fire once and reload. I was assuming that they all start firing at the same time, and they don't have to. For now ignore the rate of fire issues. If we tried to fix it here it would it could easily multiply the list of combinations a few hundred times over, if not thousands.

Why put this on the hard drive? Honestly I don't know. We're almost done with it and there shouldn't be a huge demand for it. I guess it's a bad idea though as many times as things are built and destroyed.

How a plan is made?

We now know what we can do, but why do we want to do it? I left that kind of vague. Ideally, sense we're doing all this all ahead of time and do not have to hurry up and think of something now...Use your imagination. Why would we only want to use two of the fifty of the AA turrets, or just the assault cannons when we have a line of sixty Hellfire artillery just behind them? Maybe we want to fire everything we have at a single target? Maybe we just want to use the two AA turret because the only thing coming at us is slow enough that these two AA turrets can wipe the floor with it before it get close enough the drop it's bombs.

If (Target's_ETA =  Find me a Target();
    Order all cannons to fire on ();
  Hellfire holds fire();
}

Maybe we're firing everything we have at a single target because that one target is a super dreadnought that can do five time more damage then everything else combined. In the end I guess it would be some function(s) that would assign each turret a weight based on their rate of fire or other criteria. For example, Who care if a turret fires when a leaf moves if it is ready to fire again before that leaf can move again. Likewise if you have a gun that can only fire once per game, but can kill anything on screen in that one shot you don't want it firing at a single enemy truck that just happens to wonder in range. I would think you'd either want to be despite or have a very tempting target before you let that gun fire.

Then go though each combination of turrets firing in one of the connect zones of fire and attach some criteria that you would want to be true before you allow it. We're getting closer to being done. We have our play book('The Rules of Engagement Table'), but without any way to reference or clean it up it is just a nifty place to put my drinks on so they don't ruin my tables. :P
Then based on the likelihood[...]
How will you compute likelihood?
[...]of each threat being destroyed before it posed a threat to a defense, we'd then decide how threatened a ZoF would have to before a turret or set of turrets would open fire on a target.
Again, how? I don't expect the ready algorithm, just basic steps to get the idea.

Another issue: what if you decide not to open fire at it, will you just let it fire at your defenses without returning fire?
If all shots hit 70% of the time does what I have allocated to fire have time to kill the target before it's in range to fire back? Failing that, if everything is tied up or something is in danger then the question would be what is the quickest way to reduce the most damage the enemy can do. Hopefully instead of doing a lot of math, just reading a preassign threat number of a target design vs shots needed to kill.

The idea is that the defense scales to meet the threat. Maybe the threat is just enough to use the light guns, maybe just the big guns, or maybe even some of both. Technically, yes, there would be some point where a defense or defenses would not return fire. However, that should only happen when the attacker will soon be dead and additional force would just be overkill. The idea behind that is that that additional force has a long reload time and doesn't need to be getting into small fights.
Then compute what the maximum threat value before a type of target is ignored("Ignore the lone big guns we're being over run by ants").
When I read "compute" I'm instantly asking myself "how?". And how will you differentiate between big and small guns and between "ants" and bigger targets?
The time it takes to kill them. There are two ideas behind this. First what if you are faced with a number of small target that can do lets just say 5 damage each, but you can kill in one shot. Lets also say there are 100 of them. Now what if there is also a target that can do 50 damage in one shot, but it takes 20 shots to kill. Lets say there are two of them, and we have the same rate of fire. If I live, I can spend 40 shots killing the harder hitting targets to reduce their damage output by 100 , or I can shoot 40 of the small targets and reduce their damage output by 80.

The second idea is that maybe I have a gun that can kill the harder hitting guys in one hut, but shoots 5 times slower then the other guns I have. It would be better to let my harder hitting gun attack the harder hitting targets and my weaker guns to target the weaker targets.

Each plan or possibility would also be tweaked based on what the turret was and it's proximity to other turrets. An example would be if a morter was in front of or behind a line of turrets. Though I'm not really sure how to make that absolute judgment based on relative positions.
That's where the real 'how' problems, that AI developer has to face, kick-in.
That could be resolved by which zone was breached first now that I think about it.

The execution

Thanks for making me think about so many things, btw. I got my self side track:P Now that we have all the basic information, now it's do or die time to find out if we wasted all that effort. It's time to summarize all that as much as we can get away with and compile it in some way that it will be easy to reference. Because you're absolutely right, up until now it's just a gamble that I've covered every option and accessing the outcome of those operations is easier then doing them again. At least if it's not the ability to have a well thought out pre-compiled plan is.

Let us see, the wind is blowing this way? I think I'll change my answer to match :P I can think of two ways to do this...
We can then start building a hierarchy of If/elseif/else statements using the computed threat ranges from the 'Rules of Engagement' table.
You can't really do this, unless you don't mean it literally.
You could do that literally it would just be a huge pain in backside to convert it to assemble and have the OS execute it, maybe involve a hack... :)
Honestly I can think of a way to do it, it just isn't pretty. Make generic if statement with variables you keep changing to whatever you want to evaluate.

If_Greater_Than_Function(void Arg1,void Arg2)
{
    if(Arg1>Arg2)return TRUE;
    return FALSE;
}

Truthfully I can think of no way to organize all this information in a if/elseif/else outside finding the most common denominator(s)then order the top level of this tree so that it runs the most commonly used to the least commonly used. Next have each branch that the top level leads broken into something halves the possible outcomes or a subset of common denominator. For example, lets say the common denominators between all my functions ia a variable named A and one named B. At the top level I'd first ask if A was not zero, the have a elseif ask if B was not zero. Lets say that A was zero and B was seven. After that I'd ask the middle of the lowest B and highest B that any of the plans referred to, lets say zero though nine. So the next if statement I'd use would read something like is B greater then 4. Then keep halving it until we come to the end.

The only other way would be to organize the information into object classes. Have each object hold one plan, a set of conditions to keep running that plan, and then another set of condition to jump to another object. The last set being narrowed down and simplified based on that if that all the a conditions above this one are true or false then that can exclude some plans and carry over to conditions that follow. For example if you've already check to see if B is greater then seven there is no need to check to see if it's seven or any number greater then seven again.

A few notes before I completely crash, No idea about about the possibility of guns going nuts as a fast moving target runs across a turret line, and who knows how many "Zones of Fire". If I where to draw it out it would look something like a checker board standing on a corner, All I can think is the turrets should either ignore is because they're busy or follow it just fine. As for the CPU use for of something like that? For the monument no idea how to reduce it or how it compares to what happens now.

I've all but written a essay, so I think I'll just take a brake here, and thank you for not running away when you saw this post. :) I hope it was clearer then mud! :)

Edit: As for updating things, you don't have to start over from the beginning per say. You'd start from the beginning work out what changed and they just carry over everything that didn't.
Last edited by 2_Late on 23 Sep 2007, 00:01, edited 1 time in total.

User avatar
Rman Virgil
Professional
Professional
Posts: 3812
Joined: 25 Sep 2006, 01:06
Location: USA

Re: What ever happened to...

Post by Rman Virgil » 23 Sep 2007, 01:30

------->

2-Late:

* I think what your describing is a Hierarchy of Rule Sets using an arbitration algorithm werein you have a Master set at the top which ONLY contains rules to enable the Sub-sets. This is the pre-immenent strategy for handling Large Rule Sets effectively for a lot of reasons some of which have been mentioned already. (This approuch has been used in a series of 2D, turn-based, War Games.)

* When you say "Scenarios" & "Rules of Engagement" tables the standard nomenclature in a.i. is "Rules" & "Rule Sets", their Hierarchical Org & the method of firing or triggering one over the other - Aka, "Arbitration".

* I have looked at the source code for the stuff mentioned here in my various posts - and do understand enough to appreciate the vast amount of man-hours work involved in implementing.

* I have a full source code implementation of a "Rule Based System" (RBS) that allows you to play with a simple RBS & db - it is command line driven and you can add facts to the db useing LISP syntax, run the rule set against it, see how matches are processed. Also - the "Rete" can be viewed at any time, as well the program gives lots of feedback on the "Nodes" & "Bindings".

* You might find it a useful proggy - let me know & i'll .rar it up.

- RV :)

EDIT: I compressed a bunch in this post - for a more expansive  treatment Check HERE (one of a handful of valuable game a.i. sites, imho.)
Last edited by Rman Virgil on 23 Sep 2007, 06:18, edited 1 time in total.
.

Impact = C x (R + E + A + T + E)

Contrast
Reach
Exposure
Articulation
Trust
Echo
.

themousemaster
Regular
Regular
Posts: 608
Joined: 10 Nov 2006, 16:54

Re: What ever happened to...

Post by themousemaster » 23 Sep 2007, 16:24

Rman Virgil wrote: ------->

2-Late:

* I think what your describing is a Hierarchy of Rule Sets using an arbitration algorithm werein you have a Master set at the top which ONLY contains rules to enable the Sub-sets. This is the pre-immenent strategy for handling Large Rule Sets effectively for a lot of reasons some of which have been mentioned already. (This approuch has been used in a series of 2D, turn-based, War Games.)

Heh.  I'm having painful flashbacks to my ProLog classes in college...
Troman wrote: There is a little overhead created by sensor towers, but it is neglectable.
What I meant is that an additional sensor tower will not decrease the number of required computational steps, the sensor tower should be taken symbolically, it is actually only needed for the player, to demonstrate that his possibilities have widened.


Interesting.  As I've said, I've not looked at the source code, or I would have likely known this.  I'm just completely astonished that the game was writeen in such a way that seeting the "targetting" algorithm to be meted out by a tower, rather than each AA unit, would require the same CPU time.

Astonished at WZ's original development I mean, not you.  This type of design wasn't your idea, I'm sure ;p.


Troman wrote: Yep, that's why I liked the idea.
Oh.  Thanks ;p.

User avatar
Rman Virgil
Professional
Professional
Posts: 3812
Joined: 25 Sep 2006, 01:06
Location: USA

Re: What ever happened to...

Post by Rman Virgil » 23 Sep 2007, 16:51

themousemaster wrote:
Heh.  I'm having painful flashbacks to my ProLog classes in college...

* Hehe.... it can get way, way,  nastier - A.I. "Blackboard Architectures"....

* It conjures such nightmares many in game A.I. won't even use the word "Blackboard" though they are definitely useing the tech. - which is a mechanism for coordinating several different decision making systems / a.i. technologies simultaneously like neural nets + fuzzy + GA + Rule Sets for example.

* Oh my gosh I can't even begin to wrap my brain around that.

- RV :)
.

Impact = C x (R + E + A + T + E)

Contrast
Reach
Exposure
Articulation
Trust
Echo
.

Troman
Trained
Trained
Posts: 424
Joined: 12 Aug 2006, 15:40
Contact:

Re: What ever happened to...

Post by Troman » 23 Sep 2007, 17:26

2_Late wrote: Thanks for making me think about so many things, btw.
Np ;) , but the truth is you didn't get to the point where you would have started solving AI problems that you will eventually have to face and you haven't answered any of the how questions. The problem is you are not going deep enough to recognize the sub-problems and their complexity.

It would take too much time for each of us to talk about each missing puzzle part, let's just take calculation of enemy threat value as an example, since you provided the most details about the way how you would solve this problem:
2_Late wrote: The time it takes to kill them. There are two ideas behind this. First what if you are faced with a number of small target that can do lets just say 5 damage each, but you can kill in one shot. Lets also say there are 100 of them. Now what if there is also a target that can do 50 damage in one shot, but it takes 20 shots to kill. Lets say there are two of them, and we have the same rate of fire. If I live, I can spend 40 shots killing the harder hitting targets to reduce their damage output by 100 , or I can shoot 40 of the small targets and reduce their damage output by 80.

The second idea is that maybe I have a gun that can kill the harder hitting guys in one hut, but shoots 5 times slower then the other guns I have. It would be better to let my harder hitting gun attack the harder hitting targets and my weaker guns to target the weaker targets.
Actually I see a flaw about such an approach, but if you want to know what lower-lever problems you have skipped, try to write an algorithm that will do this (maybe just out of curiosity), assuming you have access to defenses' weapon type, reload rate, accuracy, defenses' HP, position, weapon range and enemy weapon type, reload rate, accuracy, range, speed, position, HP etc (you don't have to be familiar with the source for this btw).
Another difficulty to consider is you can't calculate how long it will take to kill a target, you can only calculate how much time it takes statistically to kill some target, since you only work with probabilities, and even that will not be accurate enough, since as I already mentioned weapon's hit probability != probability that the target will be hit, but in this case you could just ignore this fact.

This will force you to go to a lower-level (and a more interesting one), where the actual AI decisions are made and problems solved.

And in order to be able to implement your algorithm you will also have to find a way how to calculate "Target's_ETA", "Time_To_Kill", "Total_Threat_In_ZoF_1_to_10" and a way to implement "Find me a Target();" function to just name those you already mentioned.
2_Late wrote: You could do that literally it would just be a huge pain in backside to convert it to assemble and have the OS execute it, maybe involve a hack...
I hope that's not how you usually write the code though. ;) You don't take some app to write if statements for you.
And to be precise everything has a probabilistic nature, we know it from the quantum physics, but even NASA still uses Newtonian physics to calculate orbital trajectory for the shuttle, so I didn't mean it was absolutely impossible, I mean you do it this way. A possible solution would be just unacceptable and hence there is a biiig chance that this won't happen, big enough to ignore the complementary probability.  ;)
Sign Up for Beta-Testing:
?topic=1617.0

Troman
Trained
Trained
Posts: 424
Joined: 12 Aug 2006, 15:40
Contact:

Re: What ever happened to...

Post by Troman » 23 Sep 2007, 19:05

Rman Virgil wrote:

* It was implemented in the mega hit F.E.A.R. in '05 (you check it out and you'll get excited too - maybe, heh ;)) and will continue in the sequel F.E.A.R. 2 - which has evolved into being called "Project Origin".


* You can get "F.E.A.R." for bargin prices now because it's 2 years old and the sequel is in final dev stage. The A.I. will blow you away - this approach works phenomenally well and is considered a breakthrough by the game industry itself from everything i've seen.
It would be very wrong to say that this is mainly GOAP's merit, it is a complex cause. It is an interesting approach, but we shouldn't overestimate it. A single approach just doesn't make a good AI, it only helps to solve one set of problems. AI is a chain, and it is as good as it's weakest link.

It is actually dedication, qualified manpower, budget, time frame and attitude that makes a good AI, although I'm not saying that all the different techniques there are play the last role, they offer ready-to-use solutions for certain problems, which you would have to (or not) solve on your own otherwise.

Fact is AI does not help selling games as much as gfx does, and it is when developers stop treating AI as a nuisance, only then we can expect something interesting. So a quality of AI it more a matter of the attitude and things seem to change slowly.

GOAP itself is a step forward, but it is still very limited. You still pre-program all the goals and actions, you just expand AI's choice, you can achieve more with neural networks for example, but it also has its downsides.
Sign Up for Beta-Testing:
?topic=1617.0

User avatar
Rman Virgil
Professional
Professional
Posts: 3812
Joined: 25 Sep 2006, 01:06
Location: USA

Re: What ever happened to...

Post by Rman Virgil » 23 Sep 2007, 22:30

Troman wrote: It would be very wrong to say that this is mainly GOAP's merit, it is a complex cause. It is an interesting approach, but we shouldn't overestimate it. A single approach just doesn't make a good AI, it only helps to solve one set of problems. AI is a chain, and it is as good as it's weakest link.

It is actually dedication, qualified manpower, budget, time frame and attitude that makes a good AI, although I'm not saying that all the different techniques there are play the last role, they offer ready-to-use solutions for certain problems, which you would have to (or not) solve on your own otherwise.

Fact is AI does not help selling games as much as gfx does, and it is when developers stop treating AI as a nuisance, only then we can expect something interesting.

.................

GOAP itself is a step forward, but it is still very limited. You still pre-program all the goals and actions, you just expand AI's choice, you can achieve more with neural networks for example, but it also has its downsides.
* The more I've dug into this the more I realize the truth of all the points you have made.

* Over & over it has come down to money: "Sorry folks your gonna have to scale back your a.i. ambitions.... this game has to go out the door on such & such a date & start generating revenues. We can't be going any more over budget so you can achieve these goals."

* GFX does drive the industry, including hardware. But more and more I see gamers less tolerant of sub-par ai just because the GFX is brilliant. One strategy of particular interest has been to make the game ai extensible & accessible to the modder & saying: "If you can make it better go to it !"

* Also, many successful franchises like "Age of Empires", "Civilization", "Total War", etc. are useing a "Blackboard Architecture"  which brings us back to a standard API & asset reuse.

* Then there's: AISeek's Game A.I. Chip

-RV :)
Last edited by Rman Virgil on 24 Sep 2007, 02:49, edited 1 time in total.
.

Impact = C x (R + E + A + T + E)

Contrast
Reach
Exposure
Articulation
Trust
Echo
.

Post Reply