Kaan Altay

Gameplay Programmer — Unreal Engine 5 · Unity

Five years building games, three professionally. Sole gameplay programmer on a UE5 co-op open-world pirate action-adventure with a publicly exhibited demo; client developer on a live-service mobile ARPG in closed beta. I build gameplay systems — AI, navigation, physics-driven movement, UI and LiveOps infrastructure — and I test what I build.

Studio work · Unreal Engine 5

Grog 'n Glory

Sole gameplay programmer · Gaming Bug (Istanbul) · Aug 2023 – Nov 2024 · C++ & Blueprint · Steam · demo showcased at GIST — press coverage

Ship physicsCustom navigation Behavior-tree AICrew management systems Chaos destructionCo-op replication Animation BlueprintsUIOptimization

A co-op open-world pirate action-adventure. I was the only gameplay programmer on the team: every gameplay system in the publicly exhibited demo — sailing, naval combat, enemy and crew AI, the crew-management layer, destruction, UI and the co-op replication underneath — is my work.

Case study — Threat-aware naval navigation

Ships in Grog 'n Glory are physically simulated hulls driven by wind and rudder — stock UE navigation can't steer them. I built a custom system: routes planned over a grid-based cost field where every hand-placed danger zone carries a power level, so a zone is only dangerous relative to the ship evaluating it. Weak ships route around waters a flagship sails straight through; a fully surrounded ship escapes through the weakest zone rather than freezing. The follower steers with the ship's real maneuverability in mind — starting the turn before the corner, the way a helmsman does — and routes re-solve when zones move, power levels change, or the ship is knocked off course. One system served both enemy fleets and the player's own autopilot.

Development footage from the editor: the planner's cost field, a danger zone's power level being changed live, and the route re-solving as a result.

  • 0:00The cost field. Every cell of the navigation grid, drawn over the water with its cost. The zone raises the price of the water it covers rather than blocking it, so the planner can route through danger when going around would cost more.
  • 0:10The same zone, re-levelled. Its power level drops from high to low while the ship is under way. The path re-solves in place: a route that arced wide now runs straight through the water it was avoiding a second earlier. Nothing else changed — only the threat's rating, and so only the ship's judgement of it.
  • 0:30Trapped, and getting out. A ship caught inside a zone stronger than itself solves for the cheapest way out instead of stalling, then re-solves to a shorter line once the zone moves off its route.

The core ideas are re-implemented from scratch in my open-source naval-navigation-sample — same thinking, brand-new code, 30 in-engine tests plus a 600-assertion engine-free harness.

Case study — Real-time crew management

The demo's signature system: a crew of fifteen split across three roles — gunners, sailors, repairers — reassigned live through a radial triangle menu. Drag the pin toward gunners and more cannons fire; toward sailors and the ship turns faster; toward repairers and the hull regenerates. Ammo types (round shot, shrapnel, chain) target hull, crew, and sails respectively, so mid-fight reallocation is the tactical heart of naval combat.

Seven sailors and four gunners meant fast manoeuvring but only two of five cannons could fire. Reallocating to ten gunners brought all five guns online. The crew is one pool: speed and firepower are bought with the same currency, and a fight is a series of decisions about which one you need in the next ten seconds.

Gameplay from the demo: crew reassigned and ammunition switched mid-engagement, in one continuous take.

  • 0:00 — Firing, badly set up for it. The crew is weighted toward sailors, which is what made the approach fast and what is now limiting the broadside.
  • 0:04The triangle. Crew is pulled off the sails and onto the guns.
  • 0:06Ammunition. Grapeshot selected from the wheel. The choice is about what you want to take away from the other ship — hull, sails, or crew — not how much damage you want to do.
  • 0:08 — The same guns, transformed. Firing resumes with the reallocated crew.
  • 0:15 — The result.
Live-service work · Unity

BladeX: End of Darkness

Client developer · Byte Lab (Izmir) · ongoing · Unity, C#, Lua · closed beta

FairyGUI UI architecturexLua scripting layer Hot-update infrastructureClient–server state sync Event-driven systemsObject pooling & mobile optimization

A mobile ARPG in closed beta. I develop the client: the FairyGUI-based UI architecture, the event-driven Lua layer and hot-update infrastructure that lets LiveOps ship behavior without app-store releases, client–server communication and state synchronization, and the pooling work that keeps it fast on mid-range phones.

Production code is private — so the architecture is demonstrated in my open-source ui-reddot-system: a hot-updatable notification system in the same Unity · FairyGUI · xLua stack, built from scratch.

Open source · clean-room samples

Systems I can show you the code for

Workplace code stays private, so these three repos re-implement the ideas from scratch — small, focused, and heavily tested. Each one states its own limits in its README, including what the test suite does not cover and how that was found.

Two ships with different power levels take different routes around a danger zone

naval-navigation-sample

UE 5.5 · C++ · threat-aware pathfinding over a sea-grid cost field, a wind-driven sailing model, and a predictive helmsman that starts turns before the corner. Event-driven replanning with hysteresis; escape-through-the-weakest-zone behavior.

  • Engine-free core — the algorithms compile and fuzz-test without Unreal
  • 30 in-engine automation tests + a 600-assertion engine-free harness, incl. an A*-vs-Dijkstra optimality check
  • Five seeded demo scenarios, recorded in the README
A Lua patch applied at runtime adds a new badge type with zero C# changes

ui-reddot-system

Unity · FairyGUI · xLua · a production-shaped red-dot notification system: rules as hot-updatable Lua data, type+key dot identities with page-scoped lifecycles, token-based seen tracking, and an event-queue/flush pipeline — no polling anywhere.

  • A runtime Lua patch adds a badge — and rewrites a shipped rule — with zero C# changes
  • 107 automated tests driving the real Lua through the real bridge
  • Editor-only reconcile checker proves the event wiring is complete