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.
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. 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. Unicornkill (2010/01/07 21:54)
Have you finished coding the server-side prediction?
Is this already implemented?
3. 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. 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. 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.
Don't know yet about concrete requirements for server, but it won't consume too much CPU nor memory.
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. 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.
7. jezek2 (2010/01/08 17:21)
Yes and yes, it will definitely stay "slower" :)
8. Unicornkill (2010/01/08 20:40)
super :p
now add a shotgun and a difficult to master akimbo and i'm hooked :p
well, a mapping tool would help too :p
darn, I gotta stay calm about this :p can't get too exited yet