Enes Sahin

My Corp Cargo Simulator

NocturnForge · 2025–2026 · NocturnForge · Founder & solo developer

What it is

An open-world delivery simulation for PC, published by No King Interactive. I founded NocturnForge and did all of the development solo, every system from low-level engine foundations up through gameplay, on a layered composition-based architecture meant to stay cheap to maintain and fast to extend as it grows. The original game design came from the publisher; I extended it heavily on top. It’s in Steam Early Access with 4,000+ wishlists: deliberately open-ended and still deep in development. Pipeline: Unity, URP.

What I built

Architecture

Three layers, three assemblies: Core & Utilities, Systems, Gameplay, roughly 550 C# scripts in total. Dependencies point one way only. Core stays generic and dependency-light, Systems holds reusable game domain code, Gameplay wires it into the actual game. Layered composition over inheritance throughout.
Roles layer onto concrete bases. Player and customer are roles on top of character; backpack is a role on top of item, so a prefab carries both roots and the lower one never knows what got layered on it. That is what keeps character code reusable while player and customer code owns its own input, AI, and prompts.
Custom IoC container, a scoped service locator built from scratch: registers types, supports interfaces, and gives flexible service lifecycles. Dependencies are resolved explicitly via Service.Resolve<T>(), a much stronger alternative to singletons, so it is an IoC / service locator and deliberately not a full auto-injecting DI container. Registration stays centralized in installers, and every service follows one lifecycle contract: constructor assigns dependencies, Initialize() subscribes and starts work, Deinitialize() tears it back down.
ID-based, composition-driven entity/item system: every dynamically spawned object gets a unique ID that is the single source of truth. Items (packages, backpacks, bicycles) each carry an Item/Entity ID; characters have their own separate ID space; a distinct Config ID locates a type’s prefab and config. Data repositories link everything in table form (id → item, id → package, id → backpack), so any system operates on an object by ID alone.
Persistence is feature-owned and ID-based. One repository per persisted data shape, storing primitive IDs and serializable data only, never Unity object references, so runtime objects are rebuilt from IDs on load. Profile save data stays separate from global settings.
Typed tags instead of Unity string tags for raycast and trigger detection (multiple logical tags per object, and a fast climb from a child collider back to its root), ordered priority events for lifecycle hooks, editor tooling, a logging system, and ScriptableObject-driven configuration.

Open world & streaming

Chunks: the world is divided into chunks addressed by integer coordinates. Positioning by chunk-int coordinate + local offset, instead of one giant world-space float, is what defeats far-from-origin floating-point precision loss. (Origin shifting exists, but is secondary.)
Tiles: the static environment geometry, streamed in and out via Addressables, living inside chunks.
Per-chunk physics scenes: each chunk is its own physics scene, a deliberate choice to support multiplayer physics later; at chunk borders, entities are replicated across neighboring physics scenes so objects can still interact across boundaries.

Gameplay, characters & AI

Core gameplay: delivery to addresses, packages and backpacks, a world map and navigation for delivery pathing, and IK-driven interactions (e.g. point-of-sale).
Full-body IK on Unity Animation Rigging, with an IK-driven grab/carry system (multiple grabbing styles) and a character-customization system (mix-and-match body-part clothing and apparel).
Game Time: a from-scratch real-time in-game clock that drives a third-party weather visual system.
Customer AI: hand-rolled FSM and behavior trees first, then third-party assets used for the shipped build.
Roads use EasyRoads3D for smooth, optimized roads. (My own procedural road generator is a separate, earlier project.)

Optimization & rendering

CPU/GPU work: batching, SetPass reduction, LOD and chunk-LOD, baked + realtime shadows and global illumination, render-state optimization, profiled with the Profiler, Frame Debugger, and Rendering Debugger. Render pipeline: URP.

Documentation as infrastructure

