01 — SELECTED WORKFrom the rules to the implementation.
MULTIPLAYER CARD GAME In development
Pub Card Game.
01
A shared table. A different kind of multiplayer problem.
Set in a physical tavern, the game lets players play cards simultaneously while Speed and Chaos modes change how their actions resolve. I work on the gameplay and server-side networking, including card interactions and action resolution.
Architecture overview · based on the project implementation
ENGINEERING NOTES
The decisions behind the game.
01Card tools built for designers+
I developed a GAS-backed card authoring workflow using data assets. Designers can configure card effects without changing the underlying C++.
EditConditionHides keeps the editor contextual: a timed effect exposes its turn duration, while instant damage exposes the relevant value. Fewer irrelevant fields make cards easier to author and review.
Card targeting is based on physical APubSeat objects. Sphere traces use seat-specific collision channels, then resolve the current occupant when an effect is applied.
This separates a target’s place at the table from the player occupying it, leaving room for future seat-swap and chaos mechanics.
Deck logic stays server-authoritative. Drawn cards are sent through RPCs to the owning client’s hand, rather than exposing every player’s hand to every client.
GAS attributes also handle the game’s Debt mechanic, which constrains maximum health through PostGameplayEffectExecute.
A solo project about scavenging waste and crafting useful tools. My focus is a reusable foundation: inventory, recipes, stations, battery management and a companion cart.
MY ROLE
Solo Game Developer
TOOLKIT
Unreal Engine · C++ · Blueprints Data Tables · Behavior Trees
View prototype ↗Crafting station interaction · development screenshot
IMPLEMENTATION ARCHIVE
Data, components and the connections between them.
01One shared item model+
Item definitions and crafting recipes live in separate Data Tables, connected by a shared item enum. Inventory, crafting and UI use the same identities instead of duplicating item logic.
02Reusable inventory & crafting+
InventoryComponent handles item quantities, capacity and add/remove operations. CraftingComponent checks recipe requirements, consumes ingredients and adds the result when crafting finishes.
03Battery drain without a Tick loop+
The battery system is activated by player input. Charge drains during active input, with activation and deactivation managed without a per-frame Tick update.
04Stations and UI from the same data+
A shared MasterStation and reusable ItemSlot let different stations draw on the same recipe data. The UI reads recipe names and sends the selected recipe back through the crafting interaction.
05A companion cart with its own behavior+
The Smart Cart uses a Behavior Tree and Blackboard for following behavior. An AI Controller manages its target and state, keeping those responsibilities separate from the player character.
02 — ABOUT ME
A designer’s mindset. A programmer’s attention to detail.
I like building systems that someone else can build on.
I’m a Digital Game Design student at Nişantaşı University, developing my practice in gameplay programming with Unreal Engine, C++ and Blueprints.
My current focus is GAS, multiplayer gameplay and modular architecture. I care about how a system works in code—and how a designer works with it in the editor.
Open to gameplay programming internships & junior opportunities
C++Unreal EngineBlueprintsGASRPC networkingData-driven systemsBehavior Trees
