BWAPI, and an inside look into StarCraft's code - Page 2

Post a Reply

Prev 1 2 All

Sonko

154 Posts

October 27 2019 09:24 GMT

#21

Really enjoyed your series on molesting crabs and such, looking forward to your newest deep dive!

Thank you! Hovercrabs cannot be molested enough!

Peeano

Netherlands5672 Posts

October 27 2019 13:35 GMT

#22

When I issue attack move command on a group of medics and marines, the medics will act the same as if I ordered the heal move command.
I always assumed it was because heal also has the hotkey a (by default). If I change the attack move hotkey from A to Z and issue attack move via Z Medic/Marine in the same group will make the medics respond the same.

My conclusion is they have coded attack move on medics to work the same as the heal command. Because other non-attacking units receive the attack move command just move instead.

If you select a group of carriers and build interceptors, all carriers will build interceptors. The same way a group of reavers will all build scarabs. Or all tanks will siege, etc.

Can you easily decipher from the code if all these special actions are specifically unique?
I'm basically asking if there is any combination where you can have 2 (or more) different units listen to same assigned hotkey the way medic marine do.

I've tried to set scarab building and interceptors to the same hotkey. In hopes that I can order a group of carriers and reavers to both build interceptors and scarabs respectively, but it doesn't work.
And I've been wondering if it is ever possible to combine 2 commands in one hotkey? For example burrow and siege mode or mael strom and psionic storm? I'm curious but too lazy to test all combinations.
Imagine being able to cast ensare and plague with just 1 click, or storm and mael strom...

Can you see how the area plague hits is defined in code? Because from my experience it seems like the aoe is slightly skewed to the right of where you click instead of being centered and ever since I wondered if it may be a small number mistake in coding.

Sonko

154 Posts

October 27 2019 17:32 GMT

#23

Hi Peeano,

I was considering answering your questions one by one, but truth to be told, all of these are to be covered in later articles, so just stay tuned. If you have some coding background, you can take a look in the source files of openBW here:

https://github.com/OpenBW/openbw/blob/master/bwgame.h

ThunderJunk

United States740 Posts

October 27 2019 20:49 GMT

#24

Wow, what an excellent series of articles. Thank you so much for sharing.

I had no idea that all ranged attacks have a 1/256 miss chance by default!

[UoN]Sentinel

United States11320 Posts

October 27 2019 21:45 GMT

#25

Btw you reference an appendix often, is this posted anywhere on the site? I'm assuming it's lifted from the forthcoming book where you do have an appendix, but there's a few things I'd like to check if you already have it up.

Also nitpick about this section:

Second, an addition to the Energy segment of unit abilities:

The starting energy of a unit is the quarter of the maximum energy of the unit type (rounded up), so upgrades affect it. The exception is the Protoss Shield Battery, with the starting energy of 100.

Dark Archon is another exception. They always start with 50 energy even with Argus Talisman researched.

Sonko

154 Posts

October 28 2019 08:35 GMT

#26

Hi,

Not yet. What are you curious about? Maybe I can look it up for you. Also, I'm considering adding stat blocks and weapon statistics to the untits' description - a little bit redundant, but maybe it would look good.

Dark Archon energy: Thanks for the find, I will add that!

Freakling

Germany1534 Posts

October 30 2019 00:13 GMT

#27

This is very interesting:

Particularly because ScmDraft does not implement this correctly yet. Gotta ask SI about it.

Anyway, I looked it up, and the function to calculate distances looks like this in OpenBW:

	int xy_length(xy vec) const {
		unsigned int x = std::abs(vec.x);
		unsigned int y = std::abs(vec.y);
		if (x < y) std::swap(x, y);
		if (x / 4 < y) x = x - x / 16 + y * 3 / 8 - x / 64 + y * 3 / 256;
		return x;
	}

It's easy to see how this would give you a dodecagonal structure like depicted above, although I haven't figured out how they came up with this particular approximation yet. Also gotta wonder why they did not just use simple Euclidian distance (I know that square roots are computationally bad, but there is little need to ever calculate and actual distance, only thing of interest is usually to check whether something is within a certain range, which can be done using only squares).
Anyway, this is certainly an interesting piece of code that you should discuss in some detail when you talk about distances.

aqrit

13 Posts

October 30 2019 22:42 GMT

#28

(a*a + b*b) costs up to 80 cycles in "ye olden times" (warcraft 2 era)

LG)Sabbath

Argentina3024 Posts

October 30 2019 23:22 GMT

#29

Also aren't all these division operations optimizable by using bit shifting?

PS. does anyone know if there's any info about the save game file formats (single or multiplayer) anywhere? I have not found anything on google at all

Sonko

154 Posts

November 02 2019 10:34 GMT

#30

