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.
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.
Nice reading ^^
But I got a little question: you just said to transfer latency from shooter to the escaper... but what if the "escaper" isn't escaping? What goes on during normal confrontation or better to say direct battle? This kind of tracking and detecting a hit enables the chance of beeing killed by the other player without knowing that you are allready dead... in this case the other client doesn't know the player is dead and track the remaining hits he does before getting information about own death from the server. In worst case the shooting enemy will be killed by the killed "escaper" ^^ you know what I mean?
Yeah, it works well in direct confrontation, never seen any problem when playing with people. The only side effect is that you can kill each other :) It doesn't happen that often, but it's funny and actually fair. Because when each client was shooting to the other they were still alive at the time and should have equal chance of killing the other one. I don't know if I should remove this feature, but the thing is that server would have to choose the one with higher latency to die, not quite fair. This is the way how other games handles it when everything is server-side. We'll see.
I also plan to have some latency (ping) handling, like server admin setting for maximum ping of players and some graceful enforcing of it so there will be controlled limit of the behaviour. But the game works pretty well even at insane pings like 500+ (even with packet loss, unless I screwed the test), better than other games actually.
wow ^^ sounds great :)
will be testing it as soons as possible... 2 running projects and work XD it kind of kills me X-P
but will be testing it :)
Your long description of using the same model for first and third person views can be solved with 3 words: True First Person (as in what you see from first person view IS the external model)