Colossal
Is a Titanfall meets Halo; multiplayer first person arena movement shooter with giant pilotable mechs!
What is Colossal?
At its core, Colossal is a cross between old-school arena titles like Halo and fast-paced movement shooters like Titanfall. With Colossal being an arena shooter, movement takes on entirely new purposes. Wallrunning, sliding, and movement abilities such as grappling hooks are now how you fight for map control, rotate to new positions, and contest powerful item spawns. As a Pilot, movement is everythin,g but when you call in a mech, everything changes.
Mechs slow things down and play more like a strategic and calculated hero shooter with fighting-game-like individual mechanics. Mechs have predefined kits, healing/reviving gameplay loops, and pseudo-objectives that reward positioning and calculated pushes. Pilots deliver a speed fantasy; mechs deliver a scale fantasy. That back-and-forth, constantly changing style of play is the core that makes this game stand out.
Why an arena shooter? Because pre-match customization narrows the player’s decision space by allowing players to lock themselves into their comfort zones, Arena pops it wide open by forcing players to adapt to whatever they find. In Colossal, weapons, pilot abilities, mech healing consumables, and even the earning of mechs are tied to lootable, limited-use items found in the match. So you’re constantly adapting to what you can secure and where you can secure it. Loadout customization locks players into their comfort zones; by design, arenas make you adapt. In Colossal, the map is your kit. Guns and even pilot abilities are limited-use pickups. This map-centric toolbox pairs perfectly with high mobility as players use their toolkits to race to contest item spawns and control the map. That paired with hero-shooter style mechs that revolve around stratgic teamplay + fighting-game-esc 1:1 combat… Colossal becomes a beautiful blend of strategy, technical skill, and immense variety.
Built in the Unity 3D Engine
Programmed in C# using Visual Studio
3D Models created using Blender
Sprites hand drawn in Adobe Photoshop
Technologies Used
Photon PUN 2 (Multiplayer Networking Solution)
Various low poly art assets by Synty Studios
Mech Pack
Nature Pack
Sci Fi City Pack
FPS Animation Framework - KINEMATION
Third Party Assets Used
Jump To Section
Design & Gameplay
Code
Design Goals
Fluid, Skill-Based Movement: The movement system is designed to reward player skill, with mechanics like wallrunning and bunnyhopping that are easy to use but hard to master.
Dynamic, Engaging Combat: By combining arena shooter elements with power-up pickups and loot drops, I want to create fast-paced, engaging battles that encourage exploration, strategic positioning, and constant action.
Team-Oriented Gameplay: The down state and revival system encourages teamwork, ensuring that every player’s role is meaningful while allowing for strategic comebacks.
Aggressive Play with Tactical Depth: Every game mechanic—from movement to combat to loot pickups—is designed to promote aggressive play while providing the tactical / Mechanical depth necessary to keep the game interesting for both casual and competitive players.
Fun Gameplay: Fundamentally, the game needs to be fun. To emphasize this goal, I’m incorporating systems like the “Lootsplosion” from Borderlands. When a player dies, their weapons, items, and abilities explode outward onto the ground, creating colorful, glowing loot drops. This not only rewards players with valuable items but also makes the death of a player feel impactful—players become their own loot box. This design adds an element of excitement and keeps the action moving, as players scramble to gather dropped gear and power-ups, reinforcing a fun, chaotic gameplay loop.
Why I Started This Project
I got into game development because no modern FPS titles were scratching my movement shooter itch. Tired of the same-old options, I decided to create my own. My game dev journey started with a passion for building content in other people’s games- whether making levels in Little Big Planet, crafting Minecraft levels for large servers, or modding levels for Titanfall 2. With this background love for creation, game development felt like a natural next step. Little did I know, it would lead me down a total rabbit hole. After almost 5 years of various projects, I finally felt ready to create my own movement shooter, and that's how Colossal was born. Drawing inspiration from my favorite franchises like Titanfall and Halo, I’ve been putting my own spin on the genre to create a fast-paced, dynamic arena shooter.
Project Breakdown
Advanced Momentum-Based Movement
Wallrunning, Sliding, and Bunnyhopping for fluid movement.
Quality-of-Life Features like Coyote Time and Jump Buffering to smooth out advanced maneuvers.
Arena Shooter-Inspired Combat
Dynamic Level Elements to keep gameplay fresh / Unique between levels and encourage different strategies.
Item and Power Weapon Pickups that reward exploration and strategic combat.
Hero Shooter-Inspired Mechanics
Mechs with class-based loadouts, adding variety to gameplay.
Down State System where teammates can revive each other, adding depth to team dynamics.
Movement System Design
The movement system prioritizes fluid, fast-paced gameplay that rewards player skill and adaptability.
Pilot Movement: Inspired by games like Titanfall and Apex Legends, the pilot features classic mechanics like wallrunning, sprinting, sliding, and jumping. The system is tuned for fluid transitions, with features like coyote time and jump buffering to help players execute advanced moves even with imperfect timing. The goal is to be easy to play but hard to master, allowing for responsive, skill-based actions.
Mech Movement: Mechs focus on heavy mobility with sliding and mantling, but lack wallrunning and jumping, making them slower and more grounded. This creates a distinct contrast between pilot and mech movement, allowing for quick role transitions based on the situation.
Design Goals
The movement system encourages aggressive play, promoting fluidity and environmental interaction whether players are on foot or in a mech, allowing for seamless transitions between the two and rewarding skillful navigation of the battlefield.
Weapon, Item, and Ability Pickup System
The pickup system enhances the fast-paced, action-oriented gameplay of arena shooters, adding layers of strategy and dynamic combat.
Weapons: A mix of projectile, hitscan, and melee options, each with unique range, damage, and fire rate. Limited ammo forces players to cycle weapons, encouraging varied combat strategies and adaptability.
Items: Limited pickups like health packs and power-ups offer quick recoveries or temporary buffs. Their scarcity creates tension, encouraging players to make strategic decisions on when and where to use them.
Abilities: Power-ups like speed boosts, deployable shields, and damage boosts enhance movement and offense. Strategically placed, they promote aggressive play, encouraging players to take risks for high-reward boosts.
Design Goals
The system fosters tactical decision-making and aggressive play, with pickups acting as incentives for players to move, adapt, and fight for mechanical advantages, preventing passive gameplay and encouraging constant engagement.
Mechs
Mech Design Overview
The mech combines powerful cinematic combat with tactical decision-making, encouraging aggressive play and team coordination. Mechs are walking tanks that demand respect from enemies and rally allies to follow. The powerhouse war-machines are made up of unique chassis akin to a Hero Shooter (ex; Overwatch or Apex Legends characters) where players pick from a set of existing mech designs each with their own unique weapons and abilities.
Additionally; mechs interact with items in the environment and one another in interesting ways.
Upgrade Cores: Power-ups unlocked by holding key zones, granting short-term buffs like increased damage or speed. This system promotes map control, team coordination, and dynamic combat.
Titan Healing Cells: Consumable items that restore health at the cost of vulnerability. Their use rewards strategic positioning and timing, discouraging passive play and promoting active sustain between fights.
Downed State & Revival: Mechs can be revived by teammates if downed, adding a layer of teamwork and giving players a chance for comebacks. This promotes aggressive support and strategic risk-taking.
Design Goals
These systems act as mini objectives; which encourage constant aggression, tactical positioning, and resource management, ensuring that players stay engaged and always have meaningful decisions to make during gameplay. When a team plays too passively their enemies might make a push for an upgrade core, which heavily encourages the passive team to contest. If a player is damaged and healing or reviving an ally, it presents an opportunity for his opponents to make an aggressive play to punish or stop the heal/ revive.
Design Challenges
Having players control characters this large presents a number of issues with standard FPS design. For example every map effectively needs to be thought of as 2 maps in 1. You have the large scale which accommodates mechs built of open lanes, large cover pieces, and interesting vertical elements and you have the small scale pilot side of the map. Which is built of regions inaccessible by mechs; buildings, tunnels, foliage, tight natural terrain paths, etc… Additionally mechs need to feel powerful but fair. Pilots should still be able to contest mechs and act as a pest without being completely shut down. This dynamic is the reason for our pilots high mobility, without it they would never stand a chance against a mech; with it they can survive.
Code
Weapon System Overview
My weapon system uses a data driven approach; utilizing Unity’s scriptable objects to store unique weapon definitions and a custom weapon factory pipeline to compile weapon behavior at runtime. Additionally I took advantage of various programming design patterns for this system such as the Factory Pattern, Strategy Pattern, Decorator Pattern, and State Machine Pattern.
Weapon Definition Stores plain language weapon stats such as
Name, damage, fire rate, projectile count, magazine size…
Behaviors: Everything any weapon in the game can do is defined in an interface based set of distinct behaviors. These behaviors can stack on top of eachother to create complex blends of weapon behavior
Weapon Factory: Takes in definitions and decides which behaviors to use for the new weapon.
Weapon State Machine: Handles runtime control of weapons with simple states such as “Idle”, “Active” and “Reload”.
Design Goals
This system allows for new diverse complex weapons to be added easily and since this system creates weapon behavior during runtime; it opens up the future possibility for weapons which change their behaviors during runtime based on for example power ups or abilities.
Weapon Factory
The weapon factory holds create methods for each type of behavior within the weapon system. Including the primary fire behavior (left click) alt fire behavior (right click) and reload behavior. Each is defined independently of one another with their own stack’s of interface based behavior implementations.
When a weapon is created it passes in its definition to the WeaponBehaviorFactory to have its behavior’s decided for it.
For larger code snippets see my GitHub Repo
Behaviors
Each hold the implementation behind each type of behavior a weapon can use. These hold an “inner” reference to another IWeaponFireBehavior to allow for the creations of stacks of behavior; where each layer can perform its functionality before calling it’s inner behavior.
-
![]()
Projectile Spawner Behavior
Base behavior responsible for creating and initializing new projectile instances
-
![]()
FireOneShotBehavior
The final behavior added to the behavior stack. Responsible for one shot functionality such as VFX and subtracting ammo from the weapon’s magazine.
-
![]()
PatternProjectileBehavior
Allows for the creation of pattern based weaponry such as shotguns with consistent bullet spread.
-
![]()
ChargeBehavior
Allows for weapons to have charge up time prior to firing like Titanfall’s Charge Rifle
-
![]()
BurstBehavior
Allows for weapons to have burst fire functionality like Halo’s famous battle rifle, or Apex Legend’s Hemlock.
Movement System Overview
I wrote a custom player character controller that uses a hierarchical state machine to define and manage the behaviors of different movement states. This structure takes advantage of polymorphism to let substates inherit and override the behavior of their parenting states.
Base State: is the highest level state implemented, defining the most universal methods such as “Tick”, “OnStateEnter”, and “OnStateExit”… This is an abstract and very generic class since other systems like my weapon state machine also utilize it.
Base Movement States: Are abstract classes that define the general state of the player; "GroundedState” and “AirborneState”, for example.
Movement States: Are the core drivers of player movement functionality, including states such as “WalkingState”, “JumpingState“, “SlidingState”, “WallrunningState“, etc…
The player controller passes its calls into its current state, which determines what behavior to use based on the input call. For example, the player controller might pass in a jump call into the current state, which happens to be CrouchState. CrouchState’s implementation of OnJumpInput then runs its exit crouch checks to determine if we can actually jump before transitioning to the JumpState.
Design Goals
Since Colossal is a movement shooter, I knew from the beginning that there would be quite a bit of complex interactions between various types of movement options. With that in mind, I knew I would need a movement “brain” that could be easily extended to add additional movement options as I build the project.
Flaws
Unfortunately, this approach has its limitations and issues. Right now its working fine since my player controller and weapon controllers are seperate, but If I wanted them to work together as a uniform character controller, it would quickly cause issues. For example, with a large enough controller with a continued reliance on my inheritance-driven approach, I could quickly run into over-specific states like “AirborneCrouchedFiringState”.
With that in mind, I’m planning to refactor my controller setup to use a pattern called the “Orthogonal State Machine.” This essentially runs and manages multiple state machines at the same time, which are broken up into distinct regions, each responsible for something specific. like “locomotion.” The biggest benefit of this refactor is that it would make it easy to block certain states from being entered based on the other region’s current state. Like preventing the weapon controller region from entering the fire state if the locomotion region is in its sprint or climb states.
