SavageWorlds4 -- is it going to ever happen?

[Ikael]

I have been slightly reviewing CoreRPG, new layering development approach and I must say I am impressed. I like the concept but it makes all existing rulesets, like SavageWorlds3 look so "deprecated". Wonder if SavageWorlds4 is every coming out, and here I do not refere just version/feature update, but that SavageWorlds ruleset would be re-build on top of CoreRPG. What I can now say is that complete re-build is required, no slacking around, and that's what concerns me if it will ever happen.

There are several advantages using layering approach, if done correctly:
- Most of the common codes can be left away from ruleset since only ruleset specific features needs to be implements
- If CoreRPG graphics and frames are respected, then look-and-feel made to other ruleset will be 80% compatible with any other ruleset using the same approach.
- Following neat new features is easier since the base codebase is shared. If totally new feature is introduced it will be in use out-of-the-box, but might require small amount of changes to make it ruleset/system specific.
- and more if you think

The situation was almost the same as when the old d20 ruleset was used as base for all an every new ruleset. They shared the same codebase and graphics done for some other d20 based ruleset was almost 100% compatible with your ruleset (I encountered this gem when developing Unicore ruleset with 11+ different look-and-feel thanks to other d20 ruleset theme designers). The situation is enhanced version of what it was back then. The question that only needs answer is: Is it sane/beneficial to try use all potention it offers?

After seeing my SW Enhancement extension getting whacked to fragments, I feel kinda down, but I know that it can and will happen in the future again if CoreRPG approach is respected. Of course your stuff will get broken, but at least you can make easier diff to check what was changed, and if most of the community uses the CoreRPG approach, many share the same codebase knowledge and it's no longer just one or two people who know how to fix issues.

My main point is to ask how people feel the future of SavageWorlds ruleset? This might be more developer based discussion, but would you see daylight for SavageWorlds4 ruleset? Would you be willing to do it? -- Should it be done?

I can think few approach issues:

• To get most benefits it should respect CoreRPG ruleset's defined graphics -- which means that (at least) frame graphics created for Savage Worlds will get broken.
• Databasenodes should also respect CoreRPG as much as possible -- This would break module compatibility, but it can be fixed.
• Respect CoreRPG templates and structure -- This would mean that re-building process is harder

What benefits could SavageWorlds4 offer:

• Lots of generic codes can be left away since it's provided by CoreRPG: Tokens, Notes, Items, Images, Story, Light mood selection, Color selection, Char portrait picture selection, Preferences (but different options needs to be registered), Modifiers, Effects, Library, Dice tower etc.
• Some codes become simpler because of base is almost the same in CoreRPG. For instance Combat Encounters, Character Selection, Desktop Portraits, etc.
• What needs to be done from the scratch: Character Sheet, NPC Sheet, Vehicle Sheet, Combat Tracker, Client Tracker, Tools, etc.
• Lots of new features provided by CoreRPG: Calendar, Rollable tables, Party Sheet, Item parcels etc.
• Laterwards, catching up with new features is easier

What do you think? Should this be done? This is defenitely not one man's project. It would requires some serious work effort, and it should be side-project next to SavageWorlds3.

Personally I would be interested in doing this project, but I would need help.

[VenomousFiligree]

I'm by no means a coder, but would be willing to help where possible, ie this "Databasenodes should also respect CoreRPG as much as possible -- This would break module compatibility, but it can be fixed" sounds like it might be easy but time consuming.

I would also be willing to provide feedback on the development ruleset.

[Sunspoticus]

I'm putting my name in the hat both here and in an email I'm going to send off to SmiteWorks. I'm willing to slice off some time to help get not only SW updated but some of the other rulesets as well.

So you need help, just ask. (software engineer 30yrs xp)

[damned]

core makes sense on every level - except the initial massive task of building the first core version.

[Moon Wizard]

Tell me about it. I did it for 5 rulesets already, and 2 more in development.

JPG

[phantomwhale]

Interested in what you meant about database nodes being broken in old modules by such an update; a recent effort towards changing some database node names in SavageWorlds was met with some resistance due to inherent lack of backwards compatibility. Are we saying a CoreRPG compatible version would require backwards incompatible database node schema changes?

SavageWorlds on top of CORERPG does indeed make sense going forward from an ongoing maintenance point of view. If may lead to a lot of work on commercial extensions too, to keep them compatible with the new version.

[damned]

Tell me about it. I did it for 5 rulesets already, and 2 more in development.

JPG

and every one of them is much appreciated.

[Ikael]

Interested in what you meant about database nodes being broken in old modules by such an update; a recent effort towards changing some database node names in SavageWorlds was met with some resistance due to inherent lack of backwards compatibility. Are we saying a CoreRPG compatible version would require backwards incompatible database node schema changes?

SavageWorlds on top of CORERPG does indeed make sense going forward from an ongoing maintenance point of view. If may lead to a lot of work on commercial extensions too, to keep them compatible with the new version.

I haven't made 100% review of changes but some that caught my eye was minor differences in how database node names were defined in for example stories, items, etc. I don't recall which one it was, but small difference like: is story formatted text field called 'description' or 'text' makes big difference. I know one approach is to continue using old naming conventions, but if code base of stories would be otherwise good in CoreRPG, why not change convention because thereafter you don't need to override anything regarding stories in SW4. Of course if database node naming convention is changed then some modules might become incompatible.

Personally in SW4 I would break compatibility if it would grant less own/ruleset code to maintain. In case of many common shared features like: stories, items, notes, images, etc there is really no need to have own code base, not even if there is small naming differences, just start respect CoreRPG way and deal with incompatibility check and fix it once.

[damned]

minor differences in how database node names were defined in for example stories, items, etc. I don't recall which one it was, but small difference like: is story formatted text field called 'description' or 'text' makes big difference.

If the majority of changes were of this nature couldnt that be scripted with a find/replace - or even done manually with a list of terms to do the find/replace with?

[Ikael]

If the majority of changes were of this nature couldnt that be scripted with a find/replace - or even done manually with a list of terms to do the find/replace with?

Indeed, these small changes can be done with easy find/replace, or xslt etc. But like said, I don't know 100% how much things are different, but I expect not much