What ever happened to...

Other talk that doesn't fit elsewhere.
This is for General Discussion, not General chat.
Chojun
Regular
Regular
Posts: 518
Joined: 25 Nov 2006, 17:49
Contact:

Re: What ever happened to...

Post by Chojun »

I'd say strategy is what defeats attrition, and Warzone2100 has a lot of attrition about it.  More to come later, I g2g.
The best thing to do when your philosophies don't stand up to debate is to lock the thread and claim victory.
2_Late
Rookie
Rookie
Posts: 29
Joined: 06 Sep 2007, 23:21

Re: What ever happened to...

Post by 2_Late »

It occurred to me that I was making a two assumptions: That any SAM site would be on the front line of any air defense & that only SAM sites where on that front line. Considering their range and reload time it would be a mistake to put them anywhere near the front line without sensor backup. So I'm going to change my assumption that all SAM sites can see the enemy coming at at least 90% of their absolute maximum range. Either because of a sensor tower(s) or a advanced defensive line(s).

Given that assumption it occurred to me a total overhaul of the AI is not required, just a player's stratagem .The ability to calculate the shots need to take a target and the absolute maximum time to execute the attack before the target can become a significant threat. So what if the VTOL gets a shot off it it's only weapon is pea shooter hitting a bunker.

In the example above, a single light VTOL may be way only require two or three hits to take from the 50ish SAMs, but that doesn't mean the first thing said SAMs should fire the second it's detected. Given that the SAMs are assumed not to be the only defensive weapon a the delay could be all AA needs to kill the target and save the SAM a reload. Unless the SAMs detected the VTOL half the map away they're not going to have time to reload and fire again, so a two or three second delay in fire will not make a critical difference to one VTOL.

This way if it's just the one target AA might take it out, if not it's still soon going to have the same number of SAM fly it's way as it would two or three seconds ago. Even if they fail to kill it those two or three seconds should not be enough time for the remaining SAM sites to react in time to take on VTOL. Also, if this was just the spear tip of a much larger wave the SAM sites that hesitated to take out the fly are now ready to bring the hammer down on much more dangerous targets.

So I'm thinking the only real tweek needed is more educated commanders and a fire delay in which defenses can switch targets. Simpler then (re)writing a complicated protocol I'd think. Where is the fire control code in the source anyway?
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 »

2_Late wrote: ...................

So I'm thinking the only real tweek needed is more educated commanders ........
* Hehe.... yes there is always that (in the spirit of K.I.S.S. design). ;)

* My weap of choice to buy-time or create a response buffer (like in the case of SAMs)  is the "Assault Gun" in its various guises (esp. 2x Tower) for many reasons not the least of which is it can handle AA duty as well as Ground and... well, you can guess the rest.

- RV :)
.

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

Contrast
Reach
Exposure
Articulation
Trust
Echo
.
themousemaster
Regular
Regular
Posts: 611
Joined: 10 Nov 2006, 16:54

Re: What ever happened to...

Post by themousemaster »

Let me throw an idea out there...

right now, the primary problem to this major discussion is that, no matter how good the targetting algorithm is, the easy counter to it is to just fly in a suicide squad to get all the SAM's to fire.  More SAM's = more suicide bugs, but in any event, it's still the Attack that has the MASSIVE monetary advantage to this type of assault (assuming 1 sam takes out 1, or even 2, bugs, and then the attacker's HEAP-class vtol takes out the SAM, the attacker wins hands down).

Here's something I don't want to see:  some uber-godly algorithm by which, if you set up your base using it, no reasonable amount of VTOL's can get anywhere close.  This is a strategy game first and foremost; setting up an "impervious" defense that can only be countered by a Human Wave strategy defeats that purpose.

What I can agree to is that there should be "some" form of calculation by which every SAM on the board won't fire at single targets.

And that calculation requires a LoS / LoD for the SAM to make it's calculation off of.

