LIGHTS ORB
Unreal Engine 4 - Blueprint
Gameplay, Tools and Systems
Lights Orb is one of my most recent projects, and was developed using Unreal Engine 4. This is actually the first project I developed with Unreal Engine 4, so this was my first complete experience with that engine, and that taught me a lot about working with it. I worked only with Blueprints, since I wasn’t comfortable enough in C++ to develop a complete game with this language.
​
Our team was made up of 2 Programmers and 3 Game Designers, and I’ve worked on almost every aspect of the game.
​
Note : Since I worked only with Blueprints, Code Sample will be accessible through Paste Bins on external links.
MY WORK ON THE PROJECT
GAMEPLAY PROGRAMMING
I developed most of the 3C features. I worked deeply on the Controller, like player movements abilities (climbing, crouching, sliding…), orb’s actions (launching, recalling…), as well as some Player Assists, implemented in order to counterbalance self-awareness problems that are involved by a first person camera. I also worked on camera movements, in order to give more impactful feedbacks (climbing, sliding, landing…), making the controller as smooth and pleasant to play as possible.
TOOLS PROGRAMMING
I developed most of the level design blocks of the game, trying to make their implementation in the levels as easy as possible. Taking advantage of Unreal Engine base tooling features like the Construction Script or Call-In-Editor Methods, I was able to create a lot of very tweakable level blocks for the Level Designers to place as wanted in the levels.
SYSTEMS PROGRAMMING
I worked on a few systems of the game, like the progression systems (checkpoints, saving…), activation system (linking activators like orb’s receptacle to other level design elements to play some actions), and other minor systems of the game.
MISCELLANEOUS
There are a few more elements I took in charge during the development of the project : I implemented a great part of the UI (gameplay and menus) ; I was in charge of a great part of the integrations (animations, sounds) ; I also had to make an optimization pass, tracking the game’s performances.
CODE SAMPLE
-
Character Climbing : A system enabling the character to climb from different heights, and move him in different ways.
​
-
Character Sliding : A system enabling the character to slide, changing its collider, camera location and also modifying its velocity depending on the ground he’s sliding on.
-
Ledge Follow : A system assisting the player’s movement and preventing him from falling when he’s walking along a ledge.
-
Building’s Impostors : A system able to copy rectangle-shaped elements (such as buildings) and fake them with much lower performance cost.
CHARACTER CLIMBING
Climbing is the action of going over a surface that is too high for the Player Character to simply walk over. This is one of the main features of the game, its implementation was very crucial, since this is an action the player is going to repeat a lot of time. We had to make it as smooth as possible, while making it very systemic in order to make it usable on any element of the game.
PROCESS AND LOGIC
Before processing any climbing movement, we check for any climbable surface in front of the player. If a climbing spot has been detected, the check system makes sure that the player can go from its original location to the climbing final location (enough space, nothing on the way…).
​
If the climbing spot is correct, the climbing type is calculated (low / medium / high climbing, depending on the height of the climbing spot) and the climbing movement is initialized. Then, the climbing movement is updated through timelines, moving the player from its original location to the final climbing location, and playing a camera movement in order to simulate the climbing movement.
​
This is a pretty systemic and flexible system, able to detect any kind of climbing surface and always making sure that no unexpected behavior is going to be generated. Camera movements and adaptability to the climbing height make this feature pretty smooth and pleasant to use.
MAIN PROBLEMATICS
MAKE MOVEMENT AS SMOOTH AS POSSIBLE
We needed to prevent climbing from feeling like some kind of a Gameplay interruption which could cause the player to lose its flow. Climbing duration is affected by the player's speed when he starts to climb, making the climbing feel like an extension of the player’s basic running movement. Also, control over its actions is returned to the player a little before the end of the climbing movement, allowing him to interrupt the climbing movement to resume its course.
AVOID UNEXPECTED BEHAVIORS
Climbing being usable on almost any element of the level, this system needed to be pretty robust in order to prevent the player from generating unexpected behaviors which could break the game. Some additional checks are processed when the player climbs, to make sure that nothing unexpected is going to happen (ex : when climbing on a spot with a small vertical space above, player climbs and is crouched during the climbing, allowing him to move in the reduced climbing space).
ADAPT CLIMBING TO VARIOUS SITUATION
Climbing isn’t always the same action if the player is crossing over a small fence or climbing a building’s ledge. Movement needed to be different depending on the climbing height (movement duration, camera movement…). The climbing type was created to generate those different movements, using different Timelines and tweaking.
CHARACTER SLIDING
Sliding is the action of being crouched while still moving at a pretty fast speed. Less important than Climbing, this feature is still pretty important in a parkour game because it is pleasant to use, and allows for more action combinations (ex : slide - jump - climb). Again, it needed to be systemic in order to work with any part of the game.
PROCESS AND LOGIC
When the player tries to crouch, its speed is processed to define if the player just crouches or performs a sliding movement. If he’s moving fast enough, the player starts to slide, granting him extra speed and reducing its collider, allowing him to pass under low obstacles. The sliding movement and speed are updated thanks to a Timeline, slowing the player down with time and ending the sliding movement once completed.
​
While sliding, the angle with the ground on which the player is moving is processed in order to make the player accelerate or slow down. For example, when sliding a down slope, the player will gain speed, and the Timeline will be slowed down in order to make the sliding movement longer.
​
Also a pretty systemic feature, sliding allows for a lot of impressive level parts, like sliding down a very big slope in order to gain a lot of speed and perform a jump that wouldn’t have been possible by just running around.
MAIN PROBLEMATICS
Sliding Problematics were pretty much the same as for climbing :
​
-
Adapt to Various Situations : To make it feel more realistic and allow for extra actions.
​
-
Smooth Movement : To allow chained actions with the other features of the game.
-
Avoid Unexpected Behaviors : To keep the player experience intact (ex : when sliding ends up below a too low ceiling, player is forced to stay crouched until he has enough space above).
LEDGE FOLLOW
As many of the game Player Assists of the Game, Ledge Follow is a very important feature, implemented to counterbalance the drawbacks of the first person view. In fact, since the player never sees his feets, it is pretty likely that he will make wrong assumptions about where his body is regarding the floor.
​
Ledge Follow assists the player by correcting its velocity when he is walking along a ledge, in order to prevent him from falling if he’s not clearly willing to go down that ledge.
PROCESS AND LOGIC
Ledge Climbing is processed using Line Traces to detect a ledge to follow. The speed and direction of the player are used to define the check distance and base direction. We translate from the player location with that vector, and then perform a vertical line trace to check if there is a ground below.
​
If no ground hase been found in front, we then rotate the forward vector from a certain angle step, until a max correction angle, both on the right and left sides of the base direction. If a ground has been found during one of the rotated checks, that means that the angle for which a ground has been found is the angle toward which the player’s velocity should be rotated to follow the ledge.
MAIN PROBLEMATICS
MAKE IT USABLE ANYWHERE
The first important question was how to implement this system in a way that would make it usable pretty much anywhere in the game. Since Line Traces are not that costly, it was pretty much okay to combine them with geometry calculation in order to detect ledges and if velocity should be corrected or not.
DO NOT FORCE PLAYER
When working on such a system, one of the trickiest things is to do is to make it non perceptible by the player. If the player is held back as he was willing to go off a ledge, his flow would be ruined. This is why ledge follow was tweakable enough to playtest and estimate the maximum angle that should be corrected.
BULDINGS' IMPOSTORS
Before adopting a more arcade artistic direction, the game took place in a more realistic urban environment. We were using a Modular Asset Pack, in which small assets (walls, windows…) could be assembled to generate different buildings pretty easily.
​
The main problem with this kind of technique is that a lot of meshes are involved, which could cause important optimization issues if all the buildings of the game are using that method.
​
Especially, we wanted to dress up the game area surroundings with a lot of buildings, in order to prevent the game from feeling too empty. Buildings’ Impostors have been developed in order to generate low-cost building, using small resolution textures and a single mesh, which is perfectly fine for buildings that are only going to be seen from afar.
A base building, composed of several meshes to make it modular
Comparison between a base building (right) and an impostor (left)
Impostors placed within a level to dress up surroundings - With very low rendering cost
A base building, composed of several meshes to make it modular
TOOL'S USABILITY
Regarding the tool’s usability, it is very simple : Select the building to fake, hit "Copy Building Set Up" to place the Capture as should be, set up the capture settings (path, name, quality), and hit “Make Impostor”.
This will generate a folder in which all materials and textures will be created, and then place the impostor right next to the true building. The generated impostor can then be converted to static mesh to have a final asset.
Left building is an impostor, right building is the base one
PROCESS AND LOGIC
This Impostors technique works with rectangular-shaped elements, and takes adventage of the Capture Scene 2D feature.
​
First, we set up the Capturer to copy the buildings settings (location and dimensions).
Then, we capture each face of the building (back, front, left, right and up) by placing the Capture Scene 2D, capturing the scene and then generating textures and materials for each face.
Finally, we spawn an impostor and set it up with the base building dimensions and generated materials to obtain a seemingly exact copy of the building.
MAIN PROBLEMATICS
POWER OF 2 DIMENSIONS FOR TEXTURES
It is always preferred to work with textures that have power of 2 dimensions. But buildings faces are pretty unlikely to have a ratio able to respect that rule. In order to respect that power of two rule anyway, void is captured above each face of the building, creating a difference between the actual dimensions of the building and the dimensions of the capture. A lot of mathematics were involved in the development process in order to finally achieve this power of 2 trick.
EASY AND QUICK PROCESS
In order to make the production of impostors as quick as possible, this tool’s usability needed to be very simple. This is why I automated most of the process, like creating the textures and materials files, giving access only to the most important tweaking variables (like the capture quality).
LEARNING AND TAKEAWAYS
As I said before, this project was the first one I developed using Unreal Engine 4, making it a gigantic source of learnings regarding this engine.
3C AND GAMEFEEL
Working deeply on the controller let me work a lot on my 3C development skills. I learnt how to create a deep character able to react differently to several situations (ex : sliding on a slope, climbing in a small space causing the player to crouch during climbing…), as well as ways to make it smooth and feel good, with the best feedbacks and camera movements as possible. It also gave me insights about ways to enhance the player’s confort with the controller by implementing several Player Assists (Ledge Follow, Coyote and Delayed Jump…)
ALLOW HIGH LEVEL OF TWEAKING
I put a lot of effort to make every developed element as tweakable as possible, whether it is a character feature or a level design block. This gave me insights about how to give as much flexibility as possible to developed features, in order to allow for as much experimentation as possible. This is something that helps me a lot during pre-production or pretty experimental projects.
UNREAL ENGINE 4 OVERALL LEARNING
Working on most of the development process (prototyping, implementation, integration, optimization…) gave me the opportunity to discover a lot of the Unreal Engine features (Blueprints, Components, Animation Blueprints, Sounds Management, Performances Tracking…)
PARKOUR FEATURE DEVELOPMENT INSIGHTS
I learnt some good practices and ways to implement features related to a first person controller game. This gave me insights about how to develop this kind of project, as well as sensitizing me to important issues linked to this kind of game (self awareness, unexpected behaviours…)
REVIEWS
Looking back at the projects Blueprints gave me the opportunity to realize bad practices I had while working on Lights Orb. Now, I do my best to avoid those bad practices and work as clean as possible on Unreal Projects.
AVOID INTER-REFERENCING
One of the main flaws of our hierarchy is that some Blueprints are referencing each other. This could be easily avoided by using lower levels of reference types, like using an Actor reference when only transform informations are required. This could also be avoided by using more Event Dispatchers.
AVOID ABUSIVE EVENT TICK
A lot of our level blocks are actually playing a tick when they didn’t really need to. This could be optimized by working as much as possible with Event-oriented actions, working with Timelines, or enabling / disabling tick at the right times.
BETTER BLUEPRINTS READABILITY
Making code easy to read is a really serious matter when it comes to work as a team. I realized that a lot of my blueprints were pretty messy, hard to read, understand and modify. Things like creating temporary local variables with explicit names, or comment code as much as possible are good practice to make the code more pleasant to read.
EXTRACT CODE, USE FUNCTION LIBRARIES
Again, some of the code I’ve worked on isn’t easily reusable as it is, being pretty much hard coded in the blueprints needing it (ex : Ledge Follow was firstly implemented directly within the Player Character). To create more reusable code, Function Libraries should be taken advantage of.