Abandon the build point recovery queue in favor of increasing build times

[Viech]

Related Problem issues: #23 #28 #60

A bit of background

TL;DR: The build point recovery queue in combination with a varying size build point pool is confusing, in addition to causing agreed-upon issue #28.

Many years ago we used to experiment a lot with the buildable resource systems (build points, power, limits). We tested changes in PvP dev games with experienced players almost every week. As far as I remember, the last thing I did was to re-introduce a Tremulous-like build point recovery queue. Since we have a varying size build point pool (whose size depends on the current number of drills or leeches), one confusing thing that can happen is that you must "recover" more build points than your pool can hold, leading to negative build points available for spending. This can happeny even if you have few or no structures left.

For educational purposes let me mention the following: There is another way in which build points can be negative: If your drill or leech gets destroyed, then you may have more active buildings than are covered by your build point pool. This results in negative build points available for spending regardless of whether there are also build points being "recovered" (these would only add to the available-for-spending debt). Only the build point difference between your pool size and the number of active buildings can cause buildings to shut down.

I do not want to discuss here further the fact that buildings shut down and you have negative build points for spending when your drills or leeches get destroyed and you have too many other buildings left. In fact, I have a very strong opinion that this is the only correct way to handle a build point pool whose size can vary throughout a match. The reason I mention it above is to highlight that all of this taken together is pretty confusing.

At this point, hopefully you will agree that having a build point queue on a pool of varying size is not the most elegant mechanic. One nasty side effect of this is precisely the issue discussed (and agreed upon) in #28.

Let me now explain why the queue even exists. Before we had it, you could instantly rebuild any structure that was destroyed. At that time, I thought that the momentum gain for destroying the structure (over and over) could make up for this. However, it turned out that destruction not also making an imapct on the playing field is frustrating. Even the player on the other side, who is constantly rebuilding, did not have the greatest experience. Thus, we wanted a mechanic to ensure that significant damage to an enemy base really is significant. The build point recovery queue was something that had worked for Tremulous towards the same cause, alas under different circumstances (a fixed size pool).

There is one more aspect to the build point queue, which makes it even more complex but which I actually like a lot: By decreasing the recovery rate throughout the game, we could replace the former "sudden death" mechanic (no building allowed after the 30 minute mark): rebuilding is never strictly forbidden but becomes much harder over time as it takes longer for lost build points to recover. This has resolved a metagame which I may summarize as "camp until sudden death". Ideally, when replacing the build point queue with another mechanic to prevent rapid rebuilding, this new mechanic would also implement such a "smooth" sudden death.

The idea

• Completely remove the build point recovery queue. Build points for destroyed buildables are returned immediately and in full.
• The cooldown after constructing a buildable is made constant (ca. 5s) instead of a fraction of the construction time.
• The construction time of buildables grows exponentially (e.g. doubles every 10 minutes) from their initial value.

Details:

• The initial construction time of buildables may be reduced slightly, in particular for core structures (non-defensive).

Scenarios

1. The game starts and you want to move the base

If uncontested, the move will be quicker as the cooldown between constructing buildables is low and buildables construct a bit faster individually.

If contested, the chances of a successful move increase for the same two reasons and because the builder can replace destroyed buildings without suffering a resource loss as long as the builder is alive. The attacking team will however gain momentum for destroying partial buildings while the moving team only gains it for completed buildings (minus the amount spent for deconstruction).

If successfully contested, the team that failed the move can attempt to quickly rebuild their main base and suffer no resource loss from the failed move; although they will be at a momentum disadvantage.

2. The game starts and you want to build a forward

Everything as for (1) applies. In particular, #28 is significantly alleviated.

3. In the early to mid game (mins 0–30), you lose a single structure

You can just rebuild it. Your enemy gained g_momentumDestroyMod/g_momentumBuildMod more momentum than you did (currently 33% more).

4. In the mid game (mins 10–30), you lose a bunch of structures

Your base is now vulnerable to a follow-up attack: while you can quickly queue up the rebuild commands due to the lower cooldown timer, the actual construction process will take significantly longer than before.

5. In the late game (min 30+), you lose a bunch of structures

You can schedule them for reconstruction at no cost but any building will take a minute or longer to complete, giving the enemy enough time to attack the weakened base again. Only if you can push back the enemy or when they are credit starved will you have a chance to rebuild. If it was a forward, it's probably gone for good.

6. In the ultra late game (min 45+), you lose a structure

Rebuilding would be quite a thing to pull off given that anything would need a few minutes to complete. But, you're free to try!

Notable side effects

• Whenever you have negative BP showing, it is now strictly because you lost a drill or leech but not much else, and the negative number is small. Reconstructing the drill/leech will get you non-negative again.
• The mechanics of "soft" sudden death are now clearly communicated to the player.
• That stupid text in the lower left UI corner can go.

Caveats

• With a straightfoward implementation, replacing/moving structures is affected. This can be problematic if in the late game someone decides to update the base layout. As the game knows when structures are replaced, it would be feasible to disable the longer construction times in this case.
• With decreased initial construction times and a low cooldown, aggressive forwarding could be oppressive in coordinated matches. (Though, moving the base to safety also becomes easier.)
• We must monitor how happy players are about destroying buildings in the midgame. It needs to feel significant. An easy approach would be to increase the momentum gain for this, while leaving the amount a team gets for construction at the current level or lowering it.

