Metal Extractor placement - Page 3

Metal Extractor placement

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

Moderators: hoijui, Moderators

User avatar
AF
AI Developer
Posts: 20687
Joined: 14 Sep 2004, 11:32

Post by AF »

It stores them with the mex positions that yield the highest value at the end of the array. It starts from the end of the array and works its way down, by comparing the closest mex position found to the current.

Code: Select all

float3 Util::MetalPos(int mexID)
{
    float3 result = StartPos;
    float3 nearest(200000,200000,200000);
    for(int g=mp;g!=0;g--)
    {
        float dist1 = Distance(StartPos,mexpositions[g]);
        float dist2 = Distance(StartPos,nearest);
        if(dist1-dist2>0)
        {
            const UnitDef* udm;
            udm = GCallback->GetUnitDef(mexID);
            if(GCallback->CanBuildAt(udm, mexpositions[g]))
            {
                nearest = mexpositions[g];
            }
        }
    }
    return result; //to be fixed later when I figure this out.
}
My latest crash has occurred now on frame 2, it's sorted through the mex positions succesfully and laoded build list, now it gives an error when trying to build the first metal extractor. Which is nice as its initial build order code has been commented out ¦D.
User avatar
AF
AI Developer
Posts: 20687
Joined: 14 Sep 2004, 11:32

Post by AF »

Nope, sortmetal algorithm as posted above DOES NOT WORK, uncommented It crashes, commented however gives 5 secs gameplay when the arrays first values is manually set to startpos, but it crashes when the second mex is attempted.

edit:: Arrgghh now I've tracked this latest bug down to the 3rd and last of my main loops, the building placement loop. Why cant I use my for loops?!?!?!??!
User avatar
AF
AI Developer
Posts: 20687
Joined: 14 Sep 2004, 11:32

Post by AF »

Ha, I've fixed my GetBuildPos function and my parser still works.

The problem has gone down to:

Code: Select all

	if(GCallback->CanBuildAt(u,BuildPos))
	{
		NewPos = GCallback->ClosestBuildSite( u,BuildPos,200,1);
	} else {
		NewPos = BuildPos;
	}
Also, are there any other thigns that might come in useful to add to this class?

Code: Select all

class MUtil
{
	public:
		MUtil();
		virtual ~MUtil();
		void SetParent(IGlobalAI* ppointer);
		int WhichCorner(float3 pos);
		void SetMDimensions(int height, int width);
		int MapFactor();
		void Init();
		float3* GetStartingGrid();
		float3* GetSurroundings(float3 pos);
		int SqRectMap();
		bool IsMMap();
	private:
		IGlobalAI* Parent;
		IGlobalAICallback* GCallback;
		int width;//mapwidth/512
		int height;//mapheight/512
		int MFactor;//Square or rectangle?
		int area;//height times width
		bool MMap;//metal map?
};
User avatar
mother
Posts: 379
Joined: 04 May 2005, 05:43

Post by mother »

Triaxx2 wrote:Does it sort by closest position? Or largest deposit? I always go for what's bigger, but most would go for what's closer.
Ok, an out-of-the-box suggestion. Use financial/economic theory a little bit.

a) The equivalent of Net Present Value... Discount future metal production. 10 metal/s 180s sooner than 15m/s during which there is geometric growth (earlier) would be like having interest rates akin to the post WWI Weimar Republic... ie the 50% less output now more than pays for itself over time.
Also remember that time isn't the only 'cost' of a mex, and 3 mexes within the range of one existing plasma battery is worth some part of 2 plasma batteries more than 3 spread out. You also want things as 'far' from enemy positions (known, or guessed) as possible.

b)Perhaps try to figure out future demand _very roughly_ (build queues, perhaps some very simple assumptions. Ideally you could grab lots of replays and shoot for a very rough regression function from them. It doesn't need to be horribly precise, just a rough gauge of what the usage curve looks like, and where on the 'curve' you are.

Part a) should be easy enough to code, might even be nice if you used an external file to load the parameters from so it would be easy to tweak. You can also use different algorithyms when you find out that you have uniform metal & large radius, small radius, 100% coverage but with hot spots, etc. When you end up on a uniform metal map you can simply start placing for optimum density, closest first, without reducing the pathing width to X.

Another thought, it would be good if the AI switched from mexxes to mm's when they became the cheaper option.

Now B... Well if someone collects the replays and extracts all the info into CSV or something, then its easy enough ;)

Ok I'll stop 'helping' now...
User avatar
AF
AI Developer
Posts: 20687
Joined: 14 Sep 2004, 11:32

