Game Mechanics Quiz 1 - How much do you really know?

[UpperKEES]

I'm not going to look at the maps but just by looking at the picture you put up I'm going to guess that the emitter in the middle has a shorter interval  in the unsuccesful map, causing the blaster on the right to focus its fire on the emiter in the middle instead of on the emitter on the right (due to very fast interval emitters needing 2 blasters to cap it) this will allow creeper to spread on the right and destroy collector there, thus preventing the win

Incorrect.

The blaster placed last will target the middle pool, this causes the difference.
Why? Probably because the last placed blaster starts with checking where the creeper is, and thus will shoot at the middle pool, the other one can't fire there, cause there isn't any creeper left, so it shoots at one of the side pools, I guess.

Correct. :) One more point for you.

Apparently the blasters check for the closest creeper in reversed order of their creation. When the left blaster is created last, it will cap the middle emitter, so the blaster on the right can target the emitter on the right. When the right blaster is created last this will be the one capping the middle emitter, enabling the emitter on the right to destroy the collector. So build order matters!

The same thing applies to emitters, only not in reversed order. When you put a delayed zero intensity emitter on top of a normal emitter with the same interval it will stop that emitter. When you would have created that zero intensity emitter first, it would be underneath the normal emitter and not stop all creeper emitted. This is something you may want to take into account when creating maps with stacked emitters.

Because we have a tie now I will keep asking questions until Sqaz or mthw2vc earns the next point and wins the quiz. Everyone can still participate and even catch up with the 2 leaders!

[Grauniad]

Because we have a tie now I will keep asking questions until Sqaz or mthw2vc earns the next point and wins the quiz. Everyone can still participate and even catch up with the 2 leaders!

Rules of fairness would demand that the winner has a clear, two-point lead. :)

[UpperKEES]

Rules of fairness would demand that the winner has a clear, two-point lead. :)

Let's apply that rule, I like it. :)

But of course I won't if Sqaz or mthw2vc have objections, so I'll give them 48 hours to let me know if they do. Next question will be posted at the end of the week, because I'm rather busy at the moment.

[ctuna]

Apparently the blasters check for the closest creeper in reversed order of their creation. When the left blaster is created last, it will cap the middle emitter, so the blaster on the right can target the emitter on the right. When the right blaster is created last this will be the one capping the middle emitter, enabling the emitter on the right to destroy the collector. So build order matters!

Does this depend strictly on the creation order, regardless of which was powered first (for example, if the path to them is different)? What about moving two into the area at the same time?

[Kapoios]

Apparently the blasters check for the closest creeper in reversed order of their creation. When the left blaster is created last, it will cap the middle emitter, so the blaster on the right can target the emitter on the right. When the right blaster is created last this will be the one capping the middle emitter, enabling the emitter on the right to destroy the collector. So build order matters!

Does this depend strictly on the creation order, regardless of which was powered first (for example, if the path to them is different)? What about moving two into the area at the same time?

It is only creation order that matters. In previous versions of the game this used to be different, however. I know that you could send a unit for a short flight and this would change order, but no longer does so. Order of connection never mattered. Of course, you could engineer an example where order of connection matters, in that one of the blasters gets to fire a frame or two earlier because the other didn't have energy. But that's a completely different thing. In the quiz example, both blasters fire at the same frame.

[Kapoios]

I dont think the center of the city has energy , but i dont know this game as you do , so it still might be right =P

It does, see here.

I now actually think that the center of the city does NOT produce energy and therefore maximal energy production of the city is 0.872. I tested by connecting the city (with relays of course!) with 1-square collectors. With 6 collectors added, it still shows production of 0.8, while with 7, it shows 0.9. You would expect it to show 0.9 with 6. I've also noticed other weird results while trying to make a map that handled energy extremely precisely and I would only explain the weirdness if there was one less green square than I thought.

EDIT: I'm not very sure about this though. Could it be one of those weird errors that arise when you truncate because of numbers stored in binary?

