It started with curiosity
As a kid, Newgrounds showed me that games and interactive experiences were things people could make and share. Someone could have an idea, figure out how to build it, and put it in front of other people. I wanted to understand how that happened.
That curiosity stayed with me. A game was something to enjoy, but it was also something to take apart in my head. How did a mechanic work? What made a choice interesting? What happened when two simple rules met?
Learning what a system has to carry
My years in the U.S. Air Force gave that curiosity a different kind of responsibility. In munitions inspection, explosive safety, quality assurance, and training, systems had to be understandable, repeatable, and useful to the people relying on them.
I worked with technical procedures, digital documentation, tracking systems, and automation. That experience taught me to look beyond an isolated feature: who uses it, what information they need, where mistakes can happen, and how to check the result.
Those questions still shape how I design. A tool earns its place by making someone's work clearer or more reliable.
Turning that experience into games
Game design gave me a place to bring those habits together with the curiosity that started it all. I studied game design at Full Sail University and continued through prototypes, professional R&D, consultation, tools, and experiments.
My work has included mechanics and level-flow proof-of-concept work on Happy! the Hippo and a focused design consultation on Flat Kingdom. Alongside those engagements, I kept building my own systems: puzzle rules, progression loops, interfaces, tools, and small pieces that helped a larger idea become playable.
I am a designer who can program. My programming skills are self-taught, developed through making things and solving the problems in front of me. Design intent comes first; implementation gives me a way to test it.
Hundreds of systems, one recurring habit
Across my life, I have built hundreds of systems, large and small. Some supported daily work. Some became parts of games. Others were experiments that answered a question and never needed to become a finished product.
Much of that work has lived inside a particular project. Some belongs to clients and stays confidential. The public portfolio is a selection of what I can share, with the scope of my contribution explained where it matters.
Why Cranberry Forge exists
Now I want to extract the reusable systems I can safely share from my games and give them a life beyond their original projects. Cranberry Forge is the home for that work.
Extraction takes care. A useful package needs clear boundaries, understandable inputs and outputs, documentation, and examples that work outside the game it came from. Private material and project-specific assumptions need to stay out. Dependencies should be explicit, and limitations should be visible.
The goal is practical: let another developer try a system, understand its behavior, and decide whether it belongs in their own project. The showcases here make those systems tangible; the public GitHub repository holds the source and documentation.
Craft, oversight, and checks
The engineering and code are hands-on work. I design and build the systems by hand, with AI used for oversight, review, and additional checks. It helps me question assumptions, look for edge cases, and examine compatibility across the environments a tool is intended to support.
I remain responsible for the design decisions and the result. Compatibility is something to establish through documented requirements, automated tests, and actual use. Checks help broaden that coverage; they do not make a promise that every system works in every environment.
That is the direction of Forge: carefully separated systems, useful demonstrations, and enough information for someone else to build with confidence.