Roles
Designer
Programmer
Team Size
Solo
Tools
Unreal Engine 5
Blueprints
Production Time
June 2024 - June 2025
Genre
First Person Shooter
Platform
Windows
Asset Packs
Battleseries is a solo first-person shooter project inspired by the Battlefield franchise and other military shooters like Squad, Hell Let Loose, and Insurgency: Sandstorm.
My main objectives have been developing mechanics such as multi-seat vehicles with unique viewports, UIs, and roles (e.g., driver, gunner). The weapon system enables gunners to switch between various seat-specific weapons. Additional vehicle systems include turret controls, optics, and countermeasures tailored to specific roles.
​
Multi-Seat Vehicle System
Vision
The goal was to create a generic yet flexible seat management system that works across various vehicles, from tanks to helicopters. This system needed to handle seat-based functionality, such as:
-
Assigning roles like driver, gunner, or passenger
-
Managing weapon systems, turrets, and optics
-
Handling HUD elements, control schemes, and audio
-
Allowing seat switching and custom seat-specific functionality (e.g., rotors spinning when entering a helicopter pilot seat)
By keeping the system modular and adaptable, it ensures that any vehicle can leverage its features while allowing specific behaviors unique to each vehicle type.
Challenge
Vehicles like the M1 Abrams tank and AH-64 Apache helicopter have vastly different functionalities but share core principles:
-
Seats must track occupancy, roles, control schemes, and access to vehicle components.
-
Players should be able to switch seats dynamically, ensuring smooth transitions.
-
Certain vehicles require unique logic per seat, such as starting engines or opening hatches.
-
The system must efficiently manage functionality, ensuring only relevant controls are granted per role.
Balancing modularity and vehicle-specific customization was the key challenge.
Solution
To achieve this, I designed a seat component system that can be attached to any vehicle. This component stores an array of structs, where each struct represents a seat and contains:
-
Seat role (Driver, Gunner, Passenger)
-
Mapping context (Control scheme for that seat)
-
HUD elements (e.g., targeting optics)
-
Weapon/turret access
-
Occupancy status and character reference​
Seat Mechanics in Action
Entering & Exiting Seat​
Seat Switching Logic
When a player changes seats, the system:
-
Searches for the next available seat using a loop, checking seat occupancy.
-
If no forward seat is available, it checks seats behind the current position.
-
Once a valid seat is found, it updates the player's seat index and executes the seat transition logic (attaching the character, updating UI, etc.).
Below is a video showcasing how the change seats works in real time and how it can be manipulated in editor:
Seat Specific Logic
To allow custom behaviors (e.g., helicopter rotors spinning when entering the pilot seat), I used interfaces to communicate with the vehicle blueprint. This ensures that unique seat-based events trigger when needed without cluttering the core system.
Below are some examples
Rotors starting up upon entering pilot seat
Humvee hatch opening and closing upon entering and exiting gunner seat
View Target Methods
Each seat has it's own method of handling the player's view in that seat that can be separated into 3 categories:​
View Target Method | Description | POV Example |
|---|---|---|
Windowed | Mainly used by seats, that are open or have windows, this method uses the camera attached to the character's head. | |
Remote | Used by seats that do not have a window, this method uses a camera attached to the vehicle. | |
Seperate | Used by seats with a special use case, this methods uses a camera on a child actor attached to the vehicle rather than a camera on the vehicle itself. |
Ground Vehicle Movement
Vision
Create a responsive and intuitive vehicle input system using Chaos Vehicle Movement, ensuring smooth transitions between throttle and reverse when using a joystick. The goal is to have natural and predictable vehicle movement where pushing forward moves the vehicle forward, and pulling back reverses it without unintended behavior.
Challenge
By default, when switching from throttle to reverse (or vice versa), the engine doesn't automatically clear the previous input. This can cause unwanted behavior, such as throttle and brake values overlapping, leading to unresponsive or inconsistent vehicle movement.
Solution
Implemented a Compare Float system to check the joystick's axis value:
-
If the value is greater than 0, apply Throttle Input.
-
If the value is less than 0, apply Brake Input.
-
If the value is 0, clear both inputs to prevent lingering forces.
-
Additionally, the Completed event ensures that both values reset when input stops, preventing conflicting inputs from affecting the vehicle's responsiveness.
Ground Vehicle Movement in Action
Suspension
I Implemented suspension functionality via animation blueprints that react dynamically to obstacle vehicle drives over
Steering
To ensure proper steering behavior, I used a boolean to determine whether or not a vehicle can turn while not moving. This is mostly used for tanks.
Helicopter Flight Model
Highlights
-
Created input handling system and flight model that allows for differentiation amongst helicopters in speed and maneuverability
-
Implemented animation system that controls rotor speed
-
Created audio system that allows for ambient cockpit/interior and rotor audio
Weapon System
Vision
The weapon system should offer a robust, flexible, and immersive combat experience, ensuring that weapons behave uniquely while maintaining a consistent, intuitive feel. Each weapon type, whether bullet, shell, or rocket/missile-based—should feature distinct characteristics such as damage, fire rate, projectile speed, and penetration mechanics. Additionally, the system should support fire group logic, allowing weapons with multiple barrels or launch points to behave correctly (e.g., alternating fire on an Apache’s rocket pods, simultaneous fire on a Little Bird’s miniguns, or single-shot fire from a tank cannon).
The system should allow for easily tunable stats so that different weapons can be balanced effectively while preserving realism and tactical depth. Weapons should integrate seamlessly into both infantry and vehicle combat, ensuring that a minigun on a helicopter, a tank’s main cannon all function logically within the same framework.
Challenge
-
Weapon Stat Handling & Data Management
-
Each weapon has multiple stats (damage, projectile speed, fire rate, reload delay, etc.), which need to be stored in a modular and scalable way while remaining easy to adjust for balancing.
-
Ensuring that weapons can share common functionality while allowing for unique behaviors (e.g., a tank shell should have slow fire rate and high damage, while a machine gun has high fire rate and low damage).
-
-
Fire Group Logic & Projectile Spawning
-
Different weapons have unique firing patterns, such as alternating left-right fire for rocket pods, single-point fire for a tank, or simultaneous multi-barrel fire for miniguns.
-
Ensuring that multiple fire points work correctly when shooting projectiles, aligning with animations and effects while keeping behavior realistic and predictable.
-
-
Dynamic Reload & Ammo Refill Handling
-
Different weapons reload and refill at different speeds.
-
Handling ammo regeneration logic, such as vehicles that have limited magazine-based weapons.
-
Solution
-
Weapon Stat Data System
-
Implement a data-driven weapon system where each weapon type has a set of core properties (damage, fire rate, projectile speed, reload speed, penetration, etc.).
-
Use structured Blueprints to allow for easy tuning of weapon stats without modifying core gameplay logic.
-
Store fire group settings within each weapon’s data to define how it handles projectile spawning (single, alternating, simultaneous).
-
-
Fire Group & Multi-Point Firing System
-
Design a modular fire group system where each weapon can define how its barrels or fire points behave:
-
Single Fire: Fires from one point (e.g., tank cannon).
-
Alternating Fire: Fires from multiple points in sequence (e.g., Apache rocket pods firing left, right, left, right).
-
Simultaneous Fire: Fires from all points at once (e.g., miniguns on both sides of a helicopter).
-
-
Ensure projectiles spawn from the correct locations based on fire group logic, maintaining proper alignment with weapon barrels and vehicle hardpoints.
-
Weapon System in Action
Weapon Stats/Data Management
Stats such as damage, fire rate, visuals and sound (VFX, Audio), reload times, and fire modes determine how all weapons behave as well as their visual interactions such as a minigun spooling up.
M1 Abrams 120mm Cannon
AH64 Apache Rocket Pods
LAV-25 25mm Cannon
M1 Abrams 50cal Gunner
Weapons like the minigun required logic in addition to the base weapon for things such as only being able to fire once spooled up and spooling down once no longer firing.
Projectile Spawning System/Rangefinder
The rangefinder system I created has 3 main functions:
-
Determine the rotation in which projectiles are spawned in at relative to where the character is looking​
-
Provide visual HUD context range info for certain weapon systems, where it serves as an actual rangefinder for players
-
Laze targets for lock-on/homing weapon systems
1. Projectile Hit Center of Screen
2. Rangefinder HUD
3. Laze Targets for Lock-on Weapons
Fire Group & Multi-Point Firing System
The weapon system accommodates for 3 different types of weapon system firing patterns:
-
Default/1 Muzzle: Method in which projectiles are spawned from only 1 muzzle/spawn point
-
Flip-Flop: Method in which projectiles are spawned from 2 muzzles with a delay between each fire in a "left-right manner"
-
Dual Fire: Method in which projectiles are spawned from 2 muzzles simultaneously
Visual Feedback (Recoil)
Certain weapon systems cause the vehicle to react to them firing in ways such as recoiling back
Weapon Management
Vision
The weapon management system should provide a dynamic, immersive combat experience for players, where they can seamlessly switch between weapons with automatic ammo, and control different types of weapons within a vehicle. The system should support various mechanics such as ammo management and weapon switching. The goal is to create an intuitive and responsive system where each weapon feels unique and conventional for the vehicle.
Challenge
-
Weapon Switching and Seat Integration: Ensuring that players can easily switch between weapons while keeping track of ammo counts and weapon stats. This is complicated when the player is inside a vehicle, as different seats control different weapons, and the player may need to switch between these seats while maintaining the appropriate weapon and ammo state.
-
Ammo Management: Keeping track of the player’s current ammo in both the magazine and the reserve for each weapon, particularly when switching between weapons or seats. It’s important to ensure that ammo values are retained and correctly updated across different contexts (on-foot, vehicle, etc.).
-
Consistent Feel Across Different Weapons and Roles: Designing a system where each weapon type feels distinct but still works seamlessly together in terms of switching, aiming, firing, and reload mechanics. Balancing the feel and functionality of these weapons across different combat roles, like gunner in a tank, is crucial.
-
User Interface and Feedback: The system needs to display relevant information to the player (e.g., ammo count, weapon type) in a clear, intuitive way without overwhelming the screen. The player should always know which weapon they are using, the ammo status, and any important weapon-related changes.
Solution
-
Weapon Switching System:
-
Implement a flexible weapon system where each weapon is tied to a specific seat.
-
Switching weapons should trigger appropriate UI updates, showing the current weapon and ammo count. This can be achieved through Blueprint-driven logic in UE5, using interfaces for switching weapons between player roles and ensuring that only the available weapons for each seat are active.
-
-
Ammo Management:
-
Each weapon has its own ammo stats (current ammo in mag, current reserve ammo, etc). When a player switches weapons or seats, the ammo values should be saved and restored, ensuring a smooth transition between weapon use without losing track of ammo.
-
Implement reload functionality triggered either manually by the player or automatically when switching weapons with depleted ammo.
-
-
UI and Feedback:
-
The HUD will display relevant weapon info, such as the weapon currently in use, ammo count, and reload status (denoted as READY or WAIT). For vehicles, the HUD will adapt to show seat-specific information (e.g., the gunner’s HUD will show targeting info, while the driver’s HUD shows vehicle controls).
-
Provide visual and audio cues for weapon changes and reloads.
-
Weapon Management in Action
Switching Weapons
When cycling between weapons, several things need to happen in order to give proper context that the player has a different weapon equipped
-
HUD
-
The weapon reticle UI needs to be updated​
-
The "weapon name" UI needs to be updated
-
The "ready wait" UI needs to be updated`
-
The ammo UI needs to be updated
-
-
​Audio: Proper contextual audio that signifies weapon cycling
-
Custom Behavior: Any custom behavior for a weapon being unequipped or equipped (animations, etc)
Ammo Management
Projectile System
.jpeg)
Vision
In fast-paced FPS and vehicle combat, projectiles must behave in a manner that is representative of their weapon's context. This can include systems such as artillery, rocket, or lock on missile based weapon systems The goal was to create a projectile system that represents the projectiles behavior fired across different weapons.
Challenge
There are many kinds of projectiles that have various types of behavior ranging from flight behavior, speeds, and if and how they acquire targets and what targets they can acquire (air, ground, or both).
Solution
Each projectile exposed parameters like initial velocity, gravity scale, “use projectile POV”, and a toggle for whether to rely on the ProjectileMovementComponent. By adjusting only these values, I could prototype a wide range of projectile behaviors—from fast hitscan-style bullets to arcing grenades, slow-moving rockets, and even possessable debug projectiles—without needing unique logic per type. This lightweight, data-tweakable setup made it easy to experiment quickly and explore different weapon concepts early in development.
Projectile System in Action
Lock-on Projectiles
-
Lock-On & Guided Weaponry – Created dynamic lock-on behaviors for air and ground targets, supporting weapons like Stinger missiles, Javelins, TOW missiles (mid-flight control), and TV-guided missiles (player-controlled POV)
-
Adaptive Targeting & Flight Logic – Designed systems for pre-fire lock-on, sustained lock-on, and mid-flight target acquisition, allowing for a variety of targeting mechanics across different weapon types
-
Diverse Projectile Behavior & Guidance – Implemented unique projectile behaviors, including fire-and-forget, laser-guided, command-guided, and manual control systems, allowing for weapons like Hellfire missiles,
User Guided Projectiles
-
Player-Controlled Steering: Designed system that allows the projectile to respond to player input during flight
-
Fixed Camera Perspective: Designed system that allows for a preset POV (missile/TV-guided or launch platform/TOW) during flight
Optics
Vision
The goal was to create a flexible optic system that supported a wide range of sight types, zoom scopes, FLIR, thermal, and IRNV, without requiring unique code paths for each. I wanted players and vehicles to seamlessly switch optics while keeping the system simple to extend and easy to maintain.
Setup Seat - Role Specific
Solution
I designed a Blueprint-based data structure containing all optic parameters, including zoom magnification, FOV settings, and post-process configurations. Each optic simply referenced a struct defining its visual and functional behavior. The weapon or vehicle would read this data at runtime and apply the appropriate zoom values and post-process effects. This kept optics entirely modular—adding a new thermal or IRNV variant was as easy as creating a new data entry while maintaining a unified, scalable workflow.
Challenge
Different optic types each require distinct visual effects and gameplay behavior. Managing zoom levels, FOV overrides, and multiple post-processing styles inside Blueprints risked becoming fragmented or tightly coupled. The core challenge was enabling these features while keeping the system clean, modular, and data-driven.
THERMAL
IRNV
FLIR
ZOOM MAGNIFICATION
.png)
Optics in Action
Turrets
Vision
Most weaponized vehicles include some form of turret that can rotate to varying degrees horizontally and vertically and some have multiple turrets that can rotate independently of each other.
Challenge
The way vehicle turrets behave is dependent on many such as:
-
How fast they can turn
-
What degree they can rotate to or can they do a full 360 degree rotation
Solution
​I used simple data to determine a given a turret's max and minimum rotation they can turn to as well as their maximum turning rate. Depending on the context (whether it was on the vehicle's mesh itself or separate from it) this data was used at runtime either via the vehicle's animation blueprint or the relative rotation of a separate turret/weapon mesh.
Key Takeaways
-
Systems Design Complexity: Developing complex mechanics like vehicle roles, seat-based functionality, and context-sensitive inputs requires careful planning and scripting. Handling interactions between players, AI, and vehicles highlighted the importance of robust communication between components.
-
Interface-Based Communication: Using interfaces in Unreal Engine made it easier to decouple different systems and ensure clean, modular interactions, like handling seat swaps and role functionality. It also emphasized the importance of designing flexible, scalable interfaces early on.
-
Data & State Management: With all of these different complex systems from suspension simulation to weapon systems and animation, audio, and UI all working together at once, managing the different objects and their data and state correctly became crucial.
Conclusion
Battleseries was by far the most ambitious project I had taken up to this point in my dev career. Born out of a passion for combined arms experiences, this project exposed me to many of the different challenges, mechanics, and complex systems such games have and the amount of planning and execution needed for them to land. While I accomplished a great deal with this project, after almost a year working on it, and after talking with industry professionals, it was clear to me that much of my architecture was antiquated and had quickly turned into a hodgepodge of tacked on state management and band-aid fixe​s.
In short, it needed to be gutted, and retooled with the lessons I had learned as well as incorporate new skills I wanted to learn. It needed a refactor. Hence Battleseries: Refactored followed shortly after.