Unity Developer · C# Gameplay Programmer

Unity gameplay systems with clear architecture and practical trade-offs.

I design and implement gameplay in C#, separate runtime rules from Unity presentation, and keep dependencies and lifecycle explicit. The two case studies below show the code, architecture, and decisions behind playable projects.

Selected work

Two projects, reviewed through their engineering decisions.

Each case focuses on responsibilities that matter in a production codebase: dependency boundaries, gameplay extensibility, lifecycle, tooling, and maintainable Unity integration.

01 · Architecture & delivery

2D Asteroids Survival

A playable Unity survival game used to demonstrate dependency direction, scene composition, gameplay lifecycle, and asynchronous navigation.

  • Zenject composition roots connect Core contracts, Infrastructure, Gameplay, and UI without runtime service lookup.
  • SignalBus subscriptions and UniTask scene transitions have explicit initialization, teardown, and duplicate-action guards.
  • Game-over flow is split between session rules, a ViewModel, and a Unity view instead of a single scene controller.
  • Unity 2022 LTS
  • C#
  • Zenject
  • SignalBus
  • UniTask
  • Assembly Definitions

02 · Gameplay systems & tooling

Last Seed Survivor

A Unity 6 mobile auto-shooter built around modular weapon progression, data-driven rewards, a segmented enemy, and repeatable balance analysis.

  • ScriptableObject reward effects update isolated runtime weapon state; roll, apply, and popup presentation remain separate.
  • The segmented worm is divided into pattern building, factory, movement, section health, combat, balance, and presentation responsibilities.
  • A deterministic Unity Editor tool evaluates the same reward data, weapon configuration, HP rules, and DPS model used by gameplay.
  • Unity 6
  • C#
  • ScriptableObjects
  • Unity Editor Tools
  • UGUI
  • Android
Engineering approach & core stack

Engineering approach

Architecture should make the next change easier to reason about.

I use the smallest useful boundary for each problem: plain C# for rules and state, Unity components for engine integration, and explicit composition for dependencies.

Architecture

Explicit dependencies

Constructor injection where practical, Zenject at composition boundaries, interfaces for replaceable infrastructure, and Assembly Definitions for dependency direction.

Gameplay

Data and runtime state

ScriptableObjects hold authored configuration while dedicated runtime models own mutable combat and progression state.

Lifecycle

Symmetric ownership

Event subscriptions, input actions, asynchronous transitions, and scene-owned services are initialized and released by a clear owner.

Tooling

Repeatable validation

Editor tooling and deterministic inputs make balance changes reviewable without replacing playtesting.

Core stack

Unity gameplay from rules to platform delivery.

The terms below map to public code paths in the two case studies.

Gameplay

C#, Unity, Physics2D, Input System, combat, weapons, projectiles, enemies, rewards, progression

Architecture

SOLID, SRP, dependency injection, Zenject, composition roots, Assembly Definitions, MVVM-style UI

Runtime

Unity Profiler, cached references, allocation-aware code, mobile constraints, explicit lifecycle

Delivery

Android, Windows, UGUI, UniTask, async/await, Git, GitHub, Unity Editor tooling

Contact

Open to Unity gameplay and systems work.

Based in Finland and available for remote B2B or contractor roles as a Unity Developer and C# Gameplay Programmer.