We can't just go giving SAM sites much longer detection ranges to account for a "larger" area of "calculation for maximum effect".  Even if we did, we'd just have a bunch of independent SAM's each trying to make calculations by which there may or may not be other, loaded SAM's in the area to handle.  With that being the primary calculatory problem, how does a SAM site know what other AA defenses it has covering it's space, AND whether or not they are ready to fire?

Obviously, an extensive algorithm can be developed, but as I said, that would destroy the spirit of this game.  Also, it would (I imagine) turn the necessary CPU processing power per frame up a few degrees of magnitude, based on the number of SAM's, as each one does it's calculation.




So, after that dissertation....


2_Late wrote: May I look stupid again and suggest another approach entirely?

Instead of extending the sensor network, Plan A, extend the arsenal. Don't have the SAM sites pay attention purely to the targets, and other SAM sights. Have it evaluate a target's range and damage capabilities vs if it took the target out directly or let a much faster firing AA gun do the work, taking out the chaff.

The idea being that the target (decoy) has neither the range or damage capabilities take either of the weapons out just yet. So the SAM hold it's fire for any other threats that are just out of sensor range, and lets the AA turrets do it's work. Then if it become absolutely necessary that the SAM open fire it can then, but not before. This way the cheap stuff that would be a waste of the SAM's attention is taken care of and the SAM is still ready to deal with the big guns.

Edit: Before you bring up what the AI might have to do for all of this, may I suggest you make a simple GUI that allows the user to link all the needed firepower as a group and give them a simple slider to decide what conditions the turrets should fire on. This way you've spared your self hours of tweaking, and allowed the users to create much more intelligent networks.

I really, really like where this is going.  If I may expound upon it a bit, 2_Late.

In an effort not to further overload processing power, I say that we do NOT change any of the AA unit's current, DEFAULT behavior in any way.  In a worst case scenario (I.E. when everything else breaks down), you want your defenses to still at least fire.

However, also give the AA a way to work with each other.

I thought about it, and came up with a way to implement 2_Late's idea, in a way I think won't cause much more processor overhead.



Anyone remember the VTOL-CB tower?  I know I don't.  In any given game, ever, I have never used it.  By the time it's available, the Wide Spectrum is just about to be as well.  And in the SP campaign, you REALLY should never have your VTOL's flying anywhere you didn't order them to.

So change (and/or add to) it's functionality.  Allow base (and maybe mobile AA) turrets to be assigned to it.  Lock any "moblie" turrets in place, however, much like indirects attached to a sensor/CB tower, to prevent suicidal intercept charges.

The VTOL-CB tower is the hub by which all AA-communication, and therefore threat determination algorithms, is centered on.

Allow the VTOL-CB tower a MUCH greater range of viewing than the AA sites themselves, so that it is capable of determining threat long before anything fires.  However, being a VTOL tower, it can only detect VTOLS (better yet, VTOLS in flight, if that's possible)

This way, every bit of processor requirement to script this AI routine only falls upon a single structure; I.E., the amount of increased processor requirement is proportionate to your number of VTOL-CB towers, rather than your AA batteries.

And as far as strategy is concerned, it should be obvious; while the Human Wave strat may still work, another option will be to eliminate the tower, causing all AA to revert to default behavior (and returning the "cannon fodder" VTOL strat to viable).




Before anyone says "it will still be possible to fool this network with a suicide squad of VTOL's", yes, it technically is.  However, you would have to have your main bombing force waiting outside the range of the Tower itself for it not to be calculated against... which, (if as I'm thinking in my own head as I write this is 4X the firing range of any given SAM site, though that is of course an arbitrary number), means that if you do try that strat, the SAM's may very well have reloaded before your main planes range in and drop their payload.




to prevent the "indirect overload" issue (I.E. you build some howitzers at your base, and then proceed to load the hole map with Sensor towers, and the howitzers attach to all of them), have it so that all AA batteries ONLY "attach" themselves to a tower that is both A) closest to it, and B) the tower is within the site's firing range.  Nothing would suck worse than putting up a new VTOL-CB at a satellite base and having your main base's SAM's no longer fire since it can't reach anything near the new tower ;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 »

