Blogs - Snak3Doct0r

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: -

Id: Fabiensanglard.net

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.

Development Report

In this latest Dev Blog we wanted to provide an update on the development of the prototype. Overall things are going slowly and we’re happy with the progress to date. We hope to move beyond the prototyping phase and into full development shortly now that we’re confident that we can do our ideas justice and that The Ranger Unit will be fun, enjoyable and challenging. To date, we have the following core elements up and running to a level we’re happy with for the time being: -

Graphics Engine – While we know it will be difficult to match similar big budget titles we are confident our graphics engine will be right up there with comparable games. We’re currently playing around with some post-processing effects to allow us to portray the feeling of being in different parts of the world at different times of day, it also allows for a cool night-vision effect. We are also drawing decals for shot collisions to provide the user with enough feedback to feel like they’re really shooting a weapon.

Materials Editor – done and dusted for now but we will need to add more material types and effects later.

Audio – We have an audio engine in place with gunshot effects.

Networking – We have online communication up and running and have introduced a system to smooth over lag.

Controls/Camera – We have the basic first person controls/camera in place and have tried to give our game it’s own feel/tempo within that framework.

Physics – We have shooting and movement physics up and running.

Collisions – We’re particularly proud of the collision system, especially for characters moving against walls/windows and going up/down stairs.

Level – We purchased a 3D model of a military base with buildings and vehicles for the prototype. N.B. for the foreseeable future all art and audio will be placeholder, we’ve been using royalty free assets and will eventually replace them with professionally made resources for release.

Our next goal is to introduce some very simple gameplay elements or scenarios. Our aim is to add a basic shooting range with targets and scoring system and a simple online Deathmatch mode. Once they’re in we can then make the final call as to whether we’re happy that the prototype provides enough fun and enough potential to start full development. We hope to be able to share the first screenshots with you in the near future. It’s always a difficult balance between showing something too early that doesn’t do the game’s potential justice and waiting too long. As such we will not rush to show screens that might underwhelm, we will wait until what we show is of a high enough quality to demonstrate how good The Ranger Unit is going to be. Before we get to that stage we want to tackle the following: -

1] Polish the environment and models

2] Improve environment, normal and specular mapping

3] Support animation in 3DS Max exporter

4] Add placeholder character and animations

Due to forthcoming holidays the next Dev Blog will be Saturday, June 20^th, over and out.

In this Dev Blog we take a look at the main game mode and start to break down how it works: -

Game Mode Title – Mission
Number of Players – 4*
Requirements – Internet Connection

*There will be single player modes as well, including playing the co-op levels as a lone wolf,
of which, we’ll reveal more later. We will also include several more
traditional online competitive modes but for this blog we’re just focussing on
the co-op mission mode.

Overview

The following is an attempt to lay out the basics of the main game mode. The Ranger Unit
Missions are designed to be played co-operatively, online, by a team of four.
Players meet up online and form their own Ranger Unit, with one being the team
leader, who receives live intel throughout the mission. We hope to allow each
player to have access to some basic character customisation options in terms of
camouflage, uniform etc. They can also create their own call sign for use in
game. Once a team is in place and ready to go we envisage the following flow to
the mode: -

1] Mission Briefing – Firstly The Ranger Unit will receive their orders e.g. rescue a
hostage, assassinate a target etc, along with any available intel such as maps,
enemy numbers etc.

2] Insertion – From the above intel The Ranger Unit must decide where they want to start the
mission, by marking the insertion point on a map. Initially they will then
parachute in but eventually we would like to offer some alternatives e.g. boat,
car, swim etc. We will allow complete freedom so if you want to be inserted a
long way from the target you can. If you’d prefer to be dropped close to the
target you can but the likelihood of being spotted early is much higher.

3] Extraction – The Ranger Unit will also agree an on extraction point, again, by marking a
map. Once the mission objective is complete, The Ranger Unit must then get to
the extraction point and await helicopter pick-up. The Ranger Unit will need an
alternate extraction point in case the landing zone is hot.

