Blog

WYSIWYG in Resistance Force (2010/01/07)

WYSIWYG (What You See Is What You Get) is a major feature of Resistance Force. Originally
this term is used for describing text processors (like MS Word) that displays exactly the
same layout as the resulting output from printer. But this term also perfectly describes
one of goals for this game.

Actually it's not one feature, but more a philosophy that affects the game across several
individual features. For example in most FPS games there is distinction between player
model when seen from own eyes and when seeing other players (or yourself using 3rd person
camera). They are usually lower detailed "external" model that everyone can see (eg. in
multiplayer) and higher detailed weapon with hands only model. This is logical separation
for performance and detail reasons. But it also means that the models are not synchronized,
in fact the pose as shown by the weapon model doesn't match the external model at all in
most games.

In fact games cheat by displaying the weapon model over all other geometry so when you're
very close to a wall, your external model is actually intersecting it and visible outside
whereas your weapon model is just drawn over all other geometry so you never see that
you intersected the wall and it looks nice. This doesn't matter in single player game
and makes the life of developers much easier. But in multiplayer it's a big problem as
you reveal your position to enemy and what is worse in some games you can be even shot from the
other side!

The solution in Resistance Force is to have only one model that acts both for internal
and external view. This way you see exactly what others would see, even when you're
intersecting the wall. The fix is easy: when near the wall the player will just put his gun
down or up so he doesn't touch the wall. The nice thing is that when some bug (eg. in map
or game code) results in intersection of the wall the players will immediately notice and can
report the bug.

Another aspect is collision detection when firing at other players. Most games use the hit boxes
for detection. Instead of detecting the collision with player model (which can be quite
expensive), it's done against simplified geometry consisting of several boxes that are
mapped to original model as closely as possible. This simplification is very common, especially
when it comes to physics simulation. It's a great thing, except that firing is a very precise
operation (even more in slower paced reality based games) and skilled players will notice it
very soon. Some games even have totally bad positions of hit boxes when the player is in certain
positions or when moving from one animation to another.

In Resistance Force the collision is always tested against the player model and no hit boxes are
used. This leads us to next problem, collision detection in network game. The problem is that
sending packets from one computer to other over network is slow. I don't mean the bandwidth but
the latency (ping). Even on very fast connections it's still noticeable. The naive approach is to have
"dumb" client that sends just the inputs and displays what it receives from server. The server
has full authority over the game but due to latency the player doesn't see his own actions
immediately.

For example, when you look left using your mouse, it prepares and sends packet to
the server, the server processes it and send back new view position. The network communication
must also handle packet loss and other not nice things that can happen when sending packets
over internet. All the processing from moving the mouse to seeing the result on screen has
very noticeable latency that results in some sort of motion sickness and is unplayable. Even
when playing on LAN it's noticeable, though still acceptable.

The solution to this is to predict movement on server side and do the movement directly
on client when pressing the button or moving the mouse. In most cases after the packet
reaches the server it concludes the same movement and it's OK. There can be small inconsistencies
here and there (due to slightly different position of players as seen on server side, small packet
loss, etc.), in that case the server just corrects the client side position and everything is allright.

Most games are obsessive against fighting cheaters to the extent that it actually hurts
gameplay for non-cheating majority. Just how many times did you hit someone, the blood was splashing
all around and nothing happened? This is direct result of server authority over game and client prediction
that is used in most games. This is just effect of latency, you hit someone, the packet is sent over
the network and when it finally arrives to the server it's decided if you actually had hit something or not. But for good
effect the client has to respond immediately by splashing the blood, otherwise it would look very
unnatural. It has to splash blood even when there is no hit because the client can't tell it beforehand,
it's not authoritative over the game.

Resistance Force is partially authoritative on client. The movement and stuff like grenades are handled
classically, server is deciding stuff and client gets corrected if differs. But the firing is controlled
by the client. This allows to have direct response because the client knows and can decide if the other
player is being shot or not. This also helps greatly in lag reduction, in fact the lag issue is entirelly shifted
from firing player to escaping player. This is good thing, when firing you're directly looking at your
enemy (so having no latency is very appreciated), but when escaping you're usually not looking at the enemy
so the latency issue is not (that) visible.

More experienced players immediately thought about how easy it would be to cheat in such system and
they're right! But this is also easy to detect, so no issue here really. Most game creators are very obsessed
about preventing any form of cheating, but they're not thinking in a larger picture. The reality is
that preventing any possible cheating also hurts normal players and the cheaters still cheat anyway :)
There are better ways how to deal with cheaters without hurting gameplay for normal players, I'll write more
about it in some future blog post.

Comments

1. By Silverfish (2010/01/07 16:51)
That was an interesting read! I'm looking forward to reading about how you will prevent cheating!

I also want to say that I REALLY appreciate your WYSIWYG approach, too many games don't do that, but now I know of two indie games that are taking that approach so it's pretty exciting. I hope the big companies will be inspired.

2. By Unicornkill (2010/01/07 21:54)
Have you finished coding the server-side prediction?
Is this already implemented?

3. By jezek2 (2010/01/07 23:08)
Yes, it was implemented long ago, otherwise the fully playable alpha version wouldn't work :) Actually it is not that complicated as it can sound.

4. By Unicornkill (2010/01/08 08:58)
but it would take at least about 5 times as much processing capacity of your server, wouldn't it?
How do you see req server configuration for the completed version? How much players would it support?

5. By jezek2 (2010/01/08 09:21)
There is practically no overhead for the client-side prediction (this is the official term, of predicting what will happen on server in future right now on client).

Actually it works by running the same game code as on server. The only thing that complicates it is when correction is applied to client. In other games it usually replays all actions from last acked state from server, but I took simpler approach of just setting the right position over time (so the correction movement is smoothed). Works well and has very little overhead.

The maximum will be like 16 players on server (8vs8). More players is not much fun anymore with this kind of game. Also map sizes won't be that big, so having more players would have overcrowded effect.

6. By Unicornkill (2010/01/08 17:13)
so you plan to 'keep' the general feeling of controlable battles we had in tce?

how about game speed? will you keep it at the same pace or would you make it faster? I personally found it very well balanced. That speed keeps it real and especially keeps all types of weapons usable.