We are trying out a new way of gaining stages on the Development & Testing Server. I’ll try to explain how it works and why we made certain decisions.

Getting rid of feeding

After moving from a fixed amount of build points to a resource system, the next thing we wanted to try out were alternative ways of gaining (and losing!) stages.

Tremulous put a team on a higher stage when they killed a number of enemies, which had two drawbacks. Most importantly, being killed by an enemy not only removed your personal equipment and gave the enemy player a resource advantage but it also made the enemy team stronger as a whole. Dying frequently was therefore called feeding and was considered a playing style that is harmful to your team, just like bad building or damaging teammates. In particular, newbies who were just learning the game and died often were at a risk of being demotivated by their teammates being mad at them.

Another problem with the old stage system was that it rewarded passive gameplay too much since it’s easiest to kill an enemy if you are inside or close to your own base. So instead of rewarding progress or taking a risk, camping was a key strategy in staging up. Once a team reached the highest stage, there was really no reason to leave the home base for anything but a co-ordinated rush, which required personal resources acquired by even more camping.

Alternative winning strategies such as building aggressive forward bases were possible and a lot of fun but hard to accomplish in a public game when your teammates prefered staying in the main base.

Expansion isn’t everything

Since we introduced the resource system, we are already rewarding expansion. Camping the main base won’t kill you right away but you won’t be able to stand a lot of attacks since you’ll be running out of build points – especially if the enemy manages to build resource generating structures closeby to disrupt your own build point generation.

There are still issues, though: once a team has managed to cluster its base with a lot of defensive structures, attacks are very expensive and the attacking team would run out of personal resources, rendering the match a stalemate.

At one point, we tried to force expansion even more by directly linking a team’s stage to its total mining efficiency. This eliminated camping completely, but the price was too high: the main issue was that the matches became unstable, and recovery from a setback was tough.

Another problem has been the high importance of builders over the course of the whole match – being forced to constantly switch between attacking and building made the games exhausting, especially in small matches. We backpedalled quickly. Our new approach for staging comes in the form of a new resource: confidence.

The overmind likes what it sees

Confidence is a value that describes how much the overmind or human headquarters trust in their teams’ capability of defeating the enemy. A team that is constantly pushing and trying to get control over the map would be considered worth the reinforcements or evolution process. Speaking in gameplay theory, we want to reward progress over time or pace.

One of our developers, Timoteo, noted that camping isn’t evil in itself; rather, the lack of progress it results in is the evil. The same would probably apply to expansion: it isn’t good in itself but it keeps the game going. So instead of forcing expansion or punishing camping directly, we decided to implement a framework that can be used to reward multiple forms of progress and punish multiple forms of passiveness.

So how does it work? Whenever you destroy an enemy buildable you will add an amount of confidence to your team’s pool. Whenever you build a structure, this will also add confidence; but you get more if you don’t cluster buildables in one place (small forwards yield a good amount, rooms full of turrets don’t). Killing an enemy inside its main base will also add a small amount which is proportional to the amount of evos or credits you get. (I consider removing the same amount from the camping team.)

The cool thing about the system is that we can easily add, remove and adjust confidence generating events as we see fit, always with the goal to reward active, skilful and fun gameplay.

I like exponential decrease

The system would now measure a team’s total progress – but we don’t want progress to lose importance once a team has reached the highest stage. So what we do is exponentially decrease the teams’ confidence.

Let’s say you rushed and gained a total of 400 confidence, and the server’s confidence half life time (g_confidenceHalfLife) is set to five minutes, then your confidence will go back to 200 if you idle for so long.

Linking confidence to stages is straight-forward. There is a base threshold for both stage two and three as well as an increase per player. The cvars are g_stage[23](BaseThreshold|IncreasePerPlayer). In order to prevent stalemates when a high amount of defensive buildings meets teams that are stuck on a low stage, we introduced a half life time for the thresholds too (g_stageThresholdHalfLife) so that longer matches have a higher chance of being fought S3 vs S3. One team dropping to S1 in late game should be very unlikely, too.

To prevent hopping between two stages, we add extra confidence on stage up and remove some on stage down. This is controlled by g_minimimumStageTime (in seconds). A value of 60 means that you will get a stage-up reward that will let you stay at least one minute on the higher stage even if your team idles. Similarly, losing a stage removes an amount of confidence corresponding to one minute of idling.

Compared to the simple approach of Tremulous this might seem like a complicated system, but I’m confident that our HUDs will be able to hide the underlying complexity. I imagine a bar displaying confidence with two markers for stage thresholds on it. This will tell you your current situation at a glance. For now, though, we have to look at the text display.

Everyone likes pretty graphs

Which is why we started implementing a gameplay statistics facility! If you want to experiment with gnuplot to find out why your team failed the last match on the Development & Testing Server, you can download gameplay logs here. We will be adding more data in the future to have a good basis for balancing and gameplay adjustments. Here’s the meaning of the columns in the log files:

T	Time since match start in seconds
num[AH]	Number of players per team
[AH]S[23]T	Stage thresholds
[AH]Con	Confidence
LMR	Level mine rate
[AH]ME	Mining efficiency
[AH]BP	Build points

If you want to help

Get online and play on the Development & Testing Server! Give feedback if you want to and by all means take part in our weekly development games (each Saturday, 21:00 UTC), otherwise granger will be very sad.