4] Re-supply – A third mark can be set on the map, for re-supply. If a Ranger Unit so chooses
they can arrange a parachute drop for more weapons and ammo etc. The Ranger
Unit missions will not contain ammo lying on the floor to be picked up, what
you have on you is it. We may allow enemy weapons to be picked up and used but
it isn’t confirmed yet. Re-supply is an option and not a requirement, sometimes
you may want to avoid it, in case the enemy gets to the re-up first. The Ranger
Unit is also able to decide what and how much equipment is in the drop but the
maximum is constrained by weight/size.

5] Kit – Before embarking on a mission, each player then has to choose what weapons, ammo,
armour etc to take with them. The amount will be limited by weight, similar to
the amount in real life. This will make ammo conservation a vital tactic in
game. If possible we will allow players to share ammo where applicable. We will
not have specific classes such as sniper, grunt, medic etc but players will
have the choice to specialise how they see fit.

6] Mission – Play out and complete the mission as per the objectives, then get to the extraction
point for pick-up.

7] Debrief – At the end of the mission, each Ranger Unit will receive a full debrief detailing
success/failure etc. There will be some sort of rewards/medals etc to be
decided later.

HUD – We want to keep it as uncluttered as possible. We will include a map but we may not
include ammo counts etc, requiring the each Unit member to keep tabs on their
own reserves.

Save/Load – Because of the nature of the mode we will not be able to offer a mid-mission
save but we will allow full save/load for character customisation, kit
preferences etc

Missions/Levels/Objectives –We hope to offer a large number and variety of environments, enemies,
objectives etc.

Death/Capture – TBC if killed you will become part of the team back at HQ and you can try and
assist by feeding real-time intel, possibly directing air support, hacking into
surveillance cameras etc. If captured, you should be able to alert your
teammates so they can attempt to rescue you or have means of escape.

Given we’re still very early in the prototyping phase of development, the above is very much
subject to change but hopefully it gives you an idea of the style of game we
want to make. The next Dev Blog will look to expand on another section of the
full Design Doc. Over and out.

Full Game Design Document

In this Dev Blog post we take a look at an overview of the Design Doc for The Ranger Unit. While
it isn’t necessary to write a Design Doc it’s something we find useful,
especially with regards to planning the schedule and identifying what software,
graphics, audio, sub-contractors we’ll need. Likewise, it isn’t vital to write
some all-encompassing 100 page document, do what works best for you and your
game. The aim of the Design Doc is to flesh out your gameplay ideas, features,
modes, levels etc. While a Design Doc should be flexible, you should always be
refining your game design, you are describing what you intend to do e.g. if the
Design says 5 game modes, there should be 5 game modes. As well as acting as a
“bible” for the game’s development it also allows you to flesh out a schedule
(which we will look at in the future) and identify areas where you’ll need
help.

The following is a list of the section headings, plus brief descriptions, for The Ranger Unit’s
Design Doc: -

Title: Name of working title plus the © sign and year.

Overview: Brief description of the game plus the intended formats.

Change Log: Track version updates and allow the reader to find the latest changes easily.

Contents: Many word processors such as Microsoft Word will allow you to set this up automatically.

Glossary: A list of any key words or technical jargon.

Feature List: A bullet point list of the game’s main features.

Game Style: A brief description of the style you’re aiming for.

Graphical Style: A brief description of the game’s look (e.g. Cartoony, Bright and colourful or
dark and gritty) and any key effects, including any relevant images.

Controls: A full description of every button press/control available plus details of any desired
control customisation options.

Cameras: A complete account of all camera positions, behaviours and customisation options.

Front End and Menus: A description of the menu style plus any reference images.

Attract Mode: A description of how the Attract Mode should work, when you should see
it, how to skip it etc.

Sound: A description of the front end music and sound effects.

Menu Flow: Typically a flow chart detailing all the screens and their options.

