A Report Card on Current Development (long)
Moderators: hoijui, Moderators
I can only speak for my own mod, but i think all mod independent, learning ais are to some degree similar. I think you haven't full understood, what we mean with learning.
size of file = n * n * size of (float) = n * n * 32 bit
yeah really big
MyAI will also use predefined strategies, but it will learn which unit of which mod will be the best for which unit.
The ai will learn which units are effective against which units.AI sends three units up a hill. My HLT kills them. What has the AI "learned"?
1. "I shouldn't send my units up hills". That's bloody stupid. That hill is mine, for all time.
2. "I should send more units up there next time". Pretty stupid, but it might work, with a reinforcement loop, it'll send a huge wave and take the HLT down, eventually. OTA more-or-less worked like that.
3. "I should send different units that way next time". Really, really stupid. Whatever it draws out've the "hat" is unlikely to be better in any fundamental way, unless used right.
n... number of unitsThe database will be hundreds of gigs
size of file = n * n * size of (float) = n * n * 32 bit
yeah really big
You will have to change your code too!And it'll be broken if you change anything about the game's rules, because that effectively makes it into a new game.
MyAI will also use predefined strategies, but it will learn which unit of which mod will be the best for which unit.
Learning is exactly the thing that makes the AI NOT make the same mistakes over and over again...I think that AIs that "learn" are just going to make the same mistakes over and over again,
There are very good AI techniques avaiable for a case such as rts... don't think about slow neural network or genetic algorithms, but for example about a case based reasoning system storing and merging cases and finding solutions for it.
Your examples have one learning "iteration", while a learning AI would be trained a number of times to get its balancing right. It's true that it won't learn much from a single HLT on one occasion, but when it has encountered a number of other HLT situations it has stored most of the possible situations and consequences of attacks, and will take the best method avaiable...
Realise that a million simple operations is nothing in C++ and todays CPUs...I saw one post that referred to millions of iterations... just to scan for metal and make decisions about planting mexes.
You're also the first person in the spring community saying he wants to write complex mod dependent AI scripts...
And writing a learning AI is just a lot of fun, period. Here AI development from the developer perspective is about creating cool AI stuff, not about having a good working AI within the time contraints (as a commercial rts would have).
The commercial developers use their simple rule systems, scripted sequences and finite state machines just because they are known to work, and are known to be finishable in a certain time.
Last edited by jcnossen on 12 Dec 2005, 23:15, edited 1 time in total.
Yes... I'll have to change the scripts... but, if a frontend was written properly, it'd be simple. Each new unit would have its own script file. That'd be seperate from the main AI scripts. Sure, things like the example FormationBlock would need to get edited, if, say, my new mod included a unit that I wanted to get used in the same relative positions as a PeeWee... big deal. I can just use a grep parser- or write relatively few states that get that specific... or assign whole classes of units to a given "formation slot".
Addressing your specific answer though... unit-vs-unit "learning" will never really do much that's genuinely useful. Who cares if Peewees own AKs as individuals? Players don't send individuals, they send units. What matters is things like, "Peewees which attack without artillery support are a lot more likely to die on cheap static defenses than they are with artillery support". This is not something you can (easily) get a "learning system" to ever figure out. But a state-driven AI can do so pretty easily. Let's take a case and pseudocode it:
If UnitSpots = EnemyUnit UnitNameString LLT
{
If UnitStrength >= 10
{
Attack_EnemyUnit
}
Else
{
Choose_NewScoutDirection
MoveTo_NewScoutPoint
}
Else Exit
}
Or, a "smarter" one:
If UnitSpots = EnemyUnit UnitNameString LLT
{
If Unit UnitNameString Peewee
And UnitFormation Contains UnitNameString Stumpy
{
Attack EnemyUnit
Send AttackInstruction UnitFormation EnemyUnit
}
Else Exit
}
...and you can make these have broader "classes", like TA did. Units, instead of being called by FBI-specific strings, could be assigned broad classes, such as "LevelOneKbotFastAttacker", etc., which could serve as proxies and give the state-driven AI terrific flexibility... or pinpoint specificity, depending on how one scripted it...
Addressing your specific answer though... unit-vs-unit "learning" will never really do much that's genuinely useful. Who cares if Peewees own AKs as individuals? Players don't send individuals, they send units. What matters is things like, "Peewees which attack without artillery support are a lot more likely to die on cheap static defenses than they are with artillery support". This is not something you can (easily) get a "learning system" to ever figure out. But a state-driven AI can do so pretty easily. Let's take a case and pseudocode it:
If UnitSpots = EnemyUnit UnitNameString LLT
{
If UnitStrength >= 10
{
Attack_EnemyUnit
}
Else
{
Choose_NewScoutDirection
MoveTo_NewScoutPoint
}
Else Exit
}
Or, a "smarter" one:
If UnitSpots = EnemyUnit UnitNameString LLT
{
If Unit UnitNameString Peewee
And UnitFormation Contains UnitNameString Stumpy
{
Attack EnemyUnit
Send AttackInstruction UnitFormation EnemyUnit
}
Else Exit
}
...and you can make these have broader "classes", like TA did. Units, instead of being called by FBI-specific strings, could be assigned broad classes, such as "LevelOneKbotFastAttacker", etc., which could serve as proxies and give the state-driven AI terrific flexibility... or pinpoint specificity, depending on how one scripted it...
Actually this is very well possible. The AI knows what it's doing, so it can use this kind of information if stored properly."Peewees which attack without artillery support are a lot more likely to die on cheap static defenses than they are with artillery support".
It could keep a set of influences of the situation:
<friendlies within enemy range>
<enemies within friendly range>
Friendly/enemy units will have to be classified as a group with certain properties to speed up processing and reduce experience database size... being artillery could be one of the properties.
Well, sure, you can do that. But why not have that be under the control of modders, instead of hard-coding it? It all boils down to the same thing, really- making rules for all of the things that any practical AI is going to have problems coming up with on its own. We're both saying the same thing here, when you look at this logically.
Now, just to make certain things clear, because I didn't explain my position well... I am not opposed to AI that, for example, makes use of "emotions" to determine whether it's attacking, defending, exploring, scouting or building. I'm not opposed to AI that can make "intelligent decisions" about when an attack has failed. I'm not opposed to AI that tries out new combos of units. What I am opposed to is an AI that does all of these things without explicit controls that modders can use, that lack really strict parameters and allow users to get what they actually need out of the AI.
For example, in Freelancer... I've had to script AI that only applies to the behavior of Freighters. Freighters need to behave differently than their Fighter escorts. Digital Anvil did this through some hard-coded behaviors (which they refer to as state_change graphs) which I assume are an "emotional" system of a crude sort. I didn't like that- it had a bunch of other hardcoded behaviors associated with it, which in practical terms were actually not terribly "smart".
Whereas the Fighter state_change graphs were left practically open. So, I rebuilt a "fighter" AI so that it used a Freighter "intelligently"- i.e., it would fight briefly, but mainly it tries to get away from the fight. Giving modders this level of control is not a bad thing- it's a good thing. It gives end-users the ability to reconfigure your software to fit their needs. Thankfully, in the case of Freelancer, Digital Anvil made it possible to do so. Most game engines aren't that cool.
Making a script parser that interprets a small artificial language structure and can read FBIs is not a problem. Anybody can make a program read some text and then interpret it as instructions. So I'm just really mystified why this major need has been neglected.
I'm not opposed to everything associated with modern AI- I'm not looking for something that cannot adapt in any way, shape or form. But I think that the emphasis everybody currently working on AIs here has placed on "learning" is unlikely to result in AIs that play well with new mods. Learning is not the same thing as adapting. Adaptive behaviors can be scripted- I can write different scenarios, add randomizers... and if whatever players come up with makes them all fail... well, that's too bad- but that's my fault, as a mod developer. In many ways, this would take you AI designers out've the hot seat- you'd "just" be responsible for building something that was as competant and the game designers who built a given mod. This is a bad thing? If you're really think you're so brilliant that your AI will out-think the game designers who create various Spring variants... heh... please... and it's not like you AI coders have unlimited time and mental energy, and can write up new customizations every time a mod comes out. Once Spring has a better unit-loading interface, and can operate more like TA:M in terms of unit mixes (and, hopefully, server-client ability to send units to clients from hosts, etc. ad nauseum, but that's another topic entirely) I expect to see a huge explosion of variant mods, random unit mixes, and other things available, instead of the relative handful we have now. An AI that can read a given unit's script and then slot it into the mix, without needing to "think" about it, is probably going to be best for this future.
I've been considering building some new content for Spring- if nothing else, porting the MechPack Improved and giving those models really nice uvmaps and stuff. I don't want to go to all of that effort, and then not have an AI that won't use the units effectively. I think that everybody can agree that this is bad.
But when "use units effectively" is a huge degree of seperation between "can build them and then send them out semi-randomly as it 'learns' what they're good for" and "follows some very simplistic but effective instructions that tell it to assemble a mixed-arms force and attack when it reaches X size"... we have problems. After all, how are these supposedly smart AIs ever going to get enough "experience" to be useful? Does anybody writing AIs have a practical way around them just playing again and again on a given person's computer? For example, can they simply "play" on a completely "virtual" battlefield, without end-users having to do anything more than hit a button and walk away for a few hours, while the AI plays itself with a given mod in a non-graphical but otherwise accurate Spring at hundreds (if not thousands) of times the regular simulation speed? No. Which, all by itself, seems to be a big stumbling block. I mean, if these AIs are supposedly going to "grow up" into something "smart", then they're going to need lots and lots and LOTS of "experience".
Think about the ramifications here, folks. To build a "learning" AI that is maybe, perhaps, sort've have a chance to play a great game, it's going to need huge databases on unit-vs-unit results. And, quite frankly, no matter how you code it... many of the resulting "lessons learned" aren't going to make any sense. My bit with the HLT is just one tiny example. How many more do I need to throw out? AIs figuring out the right sequence to cross a river with enemy artillery on the other side? AIs figuring out that they can use Transports? Yeah, right. Those sorts of things will be... yup... you guessed it... state-driven, hard coded behaviors. Even an AI like AAI will have to have specific cases for those sorts of things- or it will always be a failure as a real competitor. Why are we even pretending that this is not the case?
Why go through all of this rigamarole, when a human writing code- code with randomizers that ensure that tactics vary, code that makes sure special units get used right, code that tells the AI what build-weights to assign to things... is much easier? Yes, it's potentially time-consuming... therefore, let users build proxy classes for whole groups of units, and assign units of a given type to them. And, for units that aren't in a given codebase... give them a default value, with a build weight that is arrived at by looking at workertime / energy / metal- another area where end-users could potentially make things work really well.
Now, just to make certain things clear, because I didn't explain my position well... I am not opposed to AI that, for example, makes use of "emotions" to determine whether it's attacking, defending, exploring, scouting or building. I'm not opposed to AI that can make "intelligent decisions" about when an attack has failed. I'm not opposed to AI that tries out new combos of units. What I am opposed to is an AI that does all of these things without explicit controls that modders can use, that lack really strict parameters and allow users to get what they actually need out of the AI.
For example, in Freelancer... I've had to script AI that only applies to the behavior of Freighters. Freighters need to behave differently than their Fighter escorts. Digital Anvil did this through some hard-coded behaviors (which they refer to as state_change graphs) which I assume are an "emotional" system of a crude sort. I didn't like that- it had a bunch of other hardcoded behaviors associated with it, which in practical terms were actually not terribly "smart".
Whereas the Fighter state_change graphs were left practically open. So, I rebuilt a "fighter" AI so that it used a Freighter "intelligently"- i.e., it would fight briefly, but mainly it tries to get away from the fight. Giving modders this level of control is not a bad thing- it's a good thing. It gives end-users the ability to reconfigure your software to fit their needs. Thankfully, in the case of Freelancer, Digital Anvil made it possible to do so. Most game engines aren't that cool.
Making a script parser that interprets a small artificial language structure and can read FBIs is not a problem. Anybody can make a program read some text and then interpret it as instructions. So I'm just really mystified why this major need has been neglected.
I'm not opposed to everything associated with modern AI- I'm not looking for something that cannot adapt in any way, shape or form. But I think that the emphasis everybody currently working on AIs here has placed on "learning" is unlikely to result in AIs that play well with new mods. Learning is not the same thing as adapting. Adaptive behaviors can be scripted- I can write different scenarios, add randomizers... and if whatever players come up with makes them all fail... well, that's too bad- but that's my fault, as a mod developer. In many ways, this would take you AI designers out've the hot seat- you'd "just" be responsible for building something that was as competant and the game designers who built a given mod. This is a bad thing? If you're really think you're so brilliant that your AI will out-think the game designers who create various Spring variants... heh... please... and it's not like you AI coders have unlimited time and mental energy, and can write up new customizations every time a mod comes out. Once Spring has a better unit-loading interface, and can operate more like TA:M in terms of unit mixes (and, hopefully, server-client ability to send units to clients from hosts, etc. ad nauseum, but that's another topic entirely) I expect to see a huge explosion of variant mods, random unit mixes, and other things available, instead of the relative handful we have now. An AI that can read a given unit's script and then slot it into the mix, without needing to "think" about it, is probably going to be best for this future.
I've been considering building some new content for Spring- if nothing else, porting the MechPack Improved and giving those models really nice uvmaps and stuff. I don't want to go to all of that effort, and then not have an AI that won't use the units effectively. I think that everybody can agree that this is bad.
But when "use units effectively" is a huge degree of seperation between "can build them and then send them out semi-randomly as it 'learns' what they're good for" and "follows some very simplistic but effective instructions that tell it to assemble a mixed-arms force and attack when it reaches X size"... we have problems. After all, how are these supposedly smart AIs ever going to get enough "experience" to be useful? Does anybody writing AIs have a practical way around them just playing again and again on a given person's computer? For example, can they simply "play" on a completely "virtual" battlefield, without end-users having to do anything more than hit a button and walk away for a few hours, while the AI plays itself with a given mod in a non-graphical but otherwise accurate Spring at hundreds (if not thousands) of times the regular simulation speed? No. Which, all by itself, seems to be a big stumbling block. I mean, if these AIs are supposedly going to "grow up" into something "smart", then they're going to need lots and lots and LOTS of "experience".
Think about the ramifications here, folks. To build a "learning" AI that is maybe, perhaps, sort've have a chance to play a great game, it's going to need huge databases on unit-vs-unit results. And, quite frankly, no matter how you code it... many of the resulting "lessons learned" aren't going to make any sense. My bit with the HLT is just one tiny example. How many more do I need to throw out? AIs figuring out the right sequence to cross a river with enemy artillery on the other side? AIs figuring out that they can use Transports? Yeah, right. Those sorts of things will be... yup... you guessed it... state-driven, hard coded behaviors. Even an AI like AAI will have to have specific cases for those sorts of things- or it will always be a failure as a real competitor. Why are we even pretending that this is not the case?
Why go through all of this rigamarole, when a human writing code- code with randomizers that ensure that tactics vary, code that makes sure special units get used right, code that tells the AI what build-weights to assign to things... is much easier? Yes, it's potentially time-consuming... therefore, let users build proxy classes for whole groups of units, and assign units of a given type to them. And, for units that aren't in a given codebase... give them a default value, with a build weight that is arrived at by looking at workertime / energy / metal- another area where end-users could potentially make things work really well.
Q) Why haven't we build such an AI?:
A) Because it's more fun to make a learning one, and to participate in the AI battles
However a new unit scripting system might allow you to put up such a scripted AI layer in the future.
Also, you seem to have missed my JCAI developments in the time you weren't here. JCAI 0.10 allowed people to build base nodes that interacted... which is a start for more complex scripted behavior... but I simply didn't like it. You spend a lot of time connecting it to the config parser, and then it is still very mod dependent.
Really both methods work eventually, but the scripted version is just not fun enough for any AI developer to write right now. That's it.
A) Because it's more fun to make a learning one, and to participate in the AI battles
However a new unit scripting system might allow you to put up such a scripted AI layer in the future.
Also, you seem to have missed my JCAI developments in the time you weren't here. JCAI 0.10 allowed people to build base nodes that interacted... which is a start for more complex scripted behavior... but I simply didn't like it. You spend a lot of time connecting it to the config parser, and then it is still very mod dependent.
Really both methods work eventually, but the scripted version is just not fun enough for any AI developer to write right now. That's it.
Oh my, oh my oh my, I had a huge post in response last ngith and went to post btu my net conenction had gone before I finished it. I am not pelased with thsi at all.
Argh, a human players plays in the same way btu a human player can tell what a unti si godo at absed on tis stats, ahve you nto thought an AI could do the same very easily? Afterrall the AI has a lot more numerical pwoer than a human.
When I wrote the following I had just read your response and had been enraged by it. We develop here in our free spare time, we dont do ti because we're paid to reach a deadline,a dn we will combine whatever things give us better results in our AI's as we need, and when we see fit to implement them. There isnt the demand for thsi sort fo AI constraints that you say is so important. Most of us who'd want that actually downlaoded or loaded VS .Net and started coding a skirmish AI ourselves, I know if I hadnt gone itno the AI path I'd be making a mod right now or making maps.
So I would like to see you proove us wrong. Proove to su that our paths are pointless and that you can quickly make a state driven AI that our AI's can neve surpass without following your doctrine, code an AI that simply does the job, that relies on the modder for its tactics.
// START OF TREMENDOUSLY LONG POST
I have not incorporated learning into the current NTAI, and boosting the comamdners makignt eh AI's crash? NTAI doesnt deal with the stats of the comamnders, as long as it has the same name and can d-gun NTAI should be unnaffected, and I see no AILog.htm for proof of this or any attempt to help fix it. This si most unhelpful.
Yes we use a brute force method fo gettign mex spots becuse fo the way spring uses metal maps. We dont incorporate learning systems into the mex algorithm nor do we store masses of data. We sort what data the engien gives us till we're left with an array of hotspots then we palce the mex as close ot those spots as is possible.
I also see that I have MY project that I am working on, and this si the path I ahve chosen. I talked abotu Adaptive AI when you where ehre but then you went. You missed all the documents I did definign how TAI was going to work, what it all did, ti didnt learn it was adaptive but it looked damn godo and I ahd a good diea of how to implement it, the onyl thign stoppign em beign my alck of C++ skills which i've overcome. I tried to make TAI and failed then I made NTAI recently in the last 2 months after 7-9 months fo learnign and codign on TAI,a nd now I'm makignt he steps to what TAI was going to be and I've defined what i want after that.
HLt at top of hill untis get blown up. In AAI's case it elarns not that those utnis are abd against a HLT, btu ti takes a compeltely different approach. It learns that a HLT is good at destroying those untis when palced on that hill and remembers that the hill is an important part fo the map for future games. We arent generatign amsses fo information, the cache for AAI is barely a millionth fo the gigabytes you predicted, and ti runs on a slow computer just as well as the TestAI SJ wrote that does nothign but count how many friendlys and enemies are present.
You may be happy fiddlign thubms and writting AI configs and all these different thgisn btu that's you, whoa re you to speak for the modders of this community when you've bene gone for months. Go start a poll on the subject, zaphods tried this and he got that response and thoy ou may nto fit the norm, that doesnt mean you can rubbish everythign else.
Yes post your scripts if you think it's that easy. You dont realize that all our AI's werent created to fill a hole entirely. I started out that way but after a week ro two curiosity was what carried em through. I ahve a projecta dn ym main goal si to expand it and improve not to provide a service. I dont want a conventional state driven AI, I want an AI that is different but still does a good job and I'm willing to experiemnt to do that.
We've tested many dieas out while you've been gone, adn we can move at a very fast rate if we wish, I created NTAI 0.1 over a single weekend before JCAI 0.2 was posted. If I ahd full net access again I'd be releasing twice a day and I'd be making a lto fo progress, I'd ahve released 0.29 beta 6 by now if I hadnt collapsed in school and bene given a big mound of ICT coursework.
If you find a problem in our AI's then tell us what it is and provide us with the logs and what you where doing and what it was doing, dont just complain. We're nto creatign AI's that run totally off of a learnign algorithm, at most we're still driving our AI's through code and we're augmenting different parts in our plans with learning structrues but they arent driving the AI's totalyl at all. and you are insulting our intelligence with these remarks about Supercomputers barely running the AI's we've planned. I feel that every algorithm we've proposed or made is soemthigny uo see as an attempt to incorporate learning? You even attemtped ot make ane xampel out fo the mex algorithm as an example of bloated databases and learning, had you not even taken a loo at the code? Not even asked anybody here? We're not stupid you know, and I'm tired of getting the impressiont hat you're talking down on me.
I'm tired of people telling me what i can and cant do, stop being so pessimistic, fi you cant do soemthign its ebcause you're takign the wrong approach tog et the desired result, and I think that I am at least going to follo my own path, I wont elt you pick me up and place me down on your path folloing what you thik si a good diea and what you want from an AI.
If you want it that way so badly go write it yourself, you're just gettign annoying now, and you're not providing us with anythign useful. We tried, and we're still tryign and we've come far, adn noen fo us ahve done this before btu we're getting somewhere and thats good enough for me. Whoa re you to barge in and say that everythign we've accomplished and everythignw e paln is all wrogn ebcause of these thgins you have poitned out regardless of the fact we knwo of them already and ahve solutions ready to be implemented in the next 2-3 versions.
Stop being so inconsiderate and insensitive. Stop stressing an ideal and covnentional way that you think si right thinkignw e dont udnerstand ro we arent listening, we hear you loud ad clearly and we knwo what you're sayign but we dont agree. Well i certainly dont.
Go offer us suggestions on how we can improove systems in our AI's, go poitn out bgus and give us detailed descriptiosn fo them or better yet fix them. But dont atatck the foundations and our abilities and call us incompetent. Dont state the obvious and draw conclusions from things you think you've seen without verifying them. Dont jump to conclusions that we're all learning AI junkies.
Go read the NTAI X thread again and gabbas research. There is a flow fo logic and a mass of research supporting the basic ideas and how they work. G look at the voronoi diagram stuff and how it's used ingame. How it can eb sued to make good decisions based on available data including a mroe tactical approach to using units than simply sending them in random directions. Do not attempt to condemn what you do not understand.
Argh, a human players plays in the same way btu a human player can tell what a unti si godo at absed on tis stats, ahve you nto thought an AI could do the same very easily? Afterrall the AI has a lot more numerical pwoer than a human.
When I wrote the following I had just read your response and had been enraged by it. We develop here in our free spare time, we dont do ti because we're paid to reach a deadline,a dn we will combine whatever things give us better results in our AI's as we need, and when we see fit to implement them. There isnt the demand for thsi sort fo AI constraints that you say is so important. Most of us who'd want that actually downlaoded or loaded VS .Net and started coding a skirmish AI ourselves, I know if I hadnt gone itno the AI path I'd be making a mod right now or making maps.
So I would like to see you proove us wrong. Proove to su that our paths are pointless and that you can quickly make a state driven AI that our AI's can neve surpass without following your doctrine, code an AI that simply does the job, that relies on the modder for its tactics.
// START OF TREMENDOUSLY LONG POST
I have not incorporated learning into the current NTAI, and boosting the comamdners makignt eh AI's crash? NTAI doesnt deal with the stats of the comamnders, as long as it has the same name and can d-gun NTAI should be unnaffected, and I see no AILog.htm for proof of this or any attempt to help fix it. This si most unhelpful.
Yes we use a brute force method fo gettign mex spots becuse fo the way spring uses metal maps. We dont incorporate learning systems into the mex algorithm nor do we store masses of data. We sort what data the engien gives us till we're left with an array of hotspots then we palce the mex as close ot those spots as is possible.
I also see that I have MY project that I am working on, and this si the path I ahve chosen. I talked abotu Adaptive AI when you where ehre but then you went. You missed all the documents I did definign how TAI was going to work, what it all did, ti didnt learn it was adaptive but it looked damn godo and I ahd a good diea of how to implement it, the onyl thign stoppign em beign my alck of C++ skills which i've overcome. I tried to make TAI and failed then I made NTAI recently in the last 2 months after 7-9 months fo learnign and codign on TAI,a nd now I'm makignt he steps to what TAI was going to be and I've defined what i want after that.
HLt at top of hill untis get blown up. In AAI's case it elarns not that those utnis are abd against a HLT, btu ti takes a compeltely different approach. It learns that a HLT is good at destroying those untis when palced on that hill and remembers that the hill is an important part fo the map for future games. We arent generatign amsses fo information, the cache for AAI is barely a millionth fo the gigabytes you predicted, and ti runs on a slow computer just as well as the TestAI SJ wrote that does nothign but count how many friendlys and enemies are present.
You may be happy fiddlign thubms and writting AI configs and all these different thgisn btu that's you, whoa re you to speak for the modders of this community when you've bene gone for months. Go start a poll on the subject, zaphods tried this and he got that response and thoy ou may nto fit the norm, that doesnt mean you can rubbish everythign else.
Yes post your scripts if you think it's that easy. You dont realize that all our AI's werent created to fill a hole entirely. I started out that way but after a week ro two curiosity was what carried em through. I ahve a projecta dn ym main goal si to expand it and improve not to provide a service. I dont want a conventional state driven AI, I want an AI that is different but still does a good job and I'm willing to experiemnt to do that.
We've tested many dieas out while you've been gone, adn we can move at a very fast rate if we wish, I created NTAI 0.1 over a single weekend before JCAI 0.2 was posted. If I ahd full net access again I'd be releasing twice a day and I'd be making a lto fo progress, I'd ahve released 0.29 beta 6 by now if I hadnt collapsed in school and bene given a big mound of ICT coursework.
If you find a problem in our AI's then tell us what it is and provide us with the logs and what you where doing and what it was doing, dont just complain. We're nto creatign AI's that run totally off of a learnign algorithm, at most we're still driving our AI's through code and we're augmenting different parts in our plans with learning structrues but they arent driving the AI's totalyl at all. and you are insulting our intelligence with these remarks about Supercomputers barely running the AI's we've planned. I feel that every algorithm we've proposed or made is soemthigny uo see as an attempt to incorporate learning? You even attemtped ot make ane xampel out fo the mex algorithm as an example of bloated databases and learning, had you not even taken a loo at the code? Not even asked anybody here? We're not stupid you know, and I'm tired of getting the impressiont hat you're talking down on me.
I'm tired of people telling me what i can and cant do, stop being so pessimistic, fi you cant do soemthign its ebcause you're takign the wrong approach tog et the desired result, and I think that I am at least going to follo my own path, I wont elt you pick me up and place me down on your path folloing what you thik si a good diea and what you want from an AI.
If you want it that way so badly go write it yourself, you're just gettign annoying now, and you're not providing us with anythign useful. We tried, and we're still tryign and we've come far, adn noen fo us ahve done this before btu we're getting somewhere and thats good enough for me. Whoa re you to barge in and say that everythign we've accomplished and everythignw e paln is all wrogn ebcause of these thgins you have poitned out regardless of the fact we knwo of them already and ahve solutions ready to be implemented in the next 2-3 versions.
Stop being so inconsiderate and insensitive. Stop stressing an ideal and covnentional way that you think si right thinkignw e dont udnerstand ro we arent listening, we hear you loud ad clearly and we knwo what you're sayign but we dont agree. Well i certainly dont.
Go offer us suggestions on how we can improove systems in our AI's, go poitn out bgus and give us detailed descriptiosn fo them or better yet fix them. But dont atatck the foundations and our abilities and call us incompetent. Dont state the obvious and draw conclusions from things you think you've seen without verifying them. Dont jump to conclusions that we're all learning AI junkies.
Go read the NTAI X thread again and gabbas research. There is a flow fo logic and a mass of research supporting the basic ideas and how they work. G look at the voronoi diagram stuff and how it's used ingame. How it can eb sued to make good decisions based on available data including a mroe tactical approach to using units than simply sending them in random directions. Do not attempt to condemn what you do not understand.
<sighs>
If anybody really feels I am not qualified to offer critique, please go here. If you are not satisfied, after looking through what you will find there, that I am perfectly qualified to have an opinion on this topic, fine- I'm just another blowhard, and move on- the Internet is full of empty mouths and I'm a waste of your time. Sorry. I tend to think that I don't waste people's time, but I can't make everybody happy, and I've long since quit trying to- I just try not to make anything personal. I don't know any of you, and I am seeking a result here, not personal popularity.
I just want another game engine to work with- and I want it to have an AI I can work with, that doesn't suck, OK? I didn't start this discussion because I'm an altruistic saint, and you don't have to like me to be polite to me, or give me the respect I am due as somebody who's accomplished quite a bit over the years- and for the most part, given it away freely for strangers to enjoy. If you don't like what I have to say, move on. You can shake your head, ignore this fool, and do your thing- and that's perfectly OK. I really don't wish anybody any harm, and if what I am saying annoys you, and doesn't seem to contain valid points, then just do something else, and be happier.
@Alantai:
I'll keep this short. Ish. And then I'm really going to go for awhile- I have a project to finish, otherwise we could keep this up for months, I suspect, and it wouldn't do much good. If you really think that I am talking down to you, then I will probably need to come back when I have more time, and put my work where my mouth is on this topic- you're right, if I really wanted this, I'd do that, so therefore I must not want it badly enough. I know that is a truth in making games- I've had to learn it the hard way many times!
Another way to see why I started this conversation is to realise that I am a very prolific game designer, and I touch a lot of places and people... mainly for reasons that may or may not make sense to you. I came by last time to plant some seeds, and I've come by this time to see what sprouted. I didn't bother providing any of the hard work or sunshine, so I should probably have just left well enough alone, whether or not I liked the results.
Let's just say that I am not out to be controversial for the sake of same, and I'm sorry if I'm too ignorant to address all of your points in detail at this time- that's not terribly fair of me, and normally I'd get down-and-dirty with your source and we could argue specific points to death, if that was productive. In this case, it isn't.
So, here are my last words on this topic. Feel free to flame me as an ignorant idiot all you want- again, if I wanted this badly enough, I'd just have to get down and pwn u @11. Frankly, I think that if you folks who've been flaming thought about things for a minute, you'd realize that I'm mainly here to get you thinking again. And when I come back, I suspect that somebody will have tried their best to prove my points are completely off-base... if the effort succeeds, and we have a "smart" AI for a RTS that can adjust to any mod that modders can make... well, um... I win
So, here are a few last items. I apologise in advance for the length, but Alantai wanted to see a script... therefore, here is a working, real-world script. Anybody with a copy of Freelancer who still doubts I know what I'm talking about is more than welcome to email me, and I will send them to where they can download my work and see it in action.
1. Humans do not, in fact, generally play games by "looking at stats". This is a false assumption, based, in large part, on your personal experiences as a developer who mainly talks to other like-minded people, not on empirical evidence and the available research.
Please read some articles on the psychology of gameplay if you are really of this opinion. I am not trying to insult you, or talk down to you. I am just pointing out the fact that as a programmer, you probably genuinely do see things that way, and as a game designer, I run into these problems myself- and then have to get beta-testers to sometimes see "the obvious".
I am not really qualified to address this in technical terms, but humans generally play games in terms of abstract gestalts. Yes, human beings can, and do, break down games in terms of their numerical qualities. But- let's be real here- when most people are learning to play a game, they are not staring at the numbers. They are, instead, watching the behavioral patterns of the interface (whatever that is- whether a boardgame or a 3D character on a screen) and they are paying attention to the rules of victory and defeat, reward and penalty. When their manipulation of the game's rules results in victory, players will tend to reinforce their behaviors. But they aren't doing it numerically- it's a lot more complicated than that.
Numerical approaches that do not include explicit rulesets that compel an AI to directly address the fundamental rules of victory, such as, "if my Commander dies, I lose" are never going to work really well. That, in short, is my opinion on this point. You are confusing number-crunching, which humans are pretty lousy at, with intuitive reasoning, spacial coordination and predictive behaviors, which aren't the same things at all! Yes, a computer game is ultimately a sea of numbers that can be sliced in various ways. Yes, it is theoretically possible for a powerful enough computer to slice that sea into manageable chunks and defeat a human player through sheer horsepower. But that's really not practical. A really good game AI is going to use the least horsepower possible, not the most.
I realize that everybody but AAI is building various scenarios into the AIs, and that these projects aren't completely free-form. I did not say differently in my posts- I just argued against this particular fallacy, and explained why I want to see a script-driven, end-user-configurable system, not a black box that may or may do something stupid when I give it a new unit mix to play with. And I did not say that I oppose all forms of "learning"- I think "emotion-driven" systems are a good, proven approach for driving a realtime system. What I did say was that I do not think that hard-coding such things into your AIs is a very good idea, because this severely limits the ability of modders to work with your AI, short of recoding large sections and recompiling a custom version- which is a big hassle, and completely needless. Why is it such a big deal if your scenarios are all in text files, un-compiled, and accessible to end-users?
2. You want to see a script? Here is the entire state-script for one of the Freelancer AIs I wrote. As you can readily see, it's not terribly complicated, by coding standards- only about 200 lines. Writing something like this, which refers to hard-coded specific cases (such as how much the fighter is allowed to turn, maximum, compared to a human player, or how much the fighter's shots will tend to deviate from an aimpoint) was really just a matter of figuring out what calls were available to the Freelancer AIs, combining all available calls into a larger, coherent file like this one, and then tweaking variables.
The hard part, really, was figuring out how Digital Anvil made all of their inter-connected parts work. Believe me, what I started with was nothing like this clean- it was almost 100 pages of text, with numerous sub-sets and referants that made things very confusing at first! But the final results, which are a series of Block calls that, in turn, refer to a number of variable settings... which in turn refer back to hardcoded, low-level behaviors (and, in a couple of areas, higher-level stuff that refers beyond the game object- for example, when the fighter needs to check how far it is from its fellow spacecraft... these things are nice and tidy in this version.
I'll be the first to say that an AI this simplistic, while it can defeat a human in an action game... is not sophisticated enough to defeat a player in a RTS. But I've posted some pseudocode here demonstrating just a few ways that a script interpreter could be built that could really make things work. I'm not some insane weirdo, either- if other modders have been scared of working with something like this- either what you built as frontends (i.e., syntax, command documentation, variable descriptions) was very poor, or you just didn't post to the right people. Build something that's as powerful as this, and easy to use, and people will use it! I'd have to go back and count, and re-include certain options that aren't even in this particular AI, but basically... this has a lot of available settings- you can get a lot've interesting gameplay out've just a few lines, if the hardcoded bits will support this level of scripting.
If you'd like to see some of the AI work I've done with other game engines, let me know. I've worked with the Dawn of War engine (which is yet another state-based AI), with OTA, and with RuneswordII (although I doubt most of you would find that one remotely interesting- much of that scripting was heavily dependent on hardcoded stuff that was, quite frankly, not very tight). This is probably my best work... and I think even somebody who's not familiar with the Freelancer game engine can probably follow the references from one area to the next- I wrote this and commented it for the Freelancer development community, which I'm a member of.
At any rate, here you go. I hope this is more useful to you than my philosophical ramblings, in terms of demonstrating the concept that a state-driven AI doesn't have to be stupid- just fairly flexible, and amenable to scripting...
If anybody really feels I am not qualified to offer critique, please go here. If you are not satisfied, after looking through what you will find there, that I am perfectly qualified to have an opinion on this topic, fine- I'm just another blowhard, and move on- the Internet is full of empty mouths and I'm a waste of your time. Sorry. I tend to think that I don't waste people's time, but I can't make everybody happy, and I've long since quit trying to- I just try not to make anything personal. I don't know any of you, and I am seeking a result here, not personal popularity.
I just want another game engine to work with- and I want it to have an AI I can work with, that doesn't suck, OK? I didn't start this discussion because I'm an altruistic saint, and you don't have to like me to be polite to me, or give me the respect I am due as somebody who's accomplished quite a bit over the years- and for the most part, given it away freely for strangers to enjoy. If you don't like what I have to say, move on. You can shake your head, ignore this fool, and do your thing- and that's perfectly OK. I really don't wish anybody any harm, and if what I am saying annoys you, and doesn't seem to contain valid points, then just do something else, and be happier.
@Alantai:
I'll keep this short. Ish. And then I'm really going to go for awhile- I have a project to finish, otherwise we could keep this up for months, I suspect, and it wouldn't do much good. If you really think that I am talking down to you, then I will probably need to come back when I have more time, and put my work where my mouth is on this topic- you're right, if I really wanted this, I'd do that, so therefore I must not want it badly enough. I know that is a truth in making games- I've had to learn it the hard way many times!
Another way to see why I started this conversation is to realise that I am a very prolific game designer, and I touch a lot of places and people... mainly for reasons that may or may not make sense to you. I came by last time to plant some seeds, and I've come by this time to see what sprouted. I didn't bother providing any of the hard work or sunshine, so I should probably have just left well enough alone, whether or not I liked the results.
Let's just say that I am not out to be controversial for the sake of same, and I'm sorry if I'm too ignorant to address all of your points in detail at this time- that's not terribly fair of me, and normally I'd get down-and-dirty with your source and we could argue specific points to death, if that was productive. In this case, it isn't.
So, here are my last words on this topic. Feel free to flame me as an ignorant idiot all you want- again, if I wanted this badly enough, I'd just have to get down and pwn u @11. Frankly, I think that if you folks who've been flaming thought about things for a minute, you'd realize that I'm mainly here to get you thinking again. And when I come back, I suspect that somebody will have tried their best to prove my points are completely off-base... if the effort succeeds, and we have a "smart" AI for a RTS that can adjust to any mod that modders can make... well, um... I win
So, here are a few last items. I apologise in advance for the length, but Alantai wanted to see a script... therefore, here is a working, real-world script. Anybody with a copy of Freelancer who still doubts I know what I'm talking about is more than welcome to email me, and I will send them to where they can download my work and see it in action.
1. Humans do not, in fact, generally play games by "looking at stats". This is a false assumption, based, in large part, on your personal experiences as a developer who mainly talks to other like-minded people, not on empirical evidence and the available research.
Please read some articles on the psychology of gameplay if you are really of this opinion. I am not trying to insult you, or talk down to you. I am just pointing out the fact that as a programmer, you probably genuinely do see things that way, and as a game designer, I run into these problems myself- and then have to get beta-testers to sometimes see "the obvious".
I am not really qualified to address this in technical terms, but humans generally play games in terms of abstract gestalts. Yes, human beings can, and do, break down games in terms of their numerical qualities. But- let's be real here- when most people are learning to play a game, they are not staring at the numbers. They are, instead, watching the behavioral patterns of the interface (whatever that is- whether a boardgame or a 3D character on a screen) and they are paying attention to the rules of victory and defeat, reward and penalty. When their manipulation of the game's rules results in victory, players will tend to reinforce their behaviors. But they aren't doing it numerically- it's a lot more complicated than that.
Numerical approaches that do not include explicit rulesets that compel an AI to directly address the fundamental rules of victory, such as, "if my Commander dies, I lose" are never going to work really well. That, in short, is my opinion on this point. You are confusing number-crunching, which humans are pretty lousy at, with intuitive reasoning, spacial coordination and predictive behaviors, which aren't the same things at all! Yes, a computer game is ultimately a sea of numbers that can be sliced in various ways. Yes, it is theoretically possible for a powerful enough computer to slice that sea into manageable chunks and defeat a human player through sheer horsepower. But that's really not practical. A really good game AI is going to use the least horsepower possible, not the most.
I realize that everybody but AAI is building various scenarios into the AIs, and that these projects aren't completely free-form. I did not say differently in my posts- I just argued against this particular fallacy, and explained why I want to see a script-driven, end-user-configurable system, not a black box that may or may do something stupid when I give it a new unit mix to play with. And I did not say that I oppose all forms of "learning"- I think "emotion-driven" systems are a good, proven approach for driving a realtime system. What I did say was that I do not think that hard-coding such things into your AIs is a very good idea, because this severely limits the ability of modders to work with your AI, short of recoding large sections and recompiling a custom version- which is a big hassle, and completely needless. Why is it such a big deal if your scenarios are all in text files, un-compiled, and accessible to end-users?
2. You want to see a script? Here is the entire state-script for one of the Freelancer AIs I wrote. As you can readily see, it's not terribly complicated, by coding standards- only about 200 lines. Writing something like this, which refers to hard-coded specific cases (such as how much the fighter is allowed to turn, maximum, compared to a human player, or how much the fighter's shots will tend to deviate from an aimpoint) was really just a matter of figuring out what calls were available to the Freelancer AIs, combining all available calls into a larger, coherent file like this one, and then tweaking variables.
The hard part, really, was figuring out how Digital Anvil made all of their inter-connected parts work. Believe me, what I started with was nothing like this clean- it was almost 100 pages of text, with numerous sub-sets and referants that made things very confusing at first! But the final results, which are a series of Block calls that, in turn, refer to a number of variable settings... which in turn refer back to hardcoded, low-level behaviors (and, in a couple of areas, higher-level stuff that refers beyond the game object- for example, when the fighter needs to check how far it is from its fellow spacecraft... these things are nice and tidy in this version.
I'll be the first to say that an AI this simplistic, while it can defeat a human in an action game... is not sophisticated enough to defeat a player in a RTS. But I've posted some pseudocode here demonstrating just a few ways that a script interpreter could be built that could really make things work. I'm not some insane weirdo, either- if other modders have been scared of working with something like this- either what you built as frontends (i.e., syntax, command documentation, variable descriptions) was very poor, or you just didn't post to the right people. Build something that's as powerful as this, and easy to use, and people will use it! I'd have to go back and count, and re-include certain options that aren't even in this particular AI, but basically... this has a lot of available settings- you can get a lot've interesting gameplay out've just a few lines, if the hardcoded bits will support this level of scripting.
If you'd like to see some of the AI work I've done with other game engines, let me know. I've worked with the Dawn of War engine (which is yet another state-based AI), with OTA, and with RuneswordII (although I doubt most of you would find that one remotely interesting- much of that scripting was heavily dependent on hardcoded stuff that was, quite frankly, not very tight). This is probably my best work... and I think even somebody who's not familiar with the Freelancer game engine can probably follow the references from one area to the next- I wrote this and commented it for the Freelancer development community, which I'm a member of.
At any rate, here you go. I hope this is more useful to you than my philosophical ramblings, in terms of demonstrating the concept that a state-driven AI doesn't have to be stupid- just fairly flexible, and amenable to scripting...
Code: Select all
;/////////////////////////////////////////
;////////////////////////////////////////////////
;//////////////////////////////////////////////////////
;/////////////////////////////////////////////////////////// EASY
;//////////////////////////////////////////////////////
;////////////////////////////////////////////////
;/////////////////////////////////////////
[Pilot]
nickname = pilot_fighter_easy
job_id = fighter_easy_job
formation_id= formation_fighter_easy
;///////////////////////////////////////////////////////////////////////// DEFENSIVE IDS
missile_reaction_id = missile_reaction_fighter_easy
evade_dodge_id = evade_dodge_fighter_easy
evade_break_id = evade_break_fighter_easy
damage_reaction_id = damage_reaction_fighter_easy
countermeasure_id = countermeasure_fighter_easy
repair_id = repair_fighter_easy
;///////////////////////////////////////////////////////////////////////// OFFENSIVE IDS
gun_id = gun_fighter_easy
missile_id = missile_fighter_easy
mine_id = mine_fighter_easy
buzz_head_toward_id = buzz_head_toward_fighter_easy
buzz_pass_by_id = buzz_pass_by_fighter_easy
trail_id = trail_fighter_easy
strafe_id = strafe_fighter_easy
;//////////////////////////////////////////////////////////////////////// JOBBLOCK
[JobBlock]
nickname = fighter_easy_job
wait_for_leader_target = False
maximum_leader_target_distance = 20000
flee_when_leader_flees_style = False
scene_toughness_threshold = hardest
flee_scene_threat_style = hardest
flee_when_hull_damaged_percent = 0.25
flee_no_weapons_style = False
loot_flee_threshold = hardest
attack_subtarget_order = anything
field_targeting = always
loot_preference = lt_all
force_attack_formation = False
combat_drift_distance = 20000
attack_preference = fighter, 5000, guns | Torpedo| guided | unguided
attack_preference = freighter, 5000, guns | Torpedo| guided | unguided
attack_preference = transport, 5000, guns | Torpedo| guided | unguided
attack_preference = gunboat, 5000, Torpedo | guided | guns | unguided
attack_preference = cruiser, 5000, Torpedo | guided | guns | unguided
attack_preference = capital, 5000, Torpedo | guided | guns | unguided
attack_preference = weapons_platform, 5000, guns | Torpedo| guided | unguided
attack_preference = solar, 5000, Torpedo | guided | guns | unguided
attack_preference = anything, 5000, guns | Torpedo| guided | unguided
;///////////////////////////////////////////////////////////////////////// FORMATION
[FormationBlock]
nickname = formation_fighter_easy
force_attack_formation_active_time = 0
force_attack_formation_unactive_time = 0
break_formation_damage_trigger_percent = 0.999999
break_formation_damage_trigger_time = 0
break_formation_missile_reaction_time = 0
break_apart_formation_missile_reaction_time = 0
break_apart_formation_on_evade_break = True
break_formation_on_evade_break_time = 1
formation_exit_top_turn_break_away_throttle = 1
formation_exit_roll_outrun_throttle = 1
formation_exit_max_time = 5
;///////////////////////////////////////////////////////////////////////// DEFENSIVE
[MissileReactionBlock]
nickname = missile_reaction_fighter_easy
evade_missile_distance = 1000
evade_break_missile_reaction_time = 1
evade_slide_missile_reaction_time = 1
evade_afterburn_missile_reaction_time = 1
;///////////////////////////////////////////////////////////////////////// DEFENSIVE
[EvadeDodgeBlock]
nickname = evade_dodge_fighter_easy
evade_dodge_style_weight = corkscrew, 1.000000
evade_dodge_cone_angle = 20
evade_dodge_interval_time = 2
evade_dodge_time = 2
evade_dodge_distance = 200
evade_activate_range = 250
evade_dodge_roll_angle = 0
evade_dodge_waggle_axis_cone_angle = 0
evade_dodge_slide_throttle = 1
evade_dodge_turn_throttle = 1
evade_dodge_corkscrew_turn_throttle = 0.750000
evade_dodge_corkscrew_roll_throttle = 0.500000
evade_dodge_corkscrew_roll_flip_direction = False
evade_dodge_interval_time_variance_percent = 0.500000
evade_dodge_cone_angle_variance_percent = 0.500000
;///////////////////////////////////////////////////////////////////////// DEFENSIVE
[EvadeBreakBlock]
nickname = evade_break_fighter_easy
evade_break_roll_throttle = 0.100000
evade_break_time = 5
evade_break_interval_time = 2.500000
evade_break_afterburner_delay = 0
evade_break_turn_throttle = 1
evade_break_direction_weight = up, 1.000000
evade_break_direction_weight = down, 1.000000
evade_break_direction_weight = left, 1.000000
evade_break_direction_weight = right, 1.000000
evade_break_style_weight = sideways, 1.000000
evade_break_style_weight = outrun, 1.000000
evade_break_style_weight = reverse, 1.000000
;///////////////////////////////////////////////////////////////////////// DEFENSIVE
[DamageReactionBlock]
nickname = damage_reaction_fighter_easy
evade_break_damage_trigger_percent = 1
evade_dodge_more_damage_trigger_percent = 0.250000
engine_kill_face_damage_trigger_percent = 1
engine_kill_face_damage_trigger_time = 1
roll_damage_trigger_percent = 0.300000
roll_damage_trigger_time = 1
afterburner_damage_trigger_percent = 0.200000
afterburner_damage_trigger_time = 0.500000
brake_reverse_damage_trigger_percent = 1
drop_mines_damage_trigger_percent = 0.250000
drop_mines_damage_trigger_time = 0.100000
fire_guns_damage_trigger_percent = 1
fire_guns_damage_trigger_time = 1
fire_missiles_damage_trigger_percent = 1
fire_missiles_damage_trigger_time = 1
;///////////////////////////////////////////////////////////////////////// DEFENSIVE
[CountermeasureBlock]
nickname = countermeasure_fighter_easy
countermeasure_active_time = 3
countermeasure_unactive_time = 3
;///////////////////////////////////////////////////////////////////////// DEFENSIVE
[RepairBlock]
nickname = repair_fighter_easy
use_shield_repair_pre_delay = 0.1
use_shield_repair_post_delay = 0.1
use_shield_repair_at_damage_percent = 0.5
use_hull_repair_pre_delay = 0
use_hull_repair_post_delay = 0
use_hull_repair_at_damage_percent = 0
;/////////////////////////////////////////
;////////////////////////////////////////////////
;//////////////////////////////////////////////////////
;///////////////////////////////////////////////////////////////////////// OFFENSIVE
[GunBlock]
nickname = gun_fighter_easy
gun_fire_interval_time = 0
gun_fire_interval_variance_percent = 0.5
gun_fire_burst_interval_time = 4
gun_fire_burst_interval_variance_percent = 0.500000
gun_fire_no_burst_interval_time = 4
gun_fire_accuracy_cone_angle = 4
gun_fire_accuracy_power = 1.100000
gun_range_threshold = 1.000000
gun_target_point_switch_time = 0.5
fire_style = multiple
auto_turret_interval_time = 0
auto_turret_burst_interval_time = 3
auto_turret_no_burst_interval_time = 3
auto_turret_burst_interval_variance_percent = 0.200000
gun_range_threshold_variance_percent = 0.200000
gun_fire_accuracy_power_npc = 1
;///////////////////////////////////////////////////////////////////////// OFFENSIVE
[MissileBlock]
nickname = missile_fighter_easy
missile_launch_interval_time = 30
missile_launch_interval_variance_percent = 0.500000
missile_launch_range = 2000
missile_launch_cone_angle = 22.500000
missile_launch_allow_out_of_range = False
;///////////////////////////////////////////////////////////////////////// OFFENSIVE
[MineBlock]
nickname = mine_fighter_easy
mine_launch_interval = 10
mine_launch_cone_angle = 360
mine_launch_range = 250
;///////////////////////////////////////////////////////////////////////// OFFENSIVE
[BuzzHeadTowardBlock]
nickname = buzz_head_toward_fighter_easy
buzz_min_distance_to_head_toward = 500
buzz_min_distance_to_head_toward_variance_percent = 0.100000
buzz_max_time_to_head_away = 5
buzz_head_toward_engine_throttle = 1
buzz_head_toward_turn_throttle = 1
buzz_head_toward_roll_throttle = 1
buzz_head_toward_style_weight = straight_to, 1.000000
;///////////////////////////////////////////////////////////////////////// OFFENSIVE
[BuzzPassByBlock]
nickname = buzz_pass_by_fighter_easy
buzz_distance_to_pass_by = 100
buzz_pass_by_time = 1
buzz_break_turn_throttle = 1
buzz_break_direction_weight = left, 1.000000
buzz_break_direction_weight = right, 1.000000
buzz_pass_by_style_weight = break_away, 1.000000
;///////////////////////////////////////////////////////////////////////// OFFENSIVE
[TrailBlock]
nickname = trail_fighter_easy
trail_lock_cone_angle = 30
trail_break_time = 2.000000
trail_max_turn_throttle = 0.6
trail_distance = 300
[StrafeBlock]
nickname = strafe_fighter_easy
strafe_run_away_distance = 100
strafe_attack_throttle = 1
Nice script, it really shows well the behaviour of the fighting craft. It does have a lot of "when to do things" with the numbers, also some of what to do and where to go, mainly with the string fields.
No idea how I could map to the behaviour to the RTS AIs, maybe it's the lack of understanding, or lack of AI interface, we'd have to build this all from scratch. Maybe after that is done, even I could implement the modability/interpretation ideas.
Even if state-based AIs are the best tool for the job, I still wouldn't know what are the states we need to do the job. It's easy to figure out the "enemy attacked me" initial state and the "attack enemy" final state, just everything between the beginning and the end that isn't trivial.
Maybe I should develop a little to actually have an insight to talk about it.
Just a question, what the Dawn of War AI script tell the engine? Since it's an RTS probably that would be better understood.
No idea how I could map to the behaviour to the RTS AIs, maybe it's the lack of understanding, or lack of AI interface, we'd have to build this all from scratch. Maybe after that is done, even I could implement the modability/interpretation ideas.
Even if state-based AIs are the best tool for the job, I still wouldn't know what are the states we need to do the job. It's easy to figure out the "enemy attacked me" initial state and the "attack enemy" final state, just everything between the beginning and the end that isn't trivial.
Maybe I should develop a little to actually have an insight to talk about it.
Just a question, what the Dawn of War AI script tell the engine? Since it's an RTS probably that would be better understood.
@Renrutal:
The short answer is that the DOW AI uses a weighting system with a build tree approach, much like OTA did. And it cheats, in various explicit and user-controllable ways. You can, for example, give units various bonuses if the AI is using them, like health bonuses, faster build times, etc. And users can actually give it limitations that are very significant- like literally making it wait for X seconds until it begins doing anything, or until the Threat Level of the human's armies is high enough (it keeps a running total based on what the human builds, of course). This makes it a very controllable AI in a lot of respects, and I was very easily able to make it completely able to defeat me with sheer numbers, on any battlefields that feature relatively open terrains. Which, from my standpoint, is just about perfect- I really like being able to make an AI do what I need it to, and provide appropriate levels of challenge.
DOW's AI has a lot of hard-coded behaviors, such as seeking out specific types of objective depending on the Map Objective. These things can't be messed with, in any significant way, which is a problem- but, to some extent, it's an unavoidable problem with a state-based system, and given the complexity of the various Mission Objectives that can be used (everything from "assasinate the leader" to "capture the flags" ), I'm not surprised that these things aren't accessible to end-users or to the game-designers who built the game's balance, etc.- that stuff has to run fast, be super-optimized, and doesn't have to be terribly flexible- but it has to achieve the desired result, even if it's bloody stupid.
Still, if you just crank up the cheating a bit and make it start building units right after GO, it can very easily give a human player a very worthwhile and structured game- it builds upgrades and uses high-level units just like players do, and unlike OTA, it follows build limit instructions properly, so you don't see a lot of ridiculous stuff, like 50 Orks and only one Dreadnought. It's helped in this, of course, by the relatively small upper limit on units that any side can have- when I removed this limitation, I had to also raise its build limits and reshape it a bit to get it to give a smoother transition. I will not even slightly claim that my final results were totally, 100% airtight or perfect- this was an experiment that I conducted with the game engine because I was thinking about making a TC mod for it, and I figured that I'd start with the hard stuff first. I got just about all of the factions re-balanced and removed a great deal of the things that had annoyed me about the original game balance, and tweaked the AI, but that was as far as I got. If you'd like, I think I still have some of those scripts, and I could post them.
The short answer is that the DOW AI uses a weighting system with a build tree approach, much like OTA did. And it cheats, in various explicit and user-controllable ways. You can, for example, give units various bonuses if the AI is using them, like health bonuses, faster build times, etc. And users can actually give it limitations that are very significant- like literally making it wait for X seconds until it begins doing anything, or until the Threat Level of the human's armies is high enough (it keeps a running total based on what the human builds, of course). This makes it a very controllable AI in a lot of respects, and I was very easily able to make it completely able to defeat me with sheer numbers, on any battlefields that feature relatively open terrains. Which, from my standpoint, is just about perfect- I really like being able to make an AI do what I need it to, and provide appropriate levels of challenge.
DOW's AI has a lot of hard-coded behaviors, such as seeking out specific types of objective depending on the Map Objective. These things can't be messed with, in any significant way, which is a problem- but, to some extent, it's an unavoidable problem with a state-based system, and given the complexity of the various Mission Objectives that can be used (everything from "assasinate the leader" to "capture the flags" ), I'm not surprised that these things aren't accessible to end-users or to the game-designers who built the game's balance, etc.- that stuff has to run fast, be super-optimized, and doesn't have to be terribly flexible- but it has to achieve the desired result, even if it's bloody stupid.
Still, if you just crank up the cheating a bit and make it start building units right after GO, it can very easily give a human player a very worthwhile and structured game- it builds upgrades and uses high-level units just like players do, and unlike OTA, it follows build limit instructions properly, so you don't see a lot of ridiculous stuff, like 50 Orks and only one Dreadnought. It's helped in this, of course, by the relatively small upper limit on units that any side can have- when I removed this limitation, I had to also raise its build limits and reshape it a bit to get it to give a smoother transition. I will not even slightly claim that my final results were totally, 100% airtight or perfect- this was an experiment that I conducted with the game engine because I was thinking about making a TC mod for it, and I figured that I'd start with the hard stuff first. I got just about all of the factions re-balanced and removed a great deal of the things that had annoyed me about the original game balance, and tweaked the AI, but that was as far as I got. If you'd like, I think I still have some of those scripts, and I could post them.
that is EXACTLY what i want: a ta spring AI that gives me a very very hard time to beat it, it even possible. i dont really much care if it cheats and maybe has the buildcosts halved or less. i dont care how it works behind the scenes. i dont care how many incredible stats run while it plays against me. all i care about as a TA player is that some hundred enemy tanks and mechs approach my base and i piss myself because i just finished my first HLT :). That is what total annihilation is about - pointless battles with thousands of units and maybe someday one player will emerge as victor either because he was the more cunning one or because he build some thousand units more than his enemies.
what i was trying to say with that post was not that a "good" AI should be measured by the amount of calculations that run it in the background but rather by the success in playing vs a human. i woulndt mind if the AI cheats in terms of getting double triple or quadruple metal and energy output from all res producing buildings and units as long as i have a hard time beating it when it throws much more times the amount of units against me than it does now. i want to have to carve my path through metal when leaving my base (and not some craters from 10 attacking pyros that died from my annis 5 seconds after entering weapons range) . TA in my eyes is about building huge armies and letting them clash and watch the beauty of the battle while trying to coordinate the mess to your favor. to that respect i wont care if an AI plays dishonestly. its the same with Civilization - only after giving the AI 3 times the output in all aspects of the game it becomes a real threat to a human. in my eyes the only advantage an AI has over a human is the freakish amount of micromanagement it can accomplish on no time at all, but that bonus doesnt kick in until the armies and bases get big enough to matter. why not let them cheat? i wouldnt care as long as i have my fun with hard to beat AIs. and then start from that point - improving the AI doesnt mean it will win against more and more experienced players on more and more maps - it will mean you can decrease the "AI Bonus" you give it, until maybe you arrive at the point where you dont need any bonus at all for your AI because it has evolved to something that can beat a human player without advantages given to it.
maybe someone considers this and starts from that point - unfortunately i dont even know if letting the AI get such bonuses is even possible.
. TA in my eyes is about building huge armies and letting them clash and watch the beauty of the battle while trying to coordinate the mess to your favor. to that respect i wont care if an AI plays dishonestly. its the same with Civilization - only after giving the AI 3 times the output in all aspects of the game it becomes a real threat to a human. in my eyes the only advantage an AI has over a human is the freakish amount of micromanagement it can accomplish on no time at all, but that bonus doesnt kick in until the armies and bases get big enough to matter. why not let them cheat? i wouldnt care as long as i have my fun with hard to beat AIs. and then start from that point - improving the AI doesnt mean it will win against more and more experienced players on more and more maps - it will mean you can decrease the "AI Bonus" you give it, until maybe you arrive at the point where you dont need any bonus at all for your AI because it has evolved to something that can beat a human player without advantages given to it. maybe someone considers this and starts from that point - unfortunately i dont even know if letting the AI get such bonuses is even possible.
Well, if what you simply want is hordes attacking you, the spawn scripts are there for you, you can make one in 5 mins and adjust it to you level and preferences easily...
I wanna make a serious AI, that actually plays well in an honest way. You guys think its not possible, but i already have enough evidence to support this possibility. Gimme a couple months and you guys will see what a non-cheating AI can do
...
I simply believe its nowhere nearly as fun to have mindless hordes thrown at you when you could play against a smart opponent. Maybe im just a dreamer, but my dream of AI beating Humans on fair ground is being worked on.
Its worked for chess, and i find chess a much harder and complex game than TA!
I wanna make a serious AI, that actually plays well in an honest way. You guys think its not possible, but i already have enough evidence to support this possibility. Gimme a couple months and you guys will see what a non-cheating AI can do
...I simply believe its nowhere nearly as fun to have mindless hordes thrown at you when you could play against a smart opponent. Maybe im just a dreamer, but my dream of AI beating Humans on fair ground is being worked on.
Its worked for chess, and i find chess a much harder and complex game than TA!