Resources

[Ishq]

1. I would prefer that funds earned from killing be limited upgrading yourself. I'm not particularly a fan of having individual players spending their funds to upgrade their base. That puts a direct relation between the number of kills you have and the potential strength of your base. However, depending on popular opinion, I would not be totally against base upgrades.

2. As long as the metrics further explored in question 4 are in play, it does not make sense to have stage upgrades be permanent. In fact, an interesting suggestion I've heard tossed around is only allowing one team to have stage 3 to really finish off the other team.

3. No player upgrades should be permanent. I can see a potential argument that doing so will encourage camping because players will be less willing to rush, however, I don't think this game should be based around "swarm" rushing (which means rushing continuously and constantly without any tactics or teamwork). Permanent upgrades (assuming trem-like weapon/armor upgrades) facilitate this.

4
Resources vs Build Points: Another interesting debate which needs to be decided. Resources emphasize holding onto a location for a long period of time and rewards a team accordingly for holding onto a location for a long period of time because when a team holds onto a location for a long time, they will continuously get resources from it. On the flip side, resources means that teams are not penalized as hard when long standing RGS's are destroyed because they do not immediately lose the resources mined from them. Build points, on the other hand, emphasize keeping the RGS's alive. The length of time alive is not important as build points are received immediately after building and lost immediately after the RGS is destroyed.

Personally, I favor the resources approach. It allows a team that is consistently winning maintain its lead as opposed rapid changes in positional advantage based on random lucky strikes against weakly or undefended resource sites. It allows the the team to attack harder without needing to constantly fear the safety of the outer based.

Next, upgrade should be received in groups, much like stages in Tremulous. Receiving them individually could be interesting, but as stated above, there is really no coherent way to decide on this in a public game.

Stages would be determined by the number of RGS built at any given time. As this number can go up or down, stages can be gained or lost. The number of RGSs will be based on the number of players on a team.

[Cadynum]

I don't have time to read through this thread right now, but i just want to chip in with something I think is very important: The way you gain and spend all kind of resources should make sense.
Examples:

• Artificial constraints like you only get resources if you kill an enemy a certain distance from your base does not make any sense at all and is likely just a way to mask a larger design problem, like in this case not rewarding being aggressive enough.
• 9evo/2000credits limit - Tries to mitigate a design problem. The underlaying problem should be fixed instead.
• The game should not, mario cart style, try to help the bad players. A small example of this in tremulous is "camper evos".
• Sudden death
• Discrete stages

Credits from killing
I don't think you should get credits from killing, it only deters aggressive play. The one who dies already loses resources in form of evos/credits, and that's bad enough. It also does not make any sense for humans to get material to build weapons from when they kill an organic species.*

Pooled resources
This is something I think could work very well in clan games. An option to enable it if the team wants to would be welcome.

Don't allow customization that's not needed
Cvars are not a way to avoid making design decisions. There should never be cvars for things like build points, enable/disable dodge etc.
A lot of pointless cvars could also be removed, like gravity.

• Aliens get biomass though!

[norfenstein]

The way you gain and spend all kind of resources should make sense.

If by "make sense" you mean "be realistic" then I'd say that's exactly the opposite of how you should design a game that isn't a simulation. Aesthetic justification can always be found ex post facto and, while very important, should always be subordinate to mechanical gameplay (assuming that fun is your primary goal).

You say,

only [getting] resources if you kill an enemy a certain distance from your base does not make any sense at all and is likely just a way to mask a larger design problem, like in this case not rewarding being aggressive enough.

but immediately following the IRC discussion that brought this up several people conceived of in-world explanations for it, so it certainly can "make sense" in that way. And your point about it possibly masking a larger design problem isn't explained thoroughly enough to respond to, but I'm guessing it comes from:

I don't think you should get credits from killing, it only deters aggressive play. The one who dies already loses resources in form of evos/credits, and that's bad enough. It also does not make any sense for humans to get material to build weapons from when they kill an organic species.

To the second point: we have creative people that can explain why this should happen in the game world. Perhaps something cyberpunk about humans being mercenaries and getting paid by an amoral corporation. It's largely off-topic for this sub-forum (we should probably dedicate a future thread to what tone Unvanquished should aim for, but finishing the gameplay design is more urgent).

