SaxonDragon, on Prophesy of Pendor: Modding taught me how to lead without authority

Two articles in, you know what Prophesy of Pendor 2 is and what it intends to do. But to understand why SaxonDragon is the person capable of building it, you need to go back: to the mod that started it all, to the creative discipline that shaped it, and to the hard-won lessons about leading people who nobody is paying.

This third installment covers the most universally applicable part of the interview: how a great mod actually gets made, what modding and commercial development share (more than you'd think), and the human dimensions of game development that design documents never mention. Whether you've spent a thousand hours in Pendor or never touched Mount & Blade, this conversation speaks to anyone who has ever tried to build something with other people.

The honest answer is that Prophesy of Pendor resonated because I applied the same design principles that had been shaping my thinking since those sandbox campaigns in the 1970s, but this time I had an additional tool that most game designers weren't explicitly using: a formal psychological framework for understanding why people play games in the first place.

I had spent considerable time expanding McClelland's motivational model, a framework originally developed to explain human achievement, affiliation, and power needs, stretching it along additional axes to account for the fuller range of needs that games engage. Once you map those needs systematically and then hold a game up against that map, something clarifying happens. The gaps become visible. The places where the design is leaving player needs unmet stop being vague feelings of dissatisfaction and become specific, addressable deficiencies.

When I applied that model to Mount & Blade and Warband, the picture was clear. The base game had extraordinary bones: the combat system, the open world structure, the mounted warfare. But the presentation layer had significant holes. The lore was thin. The world didn't fully explain itself. The sense of consequence, of a living political and cultural reality operating around the player, was underdeveloped.

layers were engaging with a skeleton of a world when they deserved a world with flesh on it. Prophesy of Pendor was, at its core, an attempt to provide that flesh, to fill the gaps that the motivational mapping had made legible.

What made the execution particularly challenging, and I want to be transparent about this, was the environment in which it was built. I had no budget. No professional resources beyond my own time. I was learning a new programming language as I went. And I was leading a development team of nearly two dozen contributors who I knew only as usernames in a forum, people I had never met, spread across time zones, united entirely by shared enthusiasm for what we were building together. Managing that kind of distributed, volunteer-driven creative effort is its own discipline, and not one that comes with a manual.

The result was not what I would call perfect. I knew its limitations better than anyone, because I knew what the design was reaching for and exactly where it fell short. But perfection was never the primary goal. The goal was to demonstrate, to myself as much as to anyone else, that the skills were still there. That after years away from the industry, I could still build something that players would engage with deeply and return to repeatedly. Prophesy of Pendor answered that question more emphatically than I had dared hope.

What it also did was show me, with considerable clarity, what the next iteration needed to be. Prophesy of Pendor was the proof of concept. What comes next is the full expression of the idea.

It's a fascinating question, and having worked extensively on both sides of that line I can give you an answer that might surprise people: the difference is less fundamental than most assume. It is primarily a question of scope and scale rather than a categorical distinction in creative philosophy.

Consider how most commercial games are built today. The overwhelming majority use middleware, engines like Unity or Unreal, and when you build inside those engines you are, by definition, working inside someone else's house. You are operating within a framework you didn't architect, subject to constraints you didn't design, dependent on systems you don't fully control. The house has different furniture than a mod's house, and considerably more square footage, but the structural reality is remarkably similar. There are always walls you cannot move.

With modding the specific constraint is what developers call the black box, the hard-coded systems at the core of the original game that are simply not accessible for modification. You work around them, you work with them, you find creative solutions that achieve your design goals within their boundaries, but you cannot rewrite them. That requires a particular kind of disciplined creativity, learning to work with the grain of a system rather than against it, finding the spaces where your vision and the engine's architecture can coexist productively.

The deeper difference, in my experience, has less to do with creative freedom and more to do with the nature of commitment. When you have a full-time professional development team, you have something enormously valuable that is easy to take for granted: reliability. The work is documented. The processes are established. Every team member shows up, completes their assigned tasks, and can be counted on to deliver. The machine runs consistently.

A modding team operates on an entirely different foundation. Your contributors are conditional, they are there because they love the project, and the moment life makes competing demands on their time, the project waits. Skill levels vary enormously. Availability fluctuates without warning. Documentation is inconsistent at best. You are, in effect, leading a volunteer organization held together by shared enthusiasm, and shared enthusiasm, however real, is a more fragile binding agent than a paycheck and a contract.

But here is where the picture becomes more nuanced, because modding teams carry something that professional teams don't always have, and it matters more than people acknowledge: passion. People join a modding team because they love the base game and they believe in the vision of what you are creating together. That passion is self-selecting and self-sustaining.

Nobody fills out an application to mod a game they don't care about.

What modding taught me, ultimately, was how to lead without authority, how to inspire consistent contribution from people I had never met, using nothing but the quality of the vision and the culture of the community as my tools. That is a skill that transfers directly into any development environment, commercial or otherwise, and I would not trade having learned it for anything.

That's a question with many honest answers, and I want to resist the temptation to give you just one, because the greatest challenges in game development, whether modding or commercial, tend to cluster around a common core that doesn't get discussed nearly enough in design circles. We talk a great deal about technology and systems and pipelines. We don't talk nearly enough about the human dimensions of making games, and those, in my experience, are where the real battles are fought.

Leadership is the foundation everything else rests on. Not the kind of leadership that asserts authority or imposes vision from the top down, but the kind that creates the conditions for good work to happen.

That requires, above all else, the ability to listen, and I mean listen in the fullest sense of the word. Listening to yourself, so that your instincts and your design principles remain aligned throughout a development cycle that will do its best to pull them apart. Listening to your team, because the people closest to the work see things the design lead cannot see from a distance. Listening to your players, because they will tell you, clearly, persistently, and sometimes impolitely, exactly where your vision and their experience have diverged. And listening to everyone else, the critics, the skeptics, the voices you didn't ask for, because those are often the ones carrying the information you most need to hear.

Perhaps the most underrated challenge of all is maintaining a consistent vision across a development cycle that can span years. Scope creep is real. Team turnover is real. The temptation to chase trends, to respond to every piece of player feedback with a design change, to let the vision blur at the edges as time and pressure accumulate, all of it is real.

Holding the line on what the game fundamentally is, while remaining genuinely open to how it can be made better, is a balance that requires constant, conscious attention.

And then there is the ego. Leaving it at the door is not a one-time decision; it is a daily practice. The moment you become more invested in being right than in making something great, you have lost the thread.

Embracing the reality that you do not know everything, that your team members will see solutions you haven't considered and identify problems you haven't noticed, is not a concession of weakness. It is the most strategically intelligent position a design lead can occupy.

Lowering the power distance between yourself and your team, creating an environment where feedback flows freely in all directions and no one is afraid to say that something isn't working, consistently produces better outcomes than any amount of individual brilliance applied in isolation.

For commercial development specifically, the challenges shift in emphasis if not in kind. Changing technology is a constant pressure. Communicating effectively with the client, the people who are funding the development and whose trust you are holding, is a discipline unto itself. They need to understand what they are getting, when they are getting it, and what risks exist between here and there. That requires a level of transparency that can feel uncomfortable, because the honest answer to many development questions is: we don't know yet.

And finally, milestones. Achievable, realistic milestones that build in room for the unforeseen, because in game development, the unforeseen is not the exception, it is the rule. Every development timeline I have ever seen has been humbled by the unexpected. The difference between teams that survive those moments and teams that don't comes down to one thing: whether they built room for reality into their plans. Buffer is not pessimism. It is the scar tissue of experience.