themousemaster wrote:
............

Here's something I don't want to see:  some uber-godly algorithm by which, if you set up your base using it, no reasonable amount of VTOL's can get anywhere close.  This is a strategy game first and foremost; setting up an "impervious" defense that can only be countered by a Human Wave strategy defeats that purpose.

.....................
* Your absolutely right about that...

* Heh......we sure can get carried away in discussion (emphasis on that word) by our fondness for a.i. but in the end the prevailing holy grail (& final aribiter) is gameplay "Balance".

* And how I would define GPM "Balance" in the context of an RTS is in this way:

* "Anything that expands the set of winning battle tac-strat gamer decision opportunities is good (& on the continuum of endless replayability). Anything that reduces that set of possibilities goes counter to the core intent of an RTS game (& risks the continuum of predictability / frustration / boredom & little replay value) ."

- RV :)
.

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

Contrast
Reach
Exposure
Articulation
Trust
Echo
.
Commander_Keyes
Trained
Trained
Posts: 40
Joined: 10 Sep 2007, 00:40

Re: What ever happened to...

Post by Commander_Keyes »

Y'know, ive never played the original WZ. But a few more aviatric possibilities would be neat, and a huuge Battlecruiser fits that role well. However, naturally it must be balanced, like, traveling at the speed of a snail would be an option. O/C something smaller like a Cruiser would be neat too. But the air units you have till yet arent so great.
User avatar
Watermelon
Code contributor
Code contributor
Posts: 551
Joined: 08 Oct 2006, 09:37

Re: What ever happened to...

Post by Watermelon »

Commander_Keyes wrote: Y'know, ive never played the original WZ. But a few more aviatric possibilities would be neat, and a huuge Battlecruiser fits that role well. However, naturally it must be balanced, like, traveling at the speed of a snail would be an option. O/C something smaller like a Cruiser would be neat too. But the air units you have till yet arent so great.
I was thinking of making a mod with B12 flying fortress,but wz engine has too many limitations which prevent you from making such a mod without messing with the source:

1.Number of weapons supported
2.Targeting AI
3.Airfield for proper take-off

Battlecruiser and other capital class or smaller frigate class aviation units might be able to emerge from factory magically and never do the landing and take-off,though 1, 2 will still need to be addressed before any 'super' units can be successfully implemented.
tasks postponed until the trunk is relatively stable again.
2_Late
Rookie
Rookie
Posts: 29
Joined: 06 Sep 2007, 23:21

Re: What ever happened to...

Post by 2_Late »

I still have to find a Linux RPM macro to detect if a package is present(anyone know one?)

As for a AI I was thinking less along the lines of the solid, a sensor tower, and more along the lines of the abstract. The turrets would have little to no AI, or only as much as needed to just pull the trigger. Then have a single ,unit independent ,function control what was fired and when. With any threat calculations done when a unit was designed, and any parameters on what to fire on and when to do it calculated and updated every time a new turret was placed. Maybe make a temporary update to this 'plan' based on the percents or absents mobile units.

The idea with that is there would be the basic static turret-only plan, and a number of sub-sets ready to go. Then have this "Commander Code" is only pointing to and using the set that's relevant. This way the only code, after everything is set, the "Commander Code" only has to execute a given plan. Any "thinking" that had to be done has already be done.

If the fire control is not in a single source file can anyone let me be lazy :P and tell me the file(s) it's not in?

Edit: I can too not write in English! :P

My , not asked for, and ignorant 2 cents of a mobile carrier.

Give it some turret, but instead of fixing them to a absolute position on the make, make their x,y position a pointer that the same as carrier's, but with a offset.
Watermelon wrote: ...
3.Airfield for proper take-off
...
It's a carrier, not a destroyer, let it support it's self.
Last edited by 2_Late on 16 Sep 2007, 22:13, 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 »