To the first point I'm more sympathetic, but I think we'll have a hard time coming up with a better system*. I don't think removing the RPG element of individual "leveling-up" is something we'll want because it's a huge part of what makes games like this fun. It doesn't have to be primarily based around killing enemy players, but I'm having a hard time thinking of what else it could be tied to that wouldn't cause worse side effects. We do need to justify our gameplay decisions, but doing so depends on having a set of axioms that will necessarily be arbitrary ("this is fun, we should design a game around it"), and I suspect this might end up being one. If that's the case then things like fund limits or only earning funds away from your base could very well "make sense" mechanically.

* The game should not, mario cart style, try to help the bad players. A small example of this in tremulous is "camper evos".

Agreed. That was very much the result of an unfortunately fundamental design flaw in Tremulous.

• Discrete stages

You're going to have to explain your thoughts on this.

Don't allow customization that's not needed
Cvars are not a way to avoid making design decisions. There should never be cvars for things like build points, enable/disable dodge etc.
A lot of pointless cvars could also be removed, like gravity.

Absolutely agree.

*The best I could come up with is to make player "upgrades" free (and unlocked via map control). They would not strictly make a player stronger, just open up more options to exploit (so a team without access to most of them would not be at an absolute disadvantage). This loses the RPG element of individual powering up.

[Viech]

I'm going to elaborate on my original approach, so please read it first before your process this post.

Viech's post is almost exactly how I personally think Unvanquished should handle building. Some differences:

• Build point refunds - I know this is fairly common in strategy games, but I dislike partial refunds for moving or replacing structures. I would much rather there be no extra punishment for misplacing a structure (if it's misplaced you're already suffering from it not being optimally effective, and will have to waste time building another structure), or simply a time penalty for deconstruction.

• Structures can only be built near a RGS - I don't see much value in restricting where structures can be built (other than the RGS themselves). It makes some sense if you want structures to depend on a power source so that they become disabled when it's destroyed (thus giving bases/outposts a "weak point" to attack), but I think it's more fun if builders can simply place things anywhere (Gloom did this).

• Different starting build points or generation rate for different teams - I strongly feel this is something that should not differ between teams.

Regarding the build point refunds, I'm ok with setting the default ratio to 1.0. I'm still not to happy with a building strategy where you constantly build structures at the front, paying them by removing buildings closer to your own base. It seems to efficient for resembling a default strategy on UBP servers ("attacking" by building turrets in front of turrets until you reach the enemy base). For that reason I'd like to make the ratio a variable so we have the option to tweak it slightly below 1.0 later on.

Being able to build structures anywhere sounds fun, let's do it that way! If you decide to build "defensive" structures at the entry of the enemy base that might support an aggressive strategy while putting your team at the risk of loosing a lot of build points (the enemy team can easily destroy these structures if they manage to exit their base). If we see that we made a mistake we could always add restrictions to where buildings may be placed without touching the general resource approach.

Regarding the team differences, I find this very dangerous, too, and think we shouldn't consider this in an early state of design.

I've been thinking about this more and am starting to think that a decaying rate of build point disbursement adds little and complicates things too much. I think we'd be better off simply having one map-wide total (defined by the map, probably overrideable by the server) that depletes linearly in direct proportion to the number of RGSs present. Besides being much more intuitive and easier to understand (which makes the game more accessible), it would mean having one less variable to worry about during balancing.

I talked to norfenstein on IRC to get a better understanding of his argument:
As I understand his approach, he wants a map to have a total number of available build points. Each RGS should mine at the exact same rate independent of time, the number of available BP or the number of active RGS. The number of map wide BP left would be displayed to the player and decreases linearly dependent on the number of active RGS. As soon as the map's resources hit 0, RGS would abruptly stop to generate resource. His reasoning was that anything nonlinear would be unintuitive and make the game less accessible.

What I like about this idea is that we could introduce a Battlefield like "domination bar". Since the number of active enemy RGS could be derived from the depletion rate and the number of friendly RGS there's no point in hiding it at all. The number of RGS of both teams could be displayed at any time, showing which team currently dominates a map. This is fun and emphasizes the importance of map control.