The project ships with its own architecture reference: an onboarding path, per-system docs with sequence diagrams for the lifecycle-heavy flows (item, package, backpack, grab, delivery, customer, storage), and written contracts for services, repositories, and events.
A risk ledger records known bugs, shortcuts, and cleanup candidates instead of hiding them, with the standing rule that they get documented and not silently “fixed” by an abstraction that spreads.
All of it is written to be read by a new developer or by an AI agent working in the codebase, which is why the guidance is stated as portable patterns rather than a class list.

The hard part

Problem. An open world breaks two of Unity’s assumptions: world-space float coordinates lose precision far from the origin, and physics assumes a single shared scene, which fights any plan to run multiplayer physics later.

Constraint. Solo founder, shipping to Early Access. Every system had to work with Unity’s lifecycle, not against it, and leave room for multiplayer without a rewrite.

Solution. Two cooperating systems. Chunks give the world an integer coordinate frame: objects are placed by chunk-int coordinate plus a small local offset, so precision never degrades with distance (origin shifting is only a secondary aid). Each chunk is its own physics scene, and Tiles, the static geometry, stream in and out of those chunks via Addressables. Because objects in separate physics scenes can’t collide, entities at chunk borders are replicated across neighboring scenes so they interact seamlessly across boundaries.

Result. A streaming open world that holds precision anywhere on the map and is already structured for multiplayer physics, in Steam Early Access at 4,000+ wishlists, built end to end by one engineer. The ambient scene on this site (routes, streaming, deliveries) is a toy echo of these exact systems.

Highstreet Calamity

Highstreet Market · 2023–2025 · Senior Unity Engineer · VR combat & physics

Website

Watch on YouTube

What it is

Highstreet Calamity is a class-based multiplayer VR roguelike brawler: play solo or in co-op, fighting through procedurally generated waves and bosses to build your character. It runs on Meta Quest, PC VR, and in the browser via WebGL. It’s the second game from Highstreet Market, a ~50-person studio (~8 engineers); I worked on both of the studio’s games as Senior Unity Engineer (Jul 2023 to Sep 2025, remote) and owned the physics-driven combat on Calamity, the deeper engineering, which I highlight here.

(The studio’s other title, Highstreet Market, is a social VR game, an apparel store selling mainly watches, built on physics-based grabbing and full-body IK wearing, where a worn watch transforms into a sword to fight.)

What I built

Combat system (Highstreet Calamity)

A modular, physics-based combat system where weapons are composed from many small, single-responsibility components, each handling one aspect of the weapon. A sword’s two sharp edges are each their own damage-dealing component; shields are assembled the same way, with components that reflect or block. Because the components mirror the weapon’s physical shape, new weapons are built by arranging parts rather than writing bespoke per-weapon code.
Custom joint physics, the key challenge. Default joints reacted late and made held items shake and jitter; I implemented custom joint physics that account for the player’s motion, giving smooth, believable handheld weapon and shield physics.
Calamity is a client-server game (server-authoritative collision for anti-cheat, with hand interaction resolved on the client), and the combat I built runs within that model.

VR interaction & multiplayer

Full-body IK grabbing, shared across both games. On the social game Highstreet Market I built physics-based grabbing and wearing on a full-body IK avatar, including the watch→sword transformation.
Highstreet Market’s multiplayer runs on a custom NetworkObject/NetworkBehaviour replication netcode, and I built gameplay on top of it (I used the netcode, I didn’t author it).
Spent a long stretch maintaining a live multiplayer VR game while building new features on top, with heavy profiling and bug-fixing.

ECS, testing & mentorship

Built gameplay across GameObject and ECS/DOTS, using Burst and Jobs where performance mattered.
Built reusable ECS unit-testing infrastructure: base scripts that handle World creation and base-system bootstrapping on each test run, making system-level unit testing in ECS practical for the team.
Some REST API backend work, plus C#-to-blockchain integration through a third-party library. Mentored many developers on architecture and unit testing.

The hard part

