Developer's Kit: Point Systems

[MPHopcroft]

One of the necessary elements of a ground-up system build in the upcoming Developer's Kit will be the fact that many systems you'll want to use it for are pure point-buy; the player or GM gets a single pool of points from which to purchase ll the abilities of the character (frequently having the opportunity to gain additional points by picking up things that hinder them). M&M works somewhat like that (the PL gives you a pool of points from which to buy the PC's abilities).

So not only is that capacity important to be able to include, but it is also important to have the ability to allow the GM using the system to simply pile on the points regardless of the set limits for NPCs (for which he can use any rules he wants to create characters).

How easy will that be to code in?

[Mathias]

From what I've seen, everything in a point-buy system would be coded in the scripts - d20 skills are themselves a point-buy system, so it shouldn't be hard to expand that to using the same (or multiple) pools of points for everything on a character.

Note that for the attribute point-buy systems for d20 (from the configuration dialog that pops up at the beginning, they have a variety of point counts available.

[MPHopcroft]

From what I've seen, everything in a point-buy system would be coded in the scripts - d20 skills are themselves a point-buy system, so it shouldn't be hard to expand that to using the same (or multiple) pools of points for everything on a character.

Note that for the attribute point-buy systems for d20 (from the configuration dialog that pops up at the beginning, they have a variety of point counts available.

Remind me where in the docs its mentions coding scripts at that level. I'd like to do as little as possible through a programming language (the only such language I could ever wrap my brain around was 1978-era BASIC, which is an embarrassing thing to admit).

Theoretically the tools are in place now to do the basic setup of a completely new game system -- just not in an intuitive format. Just as I am seeing how it is possible to do all sorts of neat things to the d20 System template -- just not necessarily easy.

which leads to an interesting coding problem: find a way to take everything in the D20 System, assign it a point cost, and have it purchased from a single pool based on your level. In other words, everything: spells, skills, feats, special abilities, ability scores -- draws from the same pool of points.

[Mathias]

As far as I can tell - the ability to create that point system is not currently available in HeroLab - The data you'd need to modify to add all that in is in pre-compiled files - the ones that tell HeroLab how a D20 class or skill works in the first place.

In terms of the scripts, imagine creating a new attribute solely for the points available. A script running on everything subtracts the appropriate amount of points for whatever it is from that attribute - at least that's how the same sort of thing could be achieved in Armybuilder.

It would take heavy programming, though.

[MPHopcroft]

As far as I can tell - the ability to create that point system is not currently available in HeroLab - The data you'd need to modify to add all that in is in pre-compiled files - the ones that tell HeroLab how a D20 class or skill works in the first place.

In terms of the scripts, imagine creating a new attribute solely for the points available. A script running on everything subtracts the appropriate amount of points for whatever it is from that attribute - at least that's how the same sort of thing could be achieved in Armybuilder.

It would take heavy programming, though.

Heavy programming is beyond m own capability, I'm afraid. I wonder if there is a way for LW or someone to create something that is not tied to any system simply as a way to make the lifting lighter for people creating their own point-based game system files. Thatay be something for he ful release of the Developers Kit.

nWOD is, IIRC, point-based to a degree. MRQ in its canon form uses pools of skill points to customize characters that vary in size depending on the campaign power level. M&M is completely point-based, with your Power Level defining how many points with which you can build your character.

[rob]

At 11:14 AM 3/20/2007, you wrote:
One of the necessary elements of a ground-up system build in the upcoming Developer's Kit will be the fact that many systems you'll want to use it for are pure point-buy; the player or GM gets a single pool of points from which to purchase ll the abilities of the character (frequently having the opportunity to gain additional points by picking up things that hinder them). M&M works somewhat like that (the PL gives you a pool of points from which to buy the PC's abilities).

So not only is that capacity important to be able to include, but it is also important to have the ability to allow the GM using the system to simply pile on the points regardless of the set limits for NPCs (for which he can use any rules he wants to create characters).
ow easywil tate tocode in?
There are two factors involved with this. The first is the Hero Lab engine itself, which basically allows you to do whatever you want. The second factor is the way the data files are designed. This is where things get more interesting.

The mechanisms that are currently provided with the d20 files are actually implemented BY the d20 files. They are NOT a limitation of the engine. They are simply what has been added to the data files at this point. This is an important distinction, since users are likely to view the two as the same thing. With the development of data files for other games underway, the engine can support everything we've thrown at it so far, plus a whole lot of stuff we haven't yet tried.

Quite simply, Hero Lab provides a generic language and interface for describing RPGs. In the same way that you can write both a word processor and paint program using the same programming language, Hero Lab allows the description of radically different RPGs.

The d20 files have only implemented the handful of spell mechanisms used by the SRD. Other mechanisms can be added, with various levels of complexity involved. Each spell mechanism has to have the following performed:

1. Implement the basic mechanics for allocating the pool(s) allowed. For example, d20 assigns a fixed number of spells for each level, and so an array is used to easily specify this. For a point-buy system, a single resource pool field might be used that has points assigned to it via a script (much like how skills work). Just about anything can be supported by the Hero Lab engine.

2. Handle multiplicity. In a multi-class situation, proper handling of distinct requirements and pools must be handled properly, etc. This may require extra work to setup correctly.

3. Generalize and implement adjustments to the allocations in #1. For example, ability scores grant bonus spells.

4. Implement the basic mechanics for consumption from the pool(s). This means choosing spells and having them draw from the pool(s) allocated above.

5. Integrate the basic mechanics into the other aspects of the data files. In the case of spells, there are some aspects that tie across to other parts of the data files. This stuff needs to be verified to be working correctly.

6. Provide a reasonable interface for selecting spells with the new mechanics. This might be easy, or it might be hard. The d20 data files provide a number of pre-defined mechanisms that can be re-used within the d20 files (e.g. the cleric/wizard "memorize" method, the sorcerer "spontaneous" method, the wizard spell book, etc.). If you roll your own, you'll need to model a new solution after what's currently provided within the d20 files.

7. Add validation to ensure that the user is prompted when selections are required and when invalid conditions arise.

All of the above is handled completely by the data files. Putting the logic into the data files is what allows Hero Lab to completely morph to each game system.

For a game system like M&M, wherein point-based purchases is a standard mechanic, the core M&M files will incorporate that and it should be able to be re-used pretty easily. In the case of d20, we're already planning on adding such mechanisms so that groups that utilize those mechanics as house rules can switch over to them pretty smoothly.

As for the GM piling on points, that's easy to do. For a game like M&M, the user will specify the starting number points for the hero on the Configure Hero form instead of the starting level. This form is entirely customizable for each game system, just like everything else within Hero Lab. The Journal tab will track Power Points instead of XP (again, fully customizable). And users will be able to add custom adjustments if they want via the same approach used in the In-Play tab.

I hope this helps to explain things better. If not, let me know and I'll try to clarify further....

[rob]

At 07:24 PM 3/20/2007, you wrote:
I'd like to do as little as possible through a programming language (the only such language I could ever wrap my brain around was 1978-era BASIC, which is an embarrassing thing to admit).
If you could handle BASIC, you'll be fine. The scripting language consists of simple assignments "x=x+2", "if/then/else" blocks, "for" loops, and "while" loops. That's it.

The only thing that requires a little bit of learning curve is the target transition syntax. Basically, it's the syntax for saying "get me the bonus for the Appraise skill". It may look confusing at first blush, but it's quite simple once you get the hang of it, which hopefully won't take more than a half-dozen times playing with it.

Theoretically the tools are in place now to do the basic setup of a completely new game system -- just not in an intuitive format. Just as I am seeing how it is possible to do all sorts of neat things to the d20 System template -- just not necessarily easy.
Hopefully, my previous post helps shed some light on this. Just about everything that has been asked for can be done to the d20 System files, without having to create a new system. However, it will require that we document HOW to do it. It will also likely require that we go back and add a few new things to the engine so that users can REPLACE core mechanisms with their own. Currently, core mechanisms are additive only, which will probably work for 90% of the serious stuff users will want to do. In case we have to tweak something to accommodate the other 10%, we have to get all that in place BEFORE we publish anything, lest we risk breaking user-added material. That's something we do NOT want to do.

[rob]

At 07:17 PM 3/22/2007, you wrote:
As far as I can tell - the ability to create that point system is not currently available in HeroLab - The data you'd need to modify to add all that in is in pre-compiled files - the ones that tell HeroLab how a D20 class or skill works in the first place.
Yes and no. That ability exists within Hero Lab. However, it has not been exposed to users. That ties back to my last post regarding the documentation that needs to be written and the refinement of the engine to allow wholesale replacement of mechanisms.

In terms of the scripts, imagine creating a new attribute solely for the points available. A script running on everything subtracts the appropriate amount of points for whatever it is from that attribute - at least that's how the same sort of thing could be achieved in Armybuilder.

It would take heavy programming, though.
Fortunately, it's not NEARLY as difficult to do in HL as it is in AB. That doesn't mean stuff is easy in HL, either. It all depends on what someone wants to accomplish, since the complexities will range widely. And if we can provide a few generic point-buy mechanisms that users can simply swap into place, then it's trivial for users instead of requiring some amount of work. :-)

[MPHopcroft]

Rob,

Thank you for taking the time to discuss this inquiry in this level of depth.

At 07:24 PM 3/20/2007, you wrote:
I'd like to do as little as possible through a programming language (the only such language I could ever wrap my brain around was 1978-era BASIC, which is an embarrassing thing to admit).
If you could handle BASIC, you'll be fine. The scripting language consists of simple assignments "x=x+2", "if/then/else" blocks, "for" loops, and "while" loops. That's it.

The only thing that requires a little bit of learning curve is the target transition syntax. Basically, it's the syntax for saying "get me the bonus for the Appraise skill". It may look confusing at first blush, but it's quite simple once you get the hang of it, which hopefully won't take more than a half-dozen times playing with it.

Theoretically the tools are in place now to do the basic setup of a completely new game system -- just not in an intuitive format. Just as I am seeing how it is possible to do all sorts of neat things to the d20 System template -- just not necessarily easy.
Hopefully, my previous post helps shed some light on this. Just about everything that has been asked for can be done to the d20 System files, without having to create a new system. However, it will require that we document HOW to do it. It will also likely require that we go back and add a few new things to the engine so that users can REPLACE core mechanisms with their own. Currently, core mechanisms are additive only, which will probably work for 90% of the serious stuff users will want to do. In case we have to tweak something to accommodate the other 10%, we have to get all that in place BEFORE we publish anything, lest we risk breaking user-added material. That's something we do NOT want to do.
It sound to me, then, as though EXPLAINING the features that already exist is going to be the most difficult part of putting together the Developer's Kit and making it truly system-neutral.

Let me use another example: the Anime20 SRD (the open-content version of GoO's point-buy d20 variants) places a point system to purchase "attributes" on top of the normal system of abilities, classes, feats and skills. Everything in the system has a point cost, including Ability Scores (although, because the books that used it were d20 license products, they couldn't quite state that you could simply use points to buy your Ability Scores in the first place). It was all set up in a way that was not particularly well thought-out, but does provide a mechanism for building everything from a pool of points that can be, with work, added to and extrapolated from the existing d20 dataset.

Adding the attributes themselves, which are for the most part abilities and powers that do not fall under any of the three current main categories, shouldn't be that difficult in theory once the syntax is learned.

[rob]

At 03:19 AM 3/30/2007, you wrote:
It sound to me, then, as though EXPLAINING the features that already exist is going to be the most difficult part of putting together the Developer's Kit and making it truly system-neutral.
That's one of the biggest challenges of creating a tool that is completely generic and that can morph to any game system. For example, the Authoring Kit documentation for our Army Builder is more than 350 pages in length and took MANY months of work to get it all written. With Hero Lab, we also have to describe everything associated with the UI and the layout of edit panels and character sheets. So Hero Lab involves even more material for us to document, although I'm happy to say that the underlying engine for managing Hero Lab data files is NOT as complex as for Army Builder. It's going to take us time to get it all done, and it's one of the key things we'll be focusing on relatively soon now. Like we did with Army Builder, the Authoring Kit documentation will be released in iterative evolutions, focusing on the most important (and generally useful) stuff first and then adding the more obscure stuff.

[MPHopcroft]

At 03:19 AM 3/30/2007, you wrote:

That's one of the biggest challenges of creating a tool that is completely generic and that can morph to any game system. For example, the Authoring Kit documentation for our Army Builder is more than 350 pages in length and took MANY months of work to get it all written.

Given that one of your rival chargen programs has a PDF manual that's almost 500 pages long and uses trermino.logy that onyl a professional programmer can fathom, this does not surprise me.

With Hero Lab, we also have to describe everything associated with the UI and the layout of edit panels and character sheets. So Hero Lab involves even more material for us to document, although I'm happy to say that the underlying engine for managing Hero Lab data files is NOT as complex as for Army Builder. It's going to take us time to get it all done, and it's one of the key things we'll be focusing on relatively soon now. Like we did with Army Builder, the Authoring Kit documentation will be released in iterative evolutions, focusing on the most important (and generally useful) stuff first and then adding the more obscure stuff.

Allow me to reiterate; ouch.

I am looking forward to seeing this, and only hoping I get to see it in manageable chunks.