Unit Effectiveness
It is important to know which units are effective versus opposing units. On the simplest level, this is making anti-air units to fight planes, or anti-water defenses on water maps. A medium level of unit planning would be making groups that balance each other well, like tanks and rockets, or cloaked scouts and artillery. At the high end, unit planning would involve tracking which units the enemy has built (scouting, cheating or direct exposure) and building appropriate counter units, read from the armor.txt and weapondefs files. If they have 100 of unit X, build 100 of unit Y that does double damage to unit X. (Appropriate numbers of forces are another estimation handled elsewhere.) At the even higher end, this would involve measuring the combat performance of troops.
There are several heuristics of imporantance to mention. The first is the previously stated weapon comparisons, noting which units do extra damage. Next of course would calculate ideal damage over time calculations based on damage, rate of fire and life comparisons, assuming 100% hit. (These calculations would also assume even rows of forces standing and firing.) Next we include range and movement into our calculations, but these equations become more complex. Then we account for alternative formations, and the formation of the opposing side. This is nearly impossible to calculate, but a new equation could be drawn for each formation match up. Lastly, we would include deviations from terrain, wreckage, misses, manuerability, targeting of units (hit the high damage, low armor, low defense units first), and so on. At this level of tracking, the only thing to do is run many plausible combat tests. This leads into tactical effectiveness.
Tactical Effectiveness
It is possible for an AI to be more effective than a human player in head on skirmishes. For example, they could use math to determine lead time with rockets, and hit a steadily moving unit every time. They could (eventually strafe) move in such a way to avoid certain slow moving weapons, like artillery or rockets. It is a great amount of fun to circle with rockos and kill a superior force of thuds. It is also possible for faster moving units that can fire in reverse to run away while killing the opposing forces. (Slasher vs AK while driving away) These are tactics that could be selectively employed by either players or a game AI. Tactics could be presupplied by programmers (planes guarding ground troops, confusing enemy turrets), or devised by the AI itself (calculated effiency).
At this level, there is no estimate that could be accurate except recording game play statistics. To expeditite testing of tactical maneuvers, formations and combat matching, a series of tests could be devised, and played out. The statistics gathered from ideal matchups I shall refer to as "baseline". Baseline statistics do not reflect reality of terrain, actual play by human opponents or competitive AI, wreckage, etc. These statistics are modified and updated by changes, which are specific (only one change) or aggregated (multiple changes). The amount of movement impeding wreckage could also vary for tactical situations, and how the tactics adjust will alter performance drastically. (hiding artillery or rockets behind wreckage, artillery fires over wreckage while lasers are blocked)
How should we adjust the calculated performance effectiveness based on these varying conditions? With so many changes possible working out the updated statistics can be very complicated, especially by hand. Even programmatically this can be a daunting task, but there is an area of math that deals with this concept. It is also possible to use estimates and uncertain values in conjuction with statistics, and store a derived statistic to be tested against. Each modifying factor, like hilly terrain, a specific formation or tactic, the opponent, the (nonsynergistic) effect of having multiple types of units, etc should all be included in the calculation.
This is Bayes Rule, or Bayesian Statistics, and a very very good reason to use functional programming languages like OCaml. The data storage mechanisms we would need (immutable variables, optional inclusion, etc) are built into OCaml. This makes it easier for the programmer to express the logical changes going on, but any Turing-Complete system (which includes ancient computers, programs written in assembler, etc) can solve the problems that any other turing complete system. In fact, Turing Complete systems were detailed in 1937, before computers were invented. This is to say that while any programming language can express these statistics, some languages are easier to write for some things rather than others.
At a higher level, it is possible for similar global tactics to be employed, like resource management, threat calculations, and so on. This effectiveness calculation represents the crux of the matter, and the (I believe) unique proposal for an AI. The beauty of this level of abstraction is that any tactic (global, formation, playstyle, tactical confrontation, etc) could be used, it would simply record under what circumstances each technique was effective. There is a common conceptual mistake, and that is that the tactics used are "Artifical Intelligence" when in reality, it is the decision making processes and design of processes that really constitutes "intelligence".
At this point it should be obvious that I intend to do some work on an AI. I would prefer that to be a collaborative effort. Any programming language for the AI is acceptable that OCaml can call for specific modules. This includes C, C++, ML, Perl, Python and several more. In the next major post, I intend to detail the different modules, how they interoperate, and so on. Some 'base' modules will allow individuals to edit the behavior of the AI by editing plain text files to create tactics. I consider that "more open than open source" because the above average player can contribute rather than just the professional programmer. All designs will be declared publicly, and anyone can use any idea. My only request is to give credit where credit is due - one of the fundamental tenets of open source software and open collaboration in general.
My long term plan with this code is to create a flexible, modular AI for all Mods and customize it for different games, then turn it into an actual "real life" AI rather than just a game AI.
For contributions to this document, I would like to credit Triaxx2 for his matrix AI plans, they influenced my ideas indirectly. Also, Cain for his metal class because it clearly illustrated how different code segments have strengths and those strengths should be included where possible.
Learning AI proposal, actual combat tactics and more.
Moderators: hoijui, Moderators
have you ever been thinking about the cpu-demand of your ideas? off course you can do a lot of things and take even more aspects of the game into account, but in my opinion each ai player may not take more than a few percent of cpu power...
its also very easy to talk about things, but just try implementing them....
its also very easy to talk about things, but just try implementing them....
I have indeed, and in my post about the AI interface recently http://taspring.clan-sy.com/phpbb/viewtopic.php?t=2840
there were two CPU intensive things to do in order to implement my suggestions. The first was to get information about ally damaged units. This would only matter if the AI was on a team in order to increase the ability to assist in defence. An alternative way of sending similar data is to have a unit selected and then tell the AI in ally chat to assist that unit specifically.
As for the "intelligence" ... it is not hard computationally. No big numbers, no drastic calculations. I have spent a lot of time profiling how expensive computationally it would be to crack RSA public keys for money, and also how expensive it would be to run many thousands of encrypt/decrypt sessions recursively. This is easy.
Also, if it is (for some reason) too much math, the logging could be turned off. At the uber trick end of things, I can make the GPU do most of the floating point math for me, by writing it as OpenGL or NVidia specific commands.
Short answer: yes, and it is very feasible.
there were two CPU intensive things to do in order to implement my suggestions. The first was to get information about ally damaged units. This would only matter if the AI was on a team in order to increase the ability to assist in defence. An alternative way of sending similar data is to have a unit selected and then tell the AI in ally chat to assist that unit specifically.
A similar function is provided for the units under the AI direct control. This would increase network traffic if the ally and the AI were on separate machines, otherwise it would be local CPU of something that is already calculated. The only incremental cost is sending a pointer to the other machine on localhost, or sending the full message to a remote AI.AllyUnitDamaged() return unit data on ally when ally unit damaged (toggle this on/off for performance reasons?)
This is a mirrored copy of "UnitDamaged" sent to the opposing player, and I suggest including the weaponID that did the damage. One extra parameter per message, info sent twice. This is more likely to incurr CPU time sending network messages, but it could optionally be enabled only with the AI playing, or for performance gathering modes.UnitDoesDamage() An optional (for performance) callback that returns damage done, weapon id (or better), damage, location of unit damaged, etc. One array per unit damaged.
As for the "intelligence" ... it is not hard computationally. No big numbers, no drastic calculations. I have spent a lot of time profiling how expensive computationally it would be to crack RSA public keys for money, and also how expensive it would be to run many thousands of encrypt/decrypt sessions recursively. This is easy.
Also, if it is (for some reason) too much math, the logging could be turned off. At the uber trick end of things, I can make the GPU do most of the floating point math for me, by writing it as OpenGL or NVidia specific commands.
Short answer: yes, and it is very feasible.
I mentioned all of this before zaphod and submarine ahd made their first post, I had said a lot, the adaptive AI project predates TAI and is still ongoing today albeit no public releases have been made, and no beta releases have been made to testers, it's a very experimental project.
hmmmn...
And yes min3mat, thing is have written at darkstars or triaxx has written at darkstars permeate all the AI coded and discussed in this community with the only possible exception being cains work.
And submarine, i'd have thought you of all people would know of the CPU use of AI's that store statistics. There are different ways of doing it, and you've chosen the cpu-instensive way on a minor scale where all the information is handed to you by the engine and you need very little procesing to make it useful.
hmmmn...
I'm not sure eactly hwo ti would work but:AllyUnitDamaged() return unit data on ally when ally unit damaged (toggle this on/off for performance reasons?)
is the same as EnemeyDamaged with a check to see if the attacker is owned by your team.UnitDoesDamage() An optional (for performance) callback that returns damage done, weapon id (or better), damage, location of unit damaged, etc. One array per unit damaged.
And yes min3mat, thing is have written at darkstars or triaxx has written at darkstars permeate all the AI coded and discussed in this community with the only possible exception being cains work.
And submarine, i'd have thought you of all people would know of the CPU use of AI's that store statistics. There are different ways of doing it, and you've chosen the cpu-instensive way on a minor scale where all the information is handed to you by the engine and you need very little procesing to make it useful.
Ok so someone said they should learn, but I haven't read that doc so I don't credit that as a source. I wasn't given any access. This may all be in a plan, but I came up with these ideas independently. Historically, Church-Turing thesis is named that way because both individuals came up with the same concept in the same year independently. However, both did publish their work.
As for the actual implementation, multi layered Bayesian calculations are not trivial. I gave Alantai some references. My goal, and I doubt this is in the darkstars website, is to make a systems computing real AI. Having done real AI research, I probably have a different tact than most. And no, there is no "AI for Dummies" since it is mired in different techniques. I didn't publish everything last night, but there are ways of integrating Genetic Algorithm style behavior for finding new tactics.
As for the actual implementation, multi layered Bayesian calculations are not trivial. I gave Alantai some references. My goal, and I doubt this is in the darkstars website, is to make a systems computing real AI. Having done real AI research, I probably have a different tact than most. And no, there is no "AI for Dummies" since it is mired in different techniques. I didn't publish everything last night, but there are ways of integrating Genetic Algorithm style behavior for finding new tactics.