Request for discussion

With these kinds of ideas, the devil is always in the detail. I'm happy to hear about any other caveats you may think of. I might have a chance to implement this proposal in the coming weeks.

[illwieckz]

If we want to do that, we may need to be able to place many build orders at once, because the more you wait between placing buildable, the less you defend them, so the principle of defending buildables while they build would be defeated.

Edit: And the ability to switch weapons while the buildable is building would be needed.

[Viech]

we may need to be able to place many build orders at once

This already exists but the cooldown between placements is some fraction (60%?) of the last build time. With a ~5s constant delay you could queue a few things. You can already buy a weapon after that cooldown is over and switch to the blaster in the meantime (I think). That number can change but I would also not put it too low to prevent exploits (e.g. use blueprints as barricades) and "bad decisions in quick succession".

[illwieckz]

Another drawback of parallel building is that you could hack the momentum in very short time.

[Viech]

Another drawback of parallel building is that you could hack the momentum in very short time.

This proposal is not about parallel building, which already exists and would only be turned up a bit. Through building in general (parallel or not), you can only gain as much momentum as you have build points, minus your existing base. When you replace a building, you gain no momentum in total. When you deconstruct and then build, you first lose momentum (possibly going negative), then gain it back when the new building is complete. This has always been hack-proof. The only thing I would need to double-check is whether repeatedly building and destroying your own building gives momentum, but if that was the case then that would be very easy to fix.

[ghost]

The cooldown after constructing a buildable is made constant (ca. 5s) instead of a fraction of the construction time

This, at least, would make alien building A LOT less frustrating, special mention for the barricade which is barely useful and yet takes ages to be built.

The construction time of buildables grows exponentially (e.g. doubles every 10 minutes) from their initial value.

This, though, is a really, really good way to finish making barricades useless. And barricades are a rather important alien building. I guess one would say that anyway, the only useful alien buildings are: overmind, eggs and boosters, so maybe it's not that important.

Also, how is this "increased build time" being communicated to the player? One of the problems of the current mechanics is that there is a huge lack of information given to the player. We also do not have any way (like a proper tutorial) to teach players the consequences of good or bad building.

An easy approach would be to increase the momentum gain for this,

The more I think about it, the more I dislike the fact buildings impact momentum. It makes it very easy for a newbie player to feed enemy team momentum and prevent own team to gain momentum, so increasing this will make the game even more frustrating than it currently is. There is currently no way to know how much momentum feeding is given to enemy team, so the newbie is left with no real clue how much they're playing against their team.

Overall I am not convinced by this proposal. One is free to experiment with it though, but for such change it needs to be hosted on a separate server before being merged upstream.

[SeanScherer]

Also, how is this "increased build time" being communicated to the player? One of the problems of the current mechanics is that there is a huge lack of information given to the player.

I agree this is still a weakness. But unlike with slowing BP regen, at least players will see that buildings are taking longer to build (and can at least initiate construction, instead of having to wait around like a lame duck).

So, maybe not perfect, but in my view a serious improvement.

[SeanScherer]

There is currently no way to know how much momentum feeding is given to enemy team, so the newbie is left with no real clue how much they're playing against their team.

