The Opening Chronicle: Who I Am, What Went Wrong, and What We Built Since

Why I am writing this

This is the first entry in the Forge Chronicle, and it is the one I have been putting off. Progress reports are easy. They are about what shipped. This one is about how the studio came to exist, including the part where it almost did not.

I am writing it because the goals board and the progress reports only make sense with the context, and because I think the story is useful to other people trying to build something on their own. Some of the lessons cost me real time and real money. If they save someone else even one of those, this post did its job.

Who I am

I have worked in technology since 2008. Eighteen years, almost all of it in field-facing technical work for public safety and federal customers.

• Support engineer (2008 onward): networking, software training and implementation, hardware troubleshooting, and day-to-day ownership of customer accounts. This is where I learned that a fix nobody documented is a fix that happens twice.
• Deployment management, then field engineering: onsite implementation of vehicle routers and video systems in pre-sales, then standing behind them through testing and evaluation. You learn a lot about a system by being the person who has to make it work in a truck at 2 a.m.
• Video solutions architect (2016): the technical and architectural side of RFPs and RFQs. Reading a requirement, mapping it to an architecture, and finding the gap before the customer did.
• Leadership (2019), then director of technical services (2023): a group of more than thirty people across deployment coordination, solutions architecture, trial management, and support.

The through line across all of it is process. Turning field chaos into repeatable workflows. Writing the documentation gate that had to clear before anything shipped. Consolidating fragmented tooling into systems people would actually use. Every one of those habits shows up in how this studio runs today.

I have also been a gamer since I was five. RPGs and ARPGs are the genre I have put the most hours into by a wide margin, and mythology is what I read for fun. The idea that finally got me was simple: every mythology game I have ever played puts you in front of the gods as obstacles. I wanted to play as one. That is the whole pitch for Realms of the Ascended, and it is still the pitch.

My honest starting point on code: I was technical, but I was not a programmer. Eighteen years of networking, hardware, integration, and systems work gave me the instincts to read an architecture and smell when something is wrong. It gave me exactly zero ability to write a Gameplay Ability System class in C++. I learned that on this project, starting from courses, with every mistake out in the open.

Last year: the first attempt

In March 2025 I contracted out the build of a playable prototype. Fixed scope, roughly ninety days, a real amount of money for a self-funded studio.

• Five days in, I released the funds early. I was asked to, and I was given a direct assurance the work would be finished. That single decision is the root of most of what followed.
• The delivery date was early June 2025. The build arrived in mid October, more than seven months late.
• What came back was a ten gigabyte project that did not function as a prototype. Core systems named in the scope were missing: the second god's AI, the ability synergy system, the dungeon loop. Assets I had supplied were not used.
• I documented the gap properly. A full playthrough recording, a written assessment against the original scope, and a timeline of every commitment made and missed. That documentation is the only reason the dispute resolved at all. It closed in November 2025 through mediation.
• The net cost was survivable. The larger cost was roughly eight months of calendar time I could not get back.

I want to be clear that this is a lesson about my process, not about a person. I set the conditions that allowed it to go wrong. Here is what I took from it:

• Scope in slices you can accept or reject. A prototype scoped as "the whole vertical slice" gives you no partial credit. You find out at the end or not at all.
• Never release payment against a promise. Milestones exist so that a stalled project costs you one milestone, not the whole contract.
• Keep the work in a repository you control. I got status updates instead of visible commits. If you cannot look at the work in progress yourself, you do not know its state, and neither does anyone telling you otherwise.
• Play the build at every checkpoint. The first time I ran the project was after the money was gone.
• Own the codebase or you do not own the company. That is the one that actually changed my behavior.

The reset

In late February 2026 I stopped trying to salvage anything and started clean.

• What I kept: the design. The game design document, the pantheon structure, the ability designs, the Voidborn antagonist lore, the art direction. Years of design work, none of which was the problem.
• What I threw away: the entire delivered codebase. Not refactored, not partially reused. Deleted.
• Principle one: I write the code, or I directly understand and own every line written under my direction. Nobody hands me a black box again.
• Principle two: C++ first for systems, Blueprints for data and content only. Architecture decisions live in code I can read and diff, not in a graph nobody can review.

What we built since February