Troman wrote:
I'm not working on it though, just taking part in the collaborative musing about a non-trivial problem and I think it was my last contribution, it takes too much time. ;)
* I hear that. As facinating as this has been, I should stay focused myself on the "Trinity" project and WZ Cam scripting so I can keep making tangible progress - just not enough time for everything that is of interest in this life.

* Let this be my last contibuting thought on this challenge -

* What about Dynamic Priority Arbitration making use of "Rete" or a Rete-like algorithm ?

* Would that be applicable here (as a strat for achieving a.i. self-improving behavior) ?

- 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 »

themousemaster wrote:Here's something I don't want to see:  some uber-godly algorithm by which, if you set up your base using it, no reasonable amount of VTOL's can get anywhere close.  This is a strategy game first and foremost; setting up an "impervious" defense that can only be countered by a Human Wave strategy defeats that purpose.
Rman Virgil wrote: * Your absolutely right about that...

* Heh......we sure can get carried away in discussion (emphasis on that word) by our fondness for a.i. but in the end the prevailing holy grail (& final aribiter) is gameplay "Balance".
No panic! Grab the pitchfork, we will get that monster!  ;)

But seriously, that's not something to worry about.

It's not possible to build a real ferrari out of lego stones at some lego contest.

What an algorithm does is only using existing capabilities of things it operates with. So, in order to have uber-godly defenses you need SAMs to have uber-godly capabilities.
themousemaster wrote: We can't just go giving SAM sites much longer detection ranges to account for a "larger" area of "calculation for maximum effect".
No, that would be a very bad idea.
themousemaster wrote: Also, it would (I imagine) turn the necessary CPU processing power per frame up a few degrees of magnitude, based on the number of SAM's, as each one does it's calculation.
I don't think it would require nearly as much CPU time, you'd be amazed if you found out how much calculations WZ does per frame.

I like the idea about having some structure that would coordinate what AA defenses and feed them with additional data, but:
this will not reduce the amount of CPU time needed for calculations. For the same amount and quality of calculation you need the same amount of CPU time. The structure itself doesn't have any additional CPU built into it.
And second thing is it will still be necessary to rewrite AA AI.
themousemaster wrote:Before anyone says "it will still be possible to fool this network with a suicide squad of VTOL's", yes, it technically is.  However, you would have to have your main bombing force waiting outside the range of the Tower itself for it not to be calculated against... which, (if as I'm thinking in my own head as I write this is 4X the firing range of any given SAM site, though that is of course an arbitrary number), means that if you do try that strat, the SAM's may very well have reloaded before your main planes range in and drop their payload.
We don't want impervious defenses, do we? ;)

But personally I would prefer if the player had to rely upon the rock-paper-scissors and would counter heavy AA defenses with something different than VTOLs. Tank attack, arty, LasSat strike or a cyborg drop (if the transporter had more HP).
2_Late wrote: The idea with that is there would be the basic static turret-only plan, and a number of sub-sets ready to go. Then have this "Commander Code" is only pointing to and using the set that's relevant. This way the only code, after everything is set, the "Commander Code" only has to execute a given plan. Any "thinking" that had to be done has already be done.
I don't see how this would work, you just have to make calculations, be it distance to the enemy VTOL or it's HPs or something else, because the "Commander Code" has to know what target to point at. You guys must have some magical computers if you think that with introducing some new actor to the game you can make the PC require less calculation for the same problem. ;)
Rman Virgil wrote: * What about Dynamic Priority Arbitration making use of "Rete" or a Rete-like algorithm ?
Rete was designed for different purposes and I don't think we need an algorithm with a big name to be able to deal with AA defenses, usually it is not worth it.
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 »

Troman wrote:
Rete was designed for different purposes and I don't think we need an algorithm with a big name to be able to deal with AA defenses, usually it is not worth it.
* As I understand it, "Rete" is just a fancy term for a network of rule nodes.

* The most cutting-edge, advanced game a.i. (well beyond the current gen of games though several major studios are deving it for commercial release in the near future) is GOAP (Goal-Oriented Action Planning) & Rete is at its heart (full implementation w/justification & rule support).....

