Ok this si going to be basic moddability, that sorta falls into OTAI and AAI's sights mostly at the moment.
I propose using the CSUNParser style class veylon uses in OTAI tor ead extra tags form the unit fbi.
Primarily tags of the following type
Purpose1=Energy
Score1=60
Purpose2=....
and so on, for each unti so that a modder can deliberatly tweak them, or simply use them as default scores. AAI could use this as a starting poitn for learning files to build upon, OTAI could apply these weights to the existing ones in its file, or use them if no definition is available.
Ontop of that, the same could be added for maps, such as
Purpose1=Wind
modifier1=1.5
Purpose2=tidal
modifier2=2.5
aswell as
maptype=water
with something akin tot he following as types of map
SEA
LAND
ISLAND
CONTINENT (large landmass surrounded by sea (swampy island, anglosaxonredux))
and for purpose types
ENERGY
WIND
TIDAL
ESTORE
MSTORE
MAKER
MEX
ARTILLERY
SCOUT
STRIKE
BUILDER
AA
and so on, I'll start a thread in the mod forum asking about this and what should be on the list.
Last of all it might be of use to have two extra tags for a unit
PrimaryPurpose=
and
PrefMapType=
These tags would be ignored by the engine when parsed but available to the AI through the modifiedcsunparser class.
I'll say mroe on this tomorrow as I've sorta ran out of time...
AI Moddability Stage 1
Moderators: hoijui, Moderators
If I may... I'd suggest a couple of things:
1. Have the files be in a seperate place other than the FBIs, or have them be in a different block, so that they aren't just randomly placed just anywhere in the FBI. This would keep them visually seperate (already a problem with FBIs, which have very little structure) and easier for people to work with. At the very least... we should build examples that are nice and clean. I will be willing to alter my mini-mods to meet these standards, just so that people can see them in action (just as, for those who've been paying any attention to NanoBlobs, I've been very steadily removing all "junk" data from the mod- 90% of the initial mod's size (it was about 2.2MB) was stuff I didn't need...
2. I would like to reach some agreement on building a set of global controls that would be put into a mod's files somewhere (probably the root directory). IOW... if we're going to (eventually) see AIs that modders can do things like:
A. Make neutral unless attacked (yes, I have a game design in mind that uses that feature, as well as Gaia stuff).
B. Always "hates"/"fears" players that are a certain race (Carnivores "hate" Herbivores, for example... a simple way of building a working "ecology" with Gaia-like behaviors). This could also be done at the FBI level, so long as Gaia could attack itself...
C. Will obey a strict buildtree until it runs out've instructions (to optimize early start behaviors and give non-cheating AIs a chance to survive against people rushing it).
D. Will take a "stance" (a very general term, subject to interpretation by AI designers at the hardcoded level) based on what race/map this is. This is a global thing, not just a specific unit-by-unit thing- you want an AI to not waste time/processor trying to go Land when the map is Sea, and if we can also get some sort've properties embedded into the Map format then we'd be all set... I'll go post about that in Development...
Anyhow... the first three are, in my opinion, really necessary, if we're going to see some really sophisticated game designs that the AI can play well, and have a functional Gaia that may be crude but works OK. And I think it would be much better to leave these things open to modders to define, so that we don't run up against fundamental limitations really fast.
For example, I'd like to make a game where you could have AIs that were at war with one another, and hated one another, but ignored humans unless they attacked it. Then we could have AI races that were quite powerful, and player-controlled races that were pretty weak... and ramp gameplay so that human players would eventually have to kill the AIs to win against other players...
Lastly... and yes, this is just a random thought... do any of the current AIs "keep score" in free-for-all games, or do they all just attack pretty much anybody? That'd be useful for a variety of reasons- humans tend to gang up on each other in RTS play, to defeat players that are getting too powerful, and AIs should at least approximate this if they can.
And, yes, I know I'm asking for a lot here, so I won't hold my breath
1. Have the files be in a seperate place other than the FBIs, or have them be in a different block, so that they aren't just randomly placed just anywhere in the FBI. This would keep them visually seperate (already a problem with FBIs, which have very little structure) and easier for people to work with. At the very least... we should build examples that are nice and clean. I will be willing to alter my mini-mods to meet these standards, just so that people can see them in action (just as, for those who've been paying any attention to NanoBlobs, I've been very steadily removing all "junk" data from the mod- 90% of the initial mod's size (it was about 2.2MB) was stuff I didn't need...
2. I would like to reach some agreement on building a set of global controls that would be put into a mod's files somewhere (probably the root directory). IOW... if we're going to (eventually) see AIs that modders can do things like:
A. Make neutral unless attacked (yes, I have a game design in mind that uses that feature, as well as Gaia stuff).
B. Always "hates"/"fears" players that are a certain race (Carnivores "hate" Herbivores, for example... a simple way of building a working "ecology" with Gaia-like behaviors). This could also be done at the FBI level, so long as Gaia could attack itself...
C. Will obey a strict buildtree until it runs out've instructions (to optimize early start behaviors and give non-cheating AIs a chance to survive against people rushing it).
D. Will take a "stance" (a very general term, subject to interpretation by AI designers at the hardcoded level) based on what race/map this is. This is a global thing, not just a specific unit-by-unit thing- you want an AI to not waste time/processor trying to go Land when the map is Sea, and if we can also get some sort've properties embedded into the Map format then we'd be all set... I'll go post about that in Development...
Anyhow... the first three are, in my opinion, really necessary, if we're going to see some really sophisticated game designs that the AI can play well, and have a functional Gaia that may be crude but works OK. And I think it would be much better to leave these things open to modders to define, so that we don't run up against fundamental limitations really fast.
For example, I'd like to make a game where you could have AIs that were at war with one another, and hated one another, but ignored humans unless they attacked it. Then we could have AI races that were quite powerful, and player-controlled races that were pretty weak... and ramp gameplay so that human players would eventually have to kill the AIs to win against other players...
Lastly... and yes, this is just a random thought... do any of the current AIs "keep score" in free-for-all games, or do they all just attack pretty much anybody? That'd be useful for a variety of reasons- humans tend to gang up on each other in RTS play, to defeat players that are getting too powerful, and AIs should at least approximate this if they can.
And, yes, I know I'm asking for a lot here, so I won't hold my breath
Yes I have those in mind.
However I am willing to take this one step at a time. This is a simple thign that can be added to a unit FBI and a map SMD should the mapper/modder wish, and it has a direct existing use for AAI, and OTAI aswell as future considerations for NTAI and KAI.
However further on we get into the problem of:
proposal a is incompatible with structure a.
Our AI's work on different principles. How are AAI/JCAI/OTAI going to support custom build trees? Their construction systems work off a totally different principle to NTAI and KAI which are build tree reliant.
The weights are of use to OTAI and AAI and those types of systems, and any freeform system currently in place. Build trees can make use of this but I agree that modders should be able to customize the build trees should they wish.
My thougths currently are that if I cannot get a way of adding rules and if statements to a buildtree proposal, then it'd be as much as
[CORCK1]
item1=cormex
item2=corsolar
item3=corlab
[CORCK2]
item1= repair
item2 = repair
item3 = repair
etc... with each beign an altrnative build tree for CORCK
and perhaps a
[CORCK]
tree1=0.8
tree2 = 0.2
for weights as to which build tree is more common
However I am willing to take this one step at a time. This is a simple thign that can be added to a unit FBI and a map SMD should the mapper/modder wish, and it has a direct existing use for AAI, and OTAI aswell as future considerations for NTAI and KAI.
However further on we get into the problem of:
proposal a is incompatible with structure a.
Our AI's work on different principles. How are AAI/JCAI/OTAI going to support custom build trees? Their construction systems work off a totally different principle to NTAI and KAI which are build tree reliant.
The weights are of use to OTAI and AAI and those types of systems, and any freeform system currently in place. Build trees can make use of this but I agree that modders should be able to customize the build trees should they wish.
My thougths currently are that if I cannot get a way of adding rules and if statements to a buildtree proposal, then it'd be as much as
[CORCK1]
item1=cormex
item2=corsolar
item3=corlab
[CORCK2]
item1= repair
item2 = repair
item3 = repair
etc... with each beign an altrnative build tree for CORCK
and perhaps a
[CORCK]
tree1=0.8
tree2 = 0.2
for weights as to which build tree is more common
I think you're offloading too much of the burden of good ai-balancing onto the modders. Suppose they say the primary purpose of a moho metal extractor is metal making - your ai will skip it in preference to regular metal extractors. Suppose instead we figure out, from the unit properties, which units are best for a given strategy (metal extractors extract A amount with B energy units, mohos get 5*A and 10*B...but that is far 60 times more efficient than the alternative increased metal supply of A/2 amount and B*60 energy).
What might be interesting, and I originally though this was your proposal, was for a mod-independent parser to be made for AI's that would read the properties of each unit and create a categorization for them.
What might be interesting, and I originally though this was your proposal, was for a mod-independent parser to be made for AI's that would read the properties of each unit and create a categorization for them.
I would have to respectfully disagree.
As a game designer... I want control over everything that isn't low-level behavior to at least be somewhat possible. I don't expect that we'll get there, really, but even something fairly simple, like the weights AF is proposing are a nice step in the right direction.
If you've ever designed a complete game, you'd understand, trust me... you want control over everything, because it all ends up being a factor in how much fun the final game design is. I don't know what you've built, Kelson, but whenever I work with a new game engine, I seek out the maximum limits of the controls as fast as I can... and in this case, with the fact that Spring is joyfully Open Source, I can even (nicely, respectfully, and not-too-often) ask the development team if they'd be willing to add things to the engine and make "the impossible" happen, which is nice
As a game designer... I want control over everything that isn't low-level behavior to at least be somewhat possible. I don't expect that we'll get there, really, but even something fairly simple, like the weights AF is proposing are a nice step in the right direction.
If you've ever designed a complete game, you'd understand, trust me... you want control over everything, because it all ends up being a factor in how much fun the final game design is. I don't know what you've built, Kelson, but whenever I work with a new game engine, I seek out the maximum limits of the controls as fast as I can... and in this case, with the fact that Spring is joyfully Open Source, I can even (nicely, respectfully, and not-too-often) ask the development team if they'd be willing to add things to the engine and make "the impossible" happen, which is nice
Because that would complicate things possibly.
In the AI as it is now to get the data it's simple as
get unitdef of cormex
retrieve value item1 from file ud->filename; or return x if ti doesnt exist.
Kelson, these are nto be all end all, forcing mdoders to do this is nto what I'm doing. We will still sue our current systems, hwoever if there is extra information (such as in the form proposed here), then it should be used. Afterrall what if unti x can be used for 2 things, purpose and purpose b, yet the modder does not intend for it to have purpose b, and the AI naturally takes advantage of this.
Or what if the modder prefers that the AI attack with these unit mixes specifically even though the AI disagrees? If this data is not here then the AI makes up its own mind.
If this data was specific to NTAI ro any other AI I would definately have gone for using a seperate folder, but this si a proposed standard.
However I think it has merit, so I propose instead that we use AI/modname.tdf for the unit weights
in the form
[CORCK]
Purpose1=...
Score1=..
etc
Aswell as
AI/MapName.tdf for the map specific weights
[GENERAL]
Maptype = SEA
Purpose1=Wind
modifier1=1.5
Purpose2=tidal
modifier2=2.5
Are there any objections to this?
In the AI as it is now to get the data it's simple as
get unitdef of cormex
retrieve value item1 from file ud->filename; or return x if ti doesnt exist.
Kelson, these are nto be all end all, forcing mdoders to do this is nto what I'm doing. We will still sue our current systems, hwoever if there is extra information (such as in the form proposed here), then it should be used. Afterrall what if unti x can be used for 2 things, purpose and purpose b, yet the modder does not intend for it to have purpose b, and the AI naturally takes advantage of this.
Or what if the modder prefers that the AI attack with these unit mixes specifically even though the AI disagrees? If this data is not here then the AI makes up its own mind.
If this data was specific to NTAI ro any other AI I would definately have gone for using a seperate folder, but this si a proposed standard.
However I think it has merit, so I propose instead that we use AI/modname.tdf for the unit weights
in the form
[CORCK]
Purpose1=...
Score1=..
etc
Aswell as
AI/MapName.tdf for the map specific weights
[GENERAL]
Maptype = SEA
Purpose1=Wind
modifier1=1.5
Purpose2=tidal
modifier2=2.5
Are there any objections to this?
I should point out that I snatched the CSunParser out of the engine's source code and shoehorned it into my AI, lest anyone think that I was being original.
The only reason I did this was to get the starting locations for my scouting system and wanted a generic way to do so, in case I wanted to pull more information out of the system.
I still don't understand the big deal about buildtrees. The AI can and should rip the buildtree out of the various unitdefs. I haven't bothered much because my AI doesn't really care about them.
On categorization, OTAI does categorize by unit abilities! If it builds and moves, it's a builder. If it has dropped weapons and flys, it's a bomber. If it has a weapon in moves, it's an attacker. If it extracts metal, it's a mex.
BTW, my AI uses whatever mex comes to hand, but will replace worse mexxes with better (higher extraction) mexxes as it goes. Sometimes.
The only reason I did this was to get the starting locations for my scouting system and wanted a generic way to do so, in case I wanted to pull more information out of the system.
I still don't understand the big deal about buildtrees. The AI can and should rip the buildtree out of the various unitdefs. I haven't bothered much because my AI doesn't really care about them.
On categorization, OTAI does categorize by unit abilities! If it builds and moves, it's a builder. If it has dropped weapons and flys, it's a bomber. If it has a weapon in moves, it's an attacker. If it extracts metal, it's a mex.
BTW, my AI uses whatever mex comes to hand, but will replace worse mexxes with better (higher extraction) mexxes as it goes. Sometimes.
Veylon, imagine a unti that behaved like a factory, was very slow moving, and had a weapon, and it flew.
According to your classifications ti will fall into a single category, perhaps the modder intends it to be used as a factory, yet the AI could end up interpreting it as a gunship, or not use it both ways and conflict.
How about an artillery unit that had a small nanolathe to build a mine? Would OTAI see it as an artillery unit or a minelayer?
How about the air scouts in AA with weapons? Should you scout with them or attack with them? These configs allow the moder to set that up.
It also allows mdoders to define how well they do it, and how likely the AI should be able to build them. For example it could be used simply to generate a ratio of mex vs armed mexes, or a mex vs metal maker economy if tweaked correctly.
Yes we can take the buildtree as you put ti from the unit fbi's, btu we have that from the unitdef, or from the engine asking what commands with an id smaller than zero we cna do. That doesnt tell us what to build btu what we can build. You, zaphod and sub have taken an approach of dciding what you need then looking for something that fullfills it.
Me and krogothe have taken the approach of knowing what we want and trying to build it. You see if (event a) is true then look for factory, we see can we build corlab if so build it, that and the unti orientatd approach of build tree systems of NTAI/KAI versus the globalized approach of AAI/OTAI/JCAI/ZcAIn. That is why NTAI and KAI can use strategies better, because KAI and NTAI can have them hardcoded into the build tree so those units are built anyways.
Ontop of that we can change our build trees by adding logic and forking them based on if statements and events, and add other tasks such as repair nearest unit, move here etc.
According to your classifications ti will fall into a single category, perhaps the modder intends it to be used as a factory, yet the AI could end up interpreting it as a gunship, or not use it both ways and conflict.
How about an artillery unit that had a small nanolathe to build a mine? Would OTAI see it as an artillery unit or a minelayer?
How about the air scouts in AA with weapons? Should you scout with them or attack with them? These configs allow the moder to set that up.
It also allows mdoders to define how well they do it, and how likely the AI should be able to build them. For example it could be used simply to generate a ratio of mex vs armed mexes, or a mex vs metal maker economy if tweaked correctly.
From that statement I now know that we're talkign about totally different thigns. When I refer to build tree, I am referring to the lists of what a commander will build, and you mean what the commander can build.I still don't understand the big deal about buildtrees. The AI can and should rip the buildtree out of the various unitdefs. I haven't bothered much because my AI doesn't really care about them.
Yes we can take the buildtree as you put ti from the unit fbi's, btu we have that from the unitdef, or from the engine asking what commands with an id smaller than zero we cna do. That doesnt tell us what to build btu what we can build. You, zaphod and sub have taken an approach of dciding what you need then looking for something that fullfills it.
Me and krogothe have taken the approach of knowing what we want and trying to build it. You see if (event a) is true then look for factory, we see can we build corlab if so build it, that and the unti orientatd approach of build tree systems of NTAI/KAI versus the globalized approach of AAI/OTAI/JCAI/ZcAIn. That is why NTAI and KAI can use strategies better, because KAI and NTAI can have them hardcoded into the build tree so those units are built anyways.
Ontop of that we can change our build trees by adding logic and forking them based on if statements and events, and add other tasks such as repair nearest unit, move here etc.
I think OTAI would interpret the first two as commander-type units, using them mostly to build, but fight back when attacked. Right now it only uses units for scouts if they are specifically marked for that in the profile.
I might point out the disadvantages of hardcoding things into the AI, though. How would NTAI itself respond to the examples you presented? Does it have a way of distinguishing the categories and purposes of units that are not hardcoded into it's structure?
What if the makers of the AA mod suddenly decided to give the scout aircraft guns or the bombers lasers or changed the version number to 1.55. Would your buildtree system recognize and use these changes to the best advantage? How many decisions of balance and strategy do you really wish to defer to the modders and mapmakers?
I might point out the disadvantages of hardcoding things into the AI, though. How would NTAI itself respond to the examples you presented? Does it have a way of distinguishing the categories and purposes of units that are not hardcoded into it's structure?
What if the makers of the AA mod suddenly decided to give the scout aircraft guns or the bombers lasers or changed the version number to 1.55. Would your buildtree system recognize and use these changes to the best advantage? How many decisions of balance and strategy do you really wish to defer to the modders and mapmakers?
version change to 1.55:
No effect, IF it was hardcodd, however that would primarily be the same as always because the AA buildtree is extremely abstract because I know so little.
0.3 planned code: if base stats change evaluate the unit and generate a score, take the original score and all the existing saved values and multiply them by the percentage of difference between the new and old stats.
etc...
I hardcoded certain thigns in because it was a good course of action and provided better results than the ordinary methods, hwoever I'm not blinded by it, hence why i started creating more abstract build trees with if statements and random elements, and freeform entries where the AI decided for itself what it wanted.
NTAI also doesnt work in the same way as the other AI's in sorting its untis in that it scores each and every units according to its ability rather than sort it into capability groups. That way unti A may be good at both task A and Task B, if unti A is best at Task A then NTAI will choose it and likewise for Task B.
Also veylon, you seem to have missed the entire point of this thread. Sometimes a modder wants absolute control, and they may nto agreee with us as AI developers and may wish their untis to behave in a different way, they may think our AI's are misusing them? Currently AI developers are the be all end all of skirmish games, we're apparently responsible for every facet of a skirmish game save the players actions, sometimes we're even said to be responsible for those in this community, I dont see it that way in other games and I think it bad practise to have zero moddability in our AI's if we want to go forward.
Just look at AAI, because of submarines mod scripts support it has the potential to work for the vast majority of mods in this community. Should we destroy them in favor of letting submarine handle these thgins and hardcode them into the dll? Or should we let modders write them?
I've been coding an AI I havent been balancing out how mods play.
So please dont stress to me about hardcoded stuff in NTAI, and sorting thigns out, I'd written unit type sorting routines long before I started NTAI, and my build trees arent fully hardcoded at all in 0.3+
No effect, IF it was hardcodd, however that would primarily be the same as always because the AA buildtree is extremely abstract because I know so little.
0.3 planned code: if base stats change evaluate the unit and generate a score, take the original score and all the existing saved values and multiply them by the percentage of difference between the new and old stats.
etc...
I hardcoded certain thigns in because it was a good course of action and provided better results than the ordinary methods, hwoever I'm not blinded by it, hence why i started creating more abstract build trees with if statements and random elements, and freeform entries where the AI decided for itself what it wanted.
NTAI also doesnt work in the same way as the other AI's in sorting its untis in that it scores each and every units according to its ability rather than sort it into capability groups. That way unti A may be good at both task A and Task B, if unti A is best at Task A then NTAI will choose it and likewise for Task B.
Also veylon, you seem to have missed the entire point of this thread. Sometimes a modder wants absolute control, and they may nto agreee with us as AI developers and may wish their untis to behave in a different way, they may think our AI's are misusing them? Currently AI developers are the be all end all of skirmish games, we're apparently responsible for every facet of a skirmish game save the players actions, sometimes we're even said to be responsible for those in this community, I dont see it that way in other games and I think it bad practise to have zero moddability in our AI's if we want to go forward.
Just look at AAI, because of submarines mod scripts support it has the potential to work for the vast majority of mods in this community. Should we destroy them in favor of letting submarine handle these thgins and hardcode them into the dll? Or should we let modders write them?
I've been coding an AI I havent been balancing out how mods play.
So please dont stress to me about hardcoded stuff in NTAI, and sorting thigns out, I'd written unit type sorting routines long before I started NTAI, and my build trees arent fully hardcoded at all in 0.3+
Which is to say, yours decides what to do and then what to build and with what.
Whereas, mine builds something and then decides what to do with it.
I can see the attractiveness of the your approach, but I'll stick with mine for now. I'll try not to stress out too much about it. I'll do things my way and you can do things your way.
Whereas, mine builds something and then decides what to do with it.
I can see the attractiveness of the your approach, but I'll stick with mine for now. I'll try not to stress out too much about it. I'll do things my way and you can do things your way.