[4E] Resurrecting discussion of my retroclone, and requesting help and ideas.

[Ialdabaoth]

Tactical Rules & Index Compilation. (open4e.wikia.com)

This is an attempt to construct a patched 4E "work-alike" out of 3E's OGL, with modular systems to allow as much rules customization as possible.

At its current incarnation, progress has been made on the following components:

Core System
* Ability scores -100% complete
* Proficiencies - 100% complete
* Resolution mechanics - 100% complete
* Character creation - 75% complete
* Character progression - 95% complete
* Writing - 80% complete

Combat System
* Core mechanics - 95% complete.
* Character classes - 80% complete
-- Fighter - 99% complete
-- Rogue - 98% complete
-- Barbarian - 55% complete
-- Wizard - 70% complete
-- Sorcerer - 40% complete
-- Priest - 65% complete
* weapons and equipment - 90% complete

Exploration System
* Core mechanics - 10% complete
* Character classes - 0% complete
* equipment - 5% complete

Interaction System
* Core mechanics - 40% complete
* Character classes - 10% complete
* equipment & circumstance bonuses - 5% complete

If I can get this into a workable game, I'd still like to publish. Anyone care to help?

[Ialdabaoth]

If I can get this into a workable game, I'd still like to publish. Anyone care to help?

...did I err?

[erikun]

This looks to be a lot of material and you're asking people to visit another website to read through it all and critique, so perhaps you aren't going to get many responses. People don't seem very inclined to follow links.

Just looking through a few thinks, I begin to wonder what is your intention. You call it a 4e game based on 3.5e, but a number of design concepts don't seem to have any relation to either system. Abilities (http://open4e.wikia.com/wiki/Abilities) ends up talking about "Ability Bases", which don't seem to relate directly to the 3e ability scores nor the 4e ability + half level bonus. What exactly the Ability Base is or is used for isn't clear. Proficiencies (http://open4e.wikia.com/wiki/Proficiencies) are even further from 3e/4e design ideas.

It doesn't mean that the ideas you have are bad, mind you. It does makes me wonder what direction you want to take the project, and what your intent of making these changes was.

[Ialdabaoth]

This looks to be a lot of material and you're asking people to visit another website to read through it all and critique, so perhaps you aren't going to get many responses. People don't seem very inclined to follow links.

Just looking through a few thinks, I begin to wonder what is your intention. You call it a 4e game based on 3.5e, but a number of design concepts don't seem to have any relation to either system. Abilities (http://open4e.wikia.com/wiki/Abilities) ends up talking about "Ability Bases", which don't seem to relate directly to the 3e ability scores nor the 4e ability + half level bonus. What exactly the Ability Base is or is used for isn't clear. Proficiencies (http://open4e.wikia.com/wiki/Proficiencies) are even further from 3e/4e design ideas.

It doesn't mean that the ideas you have are bad, mind you. It does makes me wonder what direction you want to take the project, and what your intent of making these changes was.

Well, one of the primary intentions was to have a system that was explicitly modular, so that even core mechanics could be swapped in or out. (Using an 'Ability base' instead of 'modifier + 1/2 level' is one example of this - explicitly naming things that come up a lot allows you to refer to them directly if you want to change how they work).

Here is basically the evolutionary process of the game:

1. Start with the 3.5 OGL

2. Strip away everything but the D20 resolution mechanic and the six Abilities.

3. break 4E into a series of design goals.

4. For each design goal, ask "What is 4E trying to accomplish here?"

5. Ask, "Have we already constructed a mechanic that can accomplish this goal unmodified?"

6. If no, ask, "can we modify a mechanic we have already constructed to accomplish this goal and its current goals without seeming clunky?"

7. If no, ask "what is the most elegant mechanic we can construct to accomplish this goal?", then construct that mechanic.

8. If there are still unmet design goals, return to 4.

[Yakk]

When making a modular system, first start with a concrete implementation. Keep modularity in mind, but keep things as concrete as possible.

Then create a variant, and work out how to modularize the parts needed. Ensure that this modularization does not make the concrete game harder to understand: abstraction at the cost of use is an anti-pattern.

You almost certainly won't have 1000s of people using your modular system in different ways: this is even less likely if the game is harder to understand or play because it is modular. So all that investment in a modular system goes to waste, and even gets in the way of your game being playable!

Write and finish a concrete game engine, rather than a meta-engine. Concrete game engines are easier to read and easier to play. If abstraction helps the engine, then go with the abstraction: having a concept of an "ability check" somewhere, and referring to it, is an example of abstraction that may be easier than repeating "ability score modifier plus half your level plus d20" everywhere, and as it happens allows for a modular change in how "ability checks" work.

Similarly, your proficiency rules attempt to mix the rules for weapons, armor and skills together. While this seems like a laudable goal, when reading over it there is actually very little overlap between how armor, weapons and skill proficiency/expertise works!

Having that kind of design behind how armor/weapon/skill use works is good: exposing it just made it harder to read, because you keep going back between specific rules for armor, weapons and skills and general proficiency rules.

You might be able to refactor things better...

Suppose we have Abiilty Check and Ability Defence values.

Then the proficiency system can talk about "when the proficiency applies to Ability Checks or Ability Defence, you gain a +2 bonus. If you are expert, this increases to +3. If more than one proficiency would apply, use the larger bonus."

Then if there are any completely common rules elements between the 3 kinds of proficiency, also include the effects.