Settings: A detailed breakdown of all general game settings including Graphics, Audio, Control options etc.

Play: A brief description of the way the game works.

Structure: A detailed list of the flow from menu to game and back out again.

HUD: A full mock-up layout image plus list of all buttons and options.

Save and Load: Specifics of what and when you can save/load.

Options: A breakdown of all in-game options.

Game Modes: Repeat for all modes: -
Title: i.e. Deathmatch.
Overview: Online/offline, scoring system, end-of-level conditions, etc.
Player Options.
Number of Players.
Difficulty Levels.

Levels: A list of all available levels including details of location, layout, look, feel, special
features etc.

AI: A description of the desired Artificial Intelligence behaviours.

Appendices: -
Specification: Minimum and Recommended hardware specs, (these are “ideal targets” that the developer should aim for).
Art: A comprehensive list of all models, textures, effects etc.
Audio: An inclusive catalogue of all music and sound effects etc.

Typically a Design Doc would involve more sections than the above e.g. it might include,
story, script, mo-cap Appendix etc. the above is not definitive, just what we
feel is necessary for The Ranger Unit. Once we have written the full Design Doc
for The Ranger Unit we will host it somewhere for you to read.

The next blog will start to flesh out some of the above sections. Over and out.

The Anatomy of a Shot

The Ranger Unit prototype is officially up and running and we hope to be able to share some screenshots soon. As The Ranger Unit is a first person shooter at heart, one of the first things we had to implement was the shooting. At first thought this might seem like a fairly simple process e.g. press LMB, shoot. But that’s just the beginning, as you start to develop these “simple” ideas, you begin to realise just how much is needed. As we begin to flesh out the Design Doc (which will be covered in more detail, in future blog posts) we thought we’d look at this now, in hopes of demonstrating how something so simple can gain complexity very quickly and the importance of planning and designing what you’re doing.

Before we could even fire the first shot we needed a character and a gun. For now we’re using license free models, that are freely available online from sites such as TurboSquid. We decided early on to model the bullet flight/physics on real life data (a lot of shooters just draw a straight line from the gun, when the shoot button is pressed), so if you shoot straight up, that bullet will eventually drop back down to earth. This will also allow us to have ricocheting bullets but we haven’t decided whether we will do this or not as it could lead to some seemingly unfair deaths. Next we added collisions so we knew when the bullet hit something. To be able to test this we added decals to show the collision. We used a paintball gun and paint splatter for testing but then switched to a pistol and bullet hole decal. In the finished game we will have different materials which can react to a bullet in different ways e.g. glass shattering, for this we need a materials editor, to allow us to assign them accordingly. For now we only have one material type/reaction/decal though. With the above in we can now shoot in the prototype and see the end result but to take it forward we need to add a lot more: -
• Animation of the gun when firing – e.g. the hammer and slide moving appropriately
• Shell casing being ejected out of gun and hitting floor, plus sound effect.
• Recoil animation
• Reload animation
• Gunshot sound effect
• Bullet collision sound effect
• Muzzle flash graphical effect
• Smoke graphical effect
• Particle system for bullet collision graphical effects
Add several weapons and materials and you start to see the complexity involved and why games cost so much money to make. For now though, we have some basic shooting in our prototype and can start to move onto more interesting elements like creating a shooting range and being able to shoot other players via a network.

Now we’re into the prototyping phase we will probably update the dev blog slightly less often, to allow us to focus more on development. The next dev blog post will take a look at the basic Design Document. Over and out.

Prototyping

Having recently started prototyping some key elements we wanted to take some time to look at
what we’re prototyping and why. Prototyping isn’t vital but it is recommended,
we tend to always prototype some ideas, mainly because we’ve always done it and
we’ve always found it useful. We take the “fast and dirty” approach i.e. we’re
not considering how the game will look and sound, our aim is to try out the
main gameplay elements and to demonstrate they’re fun. With The Ranger Unit
prototype we also wanted to overcome a couple of key technical concerns, which
we’ll come back to shortly. For the prototype (and full game) we are using a
proprietary C++ game engine that is built on DirectX 11 for graphics, XAudio 2
for sound, and a proprietary physics engine. You might wonder why we don’t use
one of the superb off-the-shelf engines such as Unreal, Frostbite, Source,
CryEngine or Unity and the answer is simple: we’re control freaks! It’s very
satisfying knowing that there are no rules or limitations.

