Developer Interview - Field of Command

Introduce yourself, then.

I’m Southers, and I develop Field of Command: a WW2 strategy game about one command career, from platoon actions in France in 1940 towards the whole War in the West. I have been making games since a Hearts of Iron IV mod got its hooks into me during Covid, and Field of Command is the game I failed to build back then, finally being built properly.

You reduce all of game design to four things. Go on then.

The loop, the hook, the juice, and everything else. It sounds reductive, and it is, but keeping those four separate in my head is the single most useful habit I have picked up. Almost every mistake I have made, and most of the ones I watch other new developers make, comes from confusing them or building them in the wrong order.

Start with the loop then. What is it?

The loop is your core. It is what you want the player actually doing in 30-second beats, broken right down to clicks. For Field of Command that means: drag to deploy units, click to select and manoeuvre, find and target enemies, secure control points, repeat.

Written down like that it sounds basic, and at this stage it should be. The discipline is to just build it. Get the loop working early, with plain boxes on a flat plane, and worry about nothing else. If pushing boxes around is not fun, no amount of artwork is going to rescue it.

Boxes. Very glamorous.

Gloriously ugly, and that is the point. The moment there is something pretty on screen you will start polishing it, and polishing is the enemy this early. Boxes keep you honest.

Fair enough. So what is the hook?

The hook is what makes your game unique, the thing that draws players in. It has to be genuinely special, not a feature list.

For Field of Command the hook is persistence. Most RTS games separate their missions into disconnected skirmishes. I wanted to connect them: you are responsible for the same men and the same units, managed through an Order of Battle that carries from fight to fight, along with all the other things a commander has to handle beyond the tactics. Lose a veteran platoon at Cassel and it stays lost. That responsibility is the game.

And the juice? You keep warning people about the juice.

The juice is the feel and the look: graphics, animation, sound, VFX, music, haptic feedback, all of it. It is what takes a game from boxes to something that looks decent.

It is also the trap. Juice is where every new developer spends all their time before the loop and the hook are proven, and it is a big mistake. I say that with love, because I still do it myself. I will sit down to fix a pathfinding bug and surface three hours later having redesigned a muzzle flash. You have to physically drag yourself away.

Which leaves "everything else". That sounds ominous.

It should. Everything else is a bit like juice, but it is not to be underestimated: meta systems, save games, control remapping, UI and menus, localisation, marketing, and every other feature that creeps in. None of it is glamorous and none of it is optional.

Honestly, I would say everything else takes far more time than anything on the list. Plan for that from day one and it will not break your schedule or your spirit.

Walk us through the actual process on a new game.

It starts with a game design document, then a fast 2D prototype. AI tools make prototyping very quick nowadays, so there is no excuse to skip it. The prototype is loop first, then the hook in its simplest terms, and absolutely no juice. Then I tweak and perfect the prototype, updating the design document as the game teaches me what it wants to be.

Once the prototype has proven the idea, I set up the real project: a git repository with an architecture document, the full file and folder structure stubbed out, base classes in place, and lots of TODO comments marking future functions and features. I keep the structure as data-driven as possible, built modular and decoupled, so content and balance changes never mean surgery.

From there I create a todo index and turn it into a series of prioritised plan files, including a testing plan, with everything focused on the loop and the hook. Then I work to key milestones: code foundation, core loop, key features, vertical slice with juice, full horizontal blockouts, and finally content fills.

Any habits that keep it all on track?

A few that matter more than any tool. I set up a bug-reporting system early, so there is an easy feedback line when playtesting begins: logs, save game and a screenshot sent automatically into GitHub Issues and tracked from there. I use it on my own sessions as much as anyone else’s, which is humbling.

I also run a project tracker and work in sprints with strict deadlines, mostly so I learn how quickly I actually work rather than how quickly I imagine I do. The gap between those two numbers is character-building.

And give yourself breaks. Do not work weekends, or evenings, or whatever your line is. Take holidays. Exercise. A tired developer polishing juice at midnight is not making the game better.

Where does AI fit into all of this?

It is in the toolbox, and it is a good one: tools like Claude, Codex and Cursor make prototyping and coding much faster than they used to be. But it is a small part of making a game. The design, the taste, the testing and every decision that matters stay with the developer. AI speeds up the typing, not the thinking.

Final advice for someone starting out?

Publish early previews and start building an audience. It should not be your main marketing push, but opening up to an early audience on Twitter or Reddit, focused on your niche, does two important things: it tests whether the idea actually lands, and it gets you real feedback while changes are still cheap.

There is no point making something no one wants. Better to find that out in month two rather than year two.