archive by month
Skip to content

new base placement code

Today I tested Steamhammer’s new base placement code, a major step in getting rid of BWTA2. There are still a couple of big bugs, but it works well most of the time. It’s getting close to ready.

As I mentioned when I first wrote about map analysis plans last June, Dave Churchill removed BWTA as a dependency from UAlbertaBot after Steamhammer forked from it. Newer UAlbertaBot versions do the necessary map analysis themselves, and when it comes to unnecessary map analysis, they simply delete some less important features that BWTA used to provide. I won’t delete features that add strength, but for the necessary features my plan has always been to borrow from UAlbertaBot.

Here’s how placing bases works in general. A base consists of a location for the resource depot, plus a set of minerals and vespene geysers belonging to the base (plus any other info you find useful). For starting positions that a player may begin the game in, the map specifies where the resource depot goes. BWAPI passes the information through. You still have to figure out which resources belong to the base. I had Steamhammer assign all the resources within a fixed distance to each starting base, and it works fine.

For other bases, software is on its own. First, group the resources on the map into clusters, expecting that each cluster will become a base location. You probably want to skip over blocking minerals and any clusters that don’t provide enough resources to be worth placing a base at, or at least handle them differently. Then, for each cluster, figure out the best place to put the resource depot so that mining will be efficient. Details matter, but it’s not complicated, at least if you ignore weird maps like Crystallis.

I wrote my own clustering, which is simpler than UAlbertaBot’s (though I wonder if I made it too simple and crude). For placing the resource depot, I followed UAlbertaBot’s way. UAlbertaBot provides 2 methods, one of which is commented out. The commented out method finds the center of the resources by averaging their locations. (Technically, it’s the centroid.) It then uses UAlbertaBot’s building placement code to find the nearest location to the center at which it is legal to build a resource depot—you have to be at a minimum distance from any minerals and gas. The building placement code calculates a spiral of tiles centered at the desired location and tries each one until it finds one that works.

The active method in UAlbertaBot, which I took for Steamhammer, is to find the center of the bounding box of the resources. That’s the desired location, and UAlbertaBot proceeds as above.

In practice, Steamhammer’s new code usually finds exactly the same base locations as BWTA. There are some exceptions. It finds 2 bases in the center base of Fighting Spirit (as some other bots do), which I think is due to a bug that assigns the same mineral patch to more than one base. I don’t expect it to be hard to fix.

Good progress so far.

Trackbacks

No Trackbacks

Comments

Antiga / Iruian on :

Something I've long wanted to do was put two gates in the natural for protoss in pvp or pvz. I've got the build order loaded unfortunately under the old system there was a roughly 20% failure placement rate forcing me to set the use chance to 0. Does this new way of doing it handle this sort of placement better?

Jay Scott on :

No change to that misbehavior. It’s a matter of placing the pylon so that it powers free space where gateways (or whatever) can go. I intend to take some steps toward fixing it during the 1.4.x series.

MicroDK on :

I can highly recommend to use BWEB by McRave (https://github.com/Cmccrave/BWEB). It is a building placement library (only requiring BWEM). I have successfully added zerg simcity/wall to Microwave using BWEB. :D

McRave on :

BWEB would be incredibly easy to port to BWTA as well, it doesn't use very much of BWEM and what it does use could be replaced. Maybe in the future I can create and try to maintain both versions.

MicroDK on :

I am still puzzled about why you would replace perfectly working library functionality with your own. You could add BWEM and/or BWEB (McRaves building placement library) and use that for other stuff that BWTA is not good for. I would focus on new skills and bot functionality instead of rewriting existing code all the time.

Jay Scott on :

It’s not perfectly working: BWTA has to go. But the short answer is that I *am* working on new features. There is a strong argument for switching to BWEM. Even then, I would end up writing new code, because BWEM doesn’t do everything I want. Its support for hypothetical reasoning about map blocks and walls is weak. One of my goals is to be able to play on every reasonable map, and BWEM doesn’t provide the features to play on maps like Gold Rush or 815. I decided it was better in the long run to have all the map code under my own hand.

NiteKat on :

Hello Jay, I was talking with Antiga about the slowdown and timeouts that can happen for Protoss when using SteamHammer. I think I have a solution that should stop those from happening, but I am unable to test. It just takes modifying one function. It looks like there's a for loop that might iterate over a large number of items and cause massive slowdown, which doesn't have any code checking how long it is taking to run. The function in question is the getBuildingLocationNear function, and here is a pastebin link to my proposed modified version of the function. https://pastebin.com/1ff4u4vp

You may need to add an include for chrono for it to compile.

Jay Scott on :

Yes, in the worst case (which is what happens here) it iterates through the whole map. A simple mitigation would be to stop early—for example, making a bounding box of the pylon power and stop as soon as we leave the box. It’s not the kind of solution I want to go for, though, because it doesn’t fully solve the problem. I want to rewrite a bunch of the building construction code because it has other problems too, and I am going to start as soon as I finish with this BWTA task.

Antiga / Iruian on :

If there is anything we can do to help let us know. NiteKat / MicroDK spent a few hours this morning looking at it. Several solutions were proposed, the one he posted being one of them. #hoping for git someday for SH.

Jay Scott on :

I’ll make a post about the underlying problem. That will explain it better.

NiteKat on :

Yeah, my proposed solution doesn't solve all the problems related to the slowdown, and since I don't use SteamHammer myself, I'm not sure about the ramifications of ending that for loop prior to it completing. A full rewrite of how building positions are handled (and potentially some connected pieces) probably is need, but I think what I put in the pastebin could be a quick, temporary solution that would at least stop bots from lagging and timing out on SSCAIT, though they'd have to deal with any potential side effects of cutting that building search early.

The code change I proposed sets the cut off at 1 ms, which could be made larger if it's way too short.

Add Comment

E-Mail addresses will not be displayed and will only be used for E-Mail notifications.

To prevent automated Bots from commentspamming, please enter the string you see in the image below in the appropriate input box. Your comment will only be submitted if the strings match. Please ensure that your browser supports and accepts cookies, or your comment cannot be verified correctly.
CAPTCHA

Form options

Submitted comments will be subject to moderation before being displayed.