For us, the top priorities are always controls and cameras, because this is how you interact
with the game. As The Ranger Unit is an fps, the actual control layout and
camera choice isn’t such an issue, as they’re tried and tested but the feel and
speed of the controls is. For the prototype, we have a third person camera
option but this is mostly for testing collisions etc. We will also be spending
some time on the shooting and in next week’s blog we will take a much more
in-depth look at this key element. For now we are accurately modelling the
bullet physics using real life data but we may not be able to do this in online
play because of issues surrounding lag.

Coming back to the technical issues mentioned earlier, the following section looks at the two
main challenges we wanted to overcome early on: -

1] First-Person Collisions - Our engine uses a Triangulated Irregular Network (TIN) terrain and
all 3D objects have an Axis Aligned Bounding Box (AABB) tree for collision
testing. In order to allow the character to move through the world in a
realistic manner, we use a capsule (a cylinder with a hemi-sphere at each end)
to represent it. Collision detection and resolution is very simple however, we
want to allow the character to step up and over small items, including stairs.
This requires us to analyse all contacts between the capsule and the 3D world.
When attempting to move, we check if all contacts that are resisting movement
in that direction are below a certain height. If they are then we apply an
upwards impulse to step over it. Since we want our characters to be able to
crouch and go prone, we allow the length of the capsule to vary (to simulate
going from standing to crouching and vice versa). We also allow the capsule to
rotate from being vertical to horizontal, to simulate going to a prone
position. These changes to the size and orientation of the capsule are the most
common cause of problems arising such as getting the capsule embedded in a wall
or floor. A good example is being prone under a staircase and then attempting
to stand up. For this reason, it is necessary to ask the physics system if we
can stand up in our current location.

2] Networking - We have worked on several on-line games before but they have
not been time-critical. This means we could use the slower (but reliable)
Transmission Control Protocol (TCP). Since we are now working on a
first-person-shooter, we need the networking code to be as fast as possible,
therefore we are using User Datagram Protocol (UDP). We are using 'Entity
Interpolation' with the clients running at approximately 0.1 seconds behind the
server. We will be implementing 'Lag Compensation' and we are always wary of
protecting against cheating. One important feature we will be implementing is
referred to as 'NAT Punch-through'. Without this, to play online all clients
would need to setup port forwarding (unless they happen to have a fixed IP
address) just like hosts have to. By using a public "hand shake" server,
two machines that sit behind Network Address Translators (i.e. routers), can
open connections to the server and then be connected on those open sockets.

The next stage of the prototype will be to introduce some basic gameplay elements, firstly a
single player shooting range and then a very basic online co-op mission.
Assuming all the above is a success, we will then move onto the full design and
development of the Ranger Unit.

Next week’s blog post will delve deeper into what it takes to fire a shot. Over and out.

The Game Concept Document

The Game Concept Document is typically a short document of 1 to 2 pages, detailing the
key elements of your game proposal. Typically they’re produced to convince
key-stakeholders such as Publishers, Company Directors/Owners etc. to
greenlight your project for full design. As with any design doc anything you
write isn’t set in stone, you should always be prepared to be flexible, to add
better ideas and remove weak ones down the line. Design should be an evolving
progress of refinement to make the best game you can. As an Indie Dev we didn’t
need to convince anyone to fund The Ranger Unit but we still wanted to go
through the process of writing Design documentation. While it isn’t vital, it
is a good idea to help hone your vision and to commit your ideas to paper, we
also wanted it to form part of this Dev Blog. For these reasons we removed some
elements and went with a concise, one page concept doc. At some point we will
host The Ranger Unit’s concept doc and a more detailed concept doc template for
you to download.

