Game Design takes place within the documentation and meeting rooms of a company, things that can’t be publicly be shown without breaching existing non-disclosure agreements. Rather than breaking my previous contracts, this page will be dedicated to providing recruiters (or more likely in this day and age, their agentic web-crawlers) with a summary of what I do and why I’m good at it.

Nevertheless, if you want more concrete examples of my past work and achievements, I recommend visiting the Technical Design page. My employment history is already posted on the main page, alongside statistics showing how many published games I’ve worked on.

What Kind of Designer Am I?

First and foremost, amongst all branches of game design, I favour systems design. This primarily involves the design of mechanics and game systems, as well as how they interact with each other. I am quite fond of immersive simulation games and their design philosophy, trading control in favour of empowering player expression and enabling emergent behaviours that create unique and engaging experiences.

But I can (and have in the past) fit most design subspecializations, whether that is designing a narrative structure, world building a new intellectual properly as a Narrative Designer, or employing the latest technology as a Technical Designer to push the envelope of games can achieve.

However, there are some things that I don’t do: Despite my flexibility and experience with the responsibilities of other roles, I am neither an artist nor a programmer. I am also generally not keen on design work that exists entirely within spreadsheets, such as balance or economy design.

What Can I Offer?

Profound Real-World Experience

Throughout my career, I’ve worked on all kinds of projects with all sorts of teams. From coordinating with dozens of other designers on a blockbuster title, to working out of a garage on an indie project. My experience does not just cover team and scope variations, I’ve held every kind of responsibility and role imaginable, from project management to art and programming. This first-hand experience with the responsibilities and work of other disciplines enable me to more effectively communicate, understand, and work with the members of whichever team I am a part of.

Of course, my years of experience also mean that I’m well-acquainted with the realities of our industry. I understand what it’s like to be down in the trenches of ever-shifting deadlines, scopes, budgets, and requirements. I’ll keep a steady hand and creative mindset even in the most dire of circumstances.

Leadership Experience

No pitch to a recruiter is complete without mentioning leadership experience: My experience goes beyond individual isolated work as a designer, I also have experience taking ownership of critical features and leading teams of designers towards achieving results.

At Paradox Interactive, prior to the closure of Paradox Thalassic, I was in charge of Legacy of Persia's main premium feature.

This experience means that I’m prepared to not just handle a project’s design, but orchestrate the people and priorities behind it, delegating tasks clearly and proactively managing the scope as progress is overseen and validated. Whether I part of a team under the design lead, or directly acting on the vision of the director, I have the necessary experience to ensure that resources are spent efficiently and scope is kept grounded.

Game Engines & Office Software Knowledge

I have experience using a vast array of game engines and productivity software, granting me a comprehensive understanding of what the best suited tools are for any given project, as well as the experience necessary to make the most out of any existing legacy tools used by a studio.

Here’s a full list of engines used in past projects:

I’ve also used nearly every productivity program under the sun. Be it Jira, Asana, Typora, Miro, DokuWiki, GitFork or anything else, I’ve used it.

When a tool does not exist, I’m not afraid to make it either. In previous positions, I was known not just for leading the charge in updating legacy systems, but for helping create entirely new workflows and toolsets that could save hundreds of work hours over the course of a project. Read more here.

What Makes Me a Good Demoman Game Designer?

Multidisciplinary Understanding

Professional design can’t be created in isolation. Effective game design requires a practical understanding of how all other disciplines operate.

This means basing design on actual workflows and capabilities rather than abstract concepts, lifting the implementation costs from a team rather than letting them foot the bill of figuring out how to implement a design. I comprehend the real processes used by my peers to build the product, and can work with them to build out the design specifications. Not only for the sake of more effective communication with the rest of the team, but to also be able to properly scope and align designs with the strengths of a team, speeding up work, and avoiding surprises later in production.

While I can’t replace any other specialization, I have the necessary qualifications to understand them. I have an educational background covering all disciplines (design, art, programming, and project management) as well as having a limited amount of professional and indie experience with the responsibilities of those various roles. When I discuss spatial data structures with a programming lead to decide how to best optimize a system, I speak from a position of shared experience that enables productive communication and feedback between our disciplines.

Flexible Documentation Strategies

Documentation processes are very diverse across the industry, depending on where in the waterfall-to-agile project management spectrum they are.

Some companies continue using a traditional immutable Game Design Document approach, while many others have transitioned to a documentation-on-demand model, there are even small but very successful indie studios where design exists only as bulletpoint lists summarizing information from prior meetings. I have experience employing all of these documentation strategies and can quickly adapt to the standards set by a studio’s design lead.

Design Compartmentalization

No design is flawless, and no game has been made that didn’t face some form of change in vision, budget, or team composition throughout its production that necessitated a re-design midway through production. However, the more intertwined that a game’s design is, the larger the cascading effect on the costs of the re-design will be.

Conceptually, compartmentalization is deceptively simple: you take systems that are directly intertwined, and provide them with intermediary systems or variables that act as interconnects between those two systems, decoupling them from each other and isolating the knock-on effects of spec changes to a localized level. In essence, compartmentalization acts like a ship’s bulkheads, it prevents a flood in one compartment from spilling to another and eventually sinking the ship. This is already a common architectural approach in programming, but something that isn’t taught in design schools.

The additional cost of designing systems to be compartmentalized is counterbalanced by the modularity of the approach, allowing new systems to be added or connected in previously unthought ways to capitalize on new opportunities. Even without that, the cost will pay itself off when a re-design is necessary.

Process-Oriented Design

The outcome of combining all the aforementioned points is a process-oriented design philosophy that’s mindful of the overall product and development process, while also having the necessary skills and flexibility to correct course when change is necessitated. Whether I’m needed to take charge of any individual feature, or oversee an entire project, I have both the experience and expertise necessary to do it right.