Problem. A weapon or shield held in a VR player’s hand has to feel physical, but default physics joints react a frame late, so anything you hold visibly shakes. In VR, jitter on something in your own hand is instantly wrong and breaks the whole illusion.

Constraint. Combat also had to stay flexible, with many weapon types built without bespoke code each time, and hold up in a networked, server-authoritative game.

Solution. Two moves. Weapons are composed from small single-responsibility components (each sword edge or shield facet its own damage/behavior part), so the armory is data-shaped rather than hand-coded and a new weapon is an arrangement of parts. And the shaking is killed with custom joint physics that account for the player’s own motion, replacing the late-reacting default joints so held items stay stable and responsive.

Result. Smooth, believable handheld weapon and shield physics, and a combat system where new weapons are assembled from parts, shipped in a live, class-based VR roguelike on Quest, PC VR, and WebGL.

Idle Fisher

Personal project · 2019 · Personal · built solo as a student

Watch on YouTube

What it is

A top-down idle fishing simulation for mobile. You pilot a boat around the map, hold position over a shoal to fish automatically, and sell the catch for gold, which you reinvest into a growing fleet that fishes for you. Built solo in 2019 on a fully ScriptableObject-driven architecture. Released on Android and iOS long ago; since delisted.

What I built

Idle fishing loop: roam to find fish, hold to auto-fish, sell for gold, and reinvest into progression.
Autonomous AI fleet: hired boats and fishers navigate and fish on their own via FSM + NavMesh; enemy pirate boats seek and attack your ship.
Passive-income economy: gold feeds ship upgrades, hiring AI units, and pearl farms that generate a standing second income beyond active fishing.
Torpedo combat: aim and fire torpedoes to destroy attacking pirate boats.
Level-gated world: the map is split into sections that unlock as you level, pacing exploration against progression.
Fully ScriptableObject-driven, modular architecture: content and config live as data assets, not hard-coded.
Live-ops stack: GameAnalytics, Firebase (Analytics + Crashlytics), IronSource, plus A/B testing and remote config via Firebase Remote Config.

The hard part

Problem. “Idle” means the game keeps playing itself: hired boats and fishers have to roam, path, and fish believably whether or not you’re watching, and enemy boats have to threaten your ship without any babysitting.

Solution. Each boat/fisher is modeled as an FSM over NavMesh, so behavior is autonomous and composable, and the whole economy is tuned from ScriptableObject data rather than code.

Result. A complete idle game with an autonomous AI fleet and a tunable passive-income economy, the 2019 groundwork for the arcade-idle systems I later built at Hero Games.

Ant Hilton Idle

Hero Games · 2021–2023 · Hero Games · Sole programmer

Watch on YouTube

What it is

A mobile idle mining game. Ant colonies dig through areas, extracting blocks that convert into gold. Gold funds upgrades (more ants, faster movement, and a better block-to-gold conversion rate) with sub-upgrades that stack to raise the gold each mined block yields. Clear an area and it’s replaced with an empty room you can fill with decorations; each decoration generates steady passive income scaled to its level, upgradeable up to a cap. At Hero Games I was the sole programmer, working alongside a game designer and an artist.

What I built

As the sole programmer, I built all of the game’s systems:

Idle mining loop: ant agents mining blocks, block-to-gold conversion, and offline/idle progression that keeps earning while the player is away.
Layered upgrade economy: ant count, movement speed, and conversion rate, plus stacking sub-upgrades that compound the gold earned per block.
Room & decoration system: completed areas convert into rooms; placeable, upgradeable decorations produce stable passive income by level, up to a max tier.
Mobile live-ops surface: ads, analytics, and IAP-ready monetization.

The hard part

Problem. An idle economy has to stay rewarding across wildly different time scales, the first minute and the hundredth hour, without stalling early or trivializing later. Two income sources (active mining plus passive decoration income) and compounding upgrade tiers make the numbers grow fast.

