- Each army you own on a planet, up to 4, contributes
to your score. So owning 2 planets at 2 and one planet at
4 contribute a total of 4 points to your score.
- However, by owning an additional planet you are depriving the
opposing team from getting the 1-4 points associated with a
non-independent planet. So owning 2 planets at 2 is superior
to owning 1 planet at 4 and having the opponents own a planet
at 1-4.
-Kevin/Akira/Modem Tzu
Continuous Scoring System
Dave Ahn <a...@netrek.org>
[NOTE: Continuous scoring is in beta testing stage. Please
send back bug reports to vanill...@us.netrek.org.]
Continuous Scoring is a new system for determining the on-going and
final score of a league game. The old system uses an absolute planet
count of 11-8-1 for the winning condition. It has worked fine for
many years, but some players argue that it favors the use of a passive
strategy to stash a large number of armies for a last minute push
before end-game. The consequence is that the first 1/2 to 2/3 of a
clue game can often be boring and somewhat meaningless. Continuous
Scoring attempts to address these problems by using the on-going state
of the entire game to determine the winning condition instead of just
the final planet count. Whether this new system is better than the
old...only time will tell. :)
The system works by tallying the points for each team at every tick.
The INL robot runs at 10 ticks per second, so points are computed 10
times each second. A point is a weighted multiple of the army count
on each planet owned by each team, capped at 4. The formula is:
total_points =
Sum(all planets owned by team at each tick)
(weight * MINMAX(0, 4, num_armies_on_each_planet))
For example, given weight = 1.0 and the team owns 2 planets, each with
2 and 5 armies, the points given to the team at each tick would be
(1.0 * 2) + (1.0 * 4) = 6 points. If the team owns 10 planets, each
with 17 armies (such as at the beginning of a clue game), it would get
(1.0 * 4) * 10 = 40 points every tick.
The weight is linearly interpolated between the start and the end of
the game between 0.75 and 1.5. The purpose of the weighting is to
reduce the effects of high volatility in the opening while giving
extra meaning to excellent gameplay at end-game. This way, a team
that loses an SB+25 at opening and stays down several planets for the
first 1/3 of the game can still come back to dominate and win the
game. The formula for the weight is:
weight_at_tick = 0.75 + (0.75 * (current_tick / total_ticks_in_reg))
total_tick_in_reg is the total ticks in regulation time. For example,
in a 60 minute game there are (60 * 60 * 10) = 36000 ticks. The
weight is capped at 1.5, so if the game goes into overtime, the weight
is exactly 1.5.
Because these points are hard to interpret (what is a score of 12345
vs 12344?), the continuous scores are presented in planet-normalized
fashion. A continuous score of 1.0 means that a team has owned the
equivalent of 1 planet. Since the score is weighted, 1.0 is not
exactly 1 planet. A running score of 9.23 - 8.01 means that the
winning team has averaged about 9.23 planets (9 planets and about 1
army) while the losing team has averaged about 8.01 planets. The
normalization formula is:
cont_score = total_points / (weighted_total_ticks * 4)
The continuous score is announced in regular intervals during the
game. A player can also get the current score by sending the word
"SCORE" to himself. The announcement looks something like:
INL->ALL Score: FED vs ROM 8.60 - 10.28 (weighted)
INL->ALL Score: FED vs ROM 8.71 - 10.30 (continuous)
INL->ALL Score: FED vs ROM 8.50 - 10.50 (semi-continuous)
INL->ALL ROM is winning.
The first score (weighted) is the actual score. The second and third
scores (continuous and semi-continuous) are for debugging purposes and
can be ignored. The announcement is summarized with "XXX is winning."
or "Game is tied." which indicates what would happen if the game were
to end immediately.
**** WINNING CONDITION ****
The INL robot now supports two kinds of winning conditions. The first
is the traditional 11-8-1 planet count win. The second is based on
the new continuous scoring system. The default is to use the NORMAL
scoring mode based on planet count. However, both captains may switch
to the CONTINUOUS scoring mode using the command "SCOREMODE" during
pre-game. The scoring mode may be toggled back and forth between both
modes.
NORMAL scoring mode:
At the end of regulation, 11-8-1 planet count by either team
WINS the game.
Otherwise, game goes into sudden death overtime.
In overtime, the first team to get 11-8-1 WINS the game.
CONTINUOUS scoring mode:
At the end of regulation, either team with a continuous score
lead of 0.50 or more WINS the game regardless of planet count.
Otherwise, if continuous scores are within 0.5 of each other,
then the planet count is considered. If the planet count is
11-8-1 or greater, then the team with the higher planet count
WINS.
Otherwise, the game goes into sudden death overtime.
In overtime, the first team to get 11-8-1 WINS the game.
Continuous scores are tallied and announced during OT, but
they do not affect the winning condition.
**** PROBLEMS ****
There are two major issues with continuous scoring. The first is to
fine tune the parameters of the system so that a team that is losing
the game can reasonably come back to win the game. The current
weighting system should help with this, but it will need adjustment.
The other is interpreting the scores for decision-making. Given a
score of 10.00 and 9.51, what does the winning team have to do to
ensure a win with 5 minutes left in regulation? Because the scores
are weighted and summed over time, the answer is not clear. I am
thinking about adding a planet-minute count to the announcements. For
example, "ROM needs 1.25 planet-minutes to win." would mean that ROM
would have to own 1.25 planets (5 armies worth) for at least 1 full
minute to meet the winning condition. But ROM would also be able to
own 2.50 planets worth for 0.5 minutes to meet the winning condition.
This code has not yet been added, so suggestions are welcome.
Continuous scoring requires Vanilla Server 2.9pl7 or higher.
That's it.
Dave
--
--------------------------------
Dr. Kevin M. Bernatz
Post doctoral research assistant
University of Pittsburgh