Epitaph Help

Categories

Concepts	Creator Commands	Creator Tutorials	Games	Innate Commands	Known Commands
Lord	Npc	Objects	Playtesters	Rooms	Rules

Development Principles

Introduction

The following constitute the core of the principles I would like to see embedded in our approach to development.

Fun is Paramount

One of the things that was a big feature during the darker days of Discworld development was the simulationist approach to development, where realism was considered a worthwhile goal of itself. That is not our focus on Epitaph - we are not creating a world simulator, we are creating a game. Whenever we have a tension between realism and fun, then fun wins. That is not to say that we can't make changes that make the game more realistic, but that can never be the sole reason. That way lies madness. In fact, we should be actively reducing realism in order to increase fun wherever we can.

Remember this - Realism is easy. Fun is hard.

Our focus is not on creating a big game world - our game is not about how many far-flung locations you can visit. Our game is about have a rich game experience within relatively small constraints. That is not to say that we don't add in new areas and such when it's appropriate, but we do it when there's a reason. We don't simply code areas for the hell of it, we code areas to support our goal of having a rich and engaging MUD.

As an example of this, we don't simply add in a new city just because we haven't in a while. In order for it to be an appropriate development, it needs to be featureful. It needs to be unique in its theme and risks/rewards. It needs to progress our story. It needs to add something other than room-count.

Development should be Agile

Those areas that we do have under development should be assessed for what bits can be put into the game sooner rather than later. Rather than embarking on massive, monolithic, multi-year projects, we focus on small, agile projects that have a much quicker turnaround and can go into the game much quicker.

Again that is not to say we cannot aim high, but we should aim high while also maintaining a steady stream of new content in the game. If we want to add an awesome new game subsystem, we should - but it should be done as a sequence of relatively short-term deliverables.

Respectful Development

I think I'm going to refer to this as Drakkos' Law - 'We can't afford to indiscriminately piss off our players'. It used to be the case that MUDs were still growing and for each player that was lost another two would take their place. That's not the case any more - we have to be more respectful of our player-base than we have in the past. There are many examples of code that we've taken out of the game and never replaced, of times when we've changed skill checks and levels without notice (and often without good reason), and of an indifference to player complaints or requests for justification. All of that works to erode whatever trust people invest in us as developers, and only serves to limit the sense of ownership people feel about the game.

Really, what this boils down to is how we treat 'in game' code. We have to start treating code that is in the game as just an extension of our development cycle. When code goes live, we need to start treating it more carefully - we have to put a big circle around it with the label 'don't screw around with this'. This doesn't mean we can't make changes when necessary, but we shouldn't make them quite as cavalierly as has been done on Discworld. Basically, code being approved for the game now means 'this code is protected from change'. We need to thus think a bit more carefully as to when approval should be granted.

No More Secrets

Well, that's not a workable principle - but I would like to see us being more open about our development than we have in the past. We need to be careful with this to manage expectations of course, but there's no reason why we couldn't make a bigger deal of where the MUD is heading and the exciting things we have planned. Communicate with people about the plans for the game, get them excited, and get their input.

To go along with this, let's not hide all the calculations in the code. I don't mean we should put the numbers out there for everyone to see, but everyone should be aware *what* is going on and roughly how well they are achieving at things. A good game is one that prompts people to make interesting decisions. Compare two systems with differing levels of visibility - the combat system on Discworld before and after the combat messages were put in.

In the first, people picked weapons and got warnings if they were too heavy or clumsy for their stats. They'd swing a weapon, and hit or miss. If they hit, they know how much damage they have done.

In the second, feedback messages are given whenever players are acting under a positive or negative modifier. They talk about relative weapon weights, position of players in the melee, the impact of fatigue and health, and much more.

The calculations are exactly the same in both cases, and while the feedback messages don't give much granularity of information, they reveal what is used in the calculation and open up a much greater range of decisions for players seeking to excel.

So as a general rule, let's do this - when calculations are being made, players know about it, and they know (roughly) how their own setup factors into those calculations.