Are the devs open to external programmers contributing to feature development

[ronnke]

Would the devs be open to external programmers contributing to the feature development of the core Fantasy Grounds software? Like a restricted open source. Obviously, the appropriate NDA's and contracts would be signed and all rights would remain with SmiteWorks.

I'm pretty sure there are several programmers in our community that would love to offer their time to feature development. There is a big todo/wishlist and more coders would certainly help get those features out the door.

[Moon Wizard]

We are definitely open to development, but we typically ask that developers work with us on the ruleset code and utilities, which are easy to manage separately and integrate.

Please drop me an email at [email protected] to talk further.

Regards,
JPG

[phantomwhale]

My personal view, supported in part by other key user/developers of FGII, is that a move towards the community maintaining / improving / enhancing an open-source base ruleset would lift the pressure from Smiteworks to produce these improvements themselves, and concentrate more on enriching the core FGII engine API.

The current effort which best takes us towards that model is probably the foundations-core ruleset, which captures all the great core ruleset work that moon_wizard has done, adds some of Joshua's changes and strips it down to be RPG system agnostic.

If this can get more love, in terms of core development, as well as extensions / forks that build upon it to produce fully functional system-specific rulesets, I think we'll be well on our way.

Lots more info, discussion, and the all important GitHub details over here : https://www.fantasygrounds.com/forum...ad.php?t=15866

[Moon Wizard]

Since I've actually been developing on FG long enough to remember the previous Foundation ruleset, I have concerns about handing over the ruleset development reins.

The original developers came to depend on the previous foundation ruleset. Then, when the community devs on the foundation got pulled away to other things, the ruleset that FG depended on was left hanging. The original developers were not very familiar with the previous foundation ruleset, and had no ownership for addinf more commercial rulesets.

Also, I found that the previous foundation ruleset lacked a general sense of direction once Joshuha had to step away for other life concerns. A ruleset really needs a "product manager" to make sure that it has a vision and direction, plus they can sift through all the requests to find the ones that help the most people.

I have a feeling that we will end up sharing code between the release and foundation rulesets, and I welcome the interaction. However, the primary difference is that the SmiteWorks code in the rulesets that are provided today are not open licensed. The code and graphics remain the property of SmiteWorks. It's one of the protections we have in place to keep the company going. I deliberately built the most recent 3.5E (previous d20_JPG) and 4E rulesets from the old d20 ruleset before the original ruleset moved to an open license (which was the first foundation ruleset).

If anyone wants to contribute to the existing rulesets, I am more than happy to integrate any additions and/or extensions. However, we need permission from the developers to include, since the code will become SmiteWorks code at that point. For example, DrZ has allowed me to integrate any of his 4E extensions. It actually ends up saving him work, since he no longer needs to maintain them.

If anyone is interested in working directly with me on any specific projects, please send me a private message or email.

Sometimes, it's enough just to talk to people building the ruleset code, so that I can improve the underlying engine for everyone. The feature creep on v2.9 has a direct relation to that, since I had to add a fair bit of API functionality to add the improvements I wanted for the next version. It's one of the reasons that I try to stay active on the forums.

Cheers,
JPG

[Valarian]

The original developers came to depend on the previous foundation ruleset. Then, when the community devs on the foundation got pulled away to other things, the ruleset that FG depended on was left hanging. The original developers were not very familiar with the previous foundation ruleset, and had no ownership for addinf more commercial rulesets.

Also, I found that the previous foundation ruleset lacked a general sense of direction once Joshuha had to step away for other life concerns. A ruleset really needs a "product manager" to make sure that it has a vision and direction, plus they can sift through all the requests to find the ones that help the most people.

I disagree with this assessment of the previous foundation ruleset. The previous ruleset was launched and maintained by Smiteworks (previous owners), with the stated intent that it would be a base for ruleset development. The problem was that it was never supported by the original developers and had issues, especially around the combat tracker. It was the community devs that kept that ruleset going, far beyond when the original devs had abandoned it.

Link to original announcement:
https://www.fantasygrounds.com/forum...ead.php?t=9000

This ruleset was then replaced by Foen's Base ruleset, which provided more functionality and worked. This has, in turn, been replaced by Joshuha's new Foundation Core.

I strongly believe that ruleset development needs to have a strong Core ruleset, that is fully supported by Smiteworks as a base for ruleset development. This, then, gives ruleset developers a strong starting point for extending and branching for other rulesets. It will speed development, and make maintaining functionality improvements across rulesets a lot easier with a single, common, core ruleset.

