[Resolved] How, if at all, should matches forcibly end?

[norfenstein]

It sounds like no one wants matches to have to forcibly come to an end. That naturally raises the question of how the game should be structured to obviate the need for it, which I think belongs in a new thread.

[janev]

No match should last indefinitely. It’s a poorly designed game that has no end.
The match should end when there is nothing more to be gained from playing on. If it’s resources of some sort then the game ends when the resources run out. If one teams resources run out the game ends abruptly and they are the losers.

If we are going for more of a deathmatch vibe then the game ends when the last person that needs killing is dead. It might be nice to implement something that forces people to not camp in a last man standing situation (for example a dude in a vent waiting for timelimit ), either as a voteable feature or as serverside tickbox.

[norfenstein]

Let's try to close this question. There appears to be a consensus that sudden death should not be a part of the game because the game should naturally come to a satisfying conclusion somehow. We realize that there will still be cases where this doesn't happen, so there should still be a timelimit set by the server operator but players should be able to vote to extend the timelimit indefinitely.

If you disagree, propose an alternate answer.

[Anomalous]

We already have options for extending the game time limit: players can do this by calling a vote, or an admin can set it directly.

Given a replacement for SD – let's just call it ‘endgame’ for now – it would be fairly easy to add a similar mechanism for delaying endgame; though I think that the game time limit should be increased by the same amount. (Possibly also one for starting it sooner, or just use the existing SD vote for that.)

Now, a question – do we want to be able to get back out of endgame in this way? E.g. if it started two minutes ago and we want to defer it by 10 minutes, should we get another 8 minutes of build time, or just say ”too late – we're into endgame”?

Should the resource depletion period, if we do that, be configurable? I'd say so – if somebody does want SD as is, then this could be set to 0. (I think that I'd leave this one as admin-only.)

[Viech]

Should the resource depletion period, if we do that, be configurable? I'd say so – if somebody does want SD as is, then this could be set to 0. (I think that I'd leave this one as admin-only.)

The resource depletion as proposed here starts at the very beginning of a match (since the resource generation rate R(t) is a function of the leveltime t). As soon as RGS don't produce any more resources (or rather a negligible amount per time) you can still build with the resources your team has left (also since there's no real sudden death you could always rebuild free structures, if there are any). I think R(t) should indeed be configurable by the server admin (why not as an actual function?), so servers that aim for shorter games can let resources run out more quickly, more abruptly, etc. (I like brackets.)

[janev]

If the total amount of resources is fixed at the beginning of the map why not have the admins just set that total number. Say the arbitrary starting resource number for <small map, with n players> is 500 per team. The admin can change the #500 to whatever they please.

Another way, which might be better is the have the starting resource total set as a function of the map size and the number of players, at the start of each game. Then the server admins can set a resource multiplier that scales the starting total by a certain percentage.

[Ishq]

Both the total available resources and the decay rate should be cvar controlled. 0 would mean that it uses the mapper's recommended settings, but server admins can override this with map configs.

[Viech]

Both the total available resources and the decay rate should be cvar controlled. 0 would mean that it uses the mapper's recommended settings, but server admins can override this with map configs.

If you're taking my RGS proposition as a basis for your argumentation then the decay rate should not be mapper controlled because the total rate at which a team generates resources already depends on a maps size (because the bigger it is the more RGS can be built on it). Since depletion doesn't need to be adapted to a map and directly influences game pacing it should only be modified by server admins. Giving mappers control over the initial number of build points also sounds like a bad idea to me because 1) it makes balancing the game much harder for us and 2) maps would be built on top of diverse expectations about the initial amount of resources and might turn out to be incompatible to our game if we ever decide on changing the resource logic.

[Ishq]

The rationale behind having map specific decay and value is that based on the size, pacing and required resources will change. Thus, it will be beneficial to set optimal values for each map rather than use a "one size fits all" solution. (only decent settings will be allowed on the main servers).

[Anomalous]

Definitely the latter: <base bp> + <base points per player> * <no. of players>.

Base BP should be defined per map, with a default value for maps for which it isn't set.