EMIRHAN KÖSE

GAME DEVELOPER · GAMEPLAY & SIMULATION

Emirhan Köse

Unity / C# Developer & Gameplay Systems Designer

emirhan.kose.25@gmail.comgithub.com/emirhanssk ↗LinkedIn ↗

Unity / C# game developer with a released Android game and active RTS and city-simulation projects. Focus: gameplay implementation, formation geometry, economy simulation and optimization.

Started with Unreal Engine Blueprints; moved to Unity for mobile development and greater implementation freedom.

Project experience

Independent game development
Released product & active prototypes

RELEASED / ANDROID · GAMEPLAY DESIGN & IMPLEMENTATION

Fallune!

Google Play ↗

A mobile arcade sorting game built around directional swipes, accuracy and timing.

UnityC#Mobile gameplay

Input resolution. The swipe direction is matched to the expected direction of the active box. A decision window defines when a response is accepted; a narrower perfect zone distinguishes precise timing. This separates the player's directional decision from the timing challenge.

Difficulty and pacing. Spawn interval and travel duration control how often decisions arrive and how much time the player has to react. The spawner exposes a minimum travel duration and a score-linked decrease, so speed can increase without becoming unbounded.

Scoring and run state. Correct inputs, wrong inputs and missed boxes feed score, combo and level progress. Campaign completion follows level objectives, while endless play focuses on continued performance. Failure rules belong to the gameplay flow, allowing the UI to present results, retry and continuation consistently.

Feedback and recovery. Combo tiers, hit feedback, music and haptics communicate success. After a continuation, the spawner supports a delayed first spawn and grace spawns so the player can re-enter the rhythm.

Architecture & optimization +

Gameplay, input, UI and service responsibilities are separated into dedicated systems. The project includes local saves and cloud synchronization, achievements, leaderboard UI and analytics integration. Box prefabs and materials are cached; active boxes and expected directions are tracked in pre-sized collections.

Technical description reflects the reviewed repository. Store availability may vary by region.

IN DEVELOPMENT / RTS · MOVEMENT SYSTEMS

Battle Orders

A regiment-based RTS project exploring how soldiers move as a coherent formation.

Unity / URPC# simulationFormation geometry

Order and movement modes. A move order contains a destination centre and final facing. The current movement model chooses individual movement for orders within 20 metres; longer orders use rank-following movement. The selected mode is fixed when the order is issued, avoiding repeated switching as the regiment approaches.

Route construction. The planner builds a turn–straight–turn route in the horizontal plane, applies fifth-degree smoothing and checks curvature. Position, tangent and normal samples form a common route representation for movement and visual debugging.

Rank-following. Each rank advances along the route with its own progress. Soldiers are placed across the rank along the route normal, so the rank stays perpendicular to its direction of travel. Ranks reach a curve at different times rather than rotating simultaneously around one regiment centre.

Turning without backward steps. If the centre-line radius is R and the half-frontage is h, the wings follow radii R − h and R + h. Requiring R to exceed h keeps the inner wing's radius positive. The outer wing covers more distance, so advance is slowed according to curvature and formation width.

Spacing and cohesion. Minimum rank separation prevents intersecting lines, while a stretch limit stops leading ranks from leaving trailing ranks too far behind. When a safe advance is unavailable, a rank waits. This makes spacing a rule of the movement model rather than a purely visual correction.

Obstacles and arrival. Routes and individual paths account for obstacles and neighbouring regiments. Waiting and unreachable states expose the reason an order cannot proceed. Final alignment and slot placement complete the destination formation; frontage can be defined with a drag gesture.

Verification & performance +

For formation turns, the route radius must exceed the formation's half-width. This keeps the inner wing moving forward rather than requiring backward steps. Rank spacing and stretch limits prevent the formation from separating excessively.

The simulation uses planar C# geometry without UnityEngine dependencies. The 3D presentation reads the route data used by the movement system. Headless tools measure order time and allocation, verify route parity and exercise movement scenarios.

The benchmark harness includes three 24 × 6 regiments (432 soldiers). Screenshot FPS is a development capture, not a hardware-independent performance claim. Multiplayer and ranked play remain project goals.

BUILD → SUPPLY → GROW

A city is
a connected
economy.

Roads. Homes. Resources.
Services. People.

UNITY / MOBILE PROTOTYPE

IN DEVELOPMENT / MOBILE · CITY & ECONOMY SIMULATION

Cities Tycoon

A tycoon and city-building hybrid where spatial growth and production chains shape each other.

UnityEconomy simulationMobile rendering

City-building layer. Roads establish the layout, residential zoning adds housing capacity, and population growth fills that capacity. The city therefore needs both room for residents and an economy capable of supporting them.

Demand and production. Population drives demand. Raw resources enter production chains that create intermediate and finished goods. Chains such as wood to lumber and furniture, or ore and coal to steel, introduce dependencies: expanding the final factory does not solve a shortage in its inputs.

Imports and financial pressure. The economy includes external purchases and import costs. Local production and consumption are tracked alongside money flows, making supply deficits financially visible and giving the player a reason to build a more self-sufficient city.

Services and quality of life. Electricity, water, sewage and garbage systems compare service demand with capacity. Education, healthcare and security add further city-management responsibilities. Happiness applies growth and income multipliers, linking infrastructure decisions to economic development.

Progression and education. Population milestones introduce new services and production chains gradually. Advanced goods also require education thresholds, so population alone does not unlock effective high-tech production. Reached city levels remain unlocked after a population decline.

Goals and onboarding. The opening tutorial teaches roads, zoning, housing and city metrics toward a 500-resident goal. Contextual tutorials explain newly unlocked systems. Development goals combine population, services and product supply; for meaningful demand, the documented product goal requires local output to cover at least 90% of demand.

Optimization & telemetry +

Repeated road and residential meshes use GPU instancing. A chunk-based visibility system limits rendering work, while cached transform matrices and reused buffers reduce repeated CPU work.

The economy runs on a configurable tick rather than recomputing every system each rendered frame. Catch-up work is capped at two ticks per frame. Telemetry records city metrics, making demand, capacity and cash-flow behaviour inspectable during balancing.

Profiler and telemetry images show development snapshots. They are not a controlled before-and-after benchmark.