The Ranger Unit Concept Doc: -

Game Concept Doc

Working Title
The Ranger Unit

Date
April 3rd 2015

Formats
PC

High Concept
A realistic feeling, tactical, squad based FPS.

Concept Overview
As part of The Ranger Unit you will be part of a 4 man squad, taking on the most dangerous
missions anywhere in the world.
Missions will include hostage rescue, recovering intel, assassinating high value targets and more.
The game will be a more realistic simulation of warfare, a more strategic fps as opposed
to a more traditional twitch shooter.
A stealthy approach would be encouraged as would using traditional military tactics.
Realistic feel i.e. no bullet sponges, good enemy AI etc.
One well-aimed shot can kill you, hopefully leading to a feeling of tension and danger.
Arctic, jungle, desert, urban etc levels.
Encourage players to create their own squads with unique identities, call-signs etc.
World ranking system.

Play Modes
Offline: single player missions, practice modes.
Online: co-op missions, Deathmatch, team death match, capture the flag, king of the hill.
More TBC.

Target Audience
Fans of fps games such as Rainbow Six.
Fans of stealth games.
Fans of military games.

Next week’s blog post will focus on what we’re prototyping and why. Over and out.

In this blog post we wanted to look at how we came up with The Ranger Unit high concept and our
initial vision for it. Game ideas can come about in numerous ways; brainstorming,
publisher brief, contemplation, flash of genius etc and often depend on whether
you’re working on your own ideas, as part of a team or for someone else. In the
case of The Ranger Unit, the flow was somewhat as follows: -

BRIEF: Having always wanted to work on our own FPS and having discussed various other ideas
we decided the time was right to give it a go.

R&D: We talked about various games we love and replayed some of them, like Delta Force.
We watched TV shows like The Unit and films like Black Hawk Down. We also read
up on real-life military campaigns, missions and Hostage Rescue teams and
tactics.

REFINEMENT: Over the course of a couple of weeks we started to hone our ideas and we came up
with a list of the following; fps, military, realistic, stealth, dangerous,
hostage rescue, assassination, jungle, desert, squad based, tactical. We now
felt we had a good idea for the feel of the game we wanted to make and just as
importantly, what we did not want to do i.e. no bullet sponges, no stupid enemies
etc.

TITLE: We also started to throw around various names until we found one we agreed on and whose
domain etc were available. We also gave The Ranger Unit an identity, namely,
they are an elite squad that tackles the most dangerous missions, anywhere in
the world.

LOGO: We aren’t artists but we came up with a quick mock-up to help make The Ranger Unit seem
more real and to focus our visions further. We also gave ourselves call signs;
Snake Doctor and Hammer Head.

HIGH CONCEPT: The high concept should be a one line description that sums up the title, in this
case - A realistic feeling, tactical, squad based FPS.

GAME CONCEPT DOC: We will cover this in more detail in the next Blog post.

Disclaimer – As we move forward with the blog we will start to get into the Design
Documentation stage. The aim of our Blog is to give anyone who’s interested an
insight into how we do it, not necessarily the way to do it.
While most design docs share common themes there is no definitive approach,
after all every game is different. The key thing is to go through the process
of thinking about how your game will turn out and defining the key elements and
mechanics. The easiest way to do this is by playing it in your head. By doing
this you can start to build up a feel for how you want the game to look, feel
and play. Whether you write a 70 page design Doc or just jot down a few key
points, the process of committing these key elements to paper is what’s key and
you can refer back to them whenever you need. Experience has told us that more
good things happen when you plan and more bad things are likely to happen when
you don’t. With all that said, be prepared to be flexible, the final game may
look very different to that fist vision in your mind but that’s fine, after
all, rules are there to be broken sometimes. Until, next weekend, if anyone has
any questions, please get in touch via the Comments section, if you can’t see
it then just click on the title of this blog entry.

Over and out.