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

[Sqaz]

Actually that depends on the amount of free spaces, you mentioned only one, so if you'd place the storage in sector A you wouldn't be able to build SAMs there and would probably lose your storage and some reactors causing an even bigger deficit.

This of course depends on the free amount of space, so that might have been clarified a bit in the question.

No complains though, Nate deserves to win.

[UpperKEES]

The question said at least one free space. Besides that you could also build the SAM protecting section A on the other side of the wall (section D) as the spores will be coming from the south and the range upgrade has been applied. Finally getting hit by 1 spore of 1.5 intensity is less worse than losing all caps.

I'll try to post the next question on Monday. :)

[UpperKEES]

Question 8 has been posted. :)

[Colin]

I would have to say the depth of both pools is 0.1 because
both blasters and mortars have the same damage "radius",
right?

And seeing as the Creeper instantly replenishes any damage done,
the mortar would win damage per second at almost every depth
level.

[UpperKEES]

the depth of both pools is 0.1

Incorrect.

[Colin]

I guess I wasted my guess for this month on this question, huh.  ;D

[UpperKEES]

Nothing ventured, nothing gained. ;)

[mthw2vc]

Question 8:
Please have a look at the image below:



A blaster and a mortar fire from an island into two equal pools with creeper. The entire bottom of both pools is covered with emitters of 0.1 second interval, so all damage done is negated before the next shot occurs. After very accurate measuring it turns out that both weapons do precisely the same amount of damage per second. What is the exact depth of the creeper in both pools? (You are allowed to round to one decimal.) Tip: it doesn't matter if the fire rate upgrade has been applied, but it makes calculating a lot easier.... ;)

Without the firing rate upgrade applied, A blaster fires every 7 frames and a mortar every 105. The blaster causes 8 damage per shot and fires 15 shots for every one the mortar fires (105/7). The mortar shots should therefore cause 120 (8*15) damage apiece, and affect 36 squares each, which would mean the depth is 3 1/3, which, rounded to the nearest tenth of a unit, would be 3.3.

[UpperKEES]

Without the firing rate upgrade applied, A blaster fires every 7 frames and a mortar every 105. The blaster causes 8 damage per shot and fires 15 shots for every one the mortar fires (105/7). The mortar shots should therefore cause 120 (8*15) damage apiece, and affect 36 squares each, which would mean the depth is 3 1/3, which, rounded to the nearest tenth of a unit, would be 3.3.

Correct. :) One more point for you.

In other words (and using the fire rate upgrade to get round numbers, as both weapons are affected in the same way):
A blaster does 8 damage per shot and fires 6 times per second, doing 8 x 6 = 48 ccc damage per second.
A mortar does 36 x Creeper depth (D) damage per shot and fires 0.4 times per second, doing 14.4D damage per second (max D=4, so max damage = 57.6 ccc per sec).
D = 48 / 14.4 = 3¹/₃ (rounded 3.3).

This means a blaster does more damage per second in pools up to 3.3 elevation levels of creeper, while a mortar is more effective in pools with 3.4 or more elevation levels of creeper. On most maps pools never contain that much creeper, so a blaster is almost always a better choice when the edges of the pool contain just as much creeper as the center of the pool.

[Kapoios]

When looking at this, don't forget that the build packet request rate also matters here. Who says a collector requests exactly one package per second? It is very likely that a similar factor (like 0.89) is used here. Probably all gauges/displays/tickers are measured per 0.89 seconds, so maybe this affects gameplay less than we think. I'm glad CW2 will use 30 frames per second, so we won't be dealing with these kind of issues! ;)

In fact, I'm almost certain that build request is every 0.8333 seconds. See my post here.

If you can bother, please do check it yourself. This 30 vs. 32 frames for build packet requests has been bothering me for some time and is one of the reasons I joined these forums. (The other two being the history tournament and a bug I wanted to request a fix for. Which you already had!) I've known it for some time and somewhat apply it, when building. Though, of course it only really matters when building many things. Eg. the 3.2 depletion that happens when building three things is noticeably different from 3.0 as in the example in that other thread, while 1.0 and 1.066 (=32/30) doesn't make all that much difference when building, say, a single collector.

EDIT: Thanks for answering in that other thread! (which I totally hijacked)

