|
Why metal maps are associated with lag
|
2.69 MB
|
-
|
-
|
|
Metal maps allow you to get a huge economy in no time
making it very likely the number of units in the game
raises pretty fast. A high unit number leads sooner or
later to lag - it's unavoidable. I talked to AEF_Vinceboo
after the game and he told me he was on a 56KBit connection
(I'm on a 128Kbit upstream 768Kbit downstream DSL line).
I'm sure you will find more lag symptoms in this game but
the best example is probably the late game Hawk Swarm
attack™. Vinceboo told me he ordered his hawks to
target my upper fusion and saw its health bar jumping back
from lower to higher health multiple times. At my end the
Hawks sometimes stopped moving and were unkillable. No one
can tell if the Hawks had been able to take out that fusion
before getting killed by the Missle Towers in a lag free
game or not. Number wise I belive it was enough Hawks to
survive the missle fire until destruction of the fusion.
|
|
Facing lag on small maps
|
1.70 MB
|
-
|
Gods Of War
|
This game is a nice example for different symptoms of lag.
Since lag favours the attacker it becomes a ruling factor
in games on small maps with few metal patches only - like
for example Gods Of War. An early bomber/fighter can delay
production build up and expansion especially
if your Anti Air (AA) units have to
deal with teleporting units. Teleporting is a bad thing
because from the view point of the defending player the
unit is a much shorter time in fire range compared to a
game without lag. Less opportunities to score a hit means
the unit will live longer than supposed to. This may result
in one more bomber run or winning a 1 versus 1 fight
against a stronger unit. In such a situation it's all about
getting a laggy plane out first. Almost everyone playing
GOW picks this approach nowadays. In this
recording you will see yellow's AA fail on black's bomber
and vice versa
Besides the fact the recording crashed around the 90 %
mark (lag free games seem to crash the replayer less from
my experiences) keep an eye on the following facts when
watching the game:
-
Yellow bombers drop their payload way in
front of the bomber itself. It looks like
the bombs move faster than the bomber which
actually dropped them.
-
At the 14:40 mark there is a white sub
near the west coast of the 6:00
position island engagd with a torpedo
launcher. The sub and the launcher kill
each other finally. But while the launcher
blows up immediatly with the torpedo
dealing the damage necessary to finish it
off the sub lives on for a few more seconds
after the torpedo that should have killed
it hit. In this particular situation not a
real problem since there was no other
target in range of the sub during this
prolonged life time period. Now imagine
this had happened in a larger battle
where every torpedo of the strictly
speaking already dead sub would have made a
difference.
-
Around the 14:45 mark a white seekter
enters the northern shore of the 6:00
position island. A ship becomming a
hovercraft?
-
18:25 minutes in the game there is a
pelican/seekter battle going on east of the
6:00 position island. Watch the
pelicans shooting multiple times at
skeeters showing the minimum possible
health before they finally die.
-
Around 20:00 minutes in the game a
yellow submarine southwest of the top left
island teleports around.
|
|
Lucky this was a medium sized map
|
4.08 MB
|
-
|
Painted Desert
|
Watch Duke_NorthStar's units (white) in this game. He
knows for sure how to bomb but considering how much his
bombers teleported around I'm sure air strategy would pay
off for him on any map and even without any bombing
skills. If you take a closer look you will also notice
sometimes his units die with the last red tick while they
keep moving without any health bar at other
times.
Since the map is not so small and offers a lot of
alternative metal spots besides the the few near your
start position and much metal to reclaim the lag of
Northstar was very annoying but luckily not a game deciding
factor. Imagining I had to play him on Gods Of War where
you have only four metal spots to live of before the
energy-metal maker produktion is going makes me shiever.
|
|
Lag is no issue in TA - you just have to handle it?
|
4.26 MB
|
-
|
Painted Desert
|
Well, if you ever heard statements like that and belived it
then take a look at this recording. Around 12 minutes in
the game black Commander gets killed by a pathetic small
group of red's units since the d-gun damage wasn't applied
to any of the attacker's units.
Notice also what happens to the health bar of the red
Commander at center later when he comes under
Slasher fire: It disappeared like at least
two times (which means the unit should be plain dead) and
appeared again with health in red range.
The thing that annoys me most about such games is that the
other players are not even aware of the lag
situation and come to the conclusion that skill killed the
opponent and not a bad internet connection or a slow
computer.
|
|
Construction units - teleporting edition
|
2.65 MB
|
-
|
Painted Desert
|
Ever had the problem your construction units get killed
all to easy? Well, nothing a bad route couldn't fix. With
a bad route your units will just teleport out of range of
the attacker.
Keep an eye on LoC_N_LAG's units. His name already tells
you everything you have to expect from him. The last two
games I played against this guy have been really laggy.
I'm glad the like 30 flashes attacking me in mid game came
from his partner and not from LoC_N_Lag,
they died ok.
|
|
Team up with lag - and win
|
161 KB
|
-
|
Gods Of War
|
SBM_pita's bomber is a amazing. It drops bombs without
showing up at the main screen at all in mid game. Notice
also the first of his bombers just pops up bombing on the
screen while it was shown like 80% built at the plant
about two seconds before.
His Partner, SBM_Lamperer on the other hand has a kbot lab
already building a kbot while the plant is still shown as
being nanolathed. Also notice the Commander while building
stuff is too far away from the thing he builds. Typical lag
symptoms.
If you ever saw such stuff in a game you played and came
back to the game lobby only to hear everyone telling you
just played experts, well then don't worry. They are right.
Indeed, you played an expert. And his name shall be
lag. He is usally unbeatable, except he
teams up with new players.
|
|
A classic bad network route example
|
1.40 MB
|
-
|
Town & Country
|
The usual lag effects to see here but this time I took
a
snapshot of the network route
to the other player and if you take a look at it pretty
much makes the problem clear: The row
PL% shows massive packet loss along multiple
hops of the network route between SnowmanAppie's
and my computer.
The actual problem is the first hop showing lost packets.
Since this hop is under control of a Internet network
carrier company there isn't much Appie or his ISP could do
to fix this problem. Hopefully it's just a temporary
one.
|
|
Packet loss in a controlled environment part I
|
36.4 MB
|
-
|
Dark Side
|
I finally was able to setup an environment that would allow me
to create any rate of packet loss between two TA computers in
a multiplayer game. This file contains two recordings of the same
game so you can see the differences for the both players.
For this game I tired out packet loss settings of 20% and 50%.
The packet throttle was set on the UDP 'connections' in charge
for exchanging the in game data. Two of those 'connetions' exist
between each pair of TA computer in one game, each working in a
kind of one way street manner.
What was pretty much acknowledged by this test game is that
-
Packet loss allows to bypass the attacker static
defenses that would stop him otherwise.
-
Air, especially bombers, gains most advantage from
packet loss when attacking and the packet loss
affects the connection transporting the packets
in the direction defender --> air attacker.
Vice versa bombing mexes becomes pretty useless
when the packet loss affects the connection
transporting the data in the direction
air attacker --> defender.
-
People play actually two very different
games with packet loss. This is mainly related to
unit positions in the two games because those can
pretty much differ for both players at the same game
time. Again air is the worst problem here due to the
high moving speed of air units.
-
Units can fall into gaps that will make them
unkillable for quite some time. That almost dead
Hawk hanging in the air and attracting the MT fire
for ages is a classic example for this problem. It
seems if the timing is bad enough the unit wouldn't
get back into 'synch' even if a packet loss gap is
passed and game data is exchanged in a normal manner
again. The next 'synch' attempt may just fall into
the next gap which would explain that kind of problem.
-
Reclaiming debris seems to be handled the same way
as Dragon Teeth: You may have a clear attack path
next time you route a bunch of flashes over the
battle field while your opponent's units get stuck
in debris and their shots are bloked by it because
the information that your c-unit reclaimed this stuff
never made it to your opponents computer.
I tried to start to record not before I got a suffcient resource
base up first in order to avoid that you have to go thru like 20
minutes build up time but it turned out that the replayer wouldn't
show any units then until like 20 minutes elapsed. So I
recorded a 2nd game this time from the very begin which also made
the recordings quite big. I suggest you set speed to +10 until the
actual testing starts around the 34 minute mark.
I'm planning to do some more test games. I can't wait to see how
thing work out with packet loss and water units. The good old
submarine versus destroyer or submarine versus torpedo launcher
duel comes to mind here...
|
