Hello all who have been following (and a big thank you to the 5 who were willing to vote in the last poll, that was meaningful to me), it's time again to poll your opinions.
I've been perusing the blueprints.xml document from base Faster than Light and reviewing the augments. The xml entries for augmentations provide very little information, namely because augmentations can have a nearly infinite range of effects and defining their effects via xml is downright impossible.
I did some quick thinking about this and did some research into advanced programming techniques. What I discovered is that there *may* be options available that will give modders capable of Java the ability to code their own augments and inject them into Overdrive. Emphasis on *may*, as what I'm imagining may not be possible. 9/10 times when treading into unknown territory there will be complications that cut your progress dead in its tracks.
At the bottom of this post is a poll. First, read the post to let me describe the paths development can take when it comes to this stage of the project and the consequences each choice will have.
1. Hardcoded. This is vanilla Faster than Light style. All the augmentation behavior is defined in the code. The flavor data is defined in the .xml file. To add more augments, modders would have to reach out and work with the developers to turn modder ideas into game reality. The upside is that this is the easiest system for me (us, if I get volunteers) to implement. The downside is that adding additional augmentations is constrained by developer approval and free time, and the externality that there
will be a developer overseeing Overdrive in the future.
2. Softcoded. This is the potential system that will allow modders capable of Java to have an API to implement their own unique augmentations. What I imagine will have to happen is that I implement some open ended code that runs a top-level polymorphic (for those non-coding types, a rectangle can turn into a square, or a rhombus, get the analogy?) object and activates its methods on certain triggers. The caveat is that Java has to
explicitly include packages and jar files (from what I know, I'll ask if there's a way to implement dynamic inclusion and importation). As long as this restriction exists, I or someone else may have to code a packager that packs all your augmentation mods into a single jar that gets included and run with Overdrive. The upsides are wondrous; if you have the ability, you can make it happen, essentially. The downside is comparatively massive; it's a complicated, open-ended system that I/we have to look for every possible trigger/effect point, include it into the API, and make sure it doesn't break. Essentially, even after all the work is done, we'll be performing constant tech support, adding new features and making sure earlier features don't break from the strain. Since we have to implement such a complicated system and test it before release, it will most likely delay release.
3. Hardcoded release, transition to Softcoded via updates. This option gives you the benefits of both; you get Overdrive sooner, and the ability to make your own augments later. The downside is it multiplies the work for us as we have to implement two systems.
https://www.strawpoll.me/12825071
This time, if you're following this thread, I highly encourage you to vote, as this is one of the critical points of opinion that will affect Overdrive's development and outcome.