I still disagree with this approach for a number of reason. First of all I don't agree with the idea that anything nonlinear is unintuitive. There are quite a few nonlinear processes in Tremulous that don't seem to make the game any harder to understand, for example fall damage or the medikit heal rate. I agree that it's nice to have a linear process where applicable but here it seems to eliminate some of the positive side effects of my RGS approach.
The thing that bothers me most is the fact that norfensteins approach reimplements some form of sudden death (one that affects game pacing instead of just being an emergency brake). As long as there are resources left to be mined the resource system would have no influence at all on game pacing: All RGS would mine at the same rate, no matter if the game started ten seconds or twenty minutes ago. The very moment the resource pool is depleted the RGS would abruptly stop producing any more resources. While teams could still use their spare resources to rebuild some of the more important structures this effect would split the average game into two parts just as Tremulous did. Teams would wait for the depletion to occur and rush the enemy at that moment, hoping that they didn't save resources for this "post sudden death" phase. I think that having magic dates where a rush is more likely to defeat the enemy team makes matches feel repetitve and doesn't make the game more accessible.
norfenstein argued that there's no significant difference between a RGS ceasing to work completely or just generating a neglible amount of resources. That's correct but with a steadily decreasing generation rate there's no such magic date that would have an abrupt change of game state as a result. And even if each of your RGS only generates a single BP per minute you would still like to keep them as they will allow you to build a vital structure once in a while.
While norf wants to display the number of BP left on the map, a number that decreases linearly (but not constantly since it depends on the current number of active RGS), I would display the current generation rate of every single RGS. You can basically derive the same information: Norf's value focuses on the estimated time when resources run out, mine focuses on how many resources are currently generated, so both show how worthwile it still is to build another RGS and defend existing ones. I'd like to note that 1) both values have a nonconstant derivate and 2) you'd need to observe norf's value over time to get an idea of the estimate date of resource depletion.

I think it's time to elaborate on the decrease rate R(R0,t) I had in mind. As I pointed out in my original post, R(R0,t) depends on the initial generation rate R0 and the time. R0 is a fixed value that doesn't need to depend on the map (since on a bigger map you can have more RGS and mine a bigger total of BP). For the examples below I'm using R0 = 20 BP/min. The ideal value can be obtained through testing and adjusted at any point in development. We reached a consensus of 20-40 min for the length of a match so we could let R hit the 1 BP/min line somewhere between minute 20 and 30 to make sure build points get spend before minute 40. Here are two candidates for R that do this for the given R0:

