I was walking around, thinking, like I usually do, when I started thinking about a question I had asked myself years before: How does the map, Bounds, work?

For those of you who haven't played the map, it's probably one of the coolest bound maps you'll ever find. It's a make your own bound map, but it's not like the other lame ones where there's a few stupid obstacles already made for your convenience, this is a purely explosion dodging bound maker, and it is extremely customizable.
You have a 4x7 grid of Lurkers, that you cast Dark Swarm on to select. When you select a Lurker, a Dark Archon appears above it, and it has been marked as an exploding spot. You can do this wherever you like, and then you cast Dark Swarm on a crystal to change to the next step in the bound, each bound has 9 steps, a series of 9 explosions that go sequentially then start over, in each step you record the pattern of the explosions you want, and when you're done it runs through them all, repeatedly, creating your custom bound.
The map supports 5 human players.

---

Before you move on, I want you to take a moment to think, how would I do it?
When I first thought about it years ago, I thought of using the same method that is actually used in the map. Which is simply spawning different units under the Lurker depending on which step the player is on, simple enough and effective... But can you think of another, more efficient method?

---

I like to call it, Binary Boolean Array Storage, BBAS for short I'm almost sure this is not a new idea, however, I have never seen the idea mentioned in forums or in any tutorial, I'm sure it's been used, but rarely.

This method allows you to store what would normally take 32(31 depending on how you look at it), switches, in a single death count, for a single player. That's 248 switches per unit. Interested now? Well, read on

To show you how it works, I'm going to give an example of it in action, doing what is done in the map Bounds, on a smaller scale, a 3x3 grid of lurkers.
Here's how the grid looks:


Now, each section in the array is assigned a different multiple of two, in this case I would assign the numbers in the same order that SC would run through the lurkers as a unit grid, left to right, bottom to top, the locations are only to show the assigned numbers:


Whenever a unit is selected, their assigned number is added to a death, if that lurker is deselected, you subtract that amount:


Now, when the player runs their bound, you start from the highest and go to lowest, seeing if the Death has that much in it, and making an explosion in the assigned spot if there is, so in this case, 273, there is at least 256, so it subracts 256, leaving 17, and creates a DA in the 256 spot, then it runs through, no 128, no 64, no 32, but 16 can go into 17, so it subtracts 16 puts a DA in the 16 spot, now it keeps going, no 8, no 4, no 2, there is a 1, so it puts a DA in the 1 spot. Now you kill the DAs, and you have your explosions!

It's a much more efficient system, using only a single Death Count, rather than using tons of different units. And it can be applied in all sorts of maps.

Post has been edited 4 time(s), last time on Sep 7 2009, 5:17 am by Falkoner.

That is hot. I already knew how to use this but still, well done explaining it.

32 (maybe 31) switches per death count.

Yeah, i played this before.
It actually isint that hard to figure out. Not to be a "perfectionist" but that map would be a lot better with a bigger layout.
Anyways, im pretty sure that anyone on this website can replicate this map, but the person who made this map was a genius. With that being said, it would be better if there were multiple layouts, and you could choose which layout you want.
However, that would require a lot of locations, or maybe even gridding.
Anyways, I kinda strayed off topic, but good job explaining this, Falknah.

Since any number can be expressed as a unique sum of powers of 2 with no power being repeated, you can use 1, 2, 4, etc. instead of the ones you used.

And yeah, this is far from new. Congrats on discovering it for yourself, I guess.

This isn't efficient in the slightest. Maybe it's worthwhile if you have 228*12 unit types in use through death counts, but otherwise, no. In terms of triggers, it's much easier to use a brand new death count. Less triggers=smaller map. You could have used player 1-9 deaths of cantina and still had plenty of death counts to spare.

Ah you're right, it's 31, I just stopped when I saw the first big number starting with a 4, thinking that one was the Death Count limit, thanks for correcting


I did use 1, 2, 4, etc..? But yeah, any power of two up until 4294967296 can be used(although you might have to go one less, I think..)


Well, for like the past few months I keep thinking of systems that involve this being the focal point, I just started thinking about how I could explain it easily last night.


Is it? Maybe mentally, but all it takes is a few notes to remember what numbers coordinate to what things, I like it because it sorta forces you to take notes, and it keeps the map itself clear.

Welcome to death counters.

Is this just plain old binary countoffs or am I missing something?
It goes up to 2147483647((2^31)-1). Anything more is a negative number. 4294967296(2^32) and above is counted as zero.

Post has been edited 3 time(s), last time on Sep 7 2009, 1:21 am by Morphling.

Yeah, but using them to store an array of boolean data, you're really storing several values in one when you do this.


It's signed, but SC will still allow you to go up further.

Okay I see what you mean.... I had always known about this since I knew about death counters. I was using this in many of my maps which never were completed.(my own versions of Pixel Adventure and Mario Minimap Movie)

STOP. The highest degree is 31, right, but you can store 32 switches as far as you start from zero:
2^0 2^1 ... 2^31 - 32 degrees overall.

Or is there even more numbers one can store in a DC? I always forget, how many bit's is there? Is it a 64-bit signed integer variable?

Yeah, but it truly depends on what you're doing with it, I prefer to consider the 0 not really on option, at least in this case I wouldn't, although I guess it sorta is


It's 4294967295, that's the actual limit.

It might not be an actual limit if a death counter is a 64-bit integer, because what matters is the number of bits in variable but not the maximum integer number it can store.

A death counter is 32 bits. Not sure if signed or unsigned. If unsigned you can store 32 boolean values, if not, only 31.

This is nothing new. Congrats figuring out how rantent's map works
Also you can use the boolean values to store anything, not only placement arrays.

Sounds much like Calculus.


So we could toy with numbers higher than 429967296? Or would it be like a damage of 66536 and return to 0, then go up again? Please explain.

This is correct:

...But Falk said...
Whatever. I don't ever deal with numbers as big as 2¹⁶, so I'm fine not knowing definitely either way.

1111 1111 1111 1111 1111 1111 1111 1111 = 4294967295 or -1
1 0000 0000 0000 0000 0000 0000 0000 0000 = 4294967296 or 0
starcraft only reads the last 32 bits, which means 4294967296 will loop back to 0.
1 0000 0000 0000 0000 0000 0000 0000 0001 = 4294967297 or 1
scarcraft will read this a 1.

This is assuming the map would save with these numbers. Not to mention, it reads them as signed numbers, which means the most significant bit is equal to adding -2147483648.
0111 1111 1111 1111 1111 1111 1111 1111 = 2147483647
if you add the last bit, 2147483647 - 2147483648, you'll note the answer is -1.

also, numeric values are stored in 4 bytes (8^4=2^32). Since it's signed, you can only store 31 bits easily. You can probably mess around and get the 32nd bit, but it's hard and pointless.

Addition and subtraction is identical with signed and unsigned integers.

Death counts are unsigned. Here is a test map: [attach=4470]

Attachments:

Post has been edited 2 time(s), last time on Sep 7 2009, 9:44 pm by Doodle77.