zp
|
faq funny you should ask...
|
News Telepunt Download Zeroping
FAQ Feedback
|
Introduction |
About this FAQ
This document brings together the
major objections that people have voiced against client-side hitscan, and
my responses. If you're looking for information on installing and using
Zeroping, see the readme.
In the
weeks since I released the Alpha version of Zeroping, I've spent a truly
embarrassing amount of time on the PlanetUnreal and GT forums -- answering questions,
responding to criticism, and enduring flames. While it wasn't always fun,
it was a good use of my time: when CliffyB and Greenmarine objected so
publicly to Zeroping's approach, my answers to their arguments were
well-rehearsed and ready to go.
The Zeroping Beta itself is the
best response I can give to most complaints about the Alpha version. The
Beta no longer bends the rules of physics, allows players to benefit from
their own lag, or makes Unreal Tournament easier to hack. I hope this FAQ
will answer any remaining objections to client-side hitscan.
While
gameplay
concerns were a major concern with the Zeroping Alpha, the new version's
play is solid enough that I expect that section of the FAQ to fall into
disuse. Security,
likewise, is a problem that I feel I've solved in the Beta. Correctness
and fairness
are the real center of gravity here, and where I expect the dialogue to
end up in the coming weeks. I'll probably be adding a lot to these
sections as the conversation heats up.
Zeroping is an experiment,
not a crusade. It may be that client-side hitscan has never been used
because there's something horribly wrong with it; if so, I'll be happy to
let it go -- you learn the most from the experiments that fail. But so
far, I haven't heard any complaints that I don't feel I can answer. The
most substantial criticisms are listed here; more will come.
Now
that the Zeroping Beta puts most of my ideas into action, I'll be seeking
out input from programmers in the industry and community. My goal is to
get a reasonable, carefully-considered dialogue going -- on the forums,
through email, or in plan files if necessary. This FAQ will always reflect
the current state of the conversation. Despite the many hours I've
invested in Zeroping, I expect to be the first to admit it if I'm stumped.
Human nature makes it tricky though, and you should decide for yourself
whether my arguments really are valid.
At the very least,
Zeroping has proven that client-side hitscan can make games much more fun
for modem players. If it turns out that the method can't be made secure,
or fair when people's pings differ, then Zeroping will still be a mod that
makes play an absolute blast for hpb's -- even if zp games aren't
"serious" in some sense. Serious or not, Intercontinental Instagib is
pretty magical, and will always be a venue for great exhibition games. But
I contend that Zeroping is fair, and secure, and that client-side
hitscan is appropriate for serious play. |
First Reactions |
Isn't lag just a fact of
life?
Yes, but you can often hide
lag with careful programming. Since QuakeWorld, games have used
client-side motion prediction so that your own movement doesn't seem
lagged. When you jump, modern games let you jump right away -- even though
the server doesn't hear about it for some time.
We've all seen the
odd side-effects of client-side movement: you seem to warp from one place
to another when killed or nudged; lifts sometimes won't cooperate; and
players with packet-loss appear to zoom around the level when their
connections return to normal. Although these anomalies are disconcerting,
it's much better to put up with them than to have a quarter-second delay
on your "forward" key. With Zeroping, I'm arguing that the same is true of
the fire button, and the few gameplay quirks that client-side hitscan
introduces.
Why didn't you put all this
work into optimizing UT's bandwidth use?
Bandwidth isn't the real problem --
latency is. Although a T1 can transfer more bits per second than a modem,
its real advantage in online gaming is that those bits get to the
server much faster. "Ping" measures the time it takes data to get from
your computer to the server and back, and that's independent of the amount
of data that you're sending. No amount of UnrealScript optimization will
be able to lower your latency to the server.
Hasn't client-side hitscan
been tried before?
Not to my knowledge. Old games like
Doom and Duke Nukem were very different, because they didn't really use
the client-server model. A lot of people have mentioned Diablo, which
apparently had some disastrous client-side code. I only played Diablo
briefly, but I suspect the problem was that it was allowing players to hit
each other with melee weapons when they weren't really adjacent. If so,
then the trouble was analogous to problems with the Zeroping Alpha: the
rules of physics weren't always being observed. With the Zeroping Beta,
physics is holy writ; all hits are physically possible, and you never
suffer for other players' lag.
Another game people have cited is
Forsaken, which may well have had some form of client-side hitscan. Can
anyone refer me to documentation on this?
If client-side hitscan
works, why hasn't it been used before?
Client-side hitscan sounds
absolutely nuts the first time you hear about it. It opens up security and
fairness issues, and just feels wrong. Game programmers with
milestones to meet don't have time to spare for dead-end ideas, and are
unlikely to think long about anything that sounds as kooky as Zeroping. I
had client-side hitscan in the back of my mind for months before I started
Zeroping. It took root: eventually, and without ever trying, I was waking
up with solutions to all the obvious problems. It didn't take diligence or
aptitude. It just took time.
I wrote Zeroping as an argument in
favor of client-side hitscan, and am now looking for arguments against it.
I've collected major objections and my responses in this FAQ, and expect
to add more as the conversation continues. If anyone comes up a criticism
I can't answer, I'll gladly post it here. If programmers in the industry
have considered client-side hitscan and decided against it, I'd love to
know why.
Is Zeroping a cheap hack?
That depends what you mean by
"cheap" and "hack." If cheap means it's unfair, and hack
means it's somehow incorrect, then no, Zeroping is not a cheap hack. See
the sections on Fairness and Correctness
for more. If cheap means inexpensive, and hack means
awkwardly coded, then hell yes, zp is both (I bent over backwards to make
the client-side code small). |
Gameplay |
Why did low- and high-ping players
disagree so strongly about the Alpha's gameplay?
In the Alpha release of Zeroping,
some noticeably screwy things happened when high-ping players hit people:
Their shots appeared to be off-target, but registered anyway; It was
possible for them to shoot people around corners; Most annoyingly, hpb's
could sometimes kill you twice in a row by getting two quick headshots.
Modem players were, for the most part, glad to put up with the
anomalies in return for lag-free firing. Low-ping players were
understandably less happy. With hpb's getting so many bizarre-looking
kills, low-pingers couldn't help feeling gipped.
The Beta version
fixes the oddities of the Alpha release, and gameplay is now solid for
everyone. Although very low-ping players still don't benefit much from
client-side hitscan, they will notice that hpb's whine much less
on Zeroping servers. That, I'm sure, will make T1 players happy.
What gameplay quirks are
visible in the Beta?
Although the Beta version of
Zeroping looks and feels very much like normal net play, you may notice
two side effects of client-side hitscan. First, high-ping players will
seem to be aiming at a spot behind you when they miss, but when
they hit, their shots will be on-target. This makes hpb's look like they
have worse aim than they really do, and their hits are sometimes
surprising. The second side effect makes modem players' hits even more
disconcerting: because your computer doesn't know about their shot for a
little while, high pingers may seem to be hitting you at nearly
impossible times -- in mid-dodge, for instance.
Although these
side effects can be frustrating for low-ping players, it's important to
understand that modem players are not having an easier time
aiming than you are. On their screens, you're still jumping around like
mad, and can be very hard to hit. See the section on Fairness for
further explanation.
I tried a Zeroping server
and it sucked. Why?
A lot of variables affect the
quality of net play, and it's sometimes hard to figure out what makes a
particular server perform well (or awfully) for you. Because everyone
knows that Zeroping modifies UT's networking code -- but not always how --
zp often ends up taking the blame for bad connections or sick servers.
The easiest gameplay complaints to answer are the ones that have
nothing to do with Zeroping. One player emailed me complaining that the
Minigun is too powerful with zp; in fact, the current version doesn't
affect rapid-fire weapons at all. One of the first times I played Zeroping
on a public server, I was horrified to see ten-second waves of lag every
minute or two; later the administrator told me that the server had been
doing that before he ever installed Zeroping. On another server, a player
mentioned that his ping had increased noticeably in the two days since the
server started using Zeroping. A few minutes later he complained that his
frame rate had dropped to 10 fps since he installed Windows 2000... two
days earlier.
It happens both ways: one person emailed me to let
me know that Zeroping is great, and the www.zeroping.com server is smooth
as can be! But I have nothing to do with www.zeroping.com, and they don't
use my mutator. He just had a good connection to a good server.
For the record, Zeroping does not affect rapid-fire weapons,
projectile weapons, or movement. It doesn't change your ping (as reported
on the scoreboard), make the bots harder, or cause skins to turn green. If
you're seeing cows, that's the Bonus Pack.
The best way to see
what Zeroping does is to join a zp Instagib game, and compare the primary
and secondary fire modes. Primary uses Zeroping; altfire is the original
UT code.
Does Zeroping skew Unreal
Tournament's weapon balance?
Maybe. Which game has the "right"
weapon balance: normal Internet play, or LAN play?
Zeroping does
make the sniper rifle, shock rifle, and enforcer much more powerful than
they were in the hands of a modem player. However, it doesn't make them
any more powerful then they are in a LAN game. The only thing preventing
CTF-Face from deteriorating into spawn-sniping in LAN play is the fear
that your victim will cross the room and punch you.
I think
Zeroping brings Unreal Tournament's weapon balance back to where it is on
a LAN. Although projectile weapons still have lag, they're very effective
anyway. Epic designed the projectile weapons so that they have strengths
that compensate for the time it takes them to reach their targets: the
flak cannon has shot spread, the rocket launcher has splash damage, razors
bounce and the bio-rifle's all gooey. These strengths do a good job of
balancing out lag, as well as travel time: modem players use the flak
cannon and rocket launcher more than they would on a LAN, and often forget
about the shock rifle completely.
Although the Zeroping sniper
rifle may be too powerful in team games, that's not exactly my fault. The
sniper rifle's just a very strong weapon, and modem players haven't been
able to use it well until now. |
Security |
What does it mean to say
that Zeroping is "secure enough?"
Zeroping is secure enough
if it doesn't make cheating any easier than with normal UT, or let people
cheat more for the same amount of work. Client-server games are never
completely secure; a good hacker can reverse-engineer any game, and write
a hack that automatically plays better than the best human. The only thing
preventing people from hacking games is the time and work required (and
the fact that playing with a hacked client is pretty boring). As long as
Zeroping doesn't allow people to cheat more easily or effectively than
they can with ordinary UT, it's secure enough. It will always be
possible for people to write hacks that are specific to Zeroping,
but anyone who does this is taking the long way around.
Isn't it easy to write an
aim-bot proxy for Zeroping?
Not anymore. As I said earlier on my
web site, the Alpha release had absolutely no protection against proxy
attacks. A hacker could have written a simple program that sits between
his client and the server, which would claim to have hit other players
whenever he chooses. Surprisingly, no one ever did. With the Beta, this is
no longer a problem.
The Zeroping Beta encrypts its network
traffic so that hit packets can't be forged by proxies. Before
distributing the Beta, I wiped all source code from the .u files, to make
reverse-engineering difficult. Any attacker who wants to crack the
encryption will have to figure out my algorithm using only the bytecode
for Unreal Tournament's undocumented virtual machine, packed in a file
format that's pretty confusing to begin with.
While it's not
impossible to write a proxy, it's hard enough. My current encryption
wouldn't stand up to serious cryptanalysis, and falling back on bytecode
for obfuscation isn't exactly iron-clad. But writing a Zeroping proxy is
now considerably harder than hacking Unreal Tournament's checksum
enforcement, which would allow you to write an UnrealScript aim-bot
anyway. Since the zp Beta only allows hits that are physically possible,
you gain no more from a zp proxy than an UnrealScript aim-bot. Anyone
who's attacking Zeroping's network traffic is wasting his time if his goal
really is to cheat; UT is the weak link now.
Isn't Zeroping susceptible
to client-side UnrealScript hacks?
If an attacker can run arbitrary
UnrealScript routines on a client machine, he can easily cheat at Unreal
Tournament -- with or without Zeroping.
It's possible to piggyback
my encryption routines to manufacture hit packets, but there's a much
simpler and cleaner way to cheat with UnrealScript: point the player at
the nearest opponent, and call the weapon's Fire() routine. Once you've
done that, you have an aim-bot that works with or without Zeroping. If an
attacker can bypass Epic's checksum enforcement and run client-side hacks,
Zeroping is just as susceptible as Unreal Tournament itself:
completely.
Isn't it possible to cheat
by unhooking your connection?
Not in the Beta. The Alpha version
allowed you to run around killing people while you were lagged out. The
Beta ignores old hit claims, and reverts to server-side hitscan. In cases
of packet-loss or cable-pulling, the Zeroping Beta behaves exactly like
ordinary Unreal Tournament.
Is the Zeroping Beta "secure
enough?"
I believe so. Attacking Zeroping
with a proxy is harder than hacking Epic's checksum enforcement.
Zeroping's no more susceptible to UnrealScript hacks than UT itself is.
The no-brainer plug-pulling cheat is history. Unless there's something I
haven't thought of, Zeroping is now as every bit as secure as Unreal
Tournament. I leave it up to the community to find anything that I've
missed. |
Correctness |
Isn't it incorrect to let
players aim at predicted targets?
We're already aiming at predicted
targets -- but the prediction's normally done on the server. When you run
around in Unreal Tournament, the server's idea of your location is delayed
by your ping, and updated less frequently than it is on your computer. We
don't usually think of the server's image of you as "predicted" because
it's always the definitive version. But it is, in reality, a prediction
between updates. The same thing is true of your image on other players'
computers -- in fact, the same code is used to predict movement on both
client and server. While the client's predicted targets are older, they're
no less correct.
Does Zeroping violate the
rules of physics?
The Alpha did; the Beta doesn't. The
Alpha test sometimes allowed people to shoot you after you ducked behind a
corner; made hits appear to miss and vice-versa; and made it possible to
kill the same player twice in a row with double headshots. The Beta
version puts a stop to these shenanigans. Zeroping's adherence to the laws
of physics is now strict as a billiard ball's.
Isn't everyone on a Zeroping
server playing a different game?
No. As always, all game state is
kept on the server, and each client updates directly from there. The only
change Zeroping introduces is that clients see their shots appear
instantly on their own machines, and don't see exactly the trajectory that
other clients will. As far as correctness is concerned, differing shot
trajectories is much less of an issue than client-side movement's quirks.
Isn't this a misuse of
Unreal Tournament's movement prediction?
Unreal Tournament's client-side
motion predict wasn't meant to be used this way, but it works
well for the purpose. In standard networking code, the client's image of
another player is like a phantom: you can aim at it, but that's not what
you're hitting; the real shot occurs on the server, and it's only a hit if
it goes where the server says that player is. The server's idea of what's
where is definitive, and the client's version of the world is just for
show.
When programmers hear that Zeroping traces hits against this
phantom world, they usually get a queasy feeling in their stomachs,
because they've become accustomed to the idea that client-side proxies are
less real. However, the server's image of a remote player is itself a
shadow of where the player used to be; we only make it definitive by
convention, because it keeps things very simple. We should, of course,
continue to use the server image for all physics and collision detection.
But the client image is the ideal (and, I believe, more
"correct") target for hit tracing. It takes a little work to make the
client version serve this purpose, but once done it's no less correct than
tracing against server proxies.
The big hitch is packet-loss. If a
player is lagged out, server-side hitscan automatically makes him pay for
it. With a straightforward implementation of client-side hitscan (like the
Zeroping Alpha) a lagged player can benefit, because UT's motion
prediction makes everyone else an easy target. The Beta fixes this problem
by having old hits timeout -- so that lagged players' hit claims are
ignored, and server hitscans done instead. An ideal implementation of
client-side hitscan would enforce constant refresh of proxies, but that
appears to be beyond the power of a UT mutator. See the section on Fairness for
more.
In practice, client-side hitscan works very well. Since
Unreal Tournament uses the same code to interpolate position on both the
server and the client, movement is qualitatively the same. Hit
thresholding ensures that clients don't benefit from packet-loss, and that
other players are valid targets only as long as they're able to keep
moving. Although Zeroping has made some programmers queasy, it's made a
lot of gamers happy, too. I hope this FAQ will please the queasy.
|
Fairness |
What do you mean when you
say that Zeroping is "fair?"
In Internet games like UT, players
with faster computers and lower-latency net connections will always have
an advantage; a truly "fair" match is impossible. My goal with Zeroping is
to limit as much as possible the disadvantage of a lousy connection,
without making people with good pings suffer for it.
More
precisely, I'm defining "fair" in the following, very limited sense:
Zeroping is fair if it does not allow a high-ping
player to win more often than he would have if he'd had a lower ping.
The phrase "more often" is in there to prevent contrived
counter-examples. Whenever you change gameplay in any way, it's possible
to construct pathological scenarios where a particular game's outcome
differs -- even if the change is something as innocuous as lower gravity
or faster lifts. I'm saying that Zeroping is fair as long as it does not
allow a higher-ping player to win more often in general. An ideal
test would be for two players to play a large number of matches against
each other, with one player running a listen server, and alternating after
each win. Unless the higher-ping player wins more often than the
lower-ping player by a statistically significant margin, Zeroping is
fair.
Note that my definition makes no assertion about
hpbs' rights. Since I'm trying to raise modem players' gameplay above an
already-low baseline, nobody's really arguing that Zeroping is unfair to
high-pingers. A few people have said that Zeroping hurts modem players
because it "makes them think they got skillz," or are insulted by the
insinuation that hpb's need help -- but for the most part everyone agrees
that client-side hitscan helps modem players. My goal in this section is
to show that it does so without hurting anyone else.
Doesn't Zeroping make it
harder to dodge other players' shots?
No, but other players may
seem to be making some very difficult hits.
Dodging
hitscan weapons is fairly steady-state: When you know someone's sniping at
you, you juke and weave to stay out of the crosshairs, but you can't react
to individual bullets the way that you would to rockets or plasma fire.
Since you don't know in advance when and where an instant-hit shot is
coming, you have no time to react to the other player's shots, and your
movement pattern is what's important. If your attacker is running
a listen server and has a ping of zero, her ability to hit you depends on
whether or not she can click on your image while you jump around like a
madman. With Zeroping, the same thing is true of all attackers, regardless
of their pings. It's just as hard to click on a delayed image of a dodging
player as it is a current one; you still have no idea which way he's going
to jump next, even though each jump is 300 ms old. That means modem
players and server ops alike find it equally hard (or easy) to hit you.
However, Zeroping can often make it seem like modem
players are pulling off near-impossible shots, because other players don't
see the hit until it comes through the server. Say, for example, you're
double-strafe dodging repeatedly in an open area. In mid-dodge you're very
hard to hit, but between dodges you're an easy target. If a modem player
manages to click on you between dodges, the shot may not reach the server
until you're in the middle of the next dodge. The modem player will seem
to have nailed you in the middle of your slickest move, but in fact she
put a bullet in your head while you were getting your footing. It's
important to understand that you're getting hit because you were
an easy target at some point in the past -- but you were only vulnerable
to the modem player for the short amount of time that you were to everyone
else. It's no easier for modem players to hit than it is for T1 players;
modem players' hits just register at odd times.
What about packet-loss?
As long as opponents are getting
steady updates of your position, Zeroping lets you dodge as well as
before. If another player experiences heavy packet-loss, however, your
image will be dead-reckoned until their client hears from the server again
-- which would make you a very easy kill. The Zeroping Beta defends
against this by putting a threshold on the age of hits allowed; if the
server receives an out-of-date hit claim from a lagging client, it ignores
it and reverts to server-side hitscan. Although the server-side shot is
unlikely to hit anyone, you can't aim well when lagged out anyway, so
you're suffering more than you normally would while lagged. Zeroping will
display a message whenever a hit times out; if you see this message often,
then you should find another server. A game with extreme packet-loss just
isn't playable, with or without Zeroping.
A perfect implementation
of client-side hitscan would enforce constant position refresh rates
across all net connections. For example, the server would send out
location updates at 20hz, and the game would not allow players to hit
targets that are significantly older than 50ms. Although UnrealScript is
very flexible, this kind of micro-management seems to be beyond the power
of a UT mutator. If anyone knows a reasonable way to enforce constant
refresh, please let me know.
In practice, Zeroping's current
approach works very well. Players see each other moving fluidly except in
cases of extreme packet-loss -- and in these situations the lagging player
suffers, rather than his opponents. This ensures everyone's ability to
dodge as long as their own connection is healthy, and prevents simple
cheats like unplugging your ethernet or choking down your netspeed.
If dodging isn't
steady-state, then Zeroping is unfair, right?
Nope. If dodging isn't (as I claim)
a steady-state activity, then high- and low-ping players will find it
equally hard to dodge each other's shots, since they both see positions
that are as old as their combined lag.
Say Alice is a
modem player with a one-way latency of Lag_A milliseconds (so that her
"ping" is displayed in UT as 2*Lag_A). She's playing lpb Bob, with one-way
latency Lag_B. If Alice strafes left at time T, her move reaches the
server at time T + Lag_A, and Bob sees it at time T + Lag_A + Lag_B. If
Bob strafes right at time T, the server gets word at time T + Lag_B, and
Alice sees the move at time T + Lag_B + Lag_A. So each player sees an
image of the other that's (Lag_A + Lag_B) ms old. If it is, in fact,
easier to click on a delayed image of another player, then Zeroping is
still fair (meaning high ping isn't an advantage), since players
see equally old images of each other. Actually, the lower-ping player
still has the advantage, since the server will hear about his shot first.
Does Zeroping make it harder
for low-ping players to hit people?
Not at all -- in fact, Zeroping
makes aiming more accurate for low-pingers too. But it's possible to grow
accustomed to a 30-60ms lag on firing, and some hardcore low-ping players
are thrown off by Zeroping. Others are afraid they'll get used to lag-free
play, and lose their edge on standard servers. The Zeroping Beta allows
you to disable client-side hitscan on your own weapons for just these
reasons. Type "mutate zp_off" at the console, and you'll be able to play
with the lag you know and love. This setting is saved in Zeroping.ini in
your UnrealTournament/System directory, so you'll only need to do it once
in your life (well, you'll have to do it again when the next version of zp
comes out). You can use "mutate zp_on" to restore Zeroping later.
|