so gotta wonder why they did not just use simple Euclidian distance

In uniform grids, that is usually not the best approximation.Generally, the Manhattan distance is considered to be best.
Here is a link that explains the what and why:
http://theory.stanford.edu/~amitp/GameProgramming/Heuristics.html#heuristics-for-grid-maps

Also aren't all these division operations optimizable by using bit shifting?

In the openBW code, there are often bitshifts. But that's a decompiled reverse-engineered version. Functionally identical, but I'm not sure that these things are exactly the same. They probably are, though.

PS. does anyone know if there's any info about the save game file formats (single or multiplayer) anywhere? I have not found anything on google at all

Yeah, surprisingly little information. I'm not there yet.

Sonko

154 Posts

November 04 2019 13:12 GMT

#31

Hi everyone, I updated the article a bit. Some ranges were not entirely correct, and rephrased some things to be more clear.
https://makingcomputerdothings.com/brood-war-api-the-comprehensive-guide-movement-modifiers-and-terran-units/

Maybe the most interesting thing is the firebat attack pattern - I created an image that showcases how the Firebat hits work.
(with iscript source)

Sonko

154 Posts

November 13 2019 17:51 GMT

#32

I have updated and reworked some stuff since - and updated the Firebat image to be more clear.
But in bigger news here is the next part:
Brood War API – The Comprehensive Guide: Terran units continued, and some Zerg ones

Enjoy!

2Pacalypse-

Croatia9543 Posts

November 14 2019 02:04 GMT

#33

Awesome! Really cool stuff dude.

One small suggestion: drop "BWAPI" from the name of the articles. Seems like most (all?) of these articles are describing the internals of BW itself and don't have much to do with BWAPI, so it might just cause confusion. If there are some articles that talk about BWAPI, then it'd be good to recognize those as such.

Sonko

154 Posts

November 14 2019 09:35 GMT

#34

One small suggestion: drop "BWAPI" from the name of the articles. Seems like most (all?) of these articles are describing the internals of BW itself and don't have much to do with BWAPI, so it might just cause confusion. If there are some articles that talk about BWAPI, then it'd be good to recognize those as such.

In the long run, this is a part of the BWAPI book - this chapter just got a little bit longer than I anticipated

2Pacalypse-

Croatia9543 Posts

November 14 2019 13:58 GMT

#35

On November 14 2019 18:35 Sonko wrote:

Show nested quote +

In the long run, this is a part of the BWAPI book - this chapter just got a little bit longer than I anticipated

It might be a good idea to be able to quickly sort BWAPI articles from non-BWAPI articles, so that people who are only interested in BW internals and not so much in BWAPI itself, could quickly find what they're looking for ^^.

Sonko

154 Posts

November 14 2019 14:16 GMT

#36

By the way, I lied a lot. Here are some corrections, or rather, clarifications - just as an example
I made these corrections in the article as well. I'm constantly revising, rephrasing, and verifying all of this - not without help, of course.

When upgraded, the Vulture is the fastest unit in the game.

- technically, only the unit with the fastest average top speed among the controllable units. Nukes, scarabs, and interceptors are faster, for example.

(Spider mines) After being laid, it is invisible in the ground (like burrowed units)

They actually take some time to become invisible.

Added this section to the spider mine damage section:
"It fires a stationary bullet when 30 distance away from the target, then gets destroyed 9 frames later. Since this is splash damage, this explains why running away from mines can reduce the damage taken. (See Combat and Damage for more details)"

The tank's turret and base are handled as two separate units in the game code, but that has no bearing on gameplay.

That was a blatant lie. Corrected it to:

This allows the turret to face an enemy unit, while the body moves in a different direction. So when stopping and attacking, the unit does not need to change facing, effectively making it a bit more effective at hit and rtun attacks.

Also with Goliaths:

The turret can turn away from the direction of the body, but has a limit of 32 angle units, so in practice this works more like an increased fire arc.

the Valkyrie fires 8 rockets, and cannot move until all of them are fired.

It can, it just cannot be interrupted during this.

Larva timing is further clarfiied to this. (Imagine digging this out)

Each Hatchery has a larva_timer variable, which is set to 37 when a larva is spawned. This gets decreased every 9 frames, but that timer is randomized every 150 frames. So this timer is subject to 2 or 3 randomizations. This means that as long the larva count is never max, larva will spawn every 328-361 frames, otherwise this number will vary between 319-360.

I also added this to the Spore Colony:

Since it’s a building, the detection range is 7 tiles, or 7*32 pixels, which is not the same as the unit’s sight range)
but spore colony does not

It's of course, a matter of how precise I want to be exactly. At some point, it's a pointless exercise, but I feel I'm far from it.

Kudos if you have noticed any of these while reading the article :D