* Using this tech, the sophistication of game a.i. agent behaviour is positively astounding... but programming wise, it is definitely Everest formidable. In the case of WZ your likely right - not even worth contemplating since that level of sophistaction is not warranted.

Cheers, RV :)
.

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 »

No magic involved, I'm taking my que from what I've learned about dynamic routing protocols from my Cisco classes(grumble grumble). Instead of calculating the each possibility for ever turret each time a event happens it's only done once by a master function. Then instead of calculating each possibility each time something new comes into range have this function follow something like:

Lets see, I have a value threat in range of turrets 6,7 and 8. I also have a value threat in range of turrets in range of turrets 7,8,9,20 and 26. Let me work down my binary tree of plans. Given these values I've already calculated the most efficient use use of my firepower would to be have all the turrets in this zone/group fire on this threat and many turrets in zone/group to fire on this threat.

It's not the plan as some magic that lets me do more in less. It's lynch pined  on that no matter how you arrive at the end there are only possibles in the end. It's a holistically grouping possibilities from the generic to the specific. Discounting whole groups of actions based on sense is not true, every thing that was at least in part dependent on can't be true so I'm not even going to bother with them. So what then would Plan B,C or D be?

Edit: In other words instead of working from the target to the turret I'm working from the turret to the target. That is that is to say that no matter how many enemies there are I only have 10 turrets. So I can only fire on a maximum of 10 targets. I'm not directly evaluating what target should die first, I'm evaluating what combinations of what turrets firing will kill the most targets.(edit) Based on it's fast I can kill a target vs. how much damage it can do.
Last edited by 2_Late on 19 Sep 2007, 20:06, edited 1 time in total.
Troman
Trained
Trained
Posts: 424
Joined: 12 Aug 2006, 15:40
Contact:

Re: What ever happened to...

Post by Troman »

Rman Virgil wrote: * As I understand it, "Rete" is just a fancy term for a network of rule nodes.
It looks like a rule-based system capable of making inference, which one would usually use for Expert System for example, but a more efficient one. We could theoretically use something like that to deal with research in WZ (if the player has "Machinegun" and "Advanced Engineering" researched, then "Machinegun Bunker" becomes available), i'm not proposing it though, just absolutely not worth it in our case.
Rman Virgil wrote: * The most cutting-edge, advanced game a.i. (well beyond the current gen of games though several major studios are deving it for commercial release in the near future) is GOAP (Goal-Oriented Action Planning) & Rete is at its heart (full implementation w/justification & rule support).....
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.

2_Late, apart from the fact that you want to save CPU time by caching some values I don't really understand what you are trying to do, what you want to calculate and what not. Can you be a bit mores specific, or give an example?
Sign Up for Beta-Testing:
?topic=1617.0
themousemaster
Regular
Regular
Posts: 611
Joined: 10 Nov 2006, 16:54

Re: What ever happened to...

Post by themousemaster »

Troman wrote:
I like the idea about having some structure that would coordinate what AA defenses and feed them with additional data, but:
this will not reduce the amount of CPU time needed for calculations. For the same amount and quality of calculation you need the same amount of CPU time. The structure itself doesn't have any additional CPU built into it.

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?




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
2_Late
Rookie
Rookie
Posts: 29
Joined: 06 Sep 2007, 23:21

Re: What ever happened to...

Post by 2_Late »

The inspiration:
The idea I'm trying to bring from the internet to Warzone2100 is how some of the more sophisticated routeting prorocols route traffic. Usually in backbone type routers there are not more then two or three very high bandwidth interfaces on a router, the why is not important to my example. What is important to my example is what is called route summarization. Say the router has ten address, ten of these start with60.24.x.x. Lets say where all ten of these address end up are only attached to the first physical interface(the first possibility). Let's also say that only address that start with 60.24.x.x are attached to that interface.

