Game & Level Designer
Tim Andersson
Immersive Sim RPG
Inspired by classic PC games such as Deus Ex and System Shock, this experience features highly integrated RPG systems,
seamless interaction between HUD and the game world and highly interactive levels where the player makes their own
path forward.
Project Overview
Project Goals
-
No asset packs
To acquire as many skills as possible I imposed a challenge to create everything myself. The UE4 FP-template and SFX assets are the only exceptions. -
Player agency
The player creates their own playstyle and decide how to navigate the world and solve problems. -
High complexity and depth
I wanted to create nuanced and deep systems and worlds to give the player high freedom. -
High optimization and scalability
As a long term project I wanted to make the system was built on top a solid foundation and avoid potential technical debt. -
Immesion and Game feel
Valuing immersion in games, I wanted to make an effort in creating believable narratives and offer the player high interactability and gameplay feed back.
Focus Areas
- Game Design
-
Technical Design
-
Level Design
Tools Used for Development
-
Unreal Engine 4 - Project is built using UE4
-
Adobe Photoshop - 2D Assets and Level Design
-
Blender - 3D Modeling
Game Design
Game Design: Movement
Climbing and leaning
The player can climb ledges and lean. Getting the climb to work as desired has been a challenge I've struggled with through several iterations. The current itteration uses line traces to look if there is a viable position in reach.
Climbing used for both vertical and horizontal navigation
Crouching
Crouching functions mostly as any other first person with the exception of dynamically adjusting height when entering lower spaces. This gives the feeling that the character is going prone.
The player hiding under a table, leaning out to see if the coast is clear
Game Design: Cursor Mode
Keys take various forms in this project. This example shows the seemless interaction between HUD and world using cursor mode.
Interacting with pick-up items using cursor mode
The player is pressing buttons on a keypad using cursor mode
Cursor mode can be enabled at any time by pressing the F key, and switches mouse controls from free look to mouse cursor.
-
Enables greater interaction with the hud
-
The player can interact with items in the world, like taking a soda can from a table and putting it into their inventory or pushing buttons on a keypad.
-
Cursor mode seems to be jaring to players trying the game out for the first time, but I believe it ultimately creates a greater interactability and immersion.
-
The cursor mode is almost never essential and is supplementary to standard first person controls.
Inspection
In order to provide the player with contextual clues and exposition I built an inspection system. The system allows me to assign text to individual objects or classes that are read by hovering over them in cursor mode.
To further flesh the system out I also designed a log system that can receive quest objectives,
-
By looking at an item a name label appears under the player's crosshair.
-
If the player hovers the mouse cursor over the object in cursor mode important clues or simply lore text will appear instead, presented as the player character's thoughts.
-
Sometimes the content of these labels will change if the object is interacted with.
Inspecting a lock. Interacting with it updates the player's log
Game Design: RPG Systems
The player at a level up station
Feature goal
One of my primary goals through developement has been to create an intricate RPG system with a tangible effect on how each player chooses to build their character.
Although there are stats that simply increase damage and HP numbers, I've taken care to make sure that every stat affects how playing the game feels.
Stats can be allocated at the start of the game and purchased at certain stations during game play. With some exceptions, stats themselves do not affect game play, but are rather used in calculating derivative stats.
Derivative stats are the values that actually affect gameplay and take a number of variables into consideration. Some examples of derrivative stats are Movement speed, damage and recoil.
The purpose of the derivative stat system is to create nuances and join different rpg features.
Simplified version of the update derivative stats blueprint function
Actual Update Derivative Stats blueprint function.
Most nodes are other functions written by me
Implementation
Having learned from previous mistakes and difficulties in scaling larger projects, I decided to utilize function library blueprints. One of my most important functions is the Update Derivatives Function, which is responsible for taking all the player's variables into consideration and applying its actual performance.
This function is called whenever the player increases its stats, changes equipment, certain consumables are used and so on. Because this function is a large operation, triggering a chain of other events and function, and is called fairly often I implemented a feature to only run parts of it to make it more optimized. After all, if the player changes weapon, there is no need to recalculate max HP or movement speed.
Equipment
Guns and armor pick-ups
How equiping items work
The player can find weapons, armor and implants in the world that can be equipped. Their effects are compared with the players stats before actual values are set.
-
Armor is very useful but always has downsides. Wearing no armor should also be an option worth considering.
-
By designing integration for data tables it's very easy to create new weapons and armor.
-
Making unique model and sprite assets has been challenging but worth it.
Game Design: Weapons
There are two parent blueprints for weapons. One for melee weapons and one for guns. Each gun has two modes that can be toggled by hitting the T key. These modes give each weapon some flexibility and makes things a bit more interesting.
The pistol, for example has a semi-auto default mode, and a powerful burst fire mode. The burst fire mode drastically increases it's damage per second but makes it wildly inaccurate for a novice gun slinger with insufficient stats to handle the recoil.
Some weapon are arguably stronger than others, but each weapon has some advantage over the others.
Parent blueprint for all guns
Line up of weapons benefiting from the "Gun" stat. The shotgun is not finished and the grenade launcher has no unique model yet
Tech weapons benefiting from the energy weapon stat.
Weapon Showcase
Check out some of my weapons down here in the shooting range!
Put on some head phones if you can to hear the sound design as well, but
please mind the loud volume
There are currently player animation states for handling a rifle, pistol or melee type weapon.
Each gun has their own unique animation, sfx and particle sequence when shooting.
Pistol
The Pistol is basic but shouldn't be dismissed as some generic pea shooter. I have made efforts to give it a sci-fi feeling by making it feel far more powerful than a contemporary handgun.
Advantages
-
High handling gives it a low spread penalty while moving
-
A higher base to stat scaling damage ratio make it suitable for any character.
-
High damage potential in burst fire mode
Disadvantages
-
High recoil makes accurate fire need proactive aiming
-
Burst fire almost useless without stats to handle the recoil
-
Low magazine capacity, only holding 9 rounds.
Pro: Accessible. Accurate even while moving
Con: Not the best for intensive large scale battles
Laser Blaster
Pro: Efficient and has no recoil
Con: Not as consistently powerful as ballistic weapons
I wanted to make sure that energy weapons felt distinctly different from standard guns and there is no better representation of this than the Blaster. It gets reloaded with the player's energy rather than bullets from the inventory, and can be overclocked.
When overclocked shot damage and velocity is increased, but shots are delayed meaning it takes a split second for the shot to be released after pulling the trigger.
Advantages
-
Has no recoil
-
Consumes renewable energy rather than bullets
-
Packs a real punch when in overcharged mode
Disadvantages
-
Overcharged mode is inefficient and its delay before shot is difficult to handle
-
Can quickly run out of ammo if there are no accessible charging stations
-
Ill suited for very close engagements
Auto Pulser
Inspired by sci-fi like Starcraft and Aliens, I wanted to make a hard sci-fi gauss gun. Using electrictal current instead of chemical combustion for propulsion, the Auto Pulser fires magnetic darts with the holder feeling no more recoil than holding a purring cat.
Advantages
-
Suitable for both long and close range
-
Its overclocked mode has a ridiculous firing rate
-
Large ammo capacity and bullets are cheap
Disadvantages
-
Low damage per shot
-
Its bulky design makes it inaccurate while moving
-
The alternate firing mode is very wasteful on ammo
Pro: Cheap ammo, high fire rate
Con: Low handling means poor accuracy when moving
Machine gun
Pro: All around excellent
Con: Requires high stats to use effectively
Likely the best performing weapon, the machine gun requires a heavy stat investment to make the recoil manageable and damage per bullet value efficient. I argue that a futuristic military grade assault rifle should be a very strong weapon which made implementing disadvantages not as easy as for other weapons. Can be toggled between full auto and an accurate semi-auto. Also has a faint flashlight attached.
Advantages
-
Can be used for any situation
-
Incredibly powerful in the hands of a gun specialized character
-
The compact rifle design means low accuracy penalties from movement
Disadvantages
-
Incredibly inaccurate without sufficient stat investment
-
Low base damage means the pistol gives more damage per shot to an untrained character
Technical Design
Technical Design: Inventory
Arguably my largest feature so far, the drag and drop inventory is a critical part in the player's arsenal. It holds the player's equipment, resources, key items and sometimes junk.
Starting out as a grid where the player could place and take pick-up objects, the need for additional functionality such as automatically moving items to and from the inventory, merging stacks, equipping and consuming items with shortcuts quickly grew the feature to a difficult to manage size that underwent several refactorisations until finally getting scrapped and rebuilt from scratch with a modular
component based structure.
Inventory Structure
In the first itterations of the inventory every slot and interaction was seperately defined in the Player Hud class which resulted in a poorly built, difficult to scale blueprint. This structure was scrapped in favour of a modular parental structure.
By breaking each element into replicable components I could automatize large parts of implementation and modification processes.
When the game is started, Inventory slots are constructed and assigned index ID's by the Inventory Window that is in turn constructed by the player HUD class. Each Inventory slot fetches its data from arrays stored in the Game Instance Class using its assigned index ID.
Inventory Functionality
Taking, grabbing, merging, equipping, using and placing items
Inventory items can exist in three states:
-
As a pick-up objects in the world
-
Being held in the player's cursor
-
Stored in an inventory slot
For the pick-up item I made a single class that can be initialized with an enum ID and stack value. When constructed it uses its ID to fetch all of its data (including its model) from a pick-up item data table.
If the player interacts with a pick-up item using the cursor mode the player will copy its data and hold onto it until it's placed back in the world or into the inventory. A sprite is fetched from the data table and replaces the cursor sprite while an item is held in cursor mode.
In order to have the inventory work as intuitively as I wanted there were a lot of rules that needed implementation and edge cases that needed to be considered. Here are a few:
-
Functions for taking, swapping, placing and merging items
-
Finding and subtracting from specified item stacks, removing stacks with an ammount value of 0
-
Looking for an empty inventory slot and returning a failure if there is none
-
Systems for storing and transfering stack ammount values between the inventory and pick-up class
-
An algorithm for recognizing if the player should place or throw an item in the game world
These operations were often intricate and are built in function libraries for organisation and reusability
Technical Design: Gunplay
Combat plays a core part in my project, and is focused around fire fights using an array of weapons. I have put a lot of effort into modeling, designing and animating each gun, and have built a powerful system to handle the large ammount of data that is used every time the player fires a shot.
The algorithm for attacking is built to be flexible, fast and scalable. There are several components that communicate when the player performs an attack:
-
Firstly the Player character performs several tasks when a weapon is equipped, initializing relevant data to the player controller and weapon classes.
-
The Player controller class handles inputs and requests attacks while handling flow control.
-
The Equipped weapon class is responsible for performing all events related to each shot, such as shot trajectory, applying damage, sfx, vfx, recoil and animations.
Combat Algorithm
Sequence of events between Player character class(Yellow), Player controller class(Red) and Weapon class(Blue) relating to attacking.
Different weapons have different behaviours. These behaviours can be assigned in the weapon data table and exceptions can be made to overwrite the defaults in the toggle firing mode function.
My goal was to build a flexible framework where new content could be easily implemented by simply adding more rows to the data table, and although there are a few more steps than just that, I feel like I managed to set up a smart system where I can tweak my weapons comfortably by tweaking numbers from a panel.
Recoil and spread
A short automatic burst with a tampered pulser
Accurate automatic fire with pulser in default firing mode
The difference in recoil between 1 point in strength and 5 points
Recoil depends on the weapon, it's mode used and the users strength. Spread values expand the player's aim reticule making each consecuvie shot less accurate and recoil applies kick by moving the player's camera.
-
Recoil and spread are seperate values and can give character to different guns.
-
These values can depend on the weapon's firing mode.
-
Recoil = RandomDeviation*(weaponBase)*1-((totalStrenght-1)*0.17))
-
The shot is drawn somewhere randomly within the aim reticule.
-
Extreme shot deviations are reduced through a normal distribution algorithm.
Combat feedback
To make the moment to moment gameplay fun and to help sell a power fantasy, I've put lot of effort into adding layers of impact and feel to every action. With my self imposed restriction of not using any asset packs, adding feedback has pushed me out of my comfort zone and into trying things I hadn't even thought about getting into and in turn, I've picked up new skills such as animation, 2d blending, decals and sfx.
I've encountered many challenges and difficulties during endeavors like trying to align a melee attack animation with the first person aim reticule, but it has been refreshing to reexperience being a novice learning something entirely new.
Mouse look 2D blending and shooting visual feedback
Weapon feedback
My main points of focus in making gunplay feel impactful has been Animation, Sfx and Performance. It's easy to forget how important a weapon's performance is between all the shine and locomotion.
-
A slow weapon with high recoil feels powerful
-
High fire rate weapons feel empowering to shoot
Every weapon has a unique sequence of effects and moving parts when shot. A Laser Blaster lights up and gives of sparks and the assault rifle's bolt opens and spews out a case every shot.
Taking damage
To make the player feel when they take damage I added a stagger system that tugs the player camera much like how recoil works.
The magnitute of this stagger tug depends on how much damage was taken and the player's endurance stat. Frail characters can not keep their cool when trading shots with enemies while tough characters are so numb they can shrug of hits and keep doing what they need to do.
Both wearing armor and leveling up endurance will subtly affect how taking damage is experienced by the player.
The player wincing from getting shot represented by tugging the camera
Technical Design: AI
Overview
I wanted to create a simple AI that is both predictable and challenging. I have made several iterations on my basic humanoid AI and the current one uses a state machine to decide it's behaviour.
To contrast the humanoid AI I have designed and built a security network composing of cameras as eyes, turrets as defence and mechs to pressure the player.
-
An enemy's weapon and default state can be declared per object.
-
Designed for both stealth and combat gameplay.
-
Two enemy factions supports three way battles between the player, mechs and humanoids, or any combination in between.
Line up of adversaries. Or unlikely allies?
Humanoid AI
Intended as some sort of sentient zombie, the humanoid AI can be initialized with either a pipe for a melee variant or shotgun for ranged. They can also be assigned patrol routes, be static until alerted or roam.
-
The first itteration had problems with scalability, and was scrapped so I could rebuild it with state machine support.
-
Alerts nearby allies when detecting the player.
-
Building upon the starter pack animations, I have crudely made my own animations.
Pipe wielding enemies surrounding the player
Enemies patroling their territory
Current behaviour tree
Behaviour
Early enemy iterations did little more that run toward the player while attacking, but after considering how other games' enemies both threaten and give the player breathing room I tried to model my own AI behaviour that would make an effort maneuvering and positioning.
When the player is detected both variants will run toward the player until within a certain radius after which the AI initiates their combat behaviour.
Two simulations showing the difference between ranged and melee AI decision making
Melee enemy behaviour
Two melee AI's going from chasing state to engaged state
The melee variant will run towards the player on detection to close the gap, and then initiate approach behaviour when within a certain radius of the player. When in engaged mode it may attack when an opportunity presents itself.
-
Initially the AI would run straight toward the player while attacking but it did not feel right. Therefore I decided to build the Engaged state and Approach task.
-
When running its Approach protocol it may attempt to run behind the player before attacking.
-
When forming a crowd, the melee AI will often surround the player.
Simplified version of the melee AI's combat behaviour tree
Ranged Enemy Behaviour
Ranged AI's deploy algorithm in action. The left AI decides to reconsider its position
The ranged AI uses a deployment algorithm to find a viable position from where they can shoot the player. Although it currently doesn't care about cover as long as it can see the player, it could easily be implemented into the current deploy function should it be desired.
-
As to not have the AI run off somehwhere it uses its current distance to the player as a limmit when chosing it's targeted deploy position. This currently has the side effect of drawing the AI closer to the player every time it moves, but could be fixed by adding some extra parameters and operations to the deploy algorithm.
-
Has a small chance to reconsider its position even if it has line of sight to the player after every attack. This makes it a bit more aggresive and less predictable.
-
When forming a crowd, the melee AI will often surround the player.
Simplified version of ranged AI combat behaviour tree
Dealing enough damage to an enemy will break their composure and stagger them for a short while
Security network
Player triggering a security alarm by being seen by a camera. Turrets are woken up and a security mech is deployed.
Flowchart showing how the security network handles detection and keeps track of each hostile target
The player getting detected by security
To suplement my erratic humanoid AI I wanted an automated security system with very rigid behaviour. The security faction acts very predicatably and lacks mobility, but are very durable and shoot powerful laser bolts. Their computation are handled by a Security manages class in each level that keeps a log of alerted entities and assigns targets to each actor.
-
Consists of a camera for detection, turrets for defensive power, mechs for hunting.
-
Turrets and mechs can not perceive the player unless the alarm is raised. They will raise the alarm when attacked, however. If a security entity is attacked by a hidden assailant an alarm will be raised and a mech deployed, but they can not pursue the attacker unless line of sight is established.
-
A raised alarm will persist until no target is seen for 45 seconds. Afterward surviving deployed mechs to sticking around in case the intruder returns. This is to add some belivability and create the feeling that the world has been notified of the player's presence.
Level Design
There are four levels in this project, each made with different goals and under different circumstances. There is a small Tutorial level, a Scenario 1 with two levels inspired by System Shock 2 and an urban level Scenario 2.
Below you will find the second level of Scenario 1 and a narratively unrelated Scenario 2 level.
These two levels are dense and represent what kind of experience I want to create.
Scenario 1 Level 2: Deck 3
Summary
Goal: Reach Floor 3 to end the lock-down and then return to start.
Themes: Exploration, stealth and problem solving.
Time: ~80h
Core features: Security system, various kinds of locked ways, a in game sequence, multiple level states, various log entries providing flavour and hints.
Synopsis: The player arrives by elevator and the area is in lock-down. The player is pointed toward Floor 3 to lift the lock-down and but can not enter without clearance. The player finds her way down the the cells by using crawl spaces, keys or other means to find a deceased high ranking offices. With the officer's head for clearance the player can access Floor 3 and lift the lock-down. On her way back enemies breach the level and a battle takes place. The player then escapes, and the level ends.
Gameplay
The level is split into two states. One focused on slow exploration and the other fast paced action.
The first is the lock-down state where the player must make their own way to the head of security office. There is an emphasis on avoiding security and problem solving. I put in great effort to not make a single intended path, instead creating several problems and tools for solving them. Every path leads to progress in one way or another.
When the player reaches the main objective and lifts the lock-down humanoid enemies will breach into the floor using explosives, pouring in from various places, starting a three way fight between the player, the security systems and the zombie faction.
Player Agency
Each path leads to progress and has their of benefit, playstyle or needed tool. They are often intertwined and one path may lead to an advantageous position in the other
An important level design goal in this project is to not have a main route throught the levels. To accomplish this, I decided to create a set of problems and tools for the player. I took care to make these tools gameplay content rather than keys to progress.
Some paths require hints or codes from logs, some jumps require an advanced agility level or consumables, some doors require hacking, violence or keys.
Hidden paths are not shortcuts that skips the player ahead further into the level, but routes that offer one of many perspectives and ways to play the experience.
Scenario 2 Level 1: Backstreet Heist
Summary
Goal: Enter the research facility and steal the macguffin. Return to the main street.
Themes: Stealth and exploration or combat.
Time: ~60h
Core features: Multiple paths, accomodation for emergent game play, stealth
Timelapse
Vantage Points
The level features several vantage points that serve the purpose of presenting the player with decisions, and equipping them with the information they need to proceed.
Vantage points are safe as long as the player keeps her head down and provides an elevated perspective of the nearby lay-out as well as sight lines toward mid and long term goals.
Although vantage points generally serve as suitable sniper nests, this project currently has poor support for long range combat and is best used as a stealthy navigation tool.