Then in the Armor Proficiency section, describe what other effects occur. Same for Weapon Proficiency and Skill Proficiency.

Advanced rules, like Extended Checks, can be put somewhere else, and include the take-10 and take-20 rules for experts.

Now we have abstractions that work for us, not against us. We can replace the rules for Ability Checks and Ability Defences easily. By naming it Ability Defence, we also get rid of the misconception in 4e that perceptions checks less than your passive perception automatically go up to your passive perception (which makes sense, because if it was something you could see passively, why would a check make you worse?)

Perception Defence both matches how 4e uses it, and makes it clear that it is only a target number when someone else acts and has to defeat your perception...

[Ialdabaoth]

When making a modular system, first start with a concrete implementation. Keep modularity in mind, but keep things as concrete as possible.

Then create a variant, and work out how to modularize the parts needed. Ensure that this modularization does not make the concrete game harder to understand: abstraction at the cost of use is an anti-pattern.

You almost certainly won't have 1000s of people using your modular system in different ways: this is even less likely if the game is harder to understand or play because it is modular. So all that investment in a modular system goes to waste, and even gets in the way of your game being playable!

Write and finish a concrete game engine, rather than a meta-engine. Concrete game engines are easier to read and easier to play. If abstraction helps the engine, then go with the abstraction: having a concept of an "ability check" somewhere, and referring to it, is an example of abstraction that may be easier than repeating "ability score modifier plus half your level plus d20" everywhere, and as it happens allows for a modular change in how "ability checks" work.

Similarly, your proficiency rules attempt to mix the rules for weapons, armor and skills together. While this seems like a laudable goal, when reading over it there is actually very little overlap between how armor, weapons and skill proficiency/expertise works!

Having that kind of design behind how armor/weapon/skill use works is good: exposing it just made it harder to read, because you keep going back between specific rules for armor, weapons and skills and general proficiency rules.

You might be able to refactor things better...

Suppose we have Abiilty Check and Ability Defence values.

Then the proficiency system can talk about "when the proficiency applies to Ability Checks or Ability Defence, you gain a +2 bonus. If you are expert, this increases to +3. If more than one proficiency would apply, use the larger bonus."

Then if there are any completely common rules elements between the 3 kinds of proficiency, also include the effects.

Then in the Armor Proficiency section, describe what other effects occur. Same for Weapon Proficiency and Skill Proficiency.

Advanced rules, like Extended Checks, can be put somewhere else, and include the take-10 and take-20 rules for experts.

Now we have abstractions that work for us, not against us. We can replace the rules for Ability Checks and Ability Defences easily. By naming it Ability Defence, we also get rid of the misconception in 4e that perceptions checks less than your passive perception automatically go up to your passive perception (which makes sense, because if it was something you could see passively, why would a check make you worse?)

Perception Defence both matches how 4e uses it, and makes it clear that it is only a target number when someone else acts and has to defeat your perception...

*nod* that's... exactly what I intended, but obviously not what I'm communicating.

I don't know that calling it an 'Ability Defense' is accurate, because the relevant stat is a Proficiency, not an Ability. It might make more sense to simply call things a 'Check' or a 'Defense'.

[Ialdabaoth]

It doesn't mean that the ideas you have are bad, mind you. It does makes me wonder what direction you want to take the project, and what your intent of making these changes was.

I've been thinking long and hard about this comment, and I've come to the conclusion that you're right.

This isn't a 4E clone.

If I'm being honest with myself, this is a "different take" for DDN. It has about as much relation to 4E as Pathfinder has to 3E - maybe a little less.

I think my ultimate design goal can be summed up as follows: "What could D&D Next have looked like, if WotC had decided to embrace the 4E design decisions instead of abandoning them?"

It takes direction from every previous edition of D&D, ultimately trying to tie them together in a very 4E way. But this does not make it a 4E clone.

[Yakk]

By starting with Abilities being the core of your system, instead of Proficiencies, you introduce one thing at a time.

You start with abilities, their modifiers, and how to make an Ability Check against a target number. You also introduce Ability Defences, which is what you roll against when the difficulty is controlled by someone else's ability.

You also make your system more modular (notice what happens if offensive/defensive proficiencies cancel out, and you eliminate proficiencies from the game? It works!) as a side benefit. DDN did this.

Proficiencies then become modifiers to Ability Checks and Ability Defences when they apply, be it attacks, your AC, or spotting someone who is hiding. You can even strongly tie most Skills to a single ability (so you have a Skill Defence and Skill Check that does not need to be recalculated for each situation).

Start with abilities. Then cover a really tight general proficiency system -- don't mention "oh, and sometimes you can do extra stuff with expert level" unless it is an actionable item. It just adds to applicable ability checks and defences, as far as I can tell.

Then, cover skill proficiencies. This should mention what the skills are, what their attached ability is (plus the mention that rarely a different ability is attached), and how you can use them in conflict. This is a chapter.

Then, cover weapon proficiencies, and how they interact with powers and basic attacks. Maybe include weapons here.

Maybe a chapter on implement proficiencies, if you want to divorce them from classes.

Then, cover armor proficiencies.

[Ialdabaoth]

By starting with Abilities being the core of your system, instead of Proficiencies, you introduce one thing at a time.

*nod* so it sounds like there's a step even before this - I really need to be writing the DMG and PH before I write the Wiki - or at least, before I have people look at the Wiki.

I.e., I need a coherent and presentable linear explanation of my rules, before I have a hyperlink reference for those rules.