The x axis shows the time after the start of a match in minutes, the y axis shows the resource generation rate R at that time. Note that my choice of functions is only an example. Any function R(R0,t) with R(R0,0) = R0 and t --> infinite => R(R0,t) = 0 will do. The values 11 and 16 are approximate forms of t1/(tanh^-1((R0 - 1)/R0)) where t1 is the desired time with R(R0,t1) = 1, so they are no magic numbers but can be calculated for a fixed t1 (in my examples I'm using t1 = 20 and t1 = 30 respectively). Feel free to post alternative functions!

Resources vs Build Points: Another interesting debate which needs to be decided. Resources emphasize holding onto a location for a long period of time and rewards a team accordingly for holding onto a location for a long period of time because when a team holds onto a location for a long time, they will continuously get resources from it. On the flip side, resources means that teams are not penalized as hard when long standing RGS's are destroyed because they do not immediately lose the resources mined from them. Build points, on the other hand, emphasize keeping the RGS's alive. The length of time alive is not important as build points are received immediately after building and lost immediately after the RGS is destroyed.

Personally, I favor the resources approach. It allows a team that is consistently winning maintain its lead as opposed rapid changes in positional advantage based on random lucky strikes against weakly or undefended resource sites. It allows the the team to attack harder without needing to constantly fear the safety of the outer based.

I agree with this and want to add that whenever I said build points or BP I was really refering to what you call resources.

[Cadynum]

If by "make sense" you mean "be realistic" then I'd say that's exactly the opposite of how you should design a game that isn't a simulation. Aesthetic justification can always be found ex post facto and, while very important, should always be subordinate to mechanical gameplay (assuming that fun is your primary goal).
You say,
but immediately following the IRC discussion that brought this up several people conceived of in-world explanations for it, so it certainly can "make sense" in that way. And your point about it possibly masking a larger design problem isn't explained thoroughly enough to respond to, but I'm guessing it comes from:

I'm sure some explanation can be made up regarding no-resources-close-to-base, but that's not the point I'm trying to make. My main point was that artificial restrictions are bad and are often trying to hide an underlying design problem.
I think making sense and being realistic are two different things.

To the second point: we have creative people that can explain why this should happen in the game world. Perhaps something cyberpunk about humans being mercenaries and getting paid by an amoral corporation. It's largely off-topic for this sub-forum (we should probably dedicate a future thread to what tone Unvanquished should aim for, but finishing the gameplay design is more urgent).

A player shouldn't need to know some back story to know how to play the game. It should be intuitive. Arbitrary caps are not.
This remark is a small one though, my main issue with it is still the "underlying problem" mentioned above.

To the first point I'm more sympathetic, but I think we'll have a hard time coming up with a better system*. I don't think removing the RPG element of individual "leveling-up" is something we'll want because it's a huge part of what makes games like this fun. It doesn't have to be primarily based around killing enemy players, but I'm having a hard time thinking of what else it could be tied to that wouldn't cause worse side effects. We do need to justify our gameplay decisions, but doing so depends on having a set of axioms that will necessarily be arbitrary ("this is fun, we should design a game around it"), and I suspect this might end up being one. If that's the case then things like fund limits or only earning funds away from your base could very well "make sense" mechanically.

Indeed, you make a valid point. I'm somewhat sure though, that as long your own direct economy gets better from killing enemies, there will be a camping problem.
The only objective in for example starcraft is killing the base. That doesn't mean the combats are boring.

You're going to have to explain your thoughts on this.

I don't know why I added this, disregard it.

[norfenstein]

I'm somewhat sure though, that as long your own direct economy gets better from killing enemies, there will be a camping problem.

I'm not as sure. Funds-for-kills does give an incentive to camp, but there could easily be enough disincentives (or limits) that it wouldn't be a problem. We don't need to eliminate camping entirely (and may not even want to) just make it so that it doesn't hurt the game. I'm worried that the only way to remove it entirely might be to simplify away things that are fun enough to justify a few "artificial" restrictions.

My main point was that artificial restrictions are bad and are often trying to hide an underlying design problem.
I think making sense and being realistic are two different things.

I guess what I'm arguing is that a design problem that something artificial compensates for might be inseparable from something fun enough to include anyway. I would say that a game mechanic "makes sense" if it's either intrinsically fun, or if it follows logically (either directly or indirectly) from something that is intrinsically fun. I know funds-for-kills is fun; I would need to hear an alternative that sounds equally fun to be convinced that its problems aren't worth designing around.

The only objective in for example starcraft is killing the base. That doesn't mean the combats are boring.

If you were one of the units fighting the combat it might be boring...

[norfenstein]

Regarding the build point refunds, I'm ok with setting the default ratio to 1.0. ... For that reason I'd like to make the ratio a variable so we have the option to tweak it slightly below 1.0 later on.

My opinions:

• I'd like it to be balanced only by tweaking the time it takes to reclaim build points (deconstruction). I think it would be just as effective a way to adjust balance.

• I think that moving structures closer to the enemy is an legitimate strategy (it's a form of passive offense). This won't be UBP; if you get too aggressive your team will permanently lose build points.

• I feel that permanently losing build points because you want to move something is too "strict". I don't think perfect placement is something we need to emphasize, especially if we expect new players to not be harangued for trying to build.

As I understand his approach, he wants a map to have a total number of available build points. Each RGS should mine at the exact same rate independent of time, the number of available BP or the number of active RGS. The number of map wide BP left would ... [decrease] linearly dependent on the number of active RGS. As soon as the map's resources hit 0, RGS would abruptly stop to generate resource. His reasoning was that anything nonlinear would be unintuitive and make the game less accessible.

It's that, and I wasn't sure this needed to be any more complicated than the simplest approach. I'm more sure now that I have rebuttals to your counterpoints:

The thing that bothers me most is the fact that norfensteins approach reimplements some form of sudden death (one that affects game pacing instead of just being an emergency brake). As long as there are resources left to be mined the resource system would have no influence at all on game pacing: All RGS would mine at the same rate, no matter if the game started ten seconds or twenty minutes ago. The very moment the resource pool is depleted the RGS would abruptly stop producing any more resources. While teams could still use their spare resources to rebuild some of the more important structures this effect would split the average game into two parts just as Tremulous did. Teams would wait for the depletion to occur and rush the enemy at that moment, hoping that they didn't save resources for this "post sudden death" phase.

This bothered me too at first, but I now think it's an unfounded fear. You can argue that it's better it's more elegent or otherwise better for the pace of the game to change gradually instead of having any kind of explicit demarcation, but I don't think this would end up being like sudden death at all.

tl;dr Sudden death in Tremulous wasn't so important because it made the enemy unable to rebuild, it was because it guaranteed that killing a structure mattered. In Tremulous you had to follow up on attacks quickly if you wanted to make a difference before SD, because if your team waited too long the enemy could just rebuild and it'd be like nothing ever happened. In Unvanquished we've decided that killing an enemy structure permanently deprives them of those build points -- so regardless of whether the enemy has more build points to make a replacement, their team is irreparably weaker. There's no reason to wait around until your team can mount an overwhelming attack: every attack that kills an enemy structure is worthwhile. For that reason I don't see foresee any of the problems sudden death caused in Tremulous happening in Unvanquished, even if build point generation at some point abruptly ends.

While norf wants to display the number of BP left on the map, a number that decreases linearly (but not constantly since it depends on the current number of active RGS)

What I like about this idea is that we could introduce a Battlefield like "domination bar". Since the number of active enemy RGS could be derived from the depletion rate and the number of friendly RGS there's no point in hiding it at all. The number of RGS of both teams could be displayed at any time, showing which team currently dominates a map. This is fun and emphasizes the importance of map control.

Well, I see two ways of doing this, and I'd be fine with either. I think showing everything would be fun, but it's probably less "strategic" than hiding what information we can about the other team. If we show the actual number of points remaining in the map then, yes, there's no reason not to also show what the enemy has. But we could instead show the map's original total minus your team's total acquisition -- this would leave it ambiguous how many points the enemy has versus how many are still available, up until the point when the map is depleted and generation stops.

[Viech]

My opinions:

• I'd like it to be balanced only by tweaking the time it takes to reclaim build points (deconstruction). I think it would be just as effective a way to adjust balance.

• I think that moving structures closer to the enemy is an legitimate strategy (it's a form of passive offense). This won't be UBP; if you get too aggressive your team will permanently lose build points.

• I feel that permanently losing build points because you want to move something is too "strict". I don't think perfect placement is something we need to emphasize, especially if we expect new players to not be harangued for trying to build.

Your arguments seem valid and since this seems important to you, let's stick to it. So build points are always refunded in full. If you replace/move a structure the time it takes you to build the new one can be considered the penality for doing so. Instantly deconstructing a structure should either not be instantly or lead to a cooldown. This should probably be discussed in another thread but here are some resource related problems that we need to keep in mind: 1) Replacing a damaged structure with the same structure shouldn't be a faster way of healing. 2) Instantly deconstructing or replacing a structure that is under attack shouldn't save the build points that would otherwise get lost. A simple and non-confusing approach to the latter would be to allow both instant deconstruction and replacement only for structures at full health.

Sudden death in Tremulous wasn't so important because it made the enemy unable to rebuild, it was because it guaranteed that killing a structure mattered. In Tremulous you had to follow up on attacks quickly if you wanted to make a difference before SD, because if your team waited too long the enemy could just rebuild and it'd be like nothing ever happened. In Unvanquished we've decided that killing an enemy structure permanently deprives them of those build points -- so regardless of whether the enemy has more build points to make a replacement, their team is irreparably weaker. There's no reason to wait around until your team can mount an overwhelming attack: every attack that kills an enemy structure is worthwhile. For that reason I don't see foresee any of the problems sudden death caused in Tremulous happening in Unvanquished, even if build point generation at some point abruptly ends.

This makes sense to me. I also agree that the simplicity introduced by a constant generation rate per RGS has its advantages. I still think a non-abrupt stop would feel more elegant/realistic but I'm fine with your approach as long as it doesn't feel too artificial. This includes letting RGS visibly power down (spinning down like Trem's RC when it gets destroyed, shutting down lights, making a sound, etc.) as well as having the visual impression that the number of currently generated BP drops steadily over the course of a few seconds. I don't want a flashing "New game phase reached" message explain why the generation rate is set from x to 0 in the wink of an eye.
I'll presuppose your approach for the rest of my post.

Well, I see two ways of doing this, and I'd be fine with either. I think showing everything would be fun, but it's probably less "strategic" than hiding what information we can about the other team. If we show the actual number of points remaining in the map then, yes, there's no reason not to also show what the enemy has. But we could instead show the map's original total minus your team's total acquisition -- this would leave it ambiguous how many points the enemy has versus how many are still available, up until the point when the map is depleted and generation stops.

I like the second approach. However, the maps total minus your teams acquisition doesn't seem to be a relevant value to me. Throughout the resoure acquiring phase it would be nothing more than an upper boundary for the enemy teams total build points which abruptly changes to a precise value as soon as resource generation stops. Instead I'd display 1) The maps total build points, 2) your teams total acquisition and 3) the current generation rate of your team.