Instead of reading each address to it's end and then computing what interface to send the packet out of, the router will just read the first half of the address( 64.24) and realize that no matter what else the last half maybe the only place that packet can go is out the first interface. So it skips reading the rest of the address and forwards the packet out the first interface. Like wise a packet if a packet comes along with the first half of it's address being 59.24.x.x the router will know that if nothing else, it shouldn't send this packet out the first interface because only packets that start with 60.24.x.x go there.

The same protocol would apply this same logic to updates it receives about changes in the network. It may forward information or log someone of it, it will never pay attention to information tat doesn't concern it; Nor, will it send updates about Tenbuckto when the only thing that changes was some traffic in New York.

In C/C++ I guess it would look something like this:
If(Packet & 0x80000000)
{
    if(Packet & 0x08000000)
    {
        if(Packet & 0x00800000){}
            // So on and so forth down the chain of bits,  halving the possibles each time
            // until it found only one outcome. Either it got to the end or found a point with
            //  with only one possible outcome, no matter what the rest of the chain was.
        }
        else if(Packet & 0x00400000){}
        else if(Packet & 0x00200000){}
        else if(Packet & 0x00100000){}
        else{}
    }
    else if(Packet & 0x04000000){}
    else if(Packet & 0x02000000){}
    else if(Packet & 0x01000000){}
    else{}
}
else if(Packet & 0x40000000){}
else if(Packet & 0x20000000){}
else if(Packet & 0x10000000){}
else{}

The plan:
Instead of seeing a target, and figuring out how much firepower I need to kill that target, the AI will quickly work though a catalog(or play book if you prefer) of carefully thought out plans then follow that plan. 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. That's now available and ready to use in far less time.

The nuts and bolts:
To start you would have create every reasonable scenario. Not based on if 10,000 infantry show up or if a lone tank attacks, That would require a whole set of rules to keep from computing every statistical possibility, and be more work then is needed. Instead, start with a terrain map, then figure out what angle any given turret can attack from. After that you can drop the terrain map, it's served its use. 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.

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. Instead of counting each second by second as a senerio plays out time would skip ahead to whenever a turret fires or the next time one reloads. With the entire scenario lasting only as long as it takes for each turret to be reloaded and ready to fire at the same time, or the scenario to repeat it's self. After that the list of possibles is finished, We'd need to compute what kind threat enemy each design represented. Then based on the 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. 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"). 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!")

After all of that you should have a nice little table that should tell each turret if, when, and where to fire, A 'Rules of Engagment' table. Now that is done the ZoF can be stored on the hard drive in case we need them later(a turret built or lost). We can then start building a hierarchy of If/elseif/else statements using the computed threat ranges from the 'Rules of Engagement' table. This if/elseif/else tree would describe at least in some detail what should happen in what order when enemy(s) show up. Then when a target is detected turrets are not assigned a target directly, but are assigned ZoF based on the this if/elseif/else hierarchy(which was based on the A 'Rules of Engagment' table.) Then that ZoF is assigned a list target. At this point we're also done with the 'Rules of Engagment' table. Seeing the only time it will ever be needed again is if a turret is destroyed or a new one is built, in which case this version is useless, we can trash it now.

Final Notes:
Hopefully most of the needed CPU time is spent making the making a 'Rules of Engagement' table, and the if/ifelse/else tree. Then ,hopefully ,taking a minimum of time to reference, turrets can decide when, if, and on what to fire based on this if/ifelse/else tree. The ZoF was stored on the hard drive because if another turret is built later the old ZoFs can be recalled and any only possibles that did not change can them be reused to make a new Rules of Engagement' table. 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. Technically such a loss should be included in the possible a turret not firing, but the threat values where computed based on a turret being there.  :-\

Edit: Also note for I didn't explicitly say I was considering overlapping ZoFs as independent zones by them selves.

Edit2: How I really need to get my thoughts together! :( 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.

Edit3:  >:( Every time I reread the post I find another mistake!

Clear as mud now? :P
Last edited by 2_Late on 20 Sep 2007, 06:21, edited 1 time in total.
Post Reply