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