Katana Inu — GAS Programmer, Audio Lead & Social Systems Developer on a Multiplayer Battle Royale

The Project

Katana Inu is a multiplayer battle royale action game with skill-based directional melee combat, character abilities, multiple weapon types, a relic-based alternative win condition, looting, ranked/unranked matchmaking, and a play-to-earn crypto/NFT economy layer. Players choose characters with unique passive, active, and ultimate abilities and fight across a large map in free-for-all and team-based modes.

The game features a full Gameplay Ability System (GAS) framework powering all character abilities and attributes, a complete FMOD-driven audio pipeline, social features (friends, parties, matchmaking, blocking) built on Epic Online Services, and a suite of game menus and HUD elements. Built in Unreal Engine 4.27 with C++ and Blueprints.

Links: Website · Playable Build

My Role

I worked on Katana Inu periodically over approximately 2.5–3 years (2021–2023) as a co-founder of the development studio contracted to build the game, part-time alongside two other projects. The team started at roughly 5 people and grew to 30+, including gameplay programmers, 3D/animation artists, VFX artists, sound designers, and game designers.

Rather than owning a single domain for the entire project, I was rotated between areas based on where the team had the most pressing needs — functioning as a versatile problem-solver brought in when the core team needed help implementing specific systems. My three main assignments were:

GAS implementation — Researched, prototyped, and integrated the Gameplay Ability System; onboarded team members; wrote technical documentation
Audio pipeline & team management — Set up FMOD, implemented all in-game SFX and music, managed 2 audio designers. Later handed off to another team member.
Social systems & UI — Implemented the complete friends/party system and matchmaking UI using Redpoint EOS plugins; extensive bug fixing and hardening

Throughout the project I also coordinated across disciplines (gameplay, animation, VFX leads), communicated directly with the client, performed QA testing, and did code reviews.

What I Built

Gameplay Ability System (GAS) Integration

The project needed a robust framework for character abilities, attributes, and status effects that could handle networked multiplayer at scale. I researched GAS feasibility, built a standalone test project to validate the approach, then implemented the full system into the main project from scratch.

Abilities — Implemented specific networked abilities: heal, grappling hook (visuals and SFX), jump, and double jump — all with full server-client replication and prediction.

Attributes & Effects — Built Gameplay Attribute and Attribute Set systems driving character stats (health, damage, speed) with proper network replication. Debugged and resolved attribute set sync failures, movement ability rubber-banding, and intermittent cue execution failures on autonomous proxies.

Gameplay Cues — Implemented the Gameplay Cue system as a standardized framework for triggering audio/VFX in response to ability events. Created reusable base classes (GC_KI_Actor_Base, GC_KI_Static_Base, KI_ProjectileHitCueBase) to prevent code duplication, built the data-passing pipeline between abilities and cues using custom structs, handled async montage loading, and built debug tools for the cue base class.

HUD Interface — Created the interface for updating the HUD from ability state callbacks and gameplay effect events in real time.

Audio Pipeline & Implementation

I established the project’s entire audio pipeline from scratch:

FMOD Integration — Set up FMOD in the Unreal project and SVN repository. Built the character FMOD component to interface with GAS, enabling abilities to trigger context-aware audio through the same framework used for gameplay logic.

In-Game Audio — Implemented all SFX and music: locomotion sounds, level ambience, hitmarker SFX for projectile hits, combat audio, ability feedback sounds, and a sprint sound system using local gameplay cues.

Procedural Music System — Designed a procedural music system driven by real-time combat intensity, dynamically adjusting the soundtrack based on gameplay state.

Network-Optimized Playback — Standard gameplay cue events replicate like multicasts — expensive for frequently triggered abilities. I developed multiple optimization patterns: local gameplay cues for projectile hits (leveraging the fact that hit events fire locally on each client), custom anim notifies for dash sounds (piggybacking on already-replicated animation montages), and local-only cues for player-specific effects like sprint wind.

Audio Team Management

Managed a team of 2 audio designers — oversaw quality assurance on audio deliverables, issued and managed tasks, coordinated audio team output with gameplay, animation, and VFX teams, and participated in meetings to vet potential sound designers.

Built the complete social layer using Epic Online Services via Redpoint EOS plugins:

Party System — Invites, accept/reject, party leader promotion on exit, blocking, validation, and notification handling.

Friends System — Add/remove friends, presence handling (including offline states), and the invite flow.

Matchmaking — Integrated matchmaking into the main menu UI.

Bug Fixing & Hardening — The social stack surfaced dozens of edge cases that only appeared during real multiplayer testing: duplicate invites when inviting across parties, crashes when removing a friend while a party invite was pending, blocked players still able to send invites, party invites persisting after becoming invalid, and text overflow in the friend invite field causing client crashes. Systematic QA hardened the system for production use — all built and debugged in a very limited timeframe given the complexity involved.

UI Systems

Implemented a full suite of game menus and HUD elements: main menu, options menu (audio settings, keybind remapping), server browser (create/join sessions), splash screens, HUD prompts, gamemode selection, and user login screen. Fixed UI scaling issues across resolutions.

Early Multiplayer Framework

Built the initial multiplayer framework for the prototype using Steam Sessions, including session creation/joining UI. Overhauled core Unreal game classes (GameState, GameMode, GameInstance) and fixed gameplay replication issues across the board. This framework was later replaced/supplemented by EOS-based matchmaking as the project scaled.

Documentation & Onboarding

GAS has a notoriously steep learning curve. I authored two comprehensive technical documents:

A Gameplay Ability System overview covering abilities, ability tasks, attributes, effects, tags, cues, architecture notes, pros/cons, and caveats
An SFX/VFX implementation guide structured so artists could implement audio and visual effects for abilities without needing to understand networking or replication

Using these documents, I onboarded 4 team members (2 programmers, 1 3D/animation artist, 1 sound designer) so they could work with GAS independently.

Key Challenges & Solutions

GAS replication & prediction in a networked battle royale: GAS’s replication layer introduced multiple challenges — attribute sets not syncing correctly, movement abilities causing rubber-banding due to prediction mismatches, and static gameplay cues intermittently failing to execute on autonomous proxies. Each required deep understanding of UE4’s networking model and GAS internals to diagnose and resolve.

Network-optimized audio/VFX at scale: Standard gameplay cue events replicate like multicasts, which becomes expensive for abilities that trigger constantly (dash, sprint, jump). I developed a suite of optimization patterns — local cues, anim notify–based triggers, and client-side event triggers — to get audio and VFX feedback without the networking cost.

Social system edge cases: The friends/party system surfaced dozens of bugs that only appeared during real multiplayer testing — duplicate invites, crashes on friend removal during pending party invites, blocked player invite exploits, stale invite cleanup, and text overflow crashes. I built and debugged the entire system in a very limited timeframe relative to its complexity, systematically working through edge cases to harden it for production use.

Cross-discipline GAS onboarding: Making GAS accessible to non-programmers (artists, sound designers) required documentation that abstracted away networking complexity. The SFX/VFX implementation guide I wrote became the team’s standard reference for adding audio and visual effects to abilities.

Rotating between disciplines on a growing team: Moving between GAS, audio, and social systems on a team that grew from 5 to 30+ required rapid context-switching and the ability to leave each system in a state where others could maintain and extend it — through clean architecture, documentation, and base classes designed for team reuse.

Tools & Tech

Unreal Engine 4 (4.27), C++, Blueprints, Gameplay Ability System (GAS), FMOD, Epic Online Services (EOS), Redpoint EOS Plugins, Steam Sessions, SVN, ClickUp, UMG