[joshuha]

Right the idea of a common community maintained ruleset is to try and lessen pressure on people trying to patch up older rulesets with newer features. If we can successfully divorce what should be CORE FG features from game specific features it makes that much easier. How much time has been spent re-writing Savage Worlds to support newer features, how much demand do I see to add in this or that feature that is in 4E to other rulesets that people bought but are now feeling a little "antiquated"? Like many here, FG is a hobby for me so I won't always be around 100% but moving to Github I have started adding in multiple people that have permission to do merges so I think we are moving in a direction that even if one of us is on extended leave the work can continue.

The question then becomes is if people are willing to write commercial rulesets based off of Foundations Core to maintain that reusablity. Even if not an extension to Foundations Core, if the files are separated well enough you could still design commercial rulesets that would be easy enough to update once bug fixes/new features were added into Foundations Core. I currently have a commercial project I am working on, it has been slow going but it is still being worked on in bits and pieces and hope to have something more to announce in a few weeks.

[Moon Wizard]

Valarian,

Fair points. I was writing about my perception of what happened in the previous post, and did not research the history. By the time I joined, it was more work to save than to move forward with what I had built on my own.

Joshuha,

I agree that it would be better to have rulesets that could "reuse" components easier to allow a set of "common" components to be shared and updated across multiple rulesets.

Given that, I was thinking that it might be a good idea to make a break with v3.0 to change up how rulesets are built. In the last few updates and the upcoming release, I have been working on modularizing the existing D&D rulesets to allow easier portability of features, as well as adding common components and common features into the client directly. The biggest challenge in this approach (and any approach) is that the layout (graphics and text) of every ruleset needs to be highly customizable to support what developers want to do. This makes developing common components much more labor intensive than developing components for a specific ruleset or single person managed rulesets.

Given a blank slate, how would you propose to have the ability to allow rulesets to use common components. These are just ideas that have been bouncing around in my head, and are not necessarily mutually exclusive.

* Continue current process of slowly modularizing ruleset code and integrating common features into client? (low design time, driven by ruleset updates)
* Add another layer for ruleset code (FG common components/graphics, then ruleset, then extensions)? Maybe the common layer is the "foundation"? (requires extensive development and design time)
* Add template/class merging feature for easier extension creation
* Other ideas?

Of course, my primary goal for v3 is going to be map improvements. However, I've realized more and more the need for better ruleset and module management to allow easier community development.

Regards,
JPG

[Sigurd]

Doesn't the openness of the XML make some of this argument silly?

I think if Smiteworks makes the best damn rulesets they can, clearly and with good documentation other developers should be able to run with that. Right now there is no other platform for these modifications so contributing them back make sense.

As long as Smiteworks is ok with this sort of development model would an 'open source' ruleset achieve anything different?

You can always have better documentation, a better library, or cleaner code but I think the community maintaining a ruleset for the sake of it being open source is serious duplication.

What advantages did the old foundation code give Joshua or Foen?

[unerwünscht]

I think it has less to do with what it can do for the people maintaining the open source ruleset and more to do with what it can do for Smite Works, and 3rd part ruleset devs.

The first thing that opens up is that moon can spend less time working on rulesets and more time working on the base program itself and adding new features to the application.

While at the same time 3rd party developers would no longer need to waist time with punching out code that already exists, or stripping code out of another ruleset to get it down to a usable starting point.

Need to make a ruleset? Awesome here is the community core, now make a character sheet, add in some automation, design your skin and you are good to go.

[joshuha]

Doesn't the openness of the XML make some of this argument silly?

I think if Smiteworks makes the best damn rulesets they can, clearly and with good documentation other developers should be able to run with that. Right now there is no other platform for these modifications so contributing them back make sense.

As long as Smiteworks is ok with this sort of development model would an 'open source' ruleset achieve anything different?

You can always have better documentation, a better library, or cleaner code but I think the community maintaining a ruleset for the sake of it being open source is serious duplication.

What advantages did the old foundation code give Joshua or Foen?

The old and new gave the advantage of quickly creating new rulesets without having to hack out the bits from an old one that you didn't need. Being able to write extensions that extend a base ruleset is much easier than hacking away functions, image references, character sheets, etc. from a ruleset but still trying to figure out the things you want to keep (and sometimes its all intertwined). And then when Smiteworks added features/bug fixes JUST into the 4E ruleset having to repeat that work to extract just the needed improvements is a chore.