I build practical software at the boundary between product design, systems engineering, and dependable delivery.

My current focus is World of Ato, a Windows-native multiplayer RPG and custom game runtime. I am building the engine, authoritative server, native player client, content-authoring Studio, and self-updating release pipeline as one coherent product. The work spans realtime simulation, native rendering, data-first content, persistence, security, and production tooling.

World of Ato is designed around explicit boundaries:

• the authoritative server owns gameplay outcomes and persistent player state;
• the native client sends intent and renders replicated world state;
• the shared engine carries world, terrain, scripting, asset, and protocol contracts across runtime surfaces;
• Studio authors versioned worlds and content without entering the shipping player dependency graph; and
• the bootstrap and launcher validate and distribute complete client generations.

The World of Ato engineering case study includes the architecture manifest, runtime boundaries, networking, rendering, UI, persistence, security model, update chain, validation strategy, constraints, and future priorities.

• World of Ato — custom multiplayer RPG runtime with an authoritative server, native SDL3 / Direct3D 11 client, NoesisGUI player UI, Studio authoring tools, SQLite persistence, and signed self-updating distribution.
• KSuite — proprietary, production-oriented embroidery digitizing system with a typed intermediate representation, image and topology analysis, stitch generation, machine QA, desktop editor, API, browser Studio, and PES export boundary.
• KSuite case study — engineering manifest covering implementation boundaries, verification, performance observations, constraints, and publication limits.
• KSuite infrastructure — sanitized deployment, CI, and operational patterns for the KSuite stack.
• Campfire — an open-source Python project demonstrating product-minded application development.

• Keep one production source of truth and make boundaries explicit.
• Prefer measurable invariants, validation tools, and regression tests over visual guesses.
• Treat security, failure states, operational limits, and upgrade paths as part of the product.
• Use issues for decisions, branches for isolated work, pull requests for review, CI for repeatability, and releases for artifacts.
• Document both what is implemented and what remains uncertain or planned.

• Core: .NET 10, C#
• Runtime / graphics: SDL3, Direct3D 11, Vortice, NoesisGUI
• Desktop / tooling: Avalonia, WPF, WebView2
• Web: React, TypeScript
• Data / distribution: SQLite, PowerShell, WiX, GitHub Actions

• Core: Python, NumPy, OpenCV
• API / UI: FastAPI, PySide6, React/Vinext
• Domain: pyembroidery
• Delivery: Docker, GitHub Actions

Most of my repositories are works in progress. The best way to understand one is to start with its README, engineering manifest, source boundaries, and test suite.