PDA

View Full Version : Good practices when writing an extension



phantomwhale
July 12th, 2010, 19:05
Hi,

I wanted to start a thread on something I've not seen much of, perhaps as few people have written them in anger, but I was wondering what good practices there are for writing an extension to a ruleset.

To keep this less hypothetical, I have written some unofficial patches to the Savage Worlds ruleset. For these, in order to overwrite a LUA script, I had to not only copy the entire script into a new LUA file, modifying the part I wanted to modify, but also take the "windowclass" chunk of XML and copy it into the main extension XML file too.

This all felt a little overkill, not to mention I was often copying hundreds of lines of XML and LUA script, when all I wanted to do was change one LUA method. My concern came especially with regard to future updates of the underlying ruleset, which now seem very likely to break my extension, requiring me to manually locate the XML / LUA changes between the two ruleset versions and fold them into the hundreds of lines I had copy and pasted verbatum.

This concern compounds when you look at extending Savage Worlds for something like Deadlands, which would require Fate Chips and new card dealing functionality which would affect large chunks of the code. I could see this extension needed to copy and paste a large unnecessary chunk of the underlying ruleset just to add in the much smaller changes required for new functionality. This would seem very brittle indeed with any ruleset updates, one of which may potentially be in the pipeline for this year.

I am aware that some rulesets, such as Foen's BRP ruleset, have been designed with extension in mind. So perhaps the answer here is simply "you are doing the best practice with the ruleset you are extending at present". But it would be nice to have that confirmed ! Similarly, tips (or links to other threads I might have missed) from other people have gathered from extending ANY other ruleset would be of much interest.

Thanks,
Ben

Zeus
July 12th, 2010, 23:59
Ah a subject thats close to my heart.

I think your spot on. The key I believe is implementing rulesets with an abstraction layer for integrating extensions. Or in other words rulesets that are built with extensibility in mind and inherently supported by design.

I am very fortunate in that I primarily play and develop for the 4E ruleset, JPG has done a great job of exposing common methods for registering and integrating functionality without the need to override core functionality. Sure there are still times when I need to override but its a good example of how extensions can bet better supported if the ruleset designer incoporates this into the rulesets design and implementation.

An example of how this can be easily exploited can be seen in the 4E ruleset where JPG has made available an extensible roll handler capability that enables developers to extend the roll handling of 4E without ever having to override the core functionality. The benefit is that as long as the exposed methods are not changed (if they are it will be infrequently), extensions can continue to operate without the need to necessarily update them.

I have used these methods quite a lot in my extensions in an effort to cut down on maintenance updates in between 4E updates.

It would be nice to think that over time that ruleset development will mature to the degree that we will start to see more and more standardisation in the underlying core functionality across all rulesets as a common primer. I believe the Base ruleset was established to do this however i am not sure how well updated it is or whether it is still being maintained.