b[/b] depends on map and server and is important to experienced players as it gives them the possibility to foresee game pacing. Not knowing that number means having little chance to develop an initital mining strategy (e.g. gathering just enough to go aggressive (low total) versus putting effort into securing mining sites so they will give the advantage later on (high total)). I've seen a clan check the server settings for sudden death and time limit in a running GPP scrim using the console/server info dialog. We shouldn't require such out-of-game action in Unvanquished.

b[/b] is important because it is the only value that gives you an impression wether you are more likely to be at the beginning or at the end of the resource gathering phase. You need to know this in order to decide on the priority of building more/defending existent RGS. Once generation stops you can either let the player substract (2) from (1) to see the amount of build points the enemy team has mined or directly display a percentage value next to your teams total (e.g. "270.4 (52%)")

b[/b] is a quick way to see how many RGS you have running. It allows you to recognize the loss of a RGS without constantly watching the increase of (2), which not only increases the accessibility but also lets experienced players focus on playing the actual game. In professional quake matches there is a person on each team hwo doesn't play but uses a stopwatch to tell people when important items are going to respawn. I don't want Unvanquished scrims to require such a person.

(1) and (2) can be combined to a single string such as "35.6 / 500" in the gathering phase and "270.4 / 500 (52%)" when resource generation has stopped.

