You coded AI bits in JAVASCRIPT.
Holy. Fucking Shit.
That's the most Franeksteinesque creation i've ever seen
SOBot proof of concept release
Moderators: hoijui, Moderators
If you can't be civil to your peers, don't post here. Negative posts without constructive ideas are completely pointless and juvenile.
As for using Javascript... erm... what's the matter with that? It's an interpreted language, yes. It's slow, yes. But AIs only need to use optimized C++ for things that need be ultra-efficient, like mex-spot searches, scouting or attack-vector planning... high-level strategic "decision making" is not an area that needs to be incredibly efficient- it doesn't require a lot've choices per second, or thousands of iterative steps. As AI devs have already been finding, trying to micro-control their units through spamming out commands just leads to lag as the AIs tie up the network, so it's only a matter of time before AI developers try to figure out how to "bunch" commands into a single sub-behavioral command that runs as an autonomous GroupAI or a series of timed steps to prevent flooding. The more I see, personally, the more I think that a GroupAI approach, that is optimized for a certain sub-behavioral model, is probably going to work for solving certain problems.
I've been asking AI developers to use a scripting language approach since I came back and saw where things stood. Don't knock it, mod developers sorely need a control language that will allow them to make AIs do what we need them to, and if this particular approach delivers, more power to him. While I would be the first to say that if this Javascript widget runs through Microsoft/Sun's Javascript parser, then it's probably going to be horribly difficult to produce good behavior on most people's machines (due the wild, crazy situation with these parsers, since their are two "accepted standards" but both of them interpret commands differently), using Javascript as the syntax for a scripting language used to control high-level behaviors doesn't sound any worse than using LUA or any other interpreted scripting language, or just a textfile full of variable values and other things, like AAI.
As for using Javascript... erm... what's the matter with that? It's an interpreted language, yes. It's slow, yes. But AIs only need to use optimized C++ for things that need be ultra-efficient, like mex-spot searches, scouting or attack-vector planning... high-level strategic "decision making" is not an area that needs to be incredibly efficient- it doesn't require a lot've choices per second, or thousands of iterative steps. As AI devs have already been finding, trying to micro-control their units through spamming out commands just leads to lag as the AIs tie up the network, so it's only a matter of time before AI developers try to figure out how to "bunch" commands into a single sub-behavioral command that runs as an autonomous GroupAI or a series of timed steps to prevent flooding. The more I see, personally, the more I think that a GroupAI approach, that is optimized for a certain sub-behavioral model, is probably going to work for solving certain problems.
I've been asking AI developers to use a scripting language approach since I came back and saw where things stood. Don't knock it, mod developers sorely need a control language that will allow them to make AIs do what we need them to, and if this particular approach delivers, more power to him. While I would be the first to say that if this Javascript widget runs through Microsoft/Sun's Javascript parser, then it's probably going to be horribly difficult to produce good behavior on most people's machines (due the wild, crazy situation with these parsers, since their are two "accepted standards" but both of them interpret commands differently), using Javascript as the syntax for a scripting language used to control high-level behaviors doesn't sound any worse than using LUA or any other interpreted scripting language, or just a textfile full of variable values and other things, like AAI.
Spring is as "heavy" as it is mainly because of things that are not under AI developers' control, like pathing (which, from most test results, seems to be the major drain on CPU usage in most scenarios). While some AIs have created heavy CPU load problems, this is due to either over-ambitious or buggy approaches, not because AIs should be using a lot of CPU time. As AI developers figure out what they can do without overloading processors and flooding the network connection between clients with too many requests per tick, we will, I think see AI cores running at less than 10% of CPU even when multiple players on a server are AI players. That is my guess, at this time.
Over-ambitious attempts to throw pure number-crunching at the problems of command-and-control will result in AIs that simply aren't worth playing with, for those of us who don't own a refrigerated supercomputer, and AI devs will respond to "market demand"- i.e., the number of people using their AIs and providing positive/negative feedback by improving their products. Or they won't, and we will either have the choices of "fairly crappy, but functional" vs. "uber-leet, but effectively useless"
I don't think any of the AI devs want to end up building AIs that look great in theory but cannot ever be fully realised, so I am quite optimistic that things will get sorted out as we move forward- everybody's been doing a great job thus far, despite all of the challenges 
Over-ambitious attempts to throw pure number-crunching at the problems of command-and-control will result in AIs that simply aren't worth playing with, for those of us who don't own a refrigerated supercomputer, and AI devs will respond to "market demand"- i.e., the number of people using their AIs and providing positive/negative feedback by improving their products. Or they won't, and we will either have the choices of "fairly crappy, but functional" vs. "uber-leet, but effectively useless"
I don't think any of the AI devs want to end up building AIs that look great in theory but cannot ever be fully realised, so I am quite optimistic that things will get sorted out as we move forward- everybody's been doing a great job thus far, despite all of the challenges 
I've been trying to do that for months now. By making the command decisions in such a manner that the lesser AI's start the spammed commands, instead of being forced to issue each individual command from a single high level AI.Argh wrote:As AI devs have already been finding, trying to micro-control their units through spamming out commands just leads to lag as the AIs tie up the network, so it's only a matter of time before AI developers try to figure out how to "bunch" commands into a single sub-behavioral command that runs as an autonomous GroupAI or a series of timed steps to prevent flooding. The more I see, personally, the more I think that a GroupAI approach, that is optimized for a certain sub-behavioral model, is probably going to work for solving certain problems.
A general strategy determined from the highest level, can filter through each individual level very rapidly, and distribute it's commands fairly effectively.
Example: G.O.D. sees the initial layout of the map, and sees that it's fourty percent water, and sixty percent land. With naval resources being easier to hold onto, the commands are issued to the Build Agent to take the commander and build a few land resources, then a plant and head into the water. The commander does so, and then orders are issued to construct UW mexxes, and a Shipyard. At the same time, a second Build AI agent, is starting construction of the first land con, and a few ground units. The first two are scouts, which are sent out to explore the map, now under the control of a scouting AI, which has two purposes. One, is to hunt down Metal Patches, and the other is to hunt down the opponent. The next few, are heavy attackers, such as Hammers, or Samsons.
By determining the strategy at the start and issuing the orders to use a specific set of build orders, instead of randomly determining them as it goes, the AI can save itself start time, which is crucial. If AI 1 is starting in ten seconds, and AI 2 is starting in five, that's a massive lead.
I'm probably overly repeating myself here, Triaxx, but:
1. What if a mod is running where one side doesn't have water units at all, and can only build hover or air?
2. What if one side has only one NON-water unit- the Commander?
3. What if the mod doesn't require resource harvesting as a rule of play (such as NanoBlobs)?
These sorts of scenarios (and these are just major chords here, not symphonies, if you follow me) are why we need G.O.D. level behaviors to be controllable through scripting language approaches, imo. If I, as a mod developer, then hand off control from G.O.D. to behavioral GroupAIs that have some ability to accept some switches/variable states... then we're cooking with gas, because I don't need micro-level control over every unit, all the time- just a good take on initial strategy, early buildtrees, and balancing tasks
1. What if a mod is running where one side doesn't have water units at all, and can only build hover or air?
2. What if one side has only one NON-water unit- the Commander?
3. What if the mod doesn't require resource harvesting as a rule of play (such as NanoBlobs)?
These sorts of scenarios (and these are just major chords here, not symphonies, if you follow me) are why we need G.O.D. level behaviors to be controllable through scripting language approaches, imo. If I, as a mod developer, then hand off control from G.O.D. to behavioral GroupAIs that have some ability to accept some switches/variable states... then we're cooking with gas, because I don't need micro-level control over every unit, all the time- just a good take on initial strategy, early buildtrees, and balancing tasks
well arg let me tell you that you are wrong.
the ai's that you see now dont consider half the decisions a human does , in wich some are higly complex and therefore consume a lot of cpu.
but once again as i said, give it time and you'll see things start to happening but ai devs sometimes may take simplistic aproaches to issues due to cpu consuming.
the ai's that you see now dont consider half the decisions a human does , in wich some are higly complex and therefore consume a lot of cpu.
but once again as i said, give it time and you'll see things start to happening but ai devs sometimes may take simplistic aproaches to issues due to cpu consuming.
That's an incorrect way of looking at this. What AIs are doing is looking at the "world" in a way that is completely different than the way that human beings are, but attempting to arrive at similar results. AIs do not "see" the map- they "see" a threat grid/matrix/whatever. AIs don't "see" mexes, they see a series of weights in an array. AIs don't "see" their placement of factories, they just see the resulting pile of outputs, in the form of units, and call for more inputs, in the form of factories, if they can afford it. Which is, to be sure, one of the problems with current AIs, but it says a lot more about the cruddy design of the factories/yardmaps from OTA/XTA/AA than it does about anything the AI devs are doing- who's bright idea was it to have a factory with one, limited exit-point, anyhow? CAVEDOG's! Was that stupid? YES. Has any major mod fixed this? NO. Why? I do not know. I will be making factories for a mod, and they will NOT look stupid, nor will they have a yardmap that makes it likely for units to get stuck in them... ever. So there.the ai's that you see now dont consider half the decisions a human does , in wich some are higly complex and therefore consume a lot of cpu.
For example, humans do not fret about mex placement as much as an AI can. Why? Because a human knows that they only have a limited amount of time to consider this issue- we have other things we need to physically take care of, like manipulating the GUI and moving our mouse to the next build position, etc., etc. And, as any good human player will tell you, while the cumulative "edge" of super-efficient mex placement, over a long timeline, might be meaningful... IRL, it doesn't matter, because in OTA-based games (let alone something like NanoBlobs or the Myth clone I am planning now) by the time super-efficient mexxes really mattered, the other player would've either attacked your mexes and destroyed them, would've eaten a lot of your dead units for their metal, or otherwise made up for it... or they just suck and you're going to kill them anyhow. During early game, 50 Metal more than the other guy is pretty much meaningless, compared to controlling your Commander, building a first-rush defense, or rushing your opponant.
AIs, on the other hand, can (and do) approach this task with enormous number-crunching resources. Does this scare me, playing against them? No, because of the reasons above- while it's an area where computers are vastly superior to people, it's a pretty meaningless "victory".
Where the "super-computer" approaches are going horribly awry, in my opinion, is that AI developers are trying to send commands to dozens of individual units per second, instead of sending commands to larger groups, and letting the units "figure things out" using either Spring's existing unit AI or through new GroupAIs.
I can see a future where some AIs quit trying to tear through an infinity of variables and somehow out-optimax a human player by substituting math for common sense... and instead rely on sub-groups that are semi-autonomous, making the chief goal to out-produce humans by midgame and win on chaos mobile defenses, well-placed static defenses (the very key weakness in all AIs right now) and factories that are moved towards the fighting fronts... instead of a static, glob-like base. Or it'd just nuke players. Why AI devs create AIs that just try to rush in like nubs and get killed by anybody with a modicum of skill, instead of building an AI that will porc nicely and incinerate my base if I let it keep building, is beyond me
This model would not rely on commands to individual units very often, especially in the economic side, if at all.
Lastly... nobody should ever forget that humans can only micro ONE AREA AT A TIME, must take literally SECONDS to perform a few commands, and usually have FAR FEWER UNITS in their forces, but still out-perform AIs, both militarily and economically (although I will be the first to say that economics is the least important element of victory, even though it's the easiest thing to analyze mathematically).
When AI developers ask themselves why that is the case, and begin thinking of strategies to emulate these human traits through rules and randomization, they will be heading down the path towards victory. Some areas of this sort've stuff have already been fairly well sorted out, such as scouting, but generally speaking, AIs are even worse than a newbie human when they attempt to attack something, in part because that's one of the areas where, curiously, AI developers are NOT attempting to micro-manage things. I dunno whether this is related to the problems of what information the AIs can get from the game engine, or whether this is because they just aren't all that good at playing RTSs, and don't realize how key microing in combat is to winning against human players- it is THE force-multiplier, in any decent game design. Anybody who doubts that... should go watch the NanoBlobs replays again...
well let me say that i didnt even read the whole post , but keep this in mind:
giving the complexibility of a rts game (therefore is cpu consuming) it is hard to make a very good ai (not that its not doable).
notice that every tiny thing that u think and that for u is way obvious(like spliting units in an attack when you know its good) for a ai to simulate that human think might be highly complex.
so gathering all those types of human "thinks" to a ai (can u count them all ?, i dont have fingers by far..) would make you a very heavy ai and a not playable one (at least in spring).
As for other games they solve that fast , by either making the rts a simple one (ta is quite complex in a strategic way for a ai comparing to other rts's),or either making a cheating ai and giving the challenge needed for players and erasing any kind of strategic boost that the ai would need.
btw why do you want an ai that porcs ? that doesnt make much sense..
giving the complexibility of a rts game (therefore is cpu consuming) it is hard to make a very good ai (not that its not doable).
notice that every tiny thing that u think and that for u is way obvious(like spliting units in an attack when you know its good) for a ai to simulate that human think might be highly complex.
so gathering all those types of human "thinks" to a ai (can u count them all ?, i dont have fingers by far..) would make you a very heavy ai and a not playable one (at least in spring).
As for other games they solve that fast , by either making the rts a simple one (ta is quite complex in a strategic way for a ai comparing to other rts's),or either making a cheating ai and giving the challenge needed for players and erasing any kind of strategic boost that the ai would need.
btw why do you want an ai that porcs ? that doesnt make much sense..
1. It would, if created by an AI dev who was willing to share their sourcecode, be a valuable learning experience for everybody.btw why do you want an ai that porcs ?
2. It is one of the few ways that an AI might be able to beat average (not expert) humans in game designs that are OTA-like. Let's face it- porcing WORKS, otherwise nobody would do it. TA was built around allowing for very powerful porcs... XTA has weakened this by a good bit, but it's still quite possible to porc and keep out most attacks until lategame... and, when we look at AA (with the plasma repulsor) it's probably possible to porc even into lategame, and win by nuking your opponant's production into teeny-tiny, radiated pieces.
When I was tinkering around with AI with OTA, my version of Siege (which, again, I offer to anybody with enough TA:M experience to install it, because I think it might show AI developers a thing or three) would begin building nukes at about the same time that a skilled human player was just barely able to build his/her first antinuke, and was still just barely holding the AI back on defending against air rushes, etc.
This kind've desperate, "omg I'm dead if I can't hold" scenario was, to be quite real, what I was hoping for with NanoBlob. Anybody who's played that against the AI knows what I'm talking about - it's hard, it's fast, it's tricky just to stab its silicon heart out.
None of the AIs can do that with XTA/AA/SWTA/etc. Why? Because human game designers, thinking about human game balance, have, very deliberately, staged the economies so slowly, and with so many small but vital statistical traps and pitfalls... that AIs just stumble and fall, especially when one looks at how many units they waste on completely pointless attacks. I can defeat any of the AIs currently available, playing with ground forces only and no LRPCs, simply by building good Dragon's Teeth defensive lines, backing them with a few lasers and maybe one, two MRPCs or equivalent units (Merls are useful here). Then I can just attack with floods of cheap units (Peewees or AKs, because they so rarely leave corpses) and win very, very easily. It's not that the AIs don't build defenses- they do. It's that what they build is so completely, totally not able to handle even a basic rush. If they played mobile-defense, though, built good defenses that actually made sense, and didn't waste their resources on early rushes that a human can stop... and then went Air-heavy, or just went for nukes... then a non-cheating AI might be able to win, even in uber-complex game designs. Nukes/Air were put into OTA as a game-ender... AIs designed to win those game designs, imo, should play for late-game victory, instead of trying fruitlessly to out-fight a wily human with a D-Gun
well yet again i didnt even read the whole post , but for me and my ai i dont want it to porc...
i know that porcing doesnt work and thats not the way to go for IMO.
i want my ai to expand fast and take advantge of all resources available and pressure like hell.
i want an ai that plays like sj and thats what im aiming for..not a porcing ai.
btw i think u dont understand the concept but an ai can do whatever a human can, its just a matter of development time and power (number of coders on it) and abstracting the skills of a best player.
doesnt take more then that.
why doesnt a ai do all that u ask and think its miserably easy ? because the ai dev's are developing 1 ai alone and they do have a life , so step back and give time to time ok ?
after all we're doing ai's on our free time..
i know that porcing doesnt work and thats not the way to go for IMO.
i want my ai to expand fast and take advantge of all resources available and pressure like hell.
i want an ai that plays like sj and thats what im aiming for..not a porcing ai.
btw i think u dont understand the concept but an ai can do whatever a human can, its just a matter of development time and power (number of coders on it) and abstracting the skills of a best player.
doesnt take more then that.
why doesnt a ai do all that u ask and think its miserably easy ? because the ai dev's are developing 1 ai alone and they do have a life , so step back and give time to time ok ?
after all we're doing ai's on our free time..
Mark my words.btw i think u dont understand the concept but an ai can do whatever a human can
If you ever put your still-vaporware AI onto this 'site, I will make a defeat video in 24 hours
As for splitting an attack while in progress... that takes very little coding skill. Simply have attacks that involve multiple, smaller groups. Assign them slightly different objective points. Give them a command to go... and assign a GroupAI to them that will keep them from wandering off and not meeting objectives until they've reached the current attack point. It's a good simulation of what a human does, and I doubt very much that it would be a challenge to code. You don't need to simulate the whole decision-making process of a human to achieve like results.
my ai, you will most likely allways defeat without much trouble...If you ever put your still-vaporware AI onto this 'site
im only one guy and my job is not to develop a ai full time, but if i had that job and had like 10 coders on my back id happily make u eat those words(but i cant..).
lol.. you either never coded or just dont put questions to yourself ..As for splitting an attack while in progress... that takes very little coding skill.
it isnt as simple as that.
question: what do humans do when splitting attack right ?
example : im attacking with 10 flashes and 5 slahers towards a llt defended base with a comm on one side, how do i want to split ?
(notice that the first attack wasnt a splitted attack so theres already quite of a algorithm to find the best time to split(if it really needs a split)).
notice here, how do i split them ? prolly a human would send 10 flashes over the commless side and the slashers over the other(slashers ovre range the comm)..how about if the commless side has a hlt ? ..
oh come on you do make it sound easy but the things your mind calculates in a blink of an eye are not what they look like..
to emulate a true mind just for a very very accurate attack split you already got a complex algorithm..
oh btw about the groupAi and cpu consuming its pretty much the same thing whether the code is in the main ai or it has a groupAi supporting that code.GroupAI to them that will keep them from wandering off and not meeting objectives
looking at it that way its just a question of good modularity with diferent code parts.
if for one single example you dont, and if you keep taking the smoth decision that doesnt take the whole package with it when you put each skill you coded on that way all together the whole ai strength will be affected in a noticable way (one doesnt make a diference but all together they do).You don't need to simulate the whole decision-making process of a human to achieve like results
Edit:: oh almoust forgot, if you know so much of what should be done , and what should a ai take care off etc... why dont you do one yourself ?
that'd save us both time, and the comunity would be very pleased.
Last edited by Chocapic on 06 Feb 2006, 05:59, edited 1 time in total.
Well, I think the issue here is that you each have different goals. Argh wants to pose a decent game for low to medium skill players. Choco is shooting for an SJ clone, or an emulation of a very skilled player.
Argh, I fully agree with your ideas about an AI needing to porc, but they're only worthwhile for medium to weak players. Any competent player knows how to beat a porc: expand and control more territory. When a porcing player decides to spend lots of metal defending one area of the map, well, you can be damn sure that every other spot on the map will have my mex on it, thus allowing me to outproduce and own the porcing player.
I think an AI COULD raid effectively, since in theory, they are much more capable of building lots of units quickly and sending them to the right spot than a human is. NanoBlobs was the demonstration of this; when I allied with BlobKAI and watched it build, I was astounded. It grew by an order of magnitude faster than I ever could. Once that ability is tapped into, and the AIs start seeing that those windfarms are viable targets, I think that we'll have a bit more of a challenge.
AAI is already well on its way to playing smart (even after a game with it, it was starting to flank to my windfarms and expand decently, while placing not-horrible defenses); I'm surprised nobody has tried to 'train' AAI to face a skilled player.
Argh, I fully agree with your ideas about an AI needing to porc, but they're only worthwhile for medium to weak players. Any competent player knows how to beat a porc: expand and control more territory. When a porcing player decides to spend lots of metal defending one area of the map, well, you can be damn sure that every other spot on the map will have my mex on it, thus allowing me to outproduce and own the porcing player.
I think an AI COULD raid effectively, since in theory, they are much more capable of building lots of units quickly and sending them to the right spot than a human is. NanoBlobs was the demonstration of this; when I allied with BlobKAI and watched it build, I was astounded. It grew by an order of magnitude faster than I ever could. Once that ability is tapped into, and the AIs start seeing that those windfarms are viable targets, I think that we'll have a bit more of a challenge.
AAI is already well on its way to playing smart (even after a game with it, it was starting to flank to my windfarms and expand decently, while placing not-horrible defenses); I'm surprised nobody has tried to 'train' AAI to face a skilled player.
Actually, my real goal here is very simple: I'm hoping that an AI will arrive that will be customizable enough that I can fit it to the end-goal of my game design experiments. I have a final game design in mind, using Spring, that is very, very special... not like anything you've ever played before, and not just an oddball sort've novelty RTS, either.
To get there... I need two very specific things from AIs:
1. I need a really full-function, robust AI that can handle non-OTA game designs. If AAI gets there, and can handle the specifics of the mod, and needs nothing more than a single page of directives for it... that's just fine. If it's some monster that I have to write 50 pages of scripting for, but it does what I tell it and is a useful player for newbies to learn with, that's also just fine.
2. I need a real, working Gaia, that can finally allow me to build an "ecosystem" of neutral players. This is a key technology goal, and if nobody gets there, I'll just have to get down and dirty and do it myself. I have proven to people over and over again that I am not afraid to learn something new in order to achieve a goal, so if that's what it takes, OK. That said, I'd prefer to keep working on new game designs to show Spring's modders what we can do with this engine, and continue to teach my skills as a modeler, texture artist, scripter and game designer. I don't know how many of my other posts you've read around here, but I am very interested in helping Spring's community reach its full potential here, and I am working hard to help everybody- including this community.
At any rate, I've totally derailed this thread. My apologies... I have a lot more to say about all of this, but not right now.
To get there... I need two very specific things from AIs:
1. I need a really full-function, robust AI that can handle non-OTA game designs. If AAI gets there, and can handle the specifics of the mod, and needs nothing more than a single page of directives for it... that's just fine. If it's some monster that I have to write 50 pages of scripting for, but it does what I tell it and is a useful player for newbies to learn with, that's also just fine.
2. I need a real, working Gaia, that can finally allow me to build an "ecosystem" of neutral players. This is a key technology goal, and if nobody gets there, I'll just have to get down and dirty and do it myself. I have proven to people over and over again that I am not afraid to learn something new in order to achieve a goal, so if that's what it takes, OK. That said, I'd prefer to keep working on new game designs to show Spring's modders what we can do with this engine, and continue to teach my skills as a modeler, texture artist, scripter and game designer. I don't know how many of my other posts you've read around here, but I am very interested in helping Spring's community reach its full potential here, and I am working hard to help everybody- including this community.
At any rate, I've totally derailed this thread. My apologies... I have a lot more to say about all of this, but not right now.
That's part of the Reason for the G.O.D. Instead of being forced to change each individiual piece, you can simply change the command structure there, and it'll adjust. Ryhoss for example, instead of building Water units, would simply build land units as both. Wormhole's AC/DC would build Air units instead of water, with ground units on land.Argh wrote:I'm probably overly repeating myself here, Triaxx, but:
1. What if a mod is running where one side doesn't have water units at all, and can only build hover or air?
2. What if one side has only one NON-water unit- the Commander?
3. What if the mod doesn't require resource harvesting as a rule of play (such as NanoBlobs)?
These sorts of scenarios (and these are just major chords here, not symphonies, if you follow me) are why we need G.O.D. level behaviors to be controllable through scripting language approaches, imo. If I, as a mod developer, then hand off control from G.O.D. to behavioral GroupAIs that have some ability to accept some switches/variable states... then we're cooking with gas, because I don't need micro-level control over every unit, all the time- just a good take on initial strategy, early buildtrees, and balancing tasks
A simple change of a few pieces of code would make that change. Of course, if I manage to make the AI work, I'll write a program to allow for those particular changes. Perhaps based on Map/Mod. Since different mods, behave differently on different maps, this would mean the AI would already know what the basic strategy is.
In the included map Flooded Desert, it would use mainly ground attack vehicles, because the terrain isn't that rough, and probably hover cons for building in the water, since it's not that deep. On Mars though, it would use Kbots and Air units. On Small Divide, it would use tanks, and air craft.
Sorry, I was hiding behind that wall to avoid the crossfire.
Even tho this topic was meant for Sobot, I'll comment on both sides of this new discussion.
Both of you are right, and wrong.
An AI can be built using neural nets to emulate a brain and play any game.
If you look around, there are plenty of papers on that, especially from GDC.
But, oposed to that, it really isn't needed.
Farcry tried to show exactly that if I recall.
Anyways, the way I'm coding THIS AI, it's only an interface.
Or maybe a virtual AI machine.
How exactly it'll be implemented isn't up to me. (even tho ofc I intend on building my own script also in the future)
Lemme just give some examples of things that have already passed thru my mind.
In JS, every object can receive new properties.
And they can be anything, even a function.
So for example, you could take a Group object ( this shall represent a group of units which can be added and removed ), and just say:
then, on unitIdle()
memberOf() will be a method which returns the group which a unit is member of.
So the idea of having groups which have their own goals is really easy to implement.
And just like a human does, it'll act on a group of units, doing macro management. (micro can just as well be implemented)
So again I say, there's no need to fight trying to ask this AI to "do this" or "do that".
You can do whatever you like with it.
----
To any admin: Is the source on svn berlios woking in linux already ?
From the mailing list it seems it was, but it seems a bunch of changes are being made, I didn't want to get caught up in the storm.
Running under cedega kind of works, but running natively would certainly help me a lot.
peace
Even tho this topic was meant for Sobot, I'll comment on both sides of this new discussion.
Both of you are right, and wrong.
An AI can be built using neural nets to emulate a brain and play any game.
If you look around, there are plenty of papers on that, especially from GDC.
But, oposed to that, it really isn't needed.
Farcry tried to show exactly that if I recall.
Anyways, the way I'm coding THIS AI, it's only an interface.
Or maybe a virtual AI machine.
How exactly it'll be implemented isn't up to me. (even tho ofc I intend on building my own script also in the future)
Lemme just give some examples of things that have already passed thru my mind.
In JS, every object can receive new properties.
And they can be anything, even a function.
So for example, you could take a Group object ( this shall represent a group of units which can be added and removed ), and just say:
Code: Select all
alpha_grp.job = "search and destroy";
alpha_grp.job_dst = "any";
Code: Select all
function unitIdle( unit )
{
if( unit.memberOf() && unit.memberOf().job )
{
continueJob( unit.memberOf() );
return;
}
.........
So the idea of having groups which have their own goals is really easy to implement.
And just like a human does, it'll act on a group of units, doing macro management. (micro can just as well be implemented)
So again I say, there's no need to fight trying to ask this AI to "do this" or "do that".
You can do whatever you like with it.
----
To any admin: Is the source on svn berlios woking in linux already ?
From the mailing list it seems it was, but it seems a bunch of changes are being made, I didn't want to get caught up in the storm.
Running under cedega kind of works, but running natively would certainly help me a lot.
peace
Because ti gives us an advantage over rival AI's if we can do so, some of us are developing an AI naturally, such as submarine, then there are the more agressive of su who playtest and release when we think we've made a good enough improvement or need to fix a bug, such as myself, and I gage that mostly by how quickly it defeated the rival AI's and how well ti performed compared to last time.Why AI devs create AIs that just try to rush in like nubs and get killed by anybody with a modicum of skill, instead of building an AI that will porc nicely and incinerate my base if I let it keep building, is beyond me
AAI from the very start fell into base mentality.
BlobKAI expanded faster than you nemo because a human cannot expand that fast without a medium of extra hands and mice and screens, that grow exponentially as the game goes on. KAI however had limitless room to issue commands across the map in a flurry.
However the demands on th itnerface argh describes are not a problem that cna be solved by groupAI. all commands issued by AI's in spring are sent through the net buffer, that is globalAI AND groupAI, using a groupAI would simply cause a slight performance hit because the commands are going through several extra layrs rather than directly into the network buffer to be sent off.
I solved this problem by buffering commands and firing them off every frame as many as possible without reaching a maximum, which was set at around 2 or 3. That combined with a priority system meant NTAI runs a lot better. The only other solution to this I am aware of is to increase the network buffer size inside spring.
The problems with lots of commands being issued are nto because the AI is constantly sending commands, but rather because of large nubmers of units, or untis getting stuck in factories (see the old NTAI overflow I fixed in 0.29).
As for a neural net, there are too many inputs, and training them like that game that sued such nets would not be feasable on a globalAI scale, maybe as a groupAI for the player to train to micromanage but thats the extent at which ti goes.
The AI pushes so much time and effort initially into mex palcement because a human instantly knows where to palce ti yet the AI has a large array of values to sort through and many other factors just to place the mexes. Krogothes class does nto give the AI's ultra perfect placement, infact in some cases a human could do ti better instantly, but it's the best we have to place mexes half decently.
Indeed while DT will stop most AI's, it is a problem I am aware of and have taken steps to remedy in my plans ahead, as do i have remedies for numerous toher problems including your scripting to an extent.
For a GAIA AI would ti be enough to give control over wether the race in question is capable of attacking the player? Or even just tell it what races ti is capable of attacking (for gaia vs gaia only side games).
And I am aware that some players want the AI to porc because they want a long enjoyable game rather than an AI that tries to flush them out quickly.
I had so many other thigns I wanted to say but I keep forgetting thigns, this could have been a huuuuge post
If a Gaia could be built that could not attack a given race, that'd be nice. Ideally, I'd like two different sub-flavors of Gaia:For a GAIA AI would ti be enough to give control over wether the race in question is capable of attacking the player? Or even just tell it what races ti is capable of attacking (for gaia vs gaia only side games).
1. A Gaia that can attack specified races, and only those races. That way, just as an example... we could build a Gaia that other "players"- i.e., AIs- would not attack... but leave whether or not to mass-murder the Elven Forest's cute little woodchucks up to players
Individual units that were attacked should defend themselves, but will not attack players otherwise.2. A Gaia with an "anger level", so that it would not attack players on sight, but would attack players who attacked it frequently or enough times. I'd prefer a double-counter there, so that if a player annihilates 1000 civilians in a 5-minute timespan, then doesn't ever attack the Gaia again... it'd still be mad an hour later!
Why do I want two flavors of Gaia? Different purposes. One to simulate ecologies- predator/prey stuff, where human players could even interact- for example, we could have "herbivores" that left corpses, and players would have to kill them to get "food", vs. "carnivores" that would be dangerous to humans, ala AoE. The "herbivores" would reproduce up to their max pop count over time, and would probably generate their own resources (I don't see much point in doing cow --> grass --> baby cow --> milk --> adult cow... waaaay too much detail).
The second Gaia could be used for a lot've things, but the main thing I want to do with it is to simulate urban warfare conditions, by having a population that gets built by an AI that is essentially neutral to players, but can turn on them if they kill too many AI "citizens" during combat. I'm not going to devulge the entire game design at this time, but I'm sure you can see where this kind of Gaia might be really useful for a lot of potential games built with Spring- everything from WWII to 40K to fantasy games could really benefit from having "Neutrals" in the game engine that were competing with human players for resources, but might also present some opportunities... for example, in a WWII game, the "civilians" might be the only "Race" that could build "capture points" which gave each side a big boost in resources. So, for example, you'd have both sides racing into the civilian towns, trying to get the flags... and then you'd have to worry about defending the town from attackers, lest you annoyed the townspeople so much by killing them with your machine-gun and artillery misses that they turned on you. It'd also make "taking a city" a really meaningful (and interesting) experience, because if you took it without using violence (Sun Tzu style) you'd do far better than trying to take it by brute force, causing the civilians to "hate" you and attack you on sight (think Nazis trying to take Stalingrad).
I really hope that Gaias that are functional and won't just attack each other/players blindly are possible. One issue, that will require a game-engine change, however, is that Spring automatically has units attack each other when they get into range. That's something that will need to be addressed on the engine side of things, but until we have some baby-step demonstrations, I doubt very much I can get Zaphod et al to get interested in this, because it means fooling around with the low-level unit AI again.