Testing AAI - Page 4

Testing AAI

Here is where ideas can be collected for the skirmish AI in development

Moderators: hoijui, Moderators

User avatar
jcnossen
Former Engine Dev
Posts: 2440
Joined: 05 Jun 2005, 19:13

Post by jcnossen »

Might be good to build a few of each. Wind generators do have a higher profit/cost ratio on most maps, but by building a few solars you keep the AI from not totally stalling when the wind is low for a longer time.
User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Post by Argh »

I think that it needs to look at "random" vs. "non-random" generators of anything, and try to "figure out" what is cost-effective. If the AI can get the average wind-speed on a given map (which, if I recall correctly, is defined as part of the map file) then it should be able to evaluate wind generators and decide what's most effective.

It shouldn't just blindly build one or the other or... any combination thereof, though. That puts you on the path to just building yet another buildtree AI. Which, as I have stated loudly and annoyingly, I like- because I, as a game designer, want complete control over what AIs do or do not do... but it would defeat what I see as the purpose of AAI, which is to demonstrate an AI concept that can work with whatever is thrown at it. While I do not have great hope that your approach will ever be the "winner" against an AI that is fully-scriptable and controllable by a game designer who knows what they're doing, AAI shows great promise as a bug-free AI that will work with most game designs, and I think that pigeonholing it into building a specific kind of building, instead of having it compare their relative worths, would be a mistake. But hey, that's just me- if you really just want AAI to play a good game of XTA, be my guest :-)
Chocapic
Posts: 556
Joined: 16 Oct 2005, 03:35

Post by Chocapic »

yes ai's have to have that sort of coding definitly
User avatar
AF
AI Developer
Posts: 20687
Joined: 14 Sep 2004, 11:32

Post by AF »

Argh, I think as we go along with our evolution of our AI's we're going to fall itno what you say anyways. I'm already seeing things in the NTAI test build that are crying out for that sort of configuration.

I onyl wish I had a lightweight interpreter, nothing as powerful as lua, just easy to integrate, fast, with a limited feature set for basic operations.
User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Post by Argh »

Well, I could propose a common set of AI standard parameters and scripting conventions, and come up with a simple, flat-file set of definitions that would become part of mods- AI developers could also build and share a common parsing DLL, which would lead to best efficiency and less reinvention of the wheel, much like the Metal Class has helped everybody get resource-mapping down to a ridiculously exact science very quickly ;)

I'll think on this- I had about 50% of it blocked out over the last year of random posts, but just gathering together my scattered thoughts will probably just result in a hodge-podge of half-baked ideas that aren't efficient or clean... if the other AI developers (with the notable exception of Submarine, who's doing something Entirely Different) would agree on a common set of parameters (and their meanings, at least in a loose sense- no final AI would be exactly like the others, obviously) then it might be worth taking the time to define everything.
User avatar
AF
AI Developer
Posts: 20687
Joined: 14 Sep 2004, 11:32

Post by AF »

That isnt quite how I imagined it. I'm more itnerested in there actualyl being logic and rules and structures within the files. The last thing i want is a TDF file full of tags. Afterall I want to eb able to let modders modify NTAI build trees from there freeform originals into mod specific fine tuned variations. But I've learnt from NTAI 0.28 that a straight forward list never works best, you need a random element aswell as time considerations, and other game logic.

As a result what I do will end up reflecting a basic interface backed up by internal code. I'm thinking more along the lines of I lead, people follow the idea if they want, and I then change it to suit a common ground.
User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Post by Argh »

Sorry, a TDF full of tags is not what I was going to propose. I'll propose something in a week or two if I don't see any further discussion of this.
User avatar
krogothe
AI Developer
Posts: 1050
Joined: 14 Nov 2005, 17:07

Post by krogothe »

I am all for an unified system, but i think we could better use our efforts by improving the AI interface for now... You guys more than me are experienced programmers, we could add stuff like more info on features and projectiles, a working cheat interface etc, then post the ideas and code up and everyone has their go at improving and optimizing it until its good enough for spring.
Today i just rewrote GetClosestBuildSite to suit special needs, and although it seems a bit slower, it performs more operations and is playable. If we start working on the spring source together then soon we will have developed the "mood" to work on an integrated interface, which although i will probably not use myself, could be great for the AI community as a whole...

btw sub, i find solars the better choice too, wind is just too easy to destroy and its instability messes up KAI too :cry:
submarine
AI Developer
Posts: 834
Joined: 31 Jan 2005, 20:04

Post by submarine »

hmm, i dont think "GetClosestBuildSite()" is a vital part of the interface, it just makes it easier to start an own ai

i think its more important to add a function BuildSiteBlocked(int unit) to tell the ai, an ordered building could not be errectetd. Right now it might seem that orders just vanish somewhere in the engine which is (at least in this particular case) not true

i also got the impression, that UnitIdle() is not always called if a unit goes idle
Chocapic
Posts: 556
Joined: 16 Oct 2005, 03:35

Post by Chocapic »

well maybe, but for my experience so far with testing my ai i havent yet got units that stop at all forever due to not running idle() code.
User avatar
krogothe
AI Developer
Posts: 1050
Joined: 14 Nov 2005, 17:07

Post by krogothe »

Same here...
the comm does get stuck when in combat while building but taking damage normally fixes him
User avatar
AF
AI Developer
Posts: 20687
Joined: 14 Sep 2004, 11:32

Post by AF »

Look at every single version fo NTAI ever released. Construction units stall from tiem to time, and it's always after they've finsihed building soemthing. 90% fo the tiem they burst back into life if you give them an order or justs elect them and press the stop button manually.

Just look at the test build of NTAI which has no antistall code to rpevent this and relies totally on the engine to figure out if a unit is idle, it's ludicrous.

Also, some people saw a bug that occurs when a unti tries to mvoe out fo soemwhere btu ti cant. I got these errors with freakers and scouting. The factory would build a freaker which would get sent off, but it hadnt elft the factory so it slammed againstt eh side fo the factory walls and kept tryign to walk through. While this happened I got voerflow errors, and I couldnt track the problem ebcause of the hgue slowdown, and the logfiles getting overflown with hudnreds of megabytes of "Overflow 4000 3789 etc..".

Yet all fo that should never have happened if the itnerface called UnitMoveFailed(), it seems even unit Sub-AI suffered in that case.
Post Reply

Return to “AI”