I feel this is a weakness of the current setup as well (compared to Trem's clear "die = feed the enemy" ). But I think it'd make more sense to open an issue for this specifically if you have strong feelings about it, rather than weave that thought in here...

[Viech]

The more I think about it, the more I dislike the fact buildings impact momentum.

I don't see why: Do stuff, gain a reward is a good recipe! Plus, arguably it's better to have the possibility to ruin your team's match concentrated on the builder. In trem where only kills mattered, you could not play the game at all without hurting your team as a newbe. Now, kills are only a part of the team effort that unlock stuff.

In either case, this is nothing my proposal changes directly. So please do not hold this against it.

Also, how is this "increased build time" being communicated to the player? One of the problems of the current mechanics is that there is a huge lack of information given to the player.

We would, instead of the percentage, display the time to completion on the building in construction. It should not be hard to learn that this takes longer later on; much easier that learning about build point queue rules anyway.

Please everyone stay on topic as much as possible. Ponder on whether your issue really is a consequence of my proposal or just something that it does not fix.

[sweet235]

If we do this: do we need build points at all? We could instead ensure that a team cannot build faster by having two builders instead of one builder, simply by increasing the build time accordingly.

[Gireen]

I like this idea. It fixes #23 #28 and most of #60

The problem of instant rebuilding at start and mid game is a bit mitigated by the rewards for building destruction.

The construction time of buildables grows exponentially (e.g. doubles every 10 minutes) from their initial value.

I guess this will be configurable. The option of an upper limit would be nice. Maybe also in a way that it could be later easily hijacked by lua to try alternative rules. eg change Buildtime in a curve or waves or have other factors influence it, like destroyed buildings, kills or momentum.

That stupid text in the lower left UI corner can go.

It should be replaced with Buildtime +x%

As the game knows when structures are replaced, it would be feasible to disable the longer construction times in this case.

Based on the "donator" buildings health probably. Additionally maybe also based on buildtime, that the speed can be only as fast as the building it replaces. Else one could start many slow constructions in base and then quickly move them to the front. But this probably needs some testing, maybe this could be a interesting strategy to create a building farm.

aggressive forwarding could be oppressive in coordinated matches.

finally we get some tower rushes 😀

[DolceTriade]

The reason I mention it above is to highlight that all of this taken together is pretty confusing.

Indeed.

All in all, I think the idea is very interesting.

I worry that the lack of flexibility in base movement will feel constricting. You basically have to pick where you want to move super quick, execute that move, and..be happy with it.

Some base moves just aren't viable until you have adv granger or jetpack and such. Having additional build time just makes those bases, no matter how fun or creative, simply unviable.

Do you think we can come up with a way to make the game dynamic (as its current implementation suffers from this as well) by adjusting details of this implementation?

(By dynamic I mean both teams have a fighting chance to win, and if they don't, one team will have the tools to quickly overpower the other and not drag the game on...)

[Viech]

The problem of instant rebuilding at start and mid game is a bit mitigated by the rewards for building destruction.

Just to clarify, these rewards are not new. I was just considering to maybe reduce the existing momentum gain for construction, or increase that for deconstruction, or both, to maintin a significant effect to early and midgame base attacks.

The construction time of buildables grows exponentially (e.g. doubles every 10 minutes) from their initial value.

I guess this will be configurable. The option of an upper limit would be nice. Maybe also in a way that it could be later easily hijacked by lua to try alternative rules. eg change Buildtime in a curve or waves or have other factors influence it, like destroyed buildings, kills or momentum.

The double time will certainly be configurable (as is the recovery half life time now). I can also add a maximum multiplier, which would further serve the purpose to make other approaches to endgame management (like @cu-kai's classic sudden death implementation) easier to toggle. Further, one could have a set-in time and have a multiplier of 1 before that (see discussion with @DolceTriade below). I'm not sure how I would hook something to lua; so for a start I would just implement the exponential growth and the named configurations.

That stupid text in the lower left UI corner can go.

It should be replaced with Buildtime +x%

Maybe it would be better to display the time to completion alongside the current multiplier when placing the building, similar to how we display drill/leech predictions. Less clutter on the UI and would in the long run allow feedback in scenarios were we possibly discount the build time (e.g. when replacing buildables).

As the game knows when structures are replaced, it would be feasible to disable the longer construction times in this case.

Based on the "donator" buildings health probably. Additionally maybe also based on buildtime, that the speed can be only as fast as the building it replaces. Else one could start many slow constructions in base and then quickly move them to the front.

That's a good catch (pre-building of structures in safe locations), though that solution does make it a tad more complicated and could be confusing for players.

---

I worry that the lack of flexibility in base movement will feel constricting. You basically have to pick where you want to move super quick, execute that move, and..be happy with it.

Some base moves just aren't viable until you have adv granger or jetpack and such. Having additional build time just makes those bases, no matter how fun or creative, simply unviable.

Given that advanced granger and jetpack unlock around the 10 minute mark, with my proposal the build time would only have been doubled at that point, and possibly from a reduced initial value. If this is still a problem, we could work with a set-in time: Maintain the initial build time for, say, the first 10 minutes, then start to increase it (possibly at a quicker rate).

Do you think we can come up with a way to make the game dynamic (as its current implementation suffers from this as well) by adjusting details of this implementation?

(By dynamic I mean both teams have a fighting chance to win, and if they don't, one team will have the tools to quickly overpower the other and not drag the game on...)

I think overall the difficulty of rebuilding with this approach would kick in more smoothly than with the old approach, where the magnitude of the negative BP punishment is hard to predict (it depends on the size of the base lost). One difference that goes into the direction you mention is that the overmind would be affected at all: Currently you can constantly rebuild it rather quickly regardless of how few BP you have left, and as soon as it is up you just need to afford one egg, which may require a leech drop or two. With the changes, you do not need a leech but the Overmind and egg will take longer to complete, which will give humans more time to find them and end the game. For humans, the situation will be unchanged: They cannot run and rebuild.

I have to think about this more but ultimately the very idea behind this proposal is that the game is forgiving early on but will push a decision in the late game.

[Viech]

I've started with an implementation. I noticed two more side effects:

1. On the positive side, sniping of drills and leeches in the mid to late game would have a larger effect, as buildables would be powered down for longer. Currently, destroying these buildables in the late game is not very effective as they are the only structures apart from the main building that do not suffer from the build point recovery queue.

2. On the caveat side, it is no longer obvious how deconstruction of buildables under attack is supposed to function. Currently, you gain the build point fraction corresponding to the buildable's remaining health immediately while the missing health fraction is added to the recovery queue. With no queue, a straightforward implementation (SI) of the proposal would allow deconstruction or replacement of buildables at any health.

Note that, from the view of the attacker, it is already possible that a building you have almost destroyed is replaced, which is of course anticlimatic. This scenario is only made more likely by an SI.

I am considering two solutions to caveat (2):

1. Add g_deconHealthFraction: A value of 0.0 corresponds to the SI: You can deconstruct or replace anything anytime, effectively lowering the attacker's momentum gain. A value of 1.0 only allows deconstruction of undamaged buildables (in particular, marked build points are not available while the marked building is damaged). A value of 0.5 would allow only buildables above half health to be deconstructed or replaced.

2. Disable deconstruction/replacement within g_deconDisableTime seconds after a buildable took damage.

In theory, both solutions could be implemented alongside, though I would lean towards enabling only one by default.

[slipher]

If I understand correctly, the only difference between deconning and destroying a buildable under this proposal would be that destroying awards momentum to the attacker (*). So you could solve thing (2) by giving momentum proportional to (1 - health fraction) to the attackers when a buildable is deconned.

Or is the problem purely that the attacker doesn't get the sense of satisfaction of seeing a destroyed building? Maybe the destroyed building beacon could be displayed for a low-health deconned buildable.

One slightly annoying side effect of the proposal is that spamming undefended RGS in unpopulated areas of the map would work even better than it does now. With a 5s construction cooldown it may even take longer to destroy them than to build them.

(*) Actually I recall a pull request a few days ago to give credits to the attacker also; don't remember what happened with that.

[Viech]

So you could solve thing (2) by giving momentum proportional to (1 - health fraction) to the attackers when a buildable is deconned.

This is already the case:

static void G_Deconstruct( gentity_t *self, gentity_t *deconner, meansOfDeath_t deconType )
{
    // …

    // reward attackers if the structure was hurt before deconstruction
    float healthFraction = self->entity->Get<HealthComponent>()->HealthFraction();
    if ( healthFraction < 1.0f ) G_RewardAttackers( self );

Or is the problem purely that the attacker doesn't get the sense of satisfaction of seeing a destroyed building?

Kind of. For a start it is not obvious anymore what should precisely happen in the scenario. Previously, there was a smooth transition both between getting full and no momentum reward for destroying, and between having all to no build points enter the queue upon deconstruction. With no queue, it is not elegant anymore to reduce the marked-build-point-value of structures depending on their current health (as the build points are fully returned upon descruction). And if we do not reduce it, which I believe is the cleanest solution, then, yes, attackers are just more likely to see a building they are attacking replaced. So essentially I want to make it again less likely (or impossible) that this happens.

One slightly annoying side effect of the proposal is that spamming undefended RGS in unpopulated areas of the map would work even better than it does now. With a 5s construction cooldown it may even take longer to destroy them than to build them.

That is partially true. The running around and spamming as such can be done faster, yes. But, the punishment for losing the structure is unchanged: Destroying the thing already yields more momentum than building it and buildings supported by it continue to power down. Further, no build points enter the recovery queue both before and after the propsal since drill and leech cost no build points to begin with. So I think this is only a minor regression in the sense that one has to wait just 5 seconds as opposed to currently, I believe, 6 seconds between placements.

The problem you mention, I find, is nicely addressed by limiting the number of drills and leeches that can be built, as done on the popular server.

[Viech]

The only thing I would need to double-check is whether repeatedly building and destroying your own building gives momentum, but if that was the case then that would be very easy to fix.

This is indeed the case: you lose the same amount of momentum for deconstruction as you will re-gain for reconstruction, but so far no momentum is subtracted for destroying your own buildings! This is more serious under the proposal as no build point penalty is issued. This will be fixed in my implementation.

Edit: Already in the current game state it is possible to first deconstruct your base with no resource punishment at the very start of the match (momentum is capped at zero), then rebuild the same structures to obtain additional momentum. I will keep this exploit in mind and try to fix it in passing. Edit 2: Turns out the momentum cap at zero was intentionally added, so I will not change this as part of my implementation.

[VReaperV]

There should probably be a way to turn the increased build time off per-map/per-layout for PVE maps/layouts since they often require building. It wouldn't have much impact currently because spamming firebombs allows for a quick completion of the existing PVE maps, but if/when that gets fixed this change would significantly affect balance on those maps (it also would affect alien vs human PVE regardless).

[Viech]

There should probably be a way to turn the increased build time off per-map/per-layout for PVE maps/layouts since they often require building.

Noted, will add some per-map/worldspawn configuration options.

[cu-kai]

There should probably be a way to turn the increased build time off per-map/per-layout for PVE maps/layouts since they often require building.

Noted, will add some per-map/worldspawn configuration options.

Generally these maps require many cvar changes, so we prefer to use mapconfigs for them. I even provided a template for operation-dretch when I posted the release on the forums.

I don't think adding these worldspawn flags is a huge priority.

[ghost]

(*) Actually I recall a pull request a few days ago to give credits to the attacker also; don't remember what happened with that.

There were 2 PRs. One to make this an opt-in option, a long while ago (was in for 0.53's lifetime). This way, server owners could use it. After months of usage, a second proposal to have the value used by servers maintainers in vanilla was done, and merged. Fairly recently, yes, so not in any release.

[Viech]

A possible default configuration, with "smooth sudden death" setting in around minutes 25 to 30:

Grace period:  5.0 mins
Double time:  10.0 mins

         Armoury  Barricad      Acid  Overmind
        Medistat     Drill   Booster   Reactor
        Telenode     Leech       Egg          
                  Machineg      Hive          
                   Trapper    Rocket          
                              Spiker          
Minute  
     0     00:08     00:10     00:15     00:18
     5     00:08     00:10     00:15     00:18
    10     00:11     00:14     00:21     00:25
    15     00:16     00:20     00:30     00:36
    20     00:23     00:28     00:42     00:51
    25     00:32     00:40     01:00     01:12
    30     00:45     00:57     01:25     01:42
    35     01:04     01:20     02:00     02:24
    40     01:31     01:53     02:50     03:24
    45     02:08     02:40     04:00     04:48

Note the grace period in response to @DolceTriade's point about delayed base moves and the reduced initial construction time of the barricade (previously 20s) in response to @bmorel's points.

Configuration of initial build times is possible via buildable config files (as before) and the following three cvars would control the time dynamics:

• g_buildingCooldown (controls parallel building; default 5s; see discussion with @illwieckz)
• g_buildTimeDoubleTime
• g_buildTimeGracePeriod
• g_buildTimeMaxMultiplier (in response to @Gireen)

Small balance changes I'm looking to throw on top to boost (human) forward viability further (#28; in addition to reduced initial build times for utility structures):

• Medistat costs 6 BP (from 8).
• Rocket pod costs 12 BP (from 10).
• 60 BP budget per miner (from 50).

Additionaly, I would boost the Overmind's health and regen both by 16.7% (to 875/7) as its destruction in the mid to late game will be much more significant (#23).

Communication of the dynamics (HUD changes) are best showcased in a test match.

Edit: Corrected old barricade build time; was 20s instead of 15s (now 10s initially).

[Viech]

First testable version with above defaults: mod-buildtime_0.1.dpk (buildtime branch).

[Viech]

Release build with debug info (instead of debug build) to work around server lag issues: mod-buildtime_0.1.1.dpk.

[illwieckz]

There is now a demo server named buildtime testing running at:

• https://play.unvanquished.net/unvanquished.net:27970

[ghost]

It's running in debug build though, makes it pretty unplayable.

[Viech]

<@sweet235> i wonder if we should keep the build time of reactor/overmind constant

Exceptions or per-building growth functions are certainly possible, though at this time I'd like to test the KISS version of this.

I find that for the Overmind in particular, having significantly larger construction times in the late game may be a good thing (see #23). In a recent match on omega-core, a map with short distances between the bases, humans destroyed the Overmind three or four times but with very little effect overall, it was essentially rebuilt on the next attack wave. I think it would feel more natural to both teams if destroying it was harder (hence the health/regen increase of $\frac{1}{6}$ each) but significant—similar to the Reactor. Note further that on the current buildtime branch the initial construction time for the OM is reduced from $30 s$ to $18 s$ (Reactor: $20 s$ → $18 s$) so that its original construction time is only reached after $\approx 12$ minutes.

For the Reactor, I think that not much changes because it is already hard to kill without removing defenses first and rather significant if it goes down. Maybe it will be targeted more as a result of these changes but in the median match you will probably not feel it. If this turns out to be a problem, having the armoury be always powered would be another approach to balancing.

[VReaperV]

For the Reactor, I think that not much changes because it is already hard to kill without removing defenses first and rather significant if it goes down. Maybe it will be targeted more as a result of these changes but in the median match you will probably not feel it. If this turns out to be a problem, having the armoury be always powered would be another approach to balancing.

I think the biggest difference here is that aliens mostly rely on tons of eggs with swarms of aliens for defense, while disabling human defensive buidlables makes humans a lot more vulnerable since they're stuck with rifles, spawn cooldowns and the armory/medi potentially getting destroyed.

This, however, is mostly a result of a poorly constructed base or one that was severely damaged and is not being defended properly. I think this might be part of a reasoning to give builders more information on defensive structures coverage/blind spots, but that's out of scope for this issue.

[ghost]

humans destroyed the Overmind three or four times but with very little effect overall, it was essentially rebuilt on the next attack wave. I think it would feel more natural to both teams if destroying it was harder (hence the health/regen increase of 1/6 each) but significant—similar to the Reactor.

Problem is, OM is very vulnerable to a painsaw+jetpack attack, while RC is vulnerable to... well, nothing, it was always better to ignore it in the games I did those months.

[Viech]

humans destroyed the Overmind three or four times but with very little effect overall, it was essentially rebuilt on the next attack wave. I think it would feel more natural to both teams if destroying it was harder (hence the health/regen increase of 1/6 each) but significant—similar to the Reactor.

Problem is, OM is very vulnerable to a painsaw+jetpack attack, while RC is vulnerable to... well, nothing, it was always better to ignore it in the games I did those months.

I agree with that. Though I'd like to see how much of an issue this is with the changes, and then rather make the OM stronger than easier to rebuilt.

[Viech]

The changes have been tested for roughly two weeks now, both with my initial settings and some adjustments by @sweet235 (grace period 5 → 10, double time 10 → 7.5, medistation unaffected).

The first response appears positive overall, most people seem to at least prefer it over the old system, but it's clear that adjustments are necessary to deal with any regressions introduced. The following cricitism/problems were raised to me:

1. Losing the Overmind in the mid to late game is too punishing.
2. Losing the Medistation (and Armoury) is too punishing.
3. Overall the system is not punishing enough, still allowing for long games. (In particular before the above mentioned adjustments.)
4. The increase in build time is too concentrated, leading to a wait-for-sudden-death sentiment. (In particular after the adjustments.)

I think that points (1), (2), and (4) can be addressed effectively, point (3) is a bit conflicting and will likely not be solved by building limits alone (in particular the system cannot kick in when players do not succeed in destroying structures).

What I will try to accomplish before a second phase of testing is the following:

• Reduce the effect of the changes on some critical buildings, i.e. slow down or limit their build time increase. I will look to do this in some general fashion that is configurable, not with fixed exceptions.
• Smoothen the transition so that players need to worry a bit less about the clock and feel more inclined to attack before minute 20.
• A lot of people are exhausted by 60 minute games, so while (4) is a valid concern, making rebuilding of defenses hard after minute 30 (not feasible under frequent attacks) and really hard after minute 40 (not feasible under occasional attacks) remains a goal.

[illwieckz]

At first I was afraid that buildTime change may discourage to try to rush the attack in fear of losing the ability to build a good base later, but after some games played, it looks to me that the current time delays seems to be large enough for a team to try to rush the attack and if that fails, start building.

About the increased build time itself, I join a game after 30min once, building was indeed slow, but I didn't feel frustrated by it. So that's a good point to me.

Losing the Medistation (and Armoury) is too punishing.

Yes, I played a game on Orion where, once we lost the medistation, we lost it forever, because it was systematically destroyed with a single hit before building was completed. Aliens had time to die, come back from alien base, and zap the human base only once to make sure the medistation would never be rebuilt.

[Viech]

So, one could of course just upper bounded the build time of certain crucial buildables, which is straightforward, but this seems a little bit artificial, complicates balancing (at least when the upper bound is limited to matching the lower bound, which has been proposed), and does not play so nicely with the existing cvars (in particular changes to the build time double time do not affect this). I did test this approach locally for many different values but frankly I don't like it; it doesn't feel clean and the configuration options and their interaction are confusing to me.

Instead I would like to test in the second phase the following solution to the points above: One may multiply the build time double time for any building with any factor. This has a very signficant effect (in particular, one may recover static construction times by using a sufficiently high value) but it is smooth and plays well with the other settings.

As a reminder, here are the changes tested originally (before @sweet235 adjusted some of them to hotfix issues):

Grace period:  5.0 mins
Double time:  10.0 mins

         Armoury  Barricad      Acid  Overmind
        Medistat     Drill   Booster   Reactor
        Telenode     Leech       Egg          
                  Machineg      Hive          
                   Trapper    Rocket          
                              Spiker          
Minute  
     0     00:08     00:10     00:15     00:18
    10     00:11     00:14     00:21     00:25
    20     00:23     00:28     00:42     00:51
    30     00:45     00:57     01:25     01:42
    40     01:31     01:53     02:50     03:24
    50     03:01     03:46     05:39     06:47
    60     06:02     07:33     11:19     13:35

Now, I'm pondering the following defaults for the second round of testing:

Grace period:      0.0 mins
Base double time: 10.0 mins

Factor       3.0       2.5       1.5       1.5         1         1
        Overmind   Armoury  Telenode   Booster      Acid      Hive
         Reactor  Medistat                 Egg  Barricad    Rocket
                                                   Drill    Spiker
                                                   Leech   Trapper
                                                Machineg          
Minute  
     0     00:18     00:08     00:08     00:15     00:10     00:12
    10     00:23     00:11     00:13     00:24     00:20     00:24
    20     00:29     00:14     00:20     00:38     00:40     00:48
    30     00:36     00:18     00:32     01:00     01:20     01:36
    40     00:45     00:24     00:51     01:35     02:40     03:12
    50     00:57     00:32     01:21     02:31     05:20     06:24
    60     01:12     00:42     02:08     04:00     10:40     12:48

Here are my thoughts:

• First and foremost, having no grace time but a reasonably high double time is necessary to address point (4) above. Starting the increase late and at a faster rate, which @sweet235 tested to prevent 60 minute games, is being played like sudden death and was criticised (even ridiculed) and also exploited (dedicated, full-on camping to try to end with a single attack) by players.
• The Reactor almost never dies earlier than the base, so let's talk about the poor Overmind being naded or sawn to death. Its vanilla build time of 30 seconds is now reached after 20 minutes, so the midgame balance is as you know it. It does increase further from there on, because we do not want 60 minute games as a norm and balanced weak spots are fun and fine, but it only reaches a minute in the ultra late game and never goes to ridiculous values as before. Making the OM harder to kill is still on my list.
• If I had set an upper bound on the Armoury and Medistation build time it would've been maybe around 25 seconds. Having it remain at 8 seconds or similarly low values throughout the game would mean that it would almost never be a viable target while we do want to allow both for weak spots and for flexible alien decision making. Nevertheless, the build time never goes so high that one could not rebuild it with a brief (!) period of camping.
• Telenodes and Eggs are much less of an issue: When they are lost and can't be rebuild then the game just ends, and we do want games to end. I've still reduced the extreme build times that could be seen in version 1. This affects mostly minutes 30-40, during this time a rebuild was previously almost out of the question and is now doable.
• The Booster is just treated like an Egg for the time being as I've heard little criticism on it particular and it's not too difficult to rebuild it in a hidden place. Aliens also don't need much else in the late game so I find it justified to render it a value target.
• For miners and defensive structures, I've streamlined and reduced the initial build times (unlocked from start: 10 seconds, unlocked later: 12 seconds) to keep them in a similar time range throughout the game. For them we want to complicate rebuilds in the mid game (otherwise no point in attacking) and outright prevent rebuilds in the late game (otherwise games might not end). This is the core of this proposal and what people seemed to like in general. Without the grace period, rebuild difficulty increase is now shifted five minutes earlier, addressing the sentiment related to point (4) that attacks in the midgame matter to little.

[illwieckz]

I just notice that aliens have 3 buildables with max time, while humans 1, maybe Spiker and Trapper can be like Acid and Mgturret ? Spiker and Trapper are very weak anyway. i.e. basetime to 00:10.

[Viech]

There is now a branch viech/buildtime/v2 that has the build times from the above table in addition to showing completion times in the beacon info for friendly buildables.

(Make sure to reset related cvars if you want to test the new proposal as intended.)

[Viech]

In addition to the updated build times outlined above, viech/buildtime/v1...viech/buildtime/v2 adds the time to completion for friendly buildables to the beacon info display and prevents an overflow that resulted in instantaneous building if the double time was set very low.

[ghost]

Pardon me to not read the walls of text since my last intervention here. I just want to give some feedback on the current experiment status here:

The whole mechanics makes it pointless to attack early, and encourages camping in late game as one really don't want to loose the (slowly) building last (or 2nd) spawn point. I've also noticed that boosters, medis and armouries not being affected are of a medium interest. Sure, they are necessary to play, at least armoury, but I question that for the healing tools. Plus, the static build time applies to even secondary or tertiary ones, which is a real problem imo.

If I may propose an idea, I would only apply this static build time to the really critical building: OM, RC, and armoury. And for armoury, only if it's close enough to RC and to limit it for the 1st.

I do not consider medistation or booster are vital to play: they only heal or give poison/medipack. Aliens can still heal everywhere (which is actually very annoying) and rather fast is they group (as fast as a booster can provide). As for humans and medistat, we could easily make the medistant provide gratis medipack, but also make it purchasable in armoury for a small fee (say, 50¤). This, I think, would make the destruction of buildings much less pointless.

Overall, and with the current games I played on that mod, I have a mitigated opinion. At 1st, I didn't liked it much, then I loved it after 1st game but this might be because of the HUD improvements it brings (yes, knowing there's no spawn, no RC/OM, RC/OM up in XXs, time to complete a building are very useful additions which could apply to current official gameplay) but now I'm mitigated because despite the simpler gameplay, I feel the game is more campy than ever.

I think it would be nice to at least merge the HUD improvements to the current gameplay.

[Viech]

I would like to differentiate here between my v1 (roughly first week of testing), @sweet235's adjustments (roughly second week of testing, let's call it v1.5) and my v2 (not tested yet).

My v1 had 5 minutes grace period and a 10 minute half life time for everything. You can see the effects in the first table in my last post. It did not have any exceptions (i.e. static build times).

At some point @sweet235 excluded completely OM, RC, Arm and Medi from this logic as he found it too punishing to have high rebuild times on them even for a test. (I agree that these were too critical targets in v1, deciding some matches on their own.) Additionally, @sweet235 found that there were still long games and tried to make the transition more aggressive by delaying it (10 minutes grace period) but with a significantly reduced half life time (7.5 minutes). I think that these values backfired in the sense described in my last post. People now feel that there is a "sudden death timing": Due to the delay (and the hard exceptions for some buildables), rebuilding appears to be too easy in the midgame, rendering attacks ineffective, and then becomes very hard rather abruptly.

TL;DR: The current campyness might be a result of adjustments which are not an integral part of this proposal, and which I have already addressed in v2. One should not hold this against the proposal as such.

In v2, which was not yet tested, I think that I have learned both from my own errors (not special-casing critical buildings) as well as from @sweet235's adjustments, which I believe had the best intentions but went in the wrong direction by making the system more abrupt as opposed to more smooth. So I propose now (and please do refer to my last larger post for details, this paragraph is not comprehensive) to return to a 10 minute half life time but start the increase immediately. This will make (early) midgame attacks significantly more effective than they are now. Also, I see full-on exceptions for certain structures as a hotfix, not a good permanent solution. Allowing structures like Arm and Medi to be rebuild within 8 seconds at all times (with no BP punishment as before) is clearly not what was intended as this makes these structures never a viable target. The proposed v2 allows fine-tuning the double time on a per-buildable basis and has its initial defaults outlined in the second table of my last larger post.

[ghost]

But does not making too much fine-tuning per building make the game more complicated anew?

[Viech]

But does not making too much fine-tuning per building make the game more complicated anew?

If this gives good gameplay, we can live with it. We're replacing here a system which was specifically hated for being hard to predict and understand and punishing in the wrong ways. I had preferred a very simple solution, hence my v1, but it is now obvious that this is not sufficient. I've also tested heavily upper bounds but these are actually not simpler nor more elegant than a smooth increase for everything.

Not to mention, people want configurability, and this framework provides that.

[Viech]

You can read the following post without having followed the discussion so far. You can respond using another channel if you have no GitHub account and I will forward this here.

---

We need more input on this proposed build time table, which aims to replace the build point recovery queue (i.e., build points for lost structures are available immediately):

Base double time: 10.0 mins

Factor       3.0       2.5       1.5       1.5         1         1
        Overmind   Armoury  Telenode   Booster      Acid      Hive
         Reactor  Medistat                 Egg  Barricad    Rocket
                                                   Drill    Spiker
                                                   Leech   Trapper
                                                Machineg          
Minute  
     0     00:18     00:08     00:08     00:15     00:10     00:12
    10     00:23     00:11     00:13     00:24     00:20     00:24
    20     00:29     00:14     00:20     00:38     00:40     00:48
    30     00:36     00:18     00:32     01:00     01:20     01:36
    40     00:45     00:24     00:51     01:35     02:40     03:12
    50     00:57     00:32     01:21     02:31     05:20     06:24
    60     01:12     00:42     02:08     04:00     10:40     12:48

In short, the OM/RC build times would double every 30 minutes, Arm/Medi every 25 minutes, Booster/Egg/Telenode every 15 minutes, and that of defenses every 10 minutes (from reduced initial values).

The current test on the Map Testing server has (as a hotfix to my first version where all build times doubled every 10 / 7.5 minutes) set constant the build times of OM, RC, Booster, Arm and Medi at their new minimum times. This means that the OM rebuilds in 18 seconds throughout the match (as opposed to normally 30 seconds) while Arm and Medi rebuild at 8 seconds (from 10) and with reduced consequences (lost BP are not queued any more). This is arguably quite the opposite of what I intended with this proposal. Thus, I would really like to test the above second proposal. The reason this is not available for testing yet is a feedback deficit and the fear that players (like you) may still be alienated even by moderately increased build times for the mentioned buildings.

So your quick assessment of the above table will be very useful. It is sufficient to either LGTM or propose concrete changes to the initial (minute 0) or doubling times or to otherwise comment on the proposed timings quantitatively.

Please refrain from alternate approach proposals at this time, as the above is already implemented and ready for testing.

---

Optional-to-read notes:

• These values can be fine-tuned using config files/cvars after the changes are potentially merged but sensible values are required already now so that the test may be maintained for some time.
• The increased build times are supposed to help end matches before they get tiring. Players generally report this between minute 20 and 60.
• Build times are not meant to end matches on their own (they cannot have an effect when buildings don't die!)
• Players should (imo) feel incentivized to attack structures throughout the game (for momentum, to remove them, or both). We should avoid a phase where players feel that attacks are pointless.
• The above table is designed such that destroying for momentum fades into destroying for removal around minute 20.
• My earlier post gives additional background.

[VReaperV]

I don't think making armory take almost a minute to build later on is a good idea, since the alien team doesn't need any additional building (other than the overmind/reactor for both teams) to get upgrades. I guess the reasoning is to make it more rewarding, but the same can be achieved by destroying the reactor, while there's no such alternative to stop aliens from evolving.

[sweet235]

I don't think making armory take almost a minute to build later on is a good idea

On the other hand, you demostrated how a wall of armouries can be used to great effect during the endgame.

Please refrain from alternate approach proposals at this time

So I should not propose my own solution for this.

[ghost]

The reason this is not available for testing yet is a feedback deficit and the fear that players (like you) may still be alienated even by moderately increased build times for the mentioned buildings.

The reason for lack of testing of your initial proposal is that you hosted an unplayable debug build, on a server which runs the vanilla bots and only official maps, which are far from being the preferred maps of players, if I remember correctly.

or propose concrete changes to the initial (minute 0) or doubling times or to otherwise comment on the proposed timings quantitatively.

Please refrain from alternate approach proposals at this time

That's an interesting thing to read. Nonetheless, I'll do my proposal: only get the 1st armoury immune to build time increase, or at least max it out. This idea does not just comes from me, but from the many discussions we had in real games. Of course, you could argue that I'm disobeying your instructions (no alternate approach proposals) but OTOH if you seriously expect players to read github, I don't know what to think. At the very minimum, this message should be mirrored on our official forum, as should probably be all this gameplay tracker. Yes, we do have more chances that people read the forum than this.

Also, it would be possible to use the "news" section of the updater to display that kind of proposals, to make players actually aware of what's going on.

But, I'm out of topic, here, sorry for that (but I still felt like this had to be said: feel free to open another "gameplay issue" or even another tracker for that).

[Viech]

You can both tell me your alternate proposals on IRC, I take no issue with that. But you should know from experience that, when they were put in here now, your alternatives could easily derail an already unwieldy discussion from a question that I'm strongly interested in. Honestly, already the amount of effort I put into this question as such should allow me to focus the discussion just briefly. Not to mention it additionally took a few hours to come up with this particular approach (it was not my first idea), implement it, design the initial table, and write the other post that carefully explains, even defends, every choice I made. For all this I'm just asking for this idea to briefly stand in the spotlight, so that I can use the feedback to ensure it is even testable.

[Viech]

I don't think making armory take almost a minute to build later on is a good idea, since the alien team doesn't need any additional building (other than the overmind/reactor for both teams) to get upgrades. I guess the reasoning is to make it more rewarding, but the same can be achieved by destroying the reactor, while there's no such alternative to stop aliens from evolving.

Do you have different timings in mind that you would find acceptable?

By "almost a minute", I assume you are referring to the 42 seconds at minute 60? I was considering 60 minutes into the game a time at which the match is already overdue to end, as this is the largest time I heard as a threshold for players getting burned out on a single match.

Another thing to maybe keep in mind is that around minute 50 you pretty much cannot rebuild defenses anymore, so having redundant arms and medis could be a common sight in the very late game.

[VReaperV]

Do you have different timings in mind that you would find acceptable?

I'd say halving the rebuild time for it (making it 0:21) would work fine.

Yes, that's what I was referring to. I agree that a match should already end at that point, but a long armory rebuild time gives a considerable advantage to the alien team. Aliens would only need to destroy a building that has much less HP than overmind or reactor in order to stop humans from using upgrades for at least 42 seconds, and furthermore even a dretch would be able to halt the attempt at rebuilding by destroying the armory while it's being constructed.

It's true that you can build multiple arms, but I basically never see that in real matches. I don't think a human base with multiple arms is really feasible, as it relies more on defensive structures, multiple arms without much defense will just get destroyed easily.