Custom Map: Nice Job 25: The Developer

[UpperKEES]

You're doing fine.... 4th place with that score!

Or are you only satisfied when you beat me? :P In that case: pause a lot!

[kropernic]

Not specially beat you but still, i'd like to be in top 3 ^^.

But can you precise what you mean by "pause a lot" ?  Is there some technic to spare time ?

[UpperKEES]

I always pause when adding new units to be built, so I can do this at exactly the right moment (especially for collectors and reactors). Also when moving units, so they all land at the same time for instance. I also pause when planning my collector lay-out to make sure I use every single square as efficient as possible.

Spoiler

I let weapons only fire at creeper that need to be killed soon to be able to advance; the rest can wait. ;) Speed nodes can pay off when collectors further away get built faster, so the blasters protecting that area need to fire less in the meanwhile. Capping emitters is often more effective when you drop a bunch of blasters close by, instead of bunny hopping there all the way. You need to be fast to connect to them though!

[close]

[mszegedy]

I am working on a video of this map. I was disappointed by the absence of one among those on YouTube; it can really help. Do you mind?

Of course, I need to beat it first.  ;)

(up to 5:17; I've mostly figured out Phase 1, keep forgetting about survivors; blaster in center is mysteriously getting destroyed now, as is left reactor)

[UpperKEES]

I am working on a video of this map. I was disappointed by the absence of one among those on YouTube; it can really help. Do you mind?

Sure, go ahead. :)

Of course, I need to beat it first.  ;)

