Testing a new resource system
- Details
- Written by Viech
We are currently trying out a new resource-based building system on our Development & Testing Server. The system itself is work in progress and could change at any time, but as our first test games were a lot of fun and we find that it has a great potential it should be about time to explain to you how it currently works, so you can quickly adapt and discuss the system with us on a higher level of understanding.
What's a resource system?
Tremulous used a pool of build points that each team was given at the beginning of a match. Teams could spend the build points to build structures. When structures got destroyed, the build points entered a queue and after a while became available to the teams again. There was a sudden death mechanism that disabled building alltogether after a timelimit was hit.
Resources are, just like Tremulous build points, spent to build structures but they are not returned if a structure gets destroyed. Think of them as an actual payment for building the structure, as opposed to a mere limit of how many structures you can have simultaneously. Replacing and moving of structures is still possible and won't be penalized: if a structure at n% health gets deconstructed for either reason, you will get n% of its price back. The resource system I'm going to talk about describes the way that building resources, which we will still refer to as build points (BP), are acquired.
Resource Generating Structures (RGS)
Both teams are given an initial amount of build points. If they want to acquire more, they need to build Resource Generating Structures (RGS) that generate them over time. The human RGS is called Drill, the alien one is called Leech. They, too, have a construction price. RGS have a spherical area of effect described by their range. If the areas of effect of two RGS intersect, they will have a reduced efficiency, forcing teams to expand over the map.
Resource generation
Each RGS has an efficiency e. If a RGS doesn't interfere with another one (that means that their distance is above a threshold), that efficiency will be at 100% (e = 1), otherwise it will be lower, but positive. The mine rate of a RGS also depends on the level-wide (team independent) base rate r(t) (in BP/min), which itself depends on the time t (in minutes after the match begun). The current generation rate of any RGS is simply e×r(t). r(t) has an initial value r(0) = R₀ which can be configured on the server. The base rate r(t) also has a half life period T (in min), which can also be set on the server. This will replace the artifical sudden death, as teams will get a decreasing number of resources over time. The formula to calculate r(t) is R₀×2-(t/T).
Example
Let's asssume we have a single RGS on the map. Since its area of effect does not overlap with another RGS, it will generate resources at 100% efficiency, so e = 1. Now let R0 be 15 BP/min and let T be 15 min. If the RGS already exists at the beginning of the match (t = 0), it would generate at a rate of 15 BP/min at that moment. If the match has been running for 15 minutes (t = T), the RGS would only generate 7.5 BP/min (no matter if it has been present since the beginning or has just been built). After 30 minutes (t = 2T), the RGS would generate 3.75 BP/min.
Interference: Idea and Approximation
One of the key ideas behind the RGS approach is that it should force the teams to expand and gain control of the map. This is accomplished by reducing the efficiencies of RGS that are built too close to each other (another approach would've been to simply forbid placing of a RGS in the range of another one but we found this to be too artificial and rigid). Our idea was that a number of RGS together would, no matter what teams they belonged to, generate at a rate that was proportional to the volume of the union of their spherical areas of effect (AOE). This alone would've been far too complex to implement in a real time game but since we also need to assign every RGS an individual generation rate (because they might belong to different teams), this approach was out of question. We decided to use an approximation of it though: We look at pairs of interfering RGS and calculate the intersection quota q. If q = 1 then the AOEs are identical. If q ≈ 0 then they barely touch. If q = 0.5 that would mean that 50% of the AOE of one RGS lays inside the AOE of the other one. Now for two interfering RGS, we independently halve the part of the efficiency that corresponds to the overlapping area. So if the efficiency of one of the RGS was at 100% and 20% of its AOE overlapped with that of the other one, we would reduce the efficiency to 80% + 0.5 × 20% = 90%.
Example
We only have two RGS on the map. They might belong to different teams or a single team. Now let the RGS range be 800 qu (quake units), so that their area of effect is a sphere with a radius of 800 qu. If the two RGS are at a distance of 1600 qu or higher, they would both mine at 100%. If they were both in the very same spot (which is not possible, of course), they would both mine at 50% efficiency. If they were at a distance of 800 qu, parts of their AOE would overlap and we would find the relative size of the intersection area to be 5/16. So now we would half 5/16 of the initial efficiency and get a new efficiency of (1 - 5/16) × 100% + 5/16 × 100% × 0.5 = 11/16 + 5/32 = 27/32. Both RGS together would now mine at a total efficiency of 2 × (27/32) = 54/32 which is exactly the volume of the union of their AOEs divided by the volume of a single AOE. Note that our approximation is always exact if each RGS interfers with not more than another one.
Approximation side-effects
The pairwise approximation appproach yields exact results for pairs of RGS but produces an error when more than two RGS interfere. This error will always penalize the cluttering of RGS (meaning building many of them close by). If, hypothetically, n RGS are built in the very same position, the total efficiency would be n/2(n-1). So one or two RGS will yield 100% efficiency but three RGS will only generate at 3/4 of the speed of a single RGS. If you build 10 RGS in the same spot the total efficiency would drop to less than 2%. While this effect is, in theory, an error, it has a number of positive side effects:
- The number of calculations that is necessary for n interfering RGS is n×(n-1) and thus its complexity is in O(n2). The fact that players have a motivation not to let RGS AOEs interfer will help keep the server load low.
- You can choose to build two RGS closeby so that one takes over completely if the other one gets destroyed. Since this advantage comes at double price and build time, I consider it a balanced decision that can make strategic building more interesting. At the same time the penalty will prevent mindless ‘more is better’ spamming of RGS.
- RGS can also be used as a weapon against campers: Just build a lot of RGS next to the enemy camp and they won't be able to generate any more resources there.
Get involved!
If you want to help in the development of the resource system, give your feedback on the forums and help us testing by participating in our development games, which we will announce on the forums and on IRC.
About the cost of the computations. From what you write, it looks like it's very expensive to use your formulas. Yes it may look O(n2), but there are ways to reduce computations. For example, the RGS are immobile which means you rarely need to compute it: only when a new RGS is built or destroyed, you need to recompute and store the results. In case it was destroyed, you only need to recompute for the RGS that were overlapping with it (which is just a few if you store the groups of interfering RGS). In case it was built, you can use the bounding box trick to greatly reduce the number of distance comparisons between only close RGS. For each RGS, you store the percentage of the team BP rate, then in your realtime computations, you only need to compute when the next BP will be generated and put them in a queue. (Of course there are other ways to optimize but I am not going to go into details here, I just wanted to show that there are ways to make it light for the server load)
By the way, I think it is a good idea to reduce BP/min even more when you add more and more overlapping RGS: interferences are good. Also there should be a clue on the RGS to let the player know how much it interferes and that it is a bad thing. Especially for new players.
Great job.
So I propose you guys change the name Drill into Resource Transmitter. Basically what the Resource Transmitter does is teleport resources from near by colonist factories to near by off world militant bases. This would make way more sense than a Drill.
And yes, the name 'drill' should be changed.
Maybe "Accumulator" instead of "Drill" ?
Btw with the mathematics, I'm getting weird symbols instead:
The formula to calculate r(t) is R₀×2-(t/T).
Also, I think you mean diameter here:
In the paragraph of "Approximation side-effects" when you say
first of all i am also a big fan of the new RGS system...
But ...as your concept arts indicate that the current model for the leech structure is not final, could you please take the fact into consideration that the human RGS are way smaller and much more tiny at the moment, giving the human team an advantage in placing and hiding their "drills". So if you come up with a new alien leech model, please consider making it the same size as the human one and/or adjust the size of the human RGS structure accordingly.
>maybee some scaled down, modified egg model could do the job ?
The formula to calculate r(t) is R₀×2-(t/T).
I also think the foot print of the leech is too large. However, you can use that to your advantage on certain maps.
It's broken: it's converting from UTF-8 to what has become known as [URL="http://wtf-8.com/"]WTF-8[/URL], presumably intending to convert ISO8859-1 to UTF-8…
Human RGS = "Particle Sieve" (or "Wave-Particle Sieve" which is only slightly longer)
Alien RGS = "Detritus Parasite" (or "Attine Symbiont" which is rooted in the ant-fungus relationship)
By the way, I think the whole approach to this new resource system adds a valuable complexity to team strategy. Very Engaging! The bots don't seem to really get it though.