[UpperKEES]

Oh, interesting! I actually thought Spiffen meant something else by the center of the city (the 2 onboard reactors), so I never figured he was referring to the center square.

[Kapoios]

Oh, interesting! I actually thought Spiffen meant something else by the center of the city (the 2 onboard reactors), so I never figured he was referring to the center square.

Never mind, actually. Further testing seems to suggest that the center does produce energy. I think it's a rounding mistake with conversion to binary and back (something like the warning in this page).

I found a different reason why my map produced weird results. It seems that 0.2 emitters fire every 7 frames. So, they won't fire only 5 times per second, but about 5.14 times (on average).

[UpperKEES]

Never mind, actually. Further testing seems to suggest that the center does produce energy. I think it's a rounding mistake with conversion to binary and back (something like the warning in this page).

Hey, nice way to keep me busy! :P

I just created a testmap and it indeed shows the center does produce energy (see attachment). OC is placed centered on a 1 square elevation and so are 25 collectors. The energy collected is 0.7, also when you remove 1 collector. When you remove a second collector the collection drops to 0.6, so I think everything works as expected and I don't see any rounding issues involved here.

I found a different reason why my map produced weird results. It seems that 0.2 emitters fire every 7 frames. So, they won't fire only 5 times per second, but about 5.14 times (on average).

Not sure what this has to do with the city center, but everything expressed in seconds is translated into frames in the CWM file and will never be translated back. This means 0.2 seconds is translated into 0.2 * 36 = 7.2 frames, rounded to 7 and stored like that in the CWM file, so it will indeed fire more often. Maybe nice to know the rounding is always downwards: an emitter with a frequency of 0.1 seconds is translated into 0.1 * 36 = 3.6 frames and rounded to 3! This means it is more than twice as powerful as a 0.2 frequency emitter and will cost you 2.3333 times more energy to cap it....

Happy testing! ;)

[Kapoios]

I just created a testmap and it indeed shows the center does produce energy (see attachment). OC is placed centered on a 1 square elevation and so are 25 collectors. The energy collected is 0.7, also when you remove 1 collector. When you remove a second collector the collection drops to 0.6, so I think everything works as expected and I don't see any rounding issues involved here.

