I'm going to elaborate on my original approach, so please read it first before your process this post.
norfenstein wrote: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.
norfenstein wrote: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!
Ishq wrote:
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.