Post by AF »

The AI atm will build metal makers once its economy surpasses 15 metal per sec, and will continue to do so until the metal production falls below 15.

At the moment the mex placement is tied to ordinary building placement, soon I'll start fiddling the mex placement algorithm till it works.

Your suggestions are good, but I am unsure how I would implement them now, just a little bewildered with other things atm but I'm sure I'll implement them then realise that they're the same as what you said in future.

So far I plan to tie the mex algorithm to scan only the surrounding sectors of the start position and then expand that till the algorithm crashes the game again to see how far I can go.

Other than that I dont really know much about finance and economics, save the nash equilibrium, but thats game theory and I only know what ti means not howto calculate it.
User avatar
AF
AI Developer
Posts: 20687
Joined: 14 Sep 2004, 11:32

Post by AF »

int CUtil::GetTypecanBuildCL(int id)
{
for (int i =0; i<IC; i++)
{
const UnitDef* ag = GCallback->GetUnitDef(IdleC);
const std::map<int,std::string> cd=ag->buildOptions;
for(std::map<int,std::string>::const_iterator cdi=cd.begin();cdi!=cd.end();++cdi)
{
if(cdi->first == id) return IdleC;
}
}
return 0;
}


OK, I have befuddled and tracked everything down to this function. On the fixing of this function the AI will be able to build. If this function is hard coded to return 0 all the time then the AI attempts to build, only it never does anything because you cant have a unit with the ID of zero so those commands get ignored. I don't know much about the std and the template classes it uses, as some might see from the above, please fix the damned thing!!!!!!!!!

In the mean time I shall be fiddling with my algorithms and implementing rudimentary offensive features, zaphods AI attacked himyesterday, it's only a matter of time before mine attacks me. And maybe then I'll reread the std thing zaphod sent me and figure this out if nobody can be arsed.
User avatar
Veylon
AI Developer
Posts: 174
Joined: 21 Sep 2005, 19:45

Post by Veylon »

I know that this might sound naive, but why not just have the AI find the nearest, best metal spot at the beginning, using any algorithm, then build other mexxes in a hex grid, each (mex radius) apart from one another?

Mexxes are cheap, and this provides good redundancy, so it wouldn't penalize the AI too much. Thus:

Code: Select all

M-----M---
 \   / \
  \ /   \ /
---M-----M
  / \
 /   \
M--
And the placement function could find the closest buildable place to each point.
User avatar
AF
AI Developer
Posts: 20687
Joined: 14 Sep 2004, 11:32

Post by AF »

That is a valid algorithm in 'some' cases, it would be better than JCAI and TAI's method, but pales in comparison to the method suggested by cain, which he is implementing.

However it is the most efficient algorithm that can be applied in cases such as metal maps with uniform distribution.
User avatar
Veylon
AI Developer
Posts: 174
Joined: 21 Sep 2005, 19:45

Post by Veylon »

I wasn't so much thinking in terms as "best" or "most efficient". More like "simple" and "easy".

If my AI ever goes anywhere, I'll be sure to try to have something better than this. This is just for starters.
User avatar
AF
AI Developer
Posts: 20687
Joined: 14 Sep 2004, 11:32

Post by AF »

I'm curious, what is your AI design or method? For example in TAI I aim to have numerous agents co-operating to create an AI as a result of their actions.
User avatar
Veylon
AI Developer
Posts: 174
Joined: 21 Sep 2005, 19:45

Post by Veylon »

At the moment, It's just hard-coded.
I have the AI step through several if-then checks to see what to build and have either the commander or a Construction Kbot build it in the Idle() function.
They build Solars, Mexxes, Kbot Labs, LLT's, or DT's in a circle around the base.

The Kbot lab randomly builds Kbots (again, hardcoded, but that'll change), which run scouting/raiding missions to random spots on the map.

Lastly, the AI keeps a metal desirability map, which is copied from the Callback function. Each time a mex is put down, it reduces the desirability of the nearby metal. When it is destroyed, the desirability is increased again.
The unit looking to build a mex searches the metal desirability and, factoring in distance, picks the "best" spot, then builds it.

That's it for now.

(edit)
I didn't have much luck with my much-vaunted "simple" system. I might go back to it for metal maps, though.
User avatar
Triaxx2
Posts: 422
Joined: 29 Aug 2004, 22:24

Post by Triaxx2 »

Sounds an awful lot like the OTA AI, which isn't a bad thing mind you. I point to the TotalWarAI's, and some of the more powerful cheating AI's.
Post Reply

Return to “AI”