Tuesday, May 31, 2011

Dueling Blogs!

Well not really :) But Keith Davies, creator of Echelond20.org came up with an idea where we'd do a sort of point/counterpoint or blog/counterblog stretch, somewhat comparing/contrasting Threshold d20 with Echelon d20. So, with that said, he's already off and running with two posts to my 0. First I'll respond to his posts with my thoughts, then I'll kind of do what he did, but for Echelon d20.

In this post he says "It seems to be closer to using Pathfinder System Resource Document (PFSRD) as a base than the System Resource Document (SRD) or Revised System Resource Document (RSRD) directly."

Well in truth yes, that's where I started, as in, from the Pathfinder revision of the various System Reference Documents. I wanted to have that as my baseline to build up/off from. Mainly because I could easily start with a snapshot of d20pfsrd.com and then strip away the parts I don't want as I go. It was really more of just a time-saver. Well that's not entirely true because initially I had intended to keep the various things that make Pathfinder Pathfinder as opposed to 3.5 Dungeons and Dragons. That meant keeping the Combat Maneuver mechanics and the newer revisions of all of the core spells etc. However, as development has proceeded, I have continued to strip away layers such that there really isn't much Pathfinder left in it. And ultimately, that's ok, because it turns out I really want something more fundamentally different than would be possible if I saddle myself with the requirement that it has to in some way look, or sound, or play, like Pathfinder. I've moved on now :)

Site Design is simple/clean
Well yeah but that's really more just because this is a virtual scratchpad at this point. So much of what I've had up has changed so much, so often, that dedicating any (or much) energy to presentation at this point would be a waste of effort.

What's New?
Well the "What's New?" sidebars were sort of a direct response to a request from site viewers who were having a hard time keeping up with my changes. I tried to add a quick summary of what was on the page, and a high-level overview of the significance of the rules associated.

In this post, Keith says, "Classes do have some design benefits, but there can be other approaches to the same design goals that avoid some of the problems experienced in D&D." And yes, I agree. Classes can make the development end of the game easier because it makes balancing powers and abilities easier by bundling good things with bad things so that each class is a self-contained package of "balance" by making the player take some things he doesn't care about in order to get the things he does. When I make a character I don't want to have to take feature B and C because I want feature A. I want feature A, and D. I won't go into too much detail but the point is, I personally want a more fine-grained character creation process.

Then, he says, "John’s use of ‘Action Point’ here is consistent with use from other games (a measure of how much an actor can or does do in his turn).  Several d20 games use ‘Action Point’ to mean ‘extra mojo you can pull out when needed’. On the face of it ‘fine grained’ doesn’t suggest simplification to me.  However, if it clarifies things it may make things simpler."

 Yes, precisely. In Threshold, a player spends Action Points to perform Actions. They are the basic currency of combat. Virtually anything a player wants his character to do is done by spending some number of Action Points (generally ranging from 1 to 5.) So then the question becomes, does this make things easier? Obviously that remains to be seen but the biggest way I think it simplifies things is it removes the arbitrary terminology of Swift, Immediate, Standard, Complete, Full, in terms of Actions, and replaces each with a simple number. The idea is that by introducing a text layer in the equation it requires players to do a translation step in their heads. Meaning, the player must translate "Standard" action and "Complete" and "Full Round" and "Swift" into some sort of mental math to understand how much his character can perform.

The idea is that by removing that translation step and cutting straight to a numeric value, the player can more easily and quickly understand HOW much his PC can do. This will be made even easier once I roll out a preview of the Combat Assistant sheets. The concept now is that each player will have a half-sheet of paper in front of him with a diagram roughly similar to the old Van Halen logo, meaning, a flying V. The left side of the V is titled "Act", the middle of the V is titled "Option", and the right side of the V is titled "Move."

Beneath each Title are 5 rows. Each row includes 2-3 short summaries of what the player gets for his PC if he allocates his Action Points into that field. For instance, under "Move" there are 5 rows.

Row 1 - "1: Gain 1 MP"
Row 2 - "2: Gain (Speed) MP"
Row 3 - "3: Gain (Speed + Dex) MP"
Row 4 - "4: Gain (Speed x 2) MP"
Row 5 - "5: Gain (Speed + Dex) x3 MP"

Then, when the player is allocating his Action Points, if he is using tokens or counters, he can put two tokens on Row 2 under Move and know he can move his speed in movement one time. If, however, he put 4 counters on row 4, he could move his speed x2 in movement. The idea is that by using a physical representation of actions, as in tokens or counters, he can push them around the combat pad to easily see what he can do.

The middle of the V, the Option field, is a sort of "neutral" or "unassigned" field where counters sit until used. Remember, counters (or tokens) represent Action Points. So, if the player puts two tokens into the Option field, he can use them later for special things. The idea currently is that he can, at any time, spend one counter out of the Option field, to add a +1 to any one check, or to add +1 any one Defense he has. This represents/replaces "fighting defensively" and "total defense" as well as feats that grant attack bonuses in exchange for actions. But this is simpler, and doesn't involve spending feats. Any character can do it simply by leaving counters in the Option field.

So, that's Option and Move which leaves Act. Its not called "Attack" on purpose, specifically because actually attacking something is only one of many options that a character may attempt. In all cases though the PC is "acting" in some active way. Either casting a spell on himself, on a friend, on an area, or attacking an enemy, or healing a friend etc.

So that's a very long-winded way of trying to explain the method behind what some may feel is the madness of point-based subsystems.

Lastly, Keith says "Again, tracking movement using points may or may not simplify things.  I’ll have to look at it carefully when I get to the details. I’m not sure that the mention of a Fatigue Point system belongs under this section or was intended to be separate, but formatting suggests it is.  I’m leery of it, if only because I’m not really fond of fatigue systems."

Movement: The unfortunate part is that since my latest thinking (as alluded to above) isn't even really on the site yet, the movement system may LOOK more complicated than I hope it really is. A little on the intent though is that so many places in d20 use phrases like "movement costs through these sorts of spaces are doubled" and then you get into complications of stacking of doubles and multiples of doubles etc. The idea of using Movement Points is that it allows the player to understand that each square of movement he is "spending" movement points. In most cases, it costs 1 MP to enter a square, so all a player needs to know is if he has 5 movement, he can move 5 squares with one movement. However, if there is a square in the middle that costs 2 squares to enter, he just has to count it that way. This also allows for simpler rules such as "if a square costs more than 1 MP to enter, a creature can not charge through it" instead of using several sentences to describe situations where a creature can or can not charge through an area.

Fatigue: The Fatigue rules are very in flux at the moment but the idea is that they will likely become a core subsystem, in that, all Ability Scores will tie into Fatigue rules (or at least the same mechanics that define Fatigue etc.)

Ok, that's enough of a "response" post, now I'll post a short review/summary of what I find about Echelon d20.

No comments:

Post a Comment