[UpperKEES]

Yeah, I just read that, tested it (yeah, I bother ;)) and commented there. Welcome to the forums! :)

It indeed does make a difference when building multiple units simultaneously, especially when expanding your energy collection by building lots of reactors at the start of a map. The only good thing is that having a slight deficit isn't too bad as the last units being built will catch up in the end (although the first ones didn't complete as fast as they should have). I guess using the +20% faster building upgrade will make this effect even a little worse: 3.84 depletion instead of the expected 3.6 (both per ³²/₃₆ seconds, to make it as complex as possible :P).

Edit: now I think of it, I already asked questions about this in March this year, see here.

[UpperKEES]

My initial question was how many seconds it would take for a packet to travel 700 squares with 12 speed nodes (quad speed), but my results were too far off from the expected answer of 25 seconds to be precise enough, so I had to change it to avoid lengthy discussions.

Also remember the effect that the packets must stop on every network node, this explains some of the deviation, especially when using several speed nodes.

Yeah, I considered that, but this recalculation of the packet path is all done within a frame, so that frame just takes a little longer to process I guess, but shouldn't influence the travel time. The application just runs a little slower. Unless a packet really stops at a node for 1 frame of course; I could test this by replacing the relays by collectors, thus doubling the amount of intermediate nodes. I'll attach my testmap so you can experiment as well if you like.

Kapoios and I had a nice chat about this unresolved topic and he came up with the probably cause of it: by default a packets travels 2 pixels per frame. Every speed node adds half a pixel to that. Let's set the average distance between collectors and other nodes (except for relays) at 5 blocks (50 pixels) for this example. At default speed this takes 25 frames. At double speed (+4 speed nodes) 13 frames (12.5 rounded up, because it has to stop at the node to recalculate its route, which means you lose half a step each node). At triple speed 9 steps (8.33 rounded up, losing ²/₃^th step per node). At quad speed 7 steps (6,25 rounded up, losing ³/₄^th step per node).

The table below shows that the optimal number of speed nodes and the loss of speed really depends on the distance between nodes: (click here to enlarge even more)



Native English speakers please note: a comma in this table represents a decimal point!

The larger the spacing between nodes, the less loss you have when adding more speed nodes. The average doesn't say that much however; having half of your collectors spaced by 48 pixels and half of them by 56 pixels will have a completely different effect than all collectors spaced by 52 pixels, while their average is the same. In general you can say that having more speed nodes will cause more loss, so building more of them becomes relatively less effective. In fact it does not matter whether you build 21 or 29 speed nodes when your collectors are spaced 5 blocks apart, it will always take 4 frames for a packet to travel to the next node. When using only collectors you shouldn't be building more than 8 speed nodes, because the gain is minimal, so stop overbuilding!

When you build all your collectors in horizontal or vertical lines with a distance of 5 blocks you can clearly see you should never build 3, 5, 7, 8, 10 or 12 speed nodes, because this won't gain you much (if anything at all). When you build relays you'll notice this effect a lot less as not as many stops are required, but building more than 12 speed nodes won't gain you much either in this case.

Another nice thing you can deduct from the above results is that building your collectors alternating slightly diagonally won't cause the loss of speed (while the distance is longer). It often takes the same amount of frames for a packet to travel to the next node and you will gain more energy (due to less overlap). :)

Considering all of this it would be nice when every next speed node you build would cost a little less, let's say -10% of the costs of the previous one. That way it would be beneficial to keep building more of them.

Finally: the stop of the packet at a node to recalculate its route does not affect the speed, as it is all done within the same frame, which always takes ¹/₃₆^th of a second.

[thepenguin]

um, can you put that in terms I can understand

[UpperKEES]

Is it the table or the text you don't understand?

[Colin]

Basically what hes saying is that as the game mechanics
are now, there is such a thing as too many speed nodes.  :P

The most efficient numbers of them at the moment
(according to KEES) are NOT these: 3, 5, 7, 8, 10 or 12,
so build 1,2,4,6,9 or 11 nodes for the most efficient use
of energy, and speed over long distances (when using a
fractal collector grid).  :D

(@ KEES, I believe he doesn't understand what your trying
to communicate, because you use paragraphs that are too
long and he doesn't take the time to read them.)  ;)