Project Zombert (2025)

Role:

Game Designer / Game Programmer

Teamsize:

1

Duration:

Ongoing

Engine:

Unreal Engine

Genre:

TPS

Platform:

PC

About

This game is a third-person survival shooter featuring inventory management and a world overrun by various types of zombies and powerful zombie bosses. The player’s goal is to survive, gather resources, and collect key items that unlock access to new areas and opportunities for exploration.

Intentions

I am very early in development in this project and my main focus is on learning C++ whilst having fun building out various systems.

The key systems I want to build:
- Character Movement

- Combat

- Weapon Customization

- Build System

- Spatial Inventory

- AI and Boss AI

- Driving vehicles

Player Movement

I began by recreating Unreal’s third-person character template from scratch in its own C++ class and then added crouch and sprint functionality. Starting with a clear goal helped me learn the syntax and structure my code in a more organized way.

Initially, the Player Character class handled all input, but it became difficult to maintain as the project expanded. I refactored the system by introducing a Base Controller class, improving scalability, maintainability, and future-proofing the codebase for continued development.

I aimed to keep the code easy to work with, especially if collaboration becomes part of the project later on.

The player movement system is still in an early stage, with the core functionality and animations working together, but there’s room for refinement and polish.

Code Snippets

Base Player Controller

Base Character Class

Begin Play & Tick

Movement Functions

Combat

I started by implementing aiming, shooting, and weapon swap mechanics. The player uses a holster socket and a hand socket, when picking up a weapon, the system checks which socket is available. If both are occupied, the player will eventually be able to swap and drop the current weapon.

I experimented with Aiming down sights (ADS) from the weapon barrel when not ADS, but it felt very hard to control and made it difficult to aim even at static objects. To secure that the players experience is as smooth as possible I adjusted the hip-fire aiming so the player rotates and shoots toward the crosshair, ensuring consistent aiming behaviour in both ADS and non-ADS modes.

I started out with a lot of combat-related functionality inside the player character class, but to improve scalability and support future collaboration, I refactored it into its own actor component. This made it much easier to add new features and will make the codebase more manageable for others if collaboration happens later on.

I added data assets for all the different base weapon types I plan to include in the game: shotgun, assault rifle, SMG, RPG, pistol, and sniper rifle. I created one of each as a starting point to support different shooting mechanics for each weapon type and to test them early on. Along with this, I also created a base Weapon class that stores all essential information related to the weapons themselves.

Code Snippets

Combat Component Part 1

Combat Component Part 2

Weapon Master

Animations

For this project, I chose to use Synty Assets because their visual style fits with the game’s tone I am going for.
The Synty character skeleton differs from Unreal’s default skeleton so I had to retarget the rig, which took some time to get right. It was a valuable learning experience that helped me understand the IK Retargeter for future projects.

To manage animations, I kept the original Manny mesh active in the editor, while the Synty Character retargets Manny’s animations at runtime. The Manny mesh remains hidden during gameplay.

For aiming, the character’s spine bones adjust based on the pitch rotation to create natural up-and-down movement.

Currently, the weapon alignment with the left hand is slightly off, as IK for the left hand has not yet been implemented.

Left Hand IK

When implementing IK for the left hand, I encountered issues with keeping it in the correct position both while aiming and not aiming. Initially, I tried using a single reference location for both states, but this caused the arm to snap and shift constantly. To address this, I added a separate scene component specifically for the aiming position, which I could adjust to a more suitable angle. This improved the behaviour significantly, although there are still occasional snaps and unnatural movements. The system works as a first iteration, but it will require additional polishing to achieve the desired level of quality.

Interaction Component

I added an actor component to the player for the interaction system. Interaction types can be set to either hold or press, and the required hold time can be adjusted per item or per level instance depending on the use case.

With the knowledge I have so far, I aimed to create a standalone system that’s easy to expand. This allows me to add new interaction types, such as NPCs, boxes, or other objects without having to rewrite existing logic.

I also wanted the interaction widget to update automatically if the player changes their input key in the future. It took some trial and error to figure out how to access the assigned input, but I eventually found a solution by searching through the player’s input mapping context, retrieving the FKey from the specific action, and then getting its name.

On top of that, I added functionality to display whether the interaction is a hold or press action. These are small details, but they add clarity for the player and set up useful systems for future expansion of the project.

Code Snippets

Player Interaction Component

Upcoming

The next things I need to work in:

- Stat component

- Modular weapon parts

- Spatial Inventory