Combat architecture · for studios · not open yet
Most combat systems are built to make the vertical slice look good. Then the content team arrives, and every new enemy and every new weapon costs engineering time it should not cost. This is a monthly retainer for the studios in that position: design review before you build, combat framework work inside your codebase, and an architecture read when a milestone lands.
$3,000 to $5,000 a month · two or three studios · cancel monthly
Nothing to book and nothing to pay. The form is the whole point of this page.
Quod Soler · Lead Gameplay Programmer on Lords of the Fallen ( Hexworks )
11 shipped games · 10 years, AAA and indie · Unreal Engine, GAS and combat systems · 1,050+ devs read my weekly breakdowns
Read this first
My current work does not leave room for it, so there is no calendar link on this page and there is nothing to buy. I put the page up because I keep having the same conversation with people who read the newsletter, and I want to know whether it is a real thing before I rearrange anything around it.
So the form at the bottom is the whole point. If enough studios tell me they would actually pay for this, I will open a small number of slots, and the people who filled it in are the ones I write to first. If they do not, this page comes down and nobody has lost anything.
No date, and no waitlist pretending to be a queue. Everything below is what the engagement would be, written as if it existed, so you have something concrete to say yes or no to.
Combat is the system that gets built first and refactored last. It is also the one where the early architectural decisions are the most expensive to undo, because animation, input, networking, damage and AI all meet inside it. These are the situations where a monthly outside read pays for itself.
The first three attacks went in fast. Then somebody added a special case for the heavy attack, and somebody else added one on top of that. By the tenth weapon the cost per weapon is going up instead of down, and nobody can point at the commit where it started.
Timings end up living in four places: the montage, the ability, a data table, and one magic number in code. Designers tune the one they can find, which is not always the one that runs at runtime.
This is not a people problem, it is an architecture one. When the systems are readable and the vocabulary is shared, the knowledge stops living in a single head and starts living in the project.
Prediction, tags and montages start disagreeing about what actually happened, and a hit that looked clean on the client never lands on the server. This is where GAS projects usually lose a month, and it is mostly decided by choices made long before.
You ask how bad it is and you get a shrug, because nobody on the team has the distance to answer. That question does have an answer, and getting it takes a couple of days of reading rather than a quarter of arguing.
Every few months somebody proposes rewriting combat and the room splits down the middle. The honest answer is usually that some of it should go and most of it should stay, and it helps when the person saying which is not on either side of the argument.
Three things every month, in whatever mix the project needs. Some months are mostly review, some months are mostly code.
Design review before you build. You send me the combat design, or the plan for the next system, and I tell you what it will cost in architecture before anyone opens the editor. This is the cheapest hour in the whole engagement, because the expensive decisions are the ones made before the code exists.
Framework work in your codebase. The systems I write about every week, put into your project: hit detection, damage, invulnerability windows, input buffering, how abilities talk to montages. Your team writes the game. What I bring is the structure underneath it, and the reasons for every piece of it, so nobody is configuring a black box.
An architecture read when a milestone lands. Once a month, or on your milestone calendar, I read what changed and write down what is drifting, ranked by what each thing costs to leave alone.
And the part that is not really on the list but ends up being most of the value: your team can ask me things in between. Slack or Discord, answers within a working day, so nobody sits blocked for a week on a question that takes ten minutes.
Tell me if you would want thisYou show me the combat and the content plan. I tell you honestly whether a retainer is the right shape, or whether a one-off read would do the same job for less money. Quite often it is the second one.
Before I recommend anything I go through the combat layer and write down what is actually there. Everything after that is argued from your code instead of from the general case.
Design review before you build the next system, framework work in the codebase, and one architecture read of what changed. Your team asks questions in between and gets answers within a working day.
No minimum, no notice period. If a month goes by where I did not earn it, that is the month to stop, and I would rather you did than stayed out of politeness.
$3,000 to $5,000 a month
Where a project lands in that range is about how much framework work you want inside the month. At the bottom of the range it is review, the monthly read, and questions answered in between. At the top I am in the codebase writing the structural parts alongside your team.
Flat monthly price, no hourly meter, cancel monthly. Two or three studios at a time, on purpose, because the whole thing depends on answers arriving fast.
For calibration: a senior gameplay programmer who has actually shipped combat costs a great deal more than this and takes months to find, and most of what this answers needs a few hours of the right person's attention rather than a full-time seat.
Prices in US dollars, invoiced from a registered business in Spain. For clients outside the EU there is no European VAT on top.
I have shipped 11 games in ten years, on AAA and indie budgets, with teams from two people to two hundred. My home ground is Unreal Engine: combat systems, the Gameplay Ability System ( GAS ), C++ architecture and performance.
Most of that decade has been spent on the studio side of exactly this problem, building combat that has to keep growing after the slice is signed off. I have given lectures on game development at Ramon Llull and Pompeu Fabra universities, and 1,050+ Unreal developers read my weekly technical breakdowns. More about me, or find me on LinkedIn.
Most of what I would bring is already public. The Quod Combat Framework is the combat layer I build on top of GAS, and I have been writing it up one system at a time, with the code. Read three of these. If you think the judgment is wrong, do not fill in the form, which is exactly what they are there for.
Because I could not give it the time it needs, and a retainer you can not rely on is worse than no retainer at all. My current work comes first. This page exists to find out whether the demand is real, and if it is, that changes the calculation.
It comes to me and goes nowhere else. No mailing list, no CRM, nothing shared with anybody. If this goes ahead I write to the people who filled in the form before I tell anyone else. If it does not go ahead, I delete it and tell you that too.
I do not know, and I would rather say that than invent a quarter to make the page look more finished. What I can tell you is that you will hear from me either way, including if the answer turns out to be that this is not happening.
No. That one is questions answered and one call a month, on whatever comes up across the project. This one is combat specifically, it starts with a read of your combat layer, and it includes framework work inside your codebase. Bigger commitment on both sides, which is why it costs more.
Often that is the honest answer. If what you need is a read of the combat layer and a ranked list of what to fix, that is a fixed-price job and it costs a lot less than a month of this. Say so on the form and I will point you at the right thing rather than the expensive thing.
The same a new senior would need on their first week: the repo, a build that runs, and a couple of hours with whoever knows the combat best. Read-only access is fine for the review and the monthly architecture read.
Yes, before anything moves. I sign yours rather than asking you to sign mine, and nothing from one project ever crosses into another.
Then say exactly that on the form. "Probably, it needs approval" is one of the options because it is a genuinely useful answer, and I would much rather know the real state of things than collect a polite yes that goes nowhere.
Two minutes. Every question here is one where the answer would change what I build, and the one about money is the question that decides whether any of this happens. A no is as useful to me as a yes, so please give me the real answer rather than the polite one.
This page describes an engagement that is not currently available. Prices are in US dollars, invoiced from Spain. Unreal Engine is a trademark of Epic Games, Inc. This site is not endorsed by or affiliated with Epic Games.