• February. New repository, new architecture, C++ first.
• Spring. The gameplay ability framework, built from the ground up: seven parent ability classes covering melee, area of effect, spawn, buff, beam, projectile, and passive. Every god's kit derives from those seven instead of being hand rolled per character. I also wrote the project's C++ conventions down so they would survive across sessions instead of living in my head.
• Spring. The first version of an in-editor tooling bridge that lets an AI coding assistant work directly against a running Unreal editor. It started as a handful of tools.
• April. Procedural dungeon generation working end to end.
• May. I started treating AI assistant context as an engineering problem rather than a prompting problem: a conventions file that loads automatically, and a specialist guide capturing every correction I had made twice.
• June. I left my job to do this full time. My last day was June 12. That same month the tooling bridge matured into a real UE5.7 plugin and became the primary execution layer for agent-assisted work, and we moved to Unreal Engine 5.7 as the working version.
• July. The session workflow that runs the studio day to day: a handoff and pickup ritual with written relay notes, a scoped work queue, and a running log of rulings so decisions get made once. The plugin passed 300 tools, scoped into groups so a session only loads what it needs.
• Summer. Jira and Confluence became the real home of the design document. The 500-plus page document I wrote by hand in 2025 became epics, stories, and linked pages that a work session can actually query. Three gods became playable in the prototype build with full ability loadouts, plus the cross-god synergy system where two abilities combine into a visible third effect. Survival mode arrived, with escalating elite waves and a boss encounter.
• August. The MegaGrant push: nine working days scoped against a single question, does this appear on camera or in the written application. Everything else deferred. The studio site, the Mythology Codex, and this Chronicle moved from prototype to live.

Lessons I would hand to any solo developer

• You cannot delegate understanding. I can delegate typing. I cannot delegate knowing what the system does.
• AI assistants write a lot of my code, and I review all of it. The model is a very fast junior engineer with no memory. That framing gets the value without losing ownership. I read the diff, I compile it, and I run it before it counts as done.
• Verify before trusting a claim, from a person or from a model. "It builds" is not a build. "That is fixed" is not a fix. This habit has caught more problems than any tool I own. It is the same habit I built running field trials: the report is not the result, the result is the result.
• Context beats prompting. Most of my quality gains came from writing conventions, corrections, and project facts into files the assistant reads every session, not from better phrasing. This is the documentation gate from my old job, pointed at a new kind of teammate.
• A domain-aware tool is worth every hour. A generic integration knows nothing about your architecture. Ours knows the ability parents, the naming rules, the folder layout. The difference is an assistant that guesses versus one that is correct.
• Give the assistant eyes. The largest single jump in output quality came from letting it read the actual project state and logs instead of describing them.
• Session memory is infrastructure. Handoff notes and a scoped session file mean a long project does not restart from zero every morning. Anyone who has run a shift handoff will recognize the pattern.
• Cheap tooling is fine, and the free tier is often the right answer. Free asset bundles, marketplace free rotations, free version control and hosting tiers. Spend the money on the thing you cannot do yourself, which for me is art and audio.
• Scope against a question, not a wish list. Mine right now is whether a thing appears on camera. One question makes cutting easy.
• Building the real thing teaches faster than studying it. I was not a game programmer eighteen months ago. The courses were necessary to start, but the project taught me more than the courses did, and doing it where the mistakes were visible kept me honest about what I actually understood.

What comes next in the Chronicle

The goals board on the Chronicle page is the honest list of what we are working toward, with statuses instead of dates. Between progress reports I plan to write the posts I wish I could have read a year ago:

• Setting up Jira and Confluence as a solo developer's design document
• Context engineering for AI-assisted Unreal work: what goes in a conventions file, and the handoff and pickup ritual
• Building your own editor tooling bridge, and why domain-aware beats generic
• A C++ first, Blueprint data only architecture, and the ability parent class pattern
• Sourcing assets on a self-funded budget: bundle sales, free rotations, what to buy outright
• Contracting art without getting burned: milestones, checkpoints, and how to write a scope so partial delivery is still useful

Thank you for reading this far. If you want the reports in your inbox, join the Ascended. If you spot something wrong or want to talk shop, info@viseterna.com reaches me.