If it is what I think (the issue with rounding floats described in the php manual I linked above) then the rounding issue won't appear in all cases, but it's rather chaotic. In this case, the issue appears when rounding 0.9 but not when rounding 0.7 as in your example (my testing was with the city's 0.876 and adding collectors one by one, until it would reach 0.9). Look at the attached map. It's exactly your map with two 5x5 squares added, which produce an extra 0.2 energy. The energy collected when you remove one collector should still be 0.9, but it shows 0.8. Now while it shows 0.8, if you destroy one of the two 5x5 collectors, it will still show 0.8 which is now correct (apparently the rounding issue doesn't happen with 0.8 either, but only with 0.9!).

That's how I deduced, erroneously, that the center doesn't produce energy. There was this discrepancy that I interpreted as 1 square missing and then decided somewhat arbitrarily that the special square must be the center of the city.

Not sure what this has to do with the city center.

Nothing at all! I was just trying to find why I was getting deficit. I went completely the wrong way there. I thought it must be less energy produced instead of the blaster using more energy. Which in turn led me to testing the city, where I came across the rounding issue which naturally confirmed my theory! It was actually quite scientific; the rounding issue is not something that you usually think of.

[UpperKEES]

If it is what I think (the issue with rounding floats described in the php manual I linked above) then the rounding issue won't appear in all cases, but it's rather chaotic. In this case, the issue appears when rounding 0.9 but not when rounding 0.7 as in your example (my testing was with the city's 0.876 and adding collectors one by one, until it would reach 0.9). Look at the attached map. It's exactly your map with two 5x5 squares added, which produce an extra 0.2 energy. The energy collected when you remove one collector should still be 0.9, but it shows 0.8. Now while it shows 0.8, if you destroy one of the two 5x5 collectors, it will still show 0.8 which is now correct (apparently the rounding issue doesn't happen with 0.8 either, but only with 0.9!).

Just tested it and got the same results as you did. Weird! AS3 must have the same kind of problems as PHP has (and probably quite some other languages). Too bad the values are always floored instead of rounded to the nearest integer....

[Kapoios]

Just tested it and got the same results as you did. Weird! AS3 must have the same kind of problems as PHP has (and probably quite some other languages).

I think it's more like a consequence of the way computers work and not so much a problem of the programing language. You could, of course, store the decimal expansion of a number instead of the binary one. You'd still get weird results like floor(3*(1/3))=0 but not the more counterintuitive like floor(10*0.8)=7. But then operations like addition would take much more CPU time. Floats must have finite precision because of finite memory and for scientific purposes there isn't really any more badness in saying 7=6.99 than in saying π=3.14.

For the purposes of CW, you could simply store all things energy related in integers (i.e. store 0.004 as 4), since there aren't any occurences of numbers with more decimal digits.

Too bad the values are always floored instead of rounded to the nearest integer....

With my luck, I'd still stumble upon the rounding issue at exactly 7.5 or 8.5!

[UpperKEES]

I think it's more like a consequence of the way computers work and not so much a problem of the programing language. You could, of course, store the decimal expansion of a number instead of the binary one. You'd still get weird results like floor(3*(1/3))=0 but not the more counterintuitive like floor(10*0.8 )=7. But then operations like addition would take much more CPU time. Floats must have finite precision because of finite memory and for scientific purposes there isn't really any more badness in saying 7=6.99 than in saying π=3.14.

Sure, I understand that, but apparently more precise math functions are available (at least for PHP, not sure about AS3).

For the purposes of CW, you could simply store all things energy related in integers (i.e. store 0.004 as 4), since there aren't any occurences of numbers with more decimal digits.

That's exactly what CW2 will do! :)

[UpperKEES]

Okay, time for some more corrections, as I got the answers from the only person who really knows.

It looks like the game only checks for wall decays about every 7 frames

My findings are that the decay is checked for every frame, but the creeper only updates every 8 frames (actually ¹/₈^th of the creeper updates every frame, see here), so that may have influenced your results when you also used a creeper clock.

You are right about this mopa42, as Virgil states:

As for the wall decay rate.... it looks like the constant I use is 1/2100.  That amount gets subtracted from the wall starting value (which is 1).  Now this doesn't happen every frame... it only happens every 7 frames (the creeper updates on intervals of 7 frames and the wall decay happens during the creeper update calculation).

I'm not sure why shifting the start time of the emitter by one frame also shifts the survivor dying by one frame, but I guess I'll have to live with the fact that I'll never know everything.

Creeper can't flow through walls, so the creeper that would have flowed into a wall is redirected to the original cell, and a similar rule applies for terrain differences.
If you pause as the creeper first spreads, there is 3/8 of a layer of creeper over the emitter and touching the wall, assuming the emitters are intensity 1. Your original answer was correct.

This also seems right, as Virgil replied:

So that would mean 2100*7 = 14700 frames to decay a wall (if my quick peek at the code is correct).

This means the final answer to question 9 is 14700 frames and the other times calculated for wall decay are posted correctly here. Of course I won't retract points given due to my own wrong assumptions....

Finally:

For the purposes of CW, you could simply store all things energy related in integers (i.e. store 0.004 as 4), since there aren't any occurences of numbers with more decimal digits.

That's exactly what CW2 will do! :)

Yeah, in CW2 everything is explicitly an integer.  I also use frames in the editor rather than showing seconds.  The seconds that the CW1 editor shows is just a human convenience (as you have discovered).  The values always get rounded to some number of frames.

[Kamron3]

Happy 3000th post UpperKEES!