(up to 5:17; I've mostly figured out Phase 1, keep forgetting about survivors; blaster in center is mysteriously getting destroyed now, as is left reactor)

Yep, you need to keep an eye on the future users of your program.

The blaster should be able to cap the emitter, just like the other ones. Maybe it's too close to it, so better move it a few blocks away.

Or maybe you experienced some creeper flowing from phase 6 to phase 1; you'll have to find a solution for that....

[mszegedy]

Nah, I've got a theoretical solution for that.

Unfortunately, I can't move the blaster any further away, because then it won't be able to bridge to the left side of the question mark and I won't be able to abate that mass of creeper flowing from the top left right corner, which could completely cripple my whole defense.

[UpperKEES]

Nah, I've got a theoretical solution for that.

Good, you can find some hints about it in earlier comments....

Unfortunately, I can't move the blaster any further away, because then it won't be able to bridge to the left side of the question mark and I won't be able to abate that mass of creeper flowing from the top left right corner, which could completely cripple my whole defense.

Hmmm, then maybe build a connection below the question mark to the left? Although I think that I was able to connect to the left, right and upwards from the blaster capping the central emitter in section 1, without it getting damaged at all.

How many blasters are you using? And do you build some reactors to be able to sustain them?

[mszegedy]

No, reactors waste space and put on too much strain. The way I do it is put the obvious collector, then build a blaster where the artifact was (and meanwhile spend my upgrade on 20% faster building- say what you like about range, I'm sticking with this). Then, I pause, move the blaster to right below and slightly to the left of (but not on) the central emitter, and at the exact same time build a collector in its place. This is sustained quickly enough for the blaster to survive. Then, I build a collector on the right side of the question mark (in the only spot available, you know the one) which quickly gets built, then I build a second blaster right below it. It is in this time that the creeper usually gets my reactor(s), if the blaster is not completed fast enough. What's strange is that sometimes it is made with plenty of time to spare, and others the creeper spills onto my left reactor, ruining everything and eventually leading to my demise. I occasionally forget to apply the upgrade, but even when I do I get these results. I then move this blaster into the creeper and immediately seal off that emitter. It is usually by this time that my central blaster self-destructs, and my whole game is lost.

From hereonout it's open- ideally, I make a collector on the tip of the curl of the question mark, and somehow connect it to the top right collector, so I can move the central blaster away from that emitter. Of course, I build a collector bridging to the drone and second artifact as soon as possible, and this generally happens fast enough (in fact, usually quite early) so that I may save the survivors in Phase 5. I work to cap off all of the emitters, and then (this has never been achieved) build a blaster at the tip of the arrow to Phase 2.

I do not have a plan for the rest (except one for Phase 6, but it's too boring to describe).

[UpperKEES]

No, reactors waste space and put on too much strain.

Reactors waste space? That's new to me! ;) As far as I know they deliver most energy for the surface they occupy.

The way I do it is put the obvious collector, then build a blaster where the artifact was

So far, so good.

(and meanwhile spend my upgrade on 20% faster building- say what you like about range, I'm sticking with this).

Spoiler

Do you realize the '-10% building costs' also builds 10% faster and saves a lot more energy, especially during the beginning of a map? See here for more info. The range upgrade is nice with mortars and SAMs and should certainly not be your first choice.

[close]

Then, I pause, move the blaster to right below and slightly to the left of (but not on) the central emitter, and at the exact same time build a collector in its place. This is sustained quickly enough for the blaster to survive. Then, I build a collector on the right side of the question mark (in the only spot available, you know the one) which quickly gets built, then I build a second blaster right below it. It is in this time that the creeper usually gets my reactor(s), if the blaster is not completed fast enough. What's strange is that sometimes it is made with plenty of time to spare, and others the creeper spills onto my left reactor, ruining everything and eventually leading to my demise. I occasionally forget to apply the upgrade, but even when I do I get these results. I then move this blaster into the creeper and immediately seal off that emitter. It is usually by this time that my central blaster self-destructs, and my whole game is lost.

I do this almost exactly like you do, so I'd try a different upgrade.... Your approach seems to be fine! :) My blaster is on that very same spot as yours for the entire game!

From hereonout it's open- ideally, I make a collector on the tip of the curl of the question mark, and somehow connect it to the top right collector, so I can move the central blaster away from that emitter. Of course, I build a collector bridging to the drone and second artifact as soon as possible, and this generally happens fast enough (in fact, usually quite early) so that I may save the survivors in Phase 5. I work to cap off all of the emitters, and then (this has never been achieved) build a blaster at the tip of the arrow to Phase 2.

Spoiler

I would first generate as much energy as possible instead of trying to move on fast. You'll need much more and where are you going to get it? Section 1 offers quite some space. Really, reactors are the answer! Connecting soon to the drone is good (because you get upgrade 2), but don't charge it yet; that's a waste of energy. Better save it to build more reactors first and charge the drone when needed (but in time!).

[close]

[mszegedy]

Do you realize the '-10% building costs' also builds 10% faster and saves a lot more energy, especially during the beginning of a map? See here for more info. The range upgrade is nice with mortars and SAMs and should certainly not be your first choice.

No. Lower cost is not more efficient. See here:

The amount of time it takes to fill out a bar (either the building bar or the ammo bar) is dependent on this equation:

T = C/R

T is "Time taken to build", measured in seconds, C is "Cost", measured in packets, and R is "Rate at which packets are sent", measured in packets per second.
Let's use a reactor as an example (and assume that initially it's 5 packets per second, which is actually a gross exaggeration).

40/5 = 8 seconds

Now, what "costs 10% less" proposes to do is decrease C by 10%. This does not go into effect for the ammo bar. Our revision is:

36/5 = 7.2 seconds

What "builds 20% faster" proposes to do is increase R by 20%, and this works for the ammo bar too. Our revision is:

40/6 = 6 2/3 seconds

Build 20% faster is clearly the better option! Also, considering "Produce 10% more energy"...

R = P/t

P is "packets produced in one burst", measured in packets, and t is "time in between bursts", measured in seconds.
What "Produce 10% more energy" proposes to do is increase P by 10%. What "Build 20% faster" does is increase the quotient by 20% (done by dividing t by 120%). Let's see:

Original model:
10/2 = 5 packets per second

With "Produce 10% more energy" applied:
11/2 = 5.5 packets per second

With "Build 20% faster" applied:
10/(2/120%) = 6 packets per second

So "Build 20% faster" still wins.

Of course, I'm not factoring in starvation, but I don't know how it affects it anyway.

[UpperKEES]

First of all: nice to see another math lover! :) When you like to analyse these kind of things, you may want to have a look at the Game Mechanics Quiz (that just ended, but the Q&A's are still interesting).

Now, let's get to your post:

No. Lower cost is not more efficient. See here:

The amount of time it takes to fill out a bar (either the building bar or the ammo bar) is dependent on this equation:

T = C/R

R is "Rate at which packets are sent", measured in packets per second, C is "Cost", measured in packets, and T is "Time taken to build", measured in seconds.
Let's use a reactor as an example (and assume that initially it's 5 packets per second, which is actually a gross exaggeration).

40/5 = 8 seconds

By the way: the packet request rate is about once per 0.83333 seconds, see here, while the energy collection and depletion on your display are measured per 0.88888 seconds, see here. Not that it matters for your example, but maybe you like to know.

A better formula would be: T = C/R + D/S, where D = distance in pixels and S = speed in pixels per second. However we are not taking the distance into account now, so let's forget about that as well.

The request rate for ammo packets also depends on the need for ammo: a weapon with less than 50% ammo will request at double rate, see here. Of course the +20% build speed upgrade doesn't affect that.

Now, what "costs 10% less" proposes to do is decrease C by 10%. This does not go into effect for the ammo bar. Our revision is:

36/5 = 7.2 seconds

It does affect the ammo bar, only in a different way! When you look carefully it will jump from 90% to 100% when the last packet arrives (number 36 for a reactor), see here.

What "builds 20% faster" proposes to do is increase R by 20%, and this works for the ammo bar too. Our revision is:

40/6 = 6 2/3 seconds

Build 20% faster is clearly the better option!

Yes, this upgrade builds faster, that's for sure, but it also uses 20% more energy! Let's say you collect about 6 energy, then you can build about 6 reactors simultaneously without the upgrade, or about 5 reactors simultaneously with the upgrade, but faster. Besides that it only builds faster when you have the required energy in store. If you don't the reactor will be waiting for its requested packet until Odin City is able to produce it. The waiting queue is called starvation or deficit. When you see a deficit of 3 for instance, this means 3 packets have been requested, but couldn't be sent (yet), because of an energy shortage. This means the effective build speed can actually drop below the normal build speed, even when you applied this upgrade.

Also, considering "Produce 10% more energy"...

R = P/t

P is packets produced in one burst, and t is the time in between bursts.
What "Produce 10% more energy" proposes to do is increase P by 10%. What "Build 20% faster" does is increase the quotient by 20%. Let's see:

Original model:
10/2 = 5 packets per second

With "Produce 10% more energy" applied:
11/2 = 5.5 packets per second

With "Build 20% faster" applied:
10/(2/120%) = 6 packets per second

So "Build 20% faster" still wins.

Of course, I'm not factoring in starvation, but I don't know how it affects it anyway.

Nope, this is a mistake. Build 20% faster indeed increases the request rate for build packets, but +10% energy does not affect the packet requests at all. It just multiplies your energy collection by 1.1.

So in short: when you have an unlimited amount of energy the +20% build speed is great, because everything finishes 20% faster (when the distance to Odin city is not taken into account). But especially during the start of a map you don't have unlimited energy. -10% building costs really saves energy, so you can build more (and 10% faster). +10% energy gives extra energy that can be used for building and firing.

You are building 3 collectors and 2 blasters so far, which will cost you 80 units of energy (apart from the blaster ammo). The -10% building costs upgrade will save you 7 units (3x1 + 2x2), plus it saves 10% of the time. The 20% faster building upgrade will only be effective when you have enough energy (to keep the first blaster firing and to build the second). When you see a deficit, I'm sure you will be building a lot slower. My advise (for 90% of all maps and assuming you obtain the upgrades during early game): first pick the -10% building costs and secondly pick the +10% energy. If you don't believe me, just try it for yourself and find out empirically. :)

[mszegedy]

Really? Then it has the same problem as 15% fire rate (which I consider to be one of the worst upgrades because it completely nullifies my strategy of sending armies of unconnected but completely full blasters into emitters to clear out that area and hopefully allow me to build relays fast enough to connect it to them; this is how I won everything after Tucana, because it is great fun): all it really does is deplete your resources faster. I am totally not getting this upgrade until, like, fourth.

It does affect the ammo bar, only in a different way! When you look carefully it will jump from 90% to 100% when the last packet arrives (number 36 for a reactor), see here.

I did not know this.

BTW, are you up early, or just really, really late?

[Kamron3]

Really? Then it has the same problem as 15% fire rate (which I consider to be one of the worst upgrades because it completely nullifies my strategy of sending armies of unconnected but completely full blasters into emitters to clear out that area and hopefully allow me to build relays fast enough to connect it to them; this is how I won everything after Tucana, because it is great fun): all it really does is deplete your resources faster. I am totally not getting this upgrade until, like, fourth.

It does affect the ammo bar, only in a different way! When you look carefully it will jump from 90% to 100% when the last packet arrives (number 36 for a reactor), see here.

I did not know this.

BTW, are you up early, or just really, really late?

He's up really late... he's actually going to bed right now.

[mszegedy]

Ah. Understood. I myself am up quite late, but not quite as late as him! (local time 7:00 AM... wow... dedicated...)

Anyway, I don't know how to make an equation of efficiency for this now, as there are too many factors involved... I'll try tomorrow (or, more accurately, later today). Actually, let me try.

[okay, let's take the original equation UpperKEES wrote: T = C/R + D/S; seems good, R needs to be tweaked; R = P/t, hmm what can I do with that, of course change production to supply (s), what would that imply, well we need production rate for that and somehow factor in storage, I'll represent these as p/τ and σ respectively (Greek letters are sexy), p being the collective production of reactors and collectors oh I'm so glad I read that post by Virgil, and τ being yet another incarnation of time; oh, time elapsed and depletion might also be useful, gimme a second, well it somehow comes out to time elapsed times production rate minus depletion rate (the latter two in parentheses), hmm is that right yeah according to the distributive property it is, now how does that relate to everything else, aha we take P - (supply mod P) to get this properly; what determines P, eh who cares]

Finished!

I would totally write out the LaTeX for this, but, alas, I am on a pitiful trial version of Pi Cubed for iPhone. Instead, I present to you this monstrosity:

T = C/(((P-(e(p/τ - d)) mod P) + P - (P mod (e(p/τ - d) - P)))/t) + D/S
(P is packets requested)

Seems right. Lemme get the LaTeX.

(before you ask: no vidica involved)

EDIT: Seems to be nominative neutral rather than accusative masculine... fixed...

EDIT 2: Not only does it turn out that Pi Cubed does not have a "mod" function, it seems that I made a mistake in that part; stay tuned- I think this can be fixed without the use of overly technical stuff like propositional calculus!

EDIT 3: Fixed, with gratuitous use of parentheses and the modulus operation! Not sure what this accomplishes, but all is now well. No matter how hard I try, I can't get the section involving modulus to come out to 0 if s is greater than or equal to P.

EDIT 4: Still can't sleep, but I've hackneyed a pseudosolution to the math problem. It's not perfect but it's acceptable.

[UpperKEES]

Really? Then it has the same problem as 15% fire rate (which I consider to be one of the worst upgrades because it completely nullifies my strategy of sending armies of unconnected but completely full blasters into emitters to clear out that area and hopefully allow me to build relays fast enough to connect it to them; this is how I won everything after Tucana, because it is great fun): all it really does is deplete your resources faster. I am totally not getting this upgrade until, like, fourth.

Spoiler

Yep, those two upgrades can really drain your energy resources, so you should only apply them when you're generating enough energy, or when you explicitly need them because the map requires it. Maybe something needs to be finished very fast to save survivors, or maybe you need the fire rate upgrade to be able to cap an emitter with 1 blaster when only one spot is available close to the emitter. Sending out paratroopers is indeed very effective (I recommend it especially for section 3 of this map) and the extra fire rate is often not what you want then.

[close]

It does affect the ammo bar, only in a different way! When you look carefully it will jump from 90% to 100% when the last packet arrives (number 36 for a reactor), see here.

I meant health bar by the way, I just copied your words by mistake, but you probably got that....

BTW, are you up early, or just really, really late?

He's up really late... he's actually going to bed right now.

Ah. Understood. I myself am up quite late, but not quite as late as him! (local time 7:00 AM... wow... dedicated...)

Yeah, I was up very late and got so tired that I decided to answer after some sleep. Especially when I'm supposed to do some calculations that works a lot better. ;)

Anyway, I don't know how to make an equation of efficiency for this now, as there are too many factors involved... I'll try tomorrow (or, more accurately, later today). Actually, let me try.

[okay, let's take the original equation UpperKEES wrote: T = C/R + D/S; seems good, R needs to be tweaked; R = P/t, hmm what can I do with that, of course change production to supply (s), what would that imply, well we need production rate for that and somehow factor in storage, I'll represent these as p/τ and σ respectively (Greek letters are sexy), p being the collective production of reactors and collectors oh I'm so glad I read that post by Virgil, and τ being yet another incarnation of time; oh, time elapsed and depletion might also be useful, gimme a second, well it somehow comes out to time elapsed times production rate minus depletion rate (the latter two in parentheses), hmm is that right yeah according to the distributive property it is, now how does that relate to everything else, aha we take P - (supply mod P) to get this properly; what determines P, eh who cares]

Finished!

I would totally write out the LaTeX for this, but, alas, I am on a pitiful trial version of Pi Cubed for iPhone. Instead, I present to you this monstrosity:

T = C/(((P-(e(p/τ - d)) mod P) + P - (P mod (e(p/τ - d) - P)))/t) + D/S
(P is packets requested)

Heheh! :D Always nice to read things like this! It's rather complex however and I think you should just assume enough energy in store (enough energy collection at the moment of building the structure that is). If you want to take deficit and such into account, you should also be modelling the simultaneous building other units and that becomes very hard. The speed is influenced by the number of speed nodes and the distance between all nodes in your network (see quiz), so I think it really impossible to put the entire model into one formula that takes care of all exceptions. It's fun to try though! ;)

Now, have you been able to save that blaster in time? :P