Strata ²
Link - GP4 Fourth Game Project
Fourth group project I was part of at Futuregames (This was worked on in 2025 and was made in Unreal Engine 5)
The team was 11 people total with two of those being programmers.
I worked as a gameplay programmer.
The theme we had for this project was replayability.
The way we went about was this:
An arena map whose level design was constructed by falling voxel blocks in runtime, while surviving hordes of enemies in a first person bullet hell fashion.
What I worked on
I worked as our gameplay programmer.
The voxel blocks were coded by me and uses recursion to update connected blocks. I also worked a lot with movement (Including the dash and grapple abilities).
Outside of those two main things, I also worked with things such as:
- The game instance and how to connect it to other systems, like the shops and scene transfer of information.
- Helping our gameplay designers with code/design guidance to connect the stuff I made in a good fashion.
- Quick implementation of smaller systems, like the slide, overheat, aim hack ability functionality and enemy jumping.
- I also made the base scripts for weapons in C++.
Post-mortem
Strata ² was the most consistent project I have been in at Futuregames. Most of the team were at the same location, so communication across the different disciplines flowed well.
Of course. When communicating, some things needs to be explained in a different way from one discipline to another. I spent a lot of time with designers to help explain things I did. Like the math I did for some systems and how they should think when adjusting settings in those systems and sometimes the explanations could have been better structured.
I and my fellow programmer worked independently during this project. So there was not that much need to communicate things between us for the most part, but I could have been more communicative, now when I look back at the project.
For the latter part of the project, I ended up in a state of trying to find work to do, since I managed to implement most of our main systems pretty quickly. This allowed me to implement smaller things very easily when the need popped up, but I sort of felt like I was not doing enough sometimes, since I could not just add stuff without communication the intent to do so with the team. Of course when I got the good to go I just added stuff in.
My Scripts
Block Unit:
To solve the issue of having a level being created by falling blocks, which should also know when a neighbour is destroyed, I decided to use recursion to solve it.
Each block unit has variables pointing towards each neighbouring block! I use an enum to decided were to add in a new block neighbour when I create the block chains and another enum to handle it's states, like falling, grounded, locked in air and hitting block.
As mentioned earlier, I use recursion to handle the updating of the blocks. This allowed me to simply start from on block (like when it gets destroyed by the player) and then recursively jump to each neighbouring block to update them!
I also use ints to check how many non connected blocks are beneath and how many connected blocks are locked in the air.
All blocks also has a pointer to the block spawner, so that I can place them into my block poll, to then later be reused!
Now when it comes to the blueprint side of the block unit!
What you see on top, is my "AfterCodeTick" function which is called from C++ and implemented in blueprint. This gets called, it the block is in the falling state! This is were I move the block and the direction is set by the block spawner! It also handles the spawning and updating of the decal which shows were the block is about to land on!
To the left is my "SetupBlock" function which is also called by C++. This called by the block spawner and sets the starting position of the block when a block chain is being created.
Here above is my ""TakeDamageHandler" function, which handles when a block's health reaches 0. It adds itself to the block poll of the block spawner and then teleports away, to simulate it being destroyed! To the left is the unreal hit event, which handles when either the player or enemies are hit above by a falling block.
Finally beneath you can see how I handle collisions between different blocks and or ground! I use the tag system to check what the block is overlapping, then I call my recursive update functions to update the block chain, starting from the hitting block!
Block Spawner:
The block spawner handles both the spawning and reusing of block units.
It stores a struct array which houses added variables which are combined with my base stats. I chose which index based on the stage index variable.
It also calls some of the recursive functions in the block unit script, to do things like, setting up neighbour positions in the chain and set the fall direction of current block chain before it releases it for falling behaviour.
Bellow you will see two blueprint implemented functions. The first one, "ReleaseCubes" is were I set both the fall speed and fall direction of the blocks. It also adds back any blocks which failed to be released back into the block poll.
The second as you can see is split into two pictures. The function is "Spawn cubes", which either spawns in new blocks if there are no in the block poll or if there is, use the block at the final index and re-sets it up.
First Person Character:
I use a four state setup for player movement. Grounded, first jump, second jump and on not ground. I then check based on the current state, which data struct of type "FPlayerMovementData" I should combine with the base stats!
As you can see above, the blueprint has a few colliders attached. The big square collider is used to check wall jumping. Bellow you can see the blueprint overlap functions of the square collider!
What it does is it checks what side a block is from the player. it changes a bool which is used in the jump function to add a slight push from the side. Side being based on what value the bool is!
Bellow you can see the actual jump function. It changes behaviour based on the current movement state! Example it goes to first jump if you were either on ground or on block when you activate the function!
To the left you can see my "UpdateMovementData" blueprint function. It is called in the blueprint tick event and handles the updating of movement stats based on current state.
It calls the same two functions, but changes the input struct based on current state.
Bellow you can see the jump update function and bellow that the walking speed update function. Both of which are called by updateMovementData!
To the right, you can see the on component hit event, which I use to set both grounded and on block states!
Bellow you can see the slide mechanic, which activates bools which enables the slide modifiers in the updateMovementData function above!
The two last pictures are my edits to both the grapple (The second to last) and the dash (last picture).
Prototype Game Instance:
The "prototype game instance" script is used as the base for our game instance blueprint, which is used to carry over data across levels.
Both me and my fellow programmer worked on this one. I managed the enums. The enums is essentially what we checked to see what weapons/abilities the player had equipped and solved a lot of problems for our designers!
The configs and stageIndex were not created by me, but I used the stage index in my block spawner mention earlier on this page!
Weapon Base:
This script is the base used by our weapons.
As mentioned earlier, I was the one who implemented the aim hack. All I really did was checking the "aimHackActive" bool and switch over to a sphere trace check, using the "aimHackRadius" as the size for the sphere. Then I just took the closes enemy hit by that sphere!