top of page
The weekly summary

At the end of every week I try to summarize what I've been working on for the past couple of days.
Both to show my progress and to share and showcase cool things I've learned and created that might not fall in to a specific category when it comes to either game, level or technical design. 

I hope to both inspire and teach a thing or two. And I gladly take any feedback you have to improve the project.
Thank you for reading!

Week one

Testing out procedural animations
and prototype for movement functionality

The majority of the animations for the player movement are procedural. Variables controlling different alphas are being set it the Player blueprint which control Bone Modify Transforms in the animation blueprint.

Each default movement functionality is in placed and a first pass of tuning has been done. I've set up a Metrics Gym to test out the movement and tweak it thereafter. 

Setting up character inheritance
and adding the Gameplay Ability System

I created a Character C++ class and included the Gameplay Ability System framework to the class so all child characters could inherent the component.

The Player Character derives from the project C++ Character and inherents GAS from it. I added all relevenat Inputs, Mapping Context and movement functionality to the BP_Player.

Character inheritance.png

Camera design and object specific FOV

 

To prevent the weapons and/or FP arms to clip into geometry I created a material function adjusting the World Position Offset by rendering the object on top of existing geometry. This basically scales the objects vertices towards the camera without the player noticing from her point of view and always renders the same no matter the choosen FOV.

This is a very well working solution to the weapon clipping issue. One of the most used solution would be to have a seperate camera rendering the arms and weapons on top of the viewport, though this is quite complicated to achieve in Unreal Engine with a decent result.

Week two

Creating a Health Component and testing different shield mechanics

After trying to piece together using GAS to fire weapons and dealing damage I decided against it for the non ability mechanics. I felt that it became slightly too complex for just a few weapons. 

I made a Health Component in C++ instead and added a regenerating shield through blueprints. After some testing I decided that if the shield would fully be depleted, it would not start regenerating again. This is subject to change after further playtesting, but works great for the time being.

Establishing the upgrade loop

One of the main goals for this project is to limit the amount of 2D menus. I want to keep the game as diagetic as possible.

Upgrading the suit and is done by adding aquired modules to it by hand. For now, while working on the procedural animations, I've split the player logic into two characters. One used in non combat zones and the other one (while using the suit) in combat/missions.

UpgradeLoop.png

Prototyping the upgrade modules and suit workbench

 

It took a few days of research and testing to see if I could utilize GAS by having actors holding the ability classes. When attached to the upgrade bench, they'll grant the correct ability to the combat player character, while storing the given abilities in the GameInstance to be accessed across all levels. When a module is removed, so is the ability.  I think this could be a really cool and modular way of customizing your suit to cater to each players playstyle.

Week three

Cleaning up the movement

When setting up a couple of more traversal examples in the metrics gym I realized that the function handling the capsule collisions half height didn't translate as well as I first thought from crouching to sliding. 

The issue in hand became quite complicated to pin point.

I could track the float in runtime but there is no out-of-the-box feature in Unreal to change viewport in runtime while still maintain control over your character. So I made a debug camera tool which allowed me to change between viewports in runtime and automatically execute console commands to show the necessary collisions. With the help of the tool it became much easier to time the capsule half height changes.

Documenting design guidelines

I had to take a little step back from prototyping and focus a bit on the GDD this week to remind myself of a few useful guidelines to not become too overwhelmed with the long list of tasks.

With the help of notes from my educations, a bunch of GDC talks and other useful sources of information I wrote down important things for me to keep in mind during the production. I focused on analyzing design, vision, evoking emotions, approaches to fixing issues and control mastery.

Feel free to have a read, either by clicking the selected pages to the right or by going through the GDD above.

Collision filtering

At the end of this week I focused on setting up a prototype for interactions. I planned an easily scalable systems that could be applied to all actors, including enemies (which exluded utilizing a parent blueprint for interactables).


I created a component used for tracing the interactables and a custom shape actor with customizable volumes which can be attached to any object och character. To prevent inconsistencies by using custom collisions I added and defined a new collision preset, dedicated for interactables, only responding to the trace channel used by the InteractionComponent. This preset overlaps all other traces used for example physics objects and weapons.

CollisionFiltering.png
Week four

Dynamic widgets for interactables

I'm trying to keep the upgrade system as diegetic as possible, but a little bit of information about each upgrade (module) is nedeed to present to the player the usage of each one. When the player is in her ship, a tooltip widget is drawn when looking at interactables, such as the modules. 

A Name and a String variable can be set in each instance of the module which are being passed with the Interaction interface to the tooltip widget. The widget can then be recycled and we don't have to use a unique one for each single item. 

Saving transforms between levels

Modules and other decorations within the ship needs to have their individual transform saved to maintain their location when leaving and returning to the ship after missions. 

To manage this I set up an overacrching manager that handles the Cargo Hold when aquiring new objects and tracks their transform through various arrays and maps. The necessary information is saved and stored with the GameInstance and SaveDataObject through solid blueprint communcation using interfaces. By having a ShipManager blueprint I can keep the Cargo Hold modular and easily changeable both when it comes to customazation and future iterations.

Loading attached modules

Every object in the ship is handled by the ShipManager except the attached modules. Since they have to spawn attached to the correct location I chose to have the functionality in the respective sockets. This way I don't have to change a ton of blueprint when adding additional sockets to the upgrade station. By using a Map variable I can find the exact value (Module) to each key (Vector per socket) and respawn each module with the correct physics settings.

(At the moment they are being spawned back in using a Debug Key. This will be changed to calling a dispatcher when the pod returns from missions.)

Week five

Designing the player ship

After having MVP's of all the core gameplay feature in place, it's time to start designing levels. The player ship is a natural place to start since it will be a very central part of the project, connecting many elements together and bring structure to the game. It's onboard the ship that systems like the armory, upgrade station and mission select/level loading will take place. 

Read more about the level design here

HighresScreenshot00001.png
bottom of page