If someone feels we let an important element of the RGS approach out feel free to say so. Otherwise I'm going to sum it up in another thread soon.

[Theyain]

This is my idea.

http://i.imgur.com/NZKYR.gif

I would [img] it but it's a slideshow gif.

It's a rather simple idea but can be rather powerful.

[norfenstein]

Theyain's idea was brought up in IRC and appealed to a few people in the ensuing discussion, so it seems like we still need to decide how to handle build point extraction. I see only four possibilities, so unless someone can come up with another that is fundamentally different let's choose one of the following and be done with build points at a high level:

• Fixed resource sites, global build point pool - The map defines resource sites (Domination-like capture points) and teams build RGSs to claim them, but all build points are drawn from the map's total. We've already decided this isn't the first method we want to try.

• Free placement, global build point pool - RGSs can be built anywhere (but with some kind of limit to how close they can be to each other) and all draw from the map's pool. This is what most of the posts in this thread have been assuming, and is probably the simplest approach.

• Free placement, resource map - Theyain's idea.

• Fixed resource sites, with local pools - Like Domination, but each resource site can run out of build points. This has two variants: RGSs and resource sites are one-to-one, or RGSs can cover multiple sites that are in range. With the latter option, if you have a lot of resource sites it starts behaving like a resource map.

I think the big decision to make first is: do we want to force teams to expand across the entire map? Because the second two options above would do that, while the first two would let teams achieve their own equilibrium. For example, with a global pool of build points it could be a valid strategy to hold down a single (good-sized) location in a map and simply wreck any attempt the enemy makes to expand; that wouldn't be feasible if your stronghold eventually stopped generating build points altogether.

EDIT: Upon further thought, I don't think local build points will actual force teams to expand across the entire map. See here.