Steamwrecked (2025)

Project info

Role:

Game Designer / Project Owner

Engine:

Unreal Engine

Teamsize:

17 Genre:

Survival

Duration:

7 Weeks

Platform:

PC

About

In an overheated world, caused by the overuse of fossil fuel. Civilisation has moved higher up in the skies due to the harsh nature on the ground. You find yourself stranded down on the ground due to your airship breaks down. To reach home once more, you must repair and upgrade your ship in order to climb the skies back to society.

Introduction

This game was made during a 7 weeks long Game Project at Futuregames.

We were a very dedicated team with big ambitions which led us to aim high. To manage scope, we agreed early on to cut features if small milestones weren’t met. This clear approach, along with the design team’s transparency, kept everyone aligned throughout the project.

Build System

I took over the building system from another programmer and expanded on their work. It was a valuable experience that required understanding and adapting to someone else’s code and logic.

One of my first tasks was to rework the block destruction system, which had issues with overlapping line traces. By refactoring and separating the logic, the system became much cleaner and easier to manage.

The block placement logic still needs improvement. It currently performs several checks before placing a block, which could be optimized. I plan to add early exits for failed conditions and break the large function into smaller, modular parts for better clarity and maintainability.

Overall, I’m happy with the system’s current state. It performs well, with only minor polish and optimization remaining.

Code Snippets

Build Block

Removing Buildable Blocks

Tool System

I developed a base class for tools and another for nodes, designed with modularity in mind.

Each tool type applies different damage values to various node types, allowing for flexible and scalable tool interactions. This structure makes it easy to introduce new tools with unique effects on specific nodes.

To support this system, I also created a Health component and integrated a Niagara VFX component at the base level. This ensures consistent and efficient handling of visual effects and health logic across all tools and nodes.

Code Snippets

Tool Base

UI

I designed, implemented, and coded all of the UI for this project, with the exception of the inventory system.

Working on a system from start to finish was a rewarding experience, and I focused on making the UI as modular and maintainable as possible.

The building system is the part I’m most proud of, thanks to its clean and modular structure. One of my key goals was to ensure that designers could easily add new modules at runtime when players acquire new blueprints and the system fully supports that functionality.

If I had more time, I would have loved to create a fully 3D main menu rather than limiting the 3D elements to just the background.

Objective System

I worked on the objective system to handle the players tutorial sequence. I thought I wouldn't need a complete quest system since we were going to have small objectives that would guide the player though the tutorial part of the game.

Since the game got more features that we wanted to guide the player towards I would have saved myself a lot of time by building a more robust system from start.

Code Snippets

Objective Point

What I learned

I had the opportunity to dabble in a wide range of systems, which made the project both fun and a great learning experience. I learned how to structure different systems as actor components, making them modular, reusable, and less dependent on other systems.

One of the highlights for me was taking full ownership of the UI, from concept to implementation. I really appreciated the trust my teammates gave me throughout that process.

One key takeaway from this project is the importance of designing robust code from the beginning, rather than relying on simplified versions for the sake of speed. In hindsight, investing the time to make the objective system modular from the start would have ultimately saved time and effort. The simplified version I initially implemented became more difficult to expand and maintain as the project evolved.