Development Report
We have been focussing solely on getting Deathmatch up and running. One of us has satellite broadband and the low ping (>700ms) caused us problems initially. This blog post looks at how we managed to overcome this issue. We have worked on networked games in the past that were not time-critical meaning we could use TCP (Transmission Control Protocol) which is a slower but more reliable method of transferring data. However, when it comes to any FPS (First Person Shooter), TCP is simply not fast enough to handle the constantly changing state of the game. Therefore, we are using UDP (User Datagram Protocol) which is much faster but does not offer reliability. The key requirements of our networking code are:
1. A client’s experience must not be affected by another client who has a slower connection to the game server
2. There should be no delay after user-input to seeing the result on screen
3. Entities should move smoothly around the game world
4. It should be difficult for clients to cheat
With the above requirements in mind, the overview of our initial networking system is as follows:
The game “simulation” is running on the server and clients send their input (from mouse, keyboard, gamepad, etc.) to the server at regular intervals. The server steps through the simulation at a fixed time step and, for each step, processes any input received from the client, applies this input to their player, performs collision detection, collision resolution, and game logic, and finally creates a new snapshot of the game world. This snapshot is sent to all clients who can then use this to update their local copy of the game world.
The above outlined system already covers two of our requirements: #1 (at no point is the server or client waiting for something that might take a considerable amount of time to arrive) and #4 (we have an authoritative server and clients are simply slaves). To address #2, we use “Client Side Prediction” which allows the client to react to the player input immediately rather than wait for information to be sent to the server and then wait for the server to reply with the effect of that input having been applied. To achieve this, the client is permitted to apply the input to a local copy of the game state and, using exactly the same code as the server, predict what will happen as a result. When the server sends a snapshot that has applied the same input, if they differ (for example, if your player collided with another player) then the local copy is re-calculated with the new information. Finally, for requirement #3 we use “Entity Interpolation” - given that the client receives snapshots of the game state at fixed intervals, it can interpolate between these snapshots to produce smooth movement.
Having met our requirements, the next step is to compress the data being sent over the network to an absolute minimum. This is best achieved by working with “delta values” (i.e. the difference between the current state and the last acknowledged state).
Thankfully, these techniques have been tried, tested and perfected by companies such as Id (Quake 3), Valve (Counter Strike), and Unreal (Unreal Tournament). There are several resources on the web that give details on the methods used: -
Valve: Developer.valvesoftware.com
Unreal: Udn.epicgames.com
Gaffer on Games: Gafferongames.com
Gabriel Gambetta: Gabrielgambetta.com
Our intention is to continue on until the Deathmatch mode is complete enough for stress testing. As soon as we have details of the test, we’ll be in touch. Until next time, over and out.
The Ranger Unit: Sit Rep 1 - March 22nd 2015
Welcome to the inaugural Developer Blog post for The Ranger Unit, a new first person shooter, currently in the very early stages of development. We have decided to start a DevBlog as early as possible, to provide an insight into the development cycle from start to finish, including: -
Conceptualisation – How we came up with our theme, tone, vision etc.
Prototyping – What our key goals were and how we planned to achieve them.
Design – Over the coming weeks we will build up a full Design Document and share it on the blog.
Coding – We aim to provide insight into the coding of the prototype and game.
Testing – From Design testing, to a beta-test and final QA.
Release and beyond – Support and updates.
We have worked professionally in the games industry for over 15 years, working on a wide variety of games and genres. We continue to make games for a living but often play, discuss, design and develop other games in our free time. Our gaming history as players dates back much further to the days of the C64, Spectrum, NES etc. Amongst many other games and genres, we are fans of Airborne Ranger, Delta Force, Doom, Quake 1 and 2, to CoD, Battlefield 2 etc. We also love TV Shows like the Unit and 24 and films like Black Hawk Down and Zero Dark Thirty. We have long wanted to work on our own first person shooter and The Ranger Unit is it. It is still very early days but we have now started to establish an online profile for The Ranger Unit, see below: -
Our website can be found here: www.TheRangerUnit.com
Facebook: <a >Facebook</a>
Twitter: @TheRangerUnit
If you would like to contact us, you can do so via info@TheRangerUnit.com
We intend to update the blog every week or two, so please stay tuned. The next blog post will look at the inception of The Ranger Unit and our initial plans for developing it.
Over and out.