Third group project I was part of at Futuregames (This was worked on in 2025 and was made in Unreal Engine 5)
The team was 18 people total with four of those being programmers.
I was the one who did C++ programming.
The theme we had for this project was environment.
The way we went about was this:
A world split into two dimensions. The player must restore balance by "tethering" them back together.
Because I was the only one of the active programmers who knew C++ and had pretty good grasp on the engine, I needed to jump into pretty much all the parts of the project.
In detail the things I had to work with was:
Build creation, version control (perforce), Main mechanic, bug fixing, material setup for main mechanic use, knowledge assistance when it comes to unreal, The camera position switching, the base of the artifact system and maintenance of it after changes, asset implementation, music transition.

This was definitely the hardest project I have worked on as of this writing (2025-08-29). The amount of things which I had to track and maintain was staggering.
But even with the massive amounts of stress and work, I learned a lot of both unreal and what my strengths are. Of course this was a trade of since I felt that I simply did not have that much time to really perfect stuff or taking the time to create stuff in C++, since I had a lot on my plate and needed to clear task after task. As such I still feel that I have a lot to still learn when it comes to unreal C++ (Normal C++ I'm way more comfortable with)
We had amazing artists which I worked a lot with and an ambitious main mechanic, which I'm proud managed to be made into reality! Even with the amount of issues that had to be handled to get to that point!
My takeaways:
With hard work you can overcome mountains, but take the time to gently fall down it afterwards and hopefully land in a warm bed!


This here is the main mechanic of our game.
We are using an asset from FAB called "World changer sphere mask", which had also really good documentation with it.
So how it worked is by using material functions and material parameter collections to find were a sphere was covering over an object, to then change it's material based on sphere ID.
Of course this asset were made for each sphere ID to show different biomes, so it took some time to finally connect it right with our vision

The asset came with some more advanced material functions, but I did not have the time to learn it. So this became my solution (See above image). We were planning on having many smaller sphere out at the same time so I needed to find a way to handle that. So I used an array of IDs to change the sphere ID variable. The first half represented one world while the latter half represented the opposite world.
For the big world switching I used a dedicated sphere for it. Also all spheres looks for specific tags to determined if it should show or hide a prop/asset. The spheres also turns of/on collisions and shadow casting.
I worked with the artists with setting up their materials, so that it could be affected by the sphere mask. It usually was either lerping to the opposite texture, or reduce opacity to zero.



This handles our camera position switching.
I use two trigger boxes. One for entering and the other for exiting. This allows me to place were it activates when you walk into it and were it returns back to the player when you walk out of it.


This is the base class used by our artifact system.
The system itself did not get that much use out of it, since a lot of ideas got cut. But I made all the functions into BlueprintNativeEvents, to allow multiple different types of artifact, but still keep it well connected both between blueprint and C++.
This here is the base script used by the player character.
We earlier had a dash functionality, which could allow the player to dash through obstacles, but we later changed it to not allow that and then even took it out because it did not fit our games feel.
Since it was originally the pre-generated character class from the third person template, I create variable paths so that designers could affect the C++ settings.

This was something I made while researching for ways to transport the player between worlds.
I was hoping to simply switch level instances with each other to simulate the world switching.
But this was not needed because another idea which I thought was scraped was still to be used, so this became scraped instead.