top of page
Undead Onslaught Game Development
In this project, I set out to learn Unreal Engine by remaking the university group project S.M.G.V.B.S.S.H.F.. The goal was to deepen my understanding of Unreal's tools and workflows while recreating and improving upon the original game. This involved exploring Unreal Engine's advanced features to enhance gameplay and visual fidelity.
Role
Lead Developer
team size
1 person
development time
on-going
Game Engine
Unity
Genre
First Person Shooter
Technologies used
Unreal Engine 5
C#
GIT
Photoshop
Trello
Coding Process
In developing The Undead Onslaught, I followed a five-step coding process, which I will elaborate on throughout this portfolio piece. Each phase was crucial in shaping the game's mechanics, systems, and overall player experience.
1
Concept & Planning
rough coding
2
Development
3
Testing & Iteration
4
passover and feedback
5
BP_FirstPersonCharacter System
Player movement input
This blueprint handles player movement input, allowing the character to move left, right, forward, and backward. It also tracks the input values for each axis, which can be used to adjust movement speed or implement additional mechanics.
Key Features
-
Input Action (Red Node)
-
Left/Right Movement
-
Forward/Backward Movement
-
Axis Tracking (Right Green Nodes)
Input Action (Red Node)
The EnhancedInputAction IA_Move node represents the player's movement input, triggered when the player moves the joystick or presses movement keys. This node outputs two values: Action Value X, which represents horizontal movement (left and right), and Action Value Y, which represents vertical movement (forward and backward).
Left/Right Movement
The Get Actor Right Vector node retrieves the rightward direction relative to the character (local right direction). The Add Movement Input node then uses this vector to move the player character along the right axis. The movement intensity is determined by multiplying the Scale Value by the Action Value X from the input, allowing for full speed when the key or joystick is fully pressed to the side.
4o
Forward/Backward Movement
The Get Actor Forward Vector node retrieves the forward direction relative to the character (local forward direction). The Add Movement Input node then applies movement along this forward vector, with the movement speed calculated by multiplying the Scale Value by the Action Value Y, allowing for forward or backward movement based on input.
Axis Tracking (Right Green Nodes)
The SET nodes store the current movement values, with the Right/Left Axis holding the horizontal input value and the Up/Down Axis holding the vertical input value. These variables can later be used to control animations—such as walking or running—or to implement features like strafing or adjusting movement speed when moving backward.
How This System Works
The system detects input through the EnhancedInputAction IA_Move event, breaking down the input values into X (left/right) and Y (forward/backward) components. It then calculates movement by obtaining the character's right and forward vectors and applying movement using the Add Movement Input nodes. The X and Y input values are stored in separate variables to track the current movement state, which can be useful for determining movement direction or triggering animations.
Sprinting system
This blueprint handles player sprinting mechanics that enable the player to sprint within the game. It defines how sprinting is initiated, maintained, and stopped, allowing for dynamic player movement.
Key Features
-
Sprint Input
-
​Can Sprint Condition
-
Sprinting State Management
-
Custom Event: Restore Stamina
-
Timeline: Set_Restore_Stamina_TL
-
Stamina Restoring State​
Sprint Input
The InputAction Sprint node handles the player's sprint input. When the sprint key is pressed, the system evaluates specific conditions to determine whether the character can sprint. Upon releasing the key, it triggers the Stop Sprinting custom event to end the sprint, seamlessly transitioning back to normal movement.
Can Sprint Condition
The Can Sprint condition, evaluated through a Branch node, determines whether the character is allowed to sprint based on various factors, such as stamina and the character's current state. To initiate sprinting, the character must not be crouching—typically verified through the Standing/Crouch logic—and must be in a valid state to perform the sprint action.
Sprinting State Management
The Set Sprinting node updates a boolean variable (Sprinting) to true when the sprint action begins and false when it ends. This state controls related systems, such as adjusting the player's movement speed, to reflect whether the character is sprinting or not.
Stopping Actions
When sprinting, certain actions are deliberately disabled to maintain gameplay balance. One such action is ADS (Aim Down Sights), which is restricted to prevent aiming while sprinting. Additionally, firing is be blocked during sprinting to ensure realistic movement dynamics and strategic limitations.
The sprint logic dynamically adjusts the character's walking speed by using the Set Walking Speed function. This function increases the movement speed when sprinting is active and reduces it when sprinting ends, allowing for a smooth transition between normal and sprinting states.
Weapon Systems and Gameplay Mechanics
I am a passionate game designer with a strong focus on weapon system development, particularly in creating engaging and realistic shooting mechanics. My experience includes designing comprehensive weapon systems that blend fluid gameplay with realistic mechanics, fostering a consistent and immersive player experience
This system is designed to manage all aspects of how the guns function and feel. The goal was to create a set of weapons that each feel unique and satisfying to use.
Key Features
-
Input Handling
-
Stop Sprinting Dependency
-
Ammo and Reload Check
-
Switch on FireType
-
Realism and Flow
-
Timer Management
Input Handling
The InputAction Fire node handles player input for shooting and triggers when the fire button is pressed. It is linked to conditional checks to verify whether firing is allowed, ensuring that the action only proceeds under valid conditions not sprinting or reloading.
The Stop Sprinting node ensures that firing immediately interrupts any ongoing sprint, making sprinting and shooting mutually exclusive actions. This design choice enhances gameplay realism by preventing players from sprinting and firing simultaneously.
Ammo and Reload Check
A comparison checks whether the current ammo clip (Ammo Clip Current) has a value greater than 0, allowing firing to proceed if ammunition is available. Additionally, a NOT condition ensures that firing is blocked if the weapon is in the process of reloading or changing state, maintaining consistent weapon behavior.
Switch on FireType
The system handles different firing modes to accommodate various weapon types. In Single Fire mode, the weapon fires a single shot and then stops, while in Automatic mode, it initiates a continuous firing loop, likely controlled by an Auto Fire Timer to maintain a consistent rate of fire.
Realism and Flow
Prevents firing when the player is sprinting, reloading, or if no ammo is available, ensuring consistent and realistic weapon behavior. Additionally, it seamlessly transitions between different fire modes—such as single and automatic—based on the weapon's configuration and player input.
Timer Management
The system uses a Timer Handle (referred to as Auto Fire Timer) to manage the timing of automatic fire. A Branch node checks whether the timer handle is valid—if it is, the Clear and Invalidate Timer by Handle node stops the timer, effectively halting the automatic firing process. This ensures precise control over continuous fire.
FireType System
I developed a versatile weapon firing system that supports both Automatic and Single Fire modes. This system enables weapons to fire continuously when held in Automatic mode, or once per trigger pull in Single Fire mode. By implementing these firing types, I ensured that players experience a natural and intuitive weapon handling mechanic.
Dynamic Firing Logic
I designed a robust logic system that prevents firing when the weapon is reloading, changing state, or when the player is sprinting. This approach maintains consistent and realistic gameplay while preserving immersion. The system also features seamless transitions between firing modes based on the weapon's configuration and player input, allowing for a fluid and responsive shooting experience.
Automatic Fire Control
To ensure consistent firing rates in Automatic mode, I implemented an Auto Fire Timer Handle that manages the timing of continuous fire. This timer handle is validated to clear and stop automatic fire when conditions change, such as when the player releases the trigger or runs out of ammo. This functionality improves responsiveness and ensures precise control over automatic firing, enhancing the overall gameplay experience.
Realism and Player Experience
I prioritized realism in weapon behavior by designing mechanics that reflect realistic limitations. For instance, I ensured that firing is disabled during sprints or reloads, which prevents abrupt or unintended actions. By supporting fluid gameplay and maintaining immersion, I achieved a balance between realism and player satisfaction.
Through my work on weapon systems, I have demonstrated a commitment to creating gameplay that feels both engaging and authentic. By combining technical implementation with player-centric design, I ensure that weapon mechanics are not only functional but also immersive and satisfying.
Round System
This system handles the progression of rounds in a wave-based zombie game. Each round, the difficulty typically increases by spawning more zombies or making them stronger.
Key Features
-
Custom Event - "Increase Round" (Red Node)
-
Get Game Mode (Green Node)
-
Casting to GM_Zombies (Blue Node)
-
Setting the Round Number (Green Node)
Custom Event - "Increase Round" (Red Node)
The Increase Round event is a custom event that triggers when the game logic determines it's time to start the next round for example, after all zombies in the current wave have been defeated.
Get Game Mode (Green Node)
The Get Game Mode function retrieves the current active Game Mode instance, which typically manages the game's rules and state in Unreal Engine—making it the ideal place to store the round number.
Casting to GM_Zombies (Blue Node)
The Cast To GM_Zombies node attempts to convert the generic Game Mode reference into the specific subclass GM_Zombies.
If the cast succeeds, it confirms that the current Game Mode is the custom GM_Zombies class. If the cast fails, it indicates that the Game Mode belongs to a different class, preventing the system from proceeding adding error handling in this case would be beneficial.
Setting the Round Number (Green Node):
Once the cast succeeds, it grants access to the Round Number variable within GM_Zombies.
The Set node then updates the Round Number to a new value, which can either be set manually or calculated by incrementing the existing value with Round Number + 1.
bottom of page