Azulaloi
commented
4 years ago I've thought some more, and there are a few points I'd like to write down. I'll be using the term core to refer to a mod intended for use by specific mods, and library for a mod intended to be used as a resource.
What I see brought up most often is that an additional download is burdensome on the user. I think this is negligible. For one, the workshop will prompt you about dependencies, and installation is extremely simple. Second, the user can bear to click an extra couple buttons.
What I foresee as the main issue with a core mod is something I'll call retro-development. I'm sure this is a known antipattern or whatever with a catchier name. Example: I have released a mod aleph that uses my core, and I have moved on to a new mod bet that also uses this core. If bet requires a change or addition to features of the core, I must now also bear in mind the way that aleph used those features. This limits what I can change in core without needing to change aleph as well. This retro-dev overhead would increase with the amount of mods that are built upon it, acting like ball-and-chains upon my ability to develop new mods.
With most software, this is not as pronounced an issue, because you can pair a release with a version of its core. But the workshop will auto-update mods, so retro-dev would be necessary to avoid breaking old mods. Not only will it update, but it will do so silently.
Regarding libraries, mods intended to be built upon by others: library mods that are independently distributed are totally infeasible for Starbound. In libraries, the retro-development problem is magnified and exacerbated. Now, you don't know what is being used and in what way, or what changes will break other mods. You also have a far greater responsibility to not break old mods, because it would break the games of everyone using all of those mods, and attract ire towards the developers that trust you to build a functional library. I could go on about potential nightmare scenarios, but you (I) already get the gist.
So... what should I do?
Proposal: First, extract all coremod features from ExRaEq and put them into a separate mod, working name AzCore. AzC will serve as a new dev repo for mod-independent (independent is the wrong word, I forgot the word I want and it's driving me crazy) systems, as I have been using ExRaEq for. AzC will be structured in such a way as to have a placeholder prefix that I can replace later. Then, when EA:H or another mod (gimel) is ready for release, the current version of AzC will be integrated into it with a mod-specific prefix, and packaged with it. I can then continue to develop AzC and build new mods upon it.
There are some downsides to this approach. For one, I may encounter issues with using a prefix to prevent conflicts. Primarily, though, is a different kind of retro-development. If I continue developing gimel after divergence, any changes to AzC-Integrated will diverge from AzC-Master. I can either choose what changes to mirror in AzC-M, or I can rigidly ensure that all changes I make to AzC-I are mirrored in AzC-M, to prevent confusion.
While this plan has drawbacks, I believe it is the best methodology available within the present constraints. I will need to take care to ensure that I do not entangle myself. I should also draw up some best practices and guidelines for this approach. For example, it will be important to have as close to feature-completion for AzC-EA:H before integration. AzC should also be designed for flexibility, with support for features that I don't currently need but may be desired. This is already how I work, I love to build systems that could be used to suit various needs. However, due to the overhead of changes to AzC-I, support for potential future applications within a mod - like post-release content or enhancement updates - is even more important.
Things that I'm using for exotic armory should be separated from ExRaEq. I've got enough stuff implemented and planned that it's worth making a - god forbid - core mod.