Solution. A data-driven economy where mining yield, conversion, and decoration income scale on tuned curves, and offline progression is computed from elapsed time rather than simulated, so returns feel fair whether the player was gone a minute or a day.

Result. A complete, released idle title, with all of its systems coded by one engineer.

Idle Town

Solo project · 2017 · Solo · a high-school hobby

What it is

An asynchronous multiplayer idle game played entirely inside Telegram, built solo as a hobby while still in high school. It reached 400K+ registered users with 1K+ active players and, though a hobby, it was a genuinely commercial product.

What I built

Backend

The entire game server in vanilla PHP (no framework) + MySQL, driven by Telegram webhooks and cron jobs.
Resource, building, and progression systems with upgrade pipelines and time-based mechanics.

Gameplay

PvE, PvP, and boss combat with player progression and scaling.
Clan system with shared progression and role-based management.
Hero system with equipment-based upgrades and power scaling.
Leaderboards and rankings across multiple progression metrics.

Live game

In-game payments via Xsolla: a real, commercial economy that earned ~$7,000 in revenue, run solo.
Localized into 9 languages (English default), with professional translations.

The hard part

Problem. 400K+ registered users and 1K+ active players hitting a game that had no game servers in any traditional sense: just PHP, MySQL, cron jobs, and webhooks.

Constraint. One student, a student’s budget, and a stack chosen for being cheap to run rather than easy to scale.

Solution. Lean on the idle genre’s shape: state changes are either explicit player actions (webhooks, cheap to process one at a time) or time-based progression (computed in scheduled batches by cron instead of simulated continuously). The database does the multiplayer; nothing needs a persistent connection.

Result. The game served 400K+ registered users as a solo hobby project built in high school, and taught the systems thinking the rest of this portfolio is built on.

Nice Cream - Idle Tycoon

Hero Games · 2021–2023 · Hero Games · Gameplay engineer

Google Play

Watch on YouTube

What it is

An idle dessert-shop tycoon: build an ice-cream empire, hire and automate staff (chefs, cashiers, waiters, baristas), unlock new products, and keep earning idle gold while you’re offline. Originally built at Hero Games; it’s currently live on the Play Store, relaunched under Leap Games. I worked on it as a gameplay engineer.

What I built

As a gameplay engineer on the team, I worked across:

Core gameplay systems and the idle production/sales loop.
Staff automation: the hire-and-automate managers that keep the shop running.
Performance optimization for the mobile target, keeping a screen full of staff, customers, and products smooth on low-end phones.
General feature work: whatever the game needed to ship and keep iterating.

Fashion Arcade Idle

Hero Games · 2021–2023 · Hero Games · Gameplay engineer

Watch on YouTube

What it is

An idle fashion-store tycoon. You run a clothing store: collect fabric, turn it into clothing, sell it, and reinvest, buying more racks to serve more customers and expanding the shop. Hire cashiers and fabric technicians to automate production and sales, and upgrade their speed as you scale. Built at Hero Games.

What I built

I built the game’s core fabric-weaving mechanic and its supporting systems:

Fabric weaving via dynamic mesh manipulation: the player moves over a piece of fabric and rolls it up, and the mesh deforms in real time until it becomes a finished piece of clothing. This was the game’s signature interaction.
Upgrade systems for production and shop scaling.
Staff automation: hiring and upgrading cashiers and fabric technicians (the workers that produce clothing), including their speed upgrades.

The hard part

Problem. The fabric-weaving mechanic had to feel physical and satisfying, with fabric visibly rolling into clothing as you move over it, but run on mobile, where rebuilding mesh geometry every frame is exactly the kind of thing that tanks the frame rate.

Solution. Dynamic mesh manipulation that deforms and rolls the fabric mesh in real time as the player moves across it, kept cheap enough to stay smooth on the mobile target.

Result. A tactile signature mechanic, the core of how the game feels, running on phones.

Hide and Seek

Hero Games · 2021–2023 · Hero Games · Sole programmer

Watch on YouTube

What it is

A mobile arcade-idle infiltration game. You feed starter blocks into a machine that converts them into pickaxes, then deliver the pickaxes to a camp. Miners queue up, each grabs a pickaxe and moves to a ready zone; you collect the ready miners and lead them to the target zone. There, fields of unmined blocks sit under the gaze of patrolling guards, so you paint each miner the right color to blend in, mine a path to the gate, and once every block is cleared the miners open it. Past the gate they regroup, charge, and take out the remaining enemies. At Hero Games I was the sole programmer, working alongside a game designer and an artist.

What I built

As the sole programmer, I built every gameplay system:

Production pipeline: blocks into the conversion machine, pickaxes out, delivery to camp, and the miner queue that picks up tools and advances to the ready zone.
Miner agents and escort flow: collecting ready miners and leading them to the objective.
Stealth layer: guard patrol and vision, plus the color-matching mechanic that keeps correctly-painted miners unnoticed.
Mining, gate-unlock, and the end-of-zone charge-and-attack combat resolution.
Progression across zones and the mobile live-ops surface (ads, analytics, IAP).

The hard part

Problem. The game is really a pipeline of dependent stages (convert, deliver, queue, collect, escort, disguise, mine, breach, fight) where each stage feeds the next. If any stage stalls or desyncs (a miner with no pickaxe, a wrong-colored miner spotted), the whole loop jams.

Solution. Miners are modeled as small state machines moving through an explicit queue, with each stage gated on the resource it needs, so throughput scales smoothly as the player upgrades and the pipeline never deadlocks.

Result. A complete arcade-idle title with a deep multi-stage loop, all of it coded by one engineer.

Escape

Hero Games · 2021–2023 · Hero Games · Sole programmer

Watch on YouTube

What it is

A hypercasual escape game. A vending machine dispenses batteries; you collect them and carry them to power stations, filling each until they’re all powered and the exit gate unlocks, then on to the next level. A killer patrols the level the whole time, but can’t detect you while you’re hiding in a vent. At Hero Games I was the sole programmer, working alongside a game designer and an artist.

What I built

As the sole programmer, I built the full game’s code:

Core loop: battery spawning from the vending machine, pickup-and-carry, and power-station filling that gates the level exit.
Killer AI: continuous patrol, player detection, and pursuit, plus the vent-hiding rule that breaks line of sight and makes you undetectable.
Level flow and progression across escalating levels.
Mobile live-ops surface: ads, analytics, and IAP-ready monetization.

The hard part

Problem. Hypercasual tension lives or dies on the chase. The killer has to feel dangerous without being unfair, and hiding has to feel like a real escape, not a loophole.

Solution. A patrol-and-detect AI with clear, readable states (patrol → alert → chase) and a hard stealth rule, where vents fully break detection, so the player always understands why they were caught and how to get away.

Result. A tight, readable hypercasual loop, coded end to end by one engineer.

Enes Sahin Enes Sahin Enes Sahin Enes Sahin

01 / Featured projects

02 / Systems map

Unity & Engine

Architecture

Multiplayer

VR & Physics

AI & Procedural

Backend & Tools

03 / How I build

04 / Quest log

NocturnForge · Lead Game Developer

Highstreet Market · Senior Unity Engineer

Hero Games · Senior Game Developer

University projects · Computer Engineering

Idle Fisher

Idle Town · solo, a high-school hobby

05 / Achievements

06 / Contact

What it is

What I built

Architecture

Open world & streaming

Gameplay, characters & AI

Optimization & rendering

Documentation as infrastructure

The hard part

What it is

What I built

Combat system (Highstreet Calamity)

VR interaction & multiplayer

ECS, testing & mentorship

The hard part

What it is

What I built

The hard part

What it is

What I built

The hard part

What it is

What I built

Backend

Gameplay

Live game

The hard part

What it is

What I built

What it is

What I built

The hard part

What it is

What I built

The hard part

What it is

What I built

The hard part