PDA

View Full Version : BRP/CoC compatibility



Sorcerer
October 4th, 2010, 20:38
Theoretically CoC is a BRP system

and thanks to the IMPORT command in the Eldritch Horror extension

it should be possible to load CoC modules within BRP.

In fact all CoC modules are recognized, but only reference modules are
fully accessible.

The problem is that with Adventure modules, CoC records story elements in the db.xml under the tag <encounter>. Whilst in BRP they are recorded as <story> - <encounter> being reserved for ... combat encounters.

BRP tries its best to load the CoC 'encounters' but as its expecting stats and not text it does not succeed..

Obviously I could just rename <encounter> to <story> in the db.xml, but this is more of a work around than an elegant solution.
The question is, is there anything I can add to the extension to make BRP read <encounter> as <story> or is this beyond the realms of possibility?

StuartW
October 5th, 2010, 06:37
Good spot, I hadn't realised this until now. It's a shame I didn't realise this while I was developing BRP, otherwise I'd have chosen a different tag (I tried very hard to retain compatibility, such as bringing in a backwards-compatible feature to load BRP powers from the CoC spells tags).

Not sure what can be done now through, the adventure_story.xml and adventure_encounter.xml files could be replaced in the extension, but that would allow folks to run a new CoC campaign using BRP, but not use CoC material in an existing BRP campaign (which will already have saved story and encounter entries in its db.xml).

Stuart

Sorcerer
October 5th, 2010, 15:52
Yeah I didn't think it would be a straight forward fix.

I probably will just use the work around on individual adventure modules
as and when I want to port them into BRP ruleset.

As a follow-up (Since I have the developer on the line so to speak).

how do you see the long term future of these 2 product lines?
Do you think that in the long run a full extension for CoC will be developed
for BRP and the CoC ruleset allowed to wither on the vine?
Or are there some things that just can't be done in an extension that would
warrant keeping 2 distinct (if similar) rulesets?

the CoC ruleset is somewhat older than your BRP set so I guess if it were revamped it would look alot like the BRP set, in terms of functionality...

StuartW
October 5th, 2010, 21:58
I'm sorry I can't help with strategic direction, as I'm really somewhat retired from building rulesets, although I remain passionate about supporting the ones I've helped develop.

It would make sense to have a CoC v2 (like there was a new Savage Worlds ruleset a little while back) which addresses some of the points you raise, provided the community wants to support it (verbally and in terms of sales).

As regards ruleset architecture, BRP was a bit of a step in the dark. Prior to that each variant of a core mechanic (each different d20 ruleset, each different Savage Worlds plot point) was released as a separate product. With BRP we not only released a ruleset with customisation built in, we also released a manual to show folks how to do that customisation. I guess only time will tell which is a better approach.

Stuart

VenomousFiligree
October 5th, 2010, 23:15
It would make sense to have a CoC v2 (like there was a new Savage Worlds ruleset a little while back) which addresses some of the points you raise, provided the community wants to support it (verbally and in terms of sales).

Non of the Savage Worlds version updates required payment for the update as far as I'm aware.

I would love to see CoC modules for BRP and would be willing to help contribute to this (free upgrades for CoC owners to BRP functionality).

Zeus
October 6th, 2010, 09:59
I hit a similar problem during the development of the 4E Partysheet extension. In a later release, some of the XML tags I had originally used needed changing.

For new campaigns this wouldn't be a problem however for existing campaigns I had to write a check and update routine during the extensions initialisation. The routine simply checked the version of the extension and then for the existence of the XML nodes, effectively copying their child nodes to a new tree, if required.

Its doable but requires a short amount additional coding in the ruleset/extension onInit() routines.