Jump to content

RPG System v4 Updates

Recommended Posts

First update! This is picking up sort of mid-stream, but hopefully it'll make some sense anyhow. This update deals with identifying role identities for expected retail-inspired builds, and using a three-point gradient 'role chart' to start the process of turning a build from a loose concept into something actionable.

So, we're aiming for using a perk tree for character creation and development in v4, and otherwise going classless with the system. This means that, from a player perspective, you build your character by looking through the perk tree, and making choices to obtain the abilities and advantages that fit with how you envision your character. But from a design perspective, we have a bunch of things to consider to make something that seemingly simple actually happen and work well.

The first thing we have to consider is that while players will definitely want to make their own unique builds and come up with cool combinations of perks, there are also players who will want some kind of a baseline to work from, and the retail class specs are a great starting point for that. And for us, they can actually give us an avenue for starting to design the perk tree, since--if we know we want to accommodate retail specs (within the constraints to which we can)--we know we have some 'pre-set builds' to design as our templates. Structure is good!

But retail specs weren't designed with a classless 'free-form' character creation and development system in mind like how our perk tree is shaping up. So what we have to do is figure out how to 'convert' a class-based design into a classless design. And for that, we use a 'role chart.' Basically, what a role chart does, is it allows us to first identify what capabilities/responsibilities are common to different specs and builds, and use those to identify major, overarching roles. And then we can use those roles as axes on a chart, to loosely categorize builds, and 'reverse engineer' them into collections of perks.

I know it sounds complicated--and it is. But it's a necessary process to try to make sure that, for instance, a mage you build to be a certain kind of mage, actually performs and feels like they're that kind of mage. It allows us to build baselines and have a conceptual foundation to work from so that we know that something built to be a certain way should function correctly, instead of having the pitfalls that earlier versions of the system have had.

So, let's look at the current version of the role chart!


Kind of a lot going on there visually, but it's actually pretty simple to understand.

Our three main axes of the role chart are Control, Attack, and Support. At the top-left, the main capabilities/responsibilities (or 'verbs') of an axis are listed. These are conceptual more than mechanical, and act as guiding concepts for developing abilities and perks. For example, classic 'DPS'-focused abilities serve the 'Eliminates Enemies' verb, and so are more heavily found in roles which are higher up the Attack axis. For any given build, the more (and more fully) it exemplifies a given axis's verbs, the higher it should be on that axis; for example, the more a build does the things listed under the Control axis, the higher it should be on the Control axis. Pretty simple, right?

Each section of the chart pertains to a certain classification of a role. At the top right, the 'guide' shows what the generally expected balance of a role should be, given its place on the chart along a given axis. We then name these roles in a way which makes them consistent and understandable:

  • Any role which has no (or very little) influence from more than one axis, is considered a 'Pure' role on that axis. For example, a role which is all or nearly all Attack, is considered a Pure Attack role.
  • Any role which has a meaningful but not high degree of influence from a secondary axis (or two) is considered a 'Flex' role on its primary axis; for example, a build which is mostly Control, but has some amount of Attack, is considered a Control / Attack Flex role.
  • Any role which has a high degree of influence from a secondary axis (or two) is considered a 'Hybrid' role on its primary axis; for example, a build which is strongly Support, but has a high amount of Attack, is considered a Support / Attack Hybrid role.
  • And finally, a role can be both Flex and Hybrid. This relates to roles which are strongly mixed and adaptable; for example, a role which is strongly Control, but has meaningful amounts of both Attack and Support, is considered a Control Flex Hybrid role.

So now, we have a terminology and a classification method to start reverse-engineering retail builds, by plotting them on the role chart. This lets us know what the balance of abilities and perks we design for that build should be, so we don't--for example--design too much healing for a DPS build, or too much CC for a healer build.

From there, we can start breaking down retail builds and using these guidelines to identify key mechanics which make the build unique and special, how those key mechanics feed into the build's role balance, and what kinds of abilities and perks we should design to express those key mechanics. Right now, everything is still in the concept phase, but what this lets us do is go from nebulous ideas of what a build could be, to start narrowing down and identifying what actual actionable things we can design that can bring these builds to life. These can then be plotted onto a work-in-progress perk tree in the appropriate places, and we can start toying around what what a player could make out of those building blocks, and add, remove, or revise things as necessary. The end result--hopefully--being that players who want to make reasonably retail-faithful familiar builds, as well as those who want to take a traditional build and tweak it, and even those who want to make experimental and original builds from scratch, can all choose from the same broad selection of perk options in the perk tree, and have fun finding the combination and style that works best for them.

To finish up, let's look at an example retail build breakdown, with the Shadow Priest. I want to emphasize that this is not finished work, and was only created as an example of how a build breakdown could be written up to be useful from a design perspective, and that not all of the things contained in this example are likely to be retail-accurate; I just spun this one off the top of my head to illustrate the method. The actual in-depth retail build breakdowns are slowly underway by people who know retail way better than I do! But hopefully, this should give a glimpse into how builds are being classified, broken down, and turned into ability and perk concepts at this stage of development.


Whew, a lot of stuff in this update! Stay tuned for more as work on v4 continues!

Edited by aprettybigdeal
  • Like 4

Share this post

Link to post
Share on other sites
This topic is now closed to further replies.

  • Recently Browsing   0 members

    No registered users viewing this page.