As with any piece of work, it’s best to identify the goals of the work – if for no other reason than being able to know when you’re done.
My goals in developing Echelon are pretty straightforward.
A little over a month ago I posted three articles about how D&D 3.x fails.
D&D Failures Part 1, Systemic Failures
The first article was about systemic failures, places where the rules simply don’t work. These are mostly to do with how magic grows to overpower or make irrelevant other aspects of characters, or render nonmagical characters irrelevant themselves.
In Echelon, I want to fix the systemic problems.
- I want characters who are not spellcasters to have comparable abilities and power.
- I want it to be possible to have characters who have a mix of abilities without being either underpowered or overpowered.
- I want it to be possible to have playable nonhuman characters of very varying type and base power, without ending up underpowered or overpowered.
- I want ‘mundane’ skills and abilities to be as fantastic as spell casting, and not trumped by spell use.
D&D Failures Part 2, Application Failures
The second article was about application failures, places where the game was difficult or time-consuming to prepare for. This mostly lands on the Dungeon Master’s side, but players are affected by it too.
The application issues don’t necessarily affect game play directly (except when they lead to mistakes that cause TPK), but they do detract from my fun in playing the game.
- I want to reduce preparation time and effort. I’ve developed a number of tricks and a library of prepared material I can call on, but it can still be fiddly and time-consuming. Also, even with this library and these tricks I still create new stuff. I’d like that to be quicker and easier.
- I want to reduce the several numbers used to measure how powerful or how much of a challenge a creature is. We have three (Hit Dice, level, and Challenge Rating), which I think is two too many. I don’t mind the ‘CR math’ so I don’t expect to worry about it.
- An overarching goal here (not mentioned explicitly as a failure, because it isn’t really) is to reduce complexity. Anything that can streamline preparation or play, or make it easier to accurately predict the consequences of design decisions (which will reduce time and work needed to build a good scenario) is fair game.
D&D Failures Part 3, Setting Failures
The third article was about setting failures, places where reasonable application of the rules and abstractions can lead to undesirable results. These are not problems for everyone, either because their play style works around these issues or because they are comfortable with the consequences.
The setting problems aren’t so severe to me, and appear to be best handled in non-mechanical ways. I have no hard goals in this area, but I’d like to be able to encourage different behavior.
- I’d prefer to avoid a MagicMart mentality. Ideally this would be done by moving the focus away from magic items to the player characters. Reworking the abstractions behind the economic system would probably help too.
- While the extreme advancement rates may be a consequence of the advancement rules, this is fairly easily handled non-mechanically by not having so many adventures back to back. I think I can describe several ways to encourage slower pacing.
- I’d like to see it more practical or effective to spread the use of resources through the entire adventuring day, rather than expending in a short burst for maximum power.
It was not one of my intended goals, and I don’t want to make it a goal per se, but I can see how the work I’ve done on Echelon can probably be adapted for use in other genres than fantasy. Fantasy is still my primary goal, and I have seen too many ‘generic’ systems fail because of some mix of clashing assumptions, excessive complexity in order to be universal, or being too generic, but given Echelon’s architecture I think it can support a fairly broad range of genres.
We’ll have to wait and see. It’s not a goal, but if it can be accommodated I’m all for it.
I think these goals are achievable. Where it is necessary to compromise, I expect to give precedence as shown above – systemic problems first, then application problems, then setting failures. I am not trying to build a truly generic system, but the framework so far suggests it may be possible to readily adapt to a broader range of genres than I was planning.