I feel entitled to call myself somewhat of a veteran when it comes to Stonehearth modding, even if I haven’t done anything for the last two to three years, so I’ll chime in my two cents to this topic.
So while I could probably write the whole way from being excited to mess around with as many bits as possible to becoming a grumpy lurker that occasionally drops into some conversations, I think we’ll skip over most of that. For me, when Stonehearth was accessible for backers (as r4 I think, or even earlier?), it was fun to play around with. 30MB stonehearth.smod, very few services, very little AI, most of the systems were easy to read and play around.
Of course, back then, there weren’t overrides. Or mixintos. Or as many data JSONs as there are today. Or even mod loading, but let’s not dig too deep into trying to compare the first release with the almost-Beta. The point is: Things were much simpler, because it was much smaller.
The complexity in Stonehearth grew with its team size, quite exponentially. Although I’ve been messing around with the game quite actively at that point, at some point I was kicked out of the loop. I couldn’t invest enough time to keep up with development. There were also all the weird side effects that happened, that couldn’t be really explained as user, and that would have required developer intervention to identify/fix. That happened sometimes, but sadly not always, and of course we always remember the bad things more easily than the good ones. At some point, I was a bit fed up with modding Stonehearth, because the time investment of mine didn’t justify the results. I usually aim for the stars and I get really grumpy if I can’t reach them, especially if I decide to resolve to dirty/hacky solutions to get there.
At some point, @Froggy coerced me to do stuff with him. So I did. The result was Zulser, a working (but from my point of view disappointing) train that ought to be part of a bigger, now-burried mod pack I suppose, and Frostfeast '15 and Frostfeast '16.
But I think Frostfeast '15 was what did the final nail in the coffin. Although people keep saying it’s amazing and nice and what not, I was disappointed. Compared to the ideas that we had talked about, the amazing sketches we’ve drawn in our head, and what we effectively delivered… It was a huge difference for me. It wasn’t necessarily due to a lack of time from our side; a big part was just tooling and APIs. There were things that were just not working, although they did in the reference that we had (which was stonehearth.smod/radiant.smod), and all because at some point we’ve missed a mixinto into some other JSON that another service required so it would load that thing and make everything work.
I’ve realized that Stonehearth had gotten out of its baby phase and into its teenage phase. And that’s fine, I would be a hypocrite if I complained about this. After all, I’ve said more often than not that modders that are doing stuff at this stage are living on the bleeding edge, where chances are common and can really screw you over for good. The problem is, Stonehearth doesn’t feel like a bleeding edge of a knife or even a machete, it feels like a running chainsaw.
So things were changing and there was little/no explanation to it. That’s okay, it’s still an Alpha (and not even Early Access, or barely EA). It’s still a bit frustrating, a bitter pill to swallow, but understandable. It just meant that it wasn’t interesting for me anymore at that time.
FF '16 rolled around and the upgrade process was absolutely hideous. We’ve not touched it in a year, so all the new mechanics (e.g. the official hats that were adopted) didn’t help at all. Again, lots of time was wasted and the product was sub-par again. We’ve managed to squeeze in some things from last year, but over all, the campaign should have been much more, in my eyes.
I’ve watched the stream where they’ve fixed up FF '17, and I was quite furious at times and very thankful that I had other things to do this year. At some point I believe they were trying to figure out why something didn’t work, and at some point one of them went like “oh, didn’t we add some security thing because of the multiplayer? That’s why it doesn’t work!”. This kind of thing is just an absolute deal breaker for me: Without any error message, or any reason whatsoever, something just doesn’t work because of things that happened beyond-the-lua (i.e. engine-side). You can’t maintain a mod like that.
So, after babbling for a while, let me explain why I’m writing it like that. The argument “It can be modded in” was told multiple times here, and technically this is an absolute correct statement. It’s as correct as “You can write DOOM in Stonehearth” though - everything is possible if you have a turing-complete language at your hand. It’s possible to write other games with SH’s engine, but to what capabilities is the other question.
Many of the things here that were posted are, I suppose, doable with mods. I could imagine even a way or two to do some of these, but that doesn’t mean that they can effectively be done in a satisfying matter. In the end, the engine - and the performance - are the ultimate restriction for this kind of thing. Let’s pick an example: Could we have dynamic snow, where tiles get slowly snowy over time? I don’t particularly see why not, with enough effort. Could we have footprints, too? Sure, to some extent. Would that whole thing still work with reasonable FPS? I somewhat doubt it.
Mods can only be as good as the API and the available tools are, and here is an issue where Radiant/Riot is threading on incredibly thin ice. If they decide to out-source (i.e. put it into the C++ side) more components or services, they gain (a huge) performance boost - however, that means that modding becomes “impossible” (we’ll not argue about how overrides/monkey patching are actual “possibilities” for now…). It means another system fixed in place.
In current-day Stonehearth, you can override pretty much anything with the right amount of effort, or worst case, patching the .smod. That’s something to be admired, and quite a rarity indeed. It comes with the drawbacks of the chosen technologies though.
Something that saddened me a bit, or rather made me a bit unhappy was the focus on the whole data-driven experience of Stonehearth. The idea to have data (JSONs) to drive the whole game is quite cool in terms of that it allows you to have a lot of content very easily created, at the cost of that all that content is rather boring because it’s the same. A chair’s a chair, it may look fancy and may glow in the dark, but it cannot (for example) spawn hearthling-eating, fire-spewing Hellsheep from the 58th circle of the underworld. For that, you’d need code/components again. This is still technical possible of course (as seen in Frostfeast/some of the stupid mods I’ve made), but requires a solid API and more importantly, a solid documentation.
So if there’s a “modding guide”, in order to find it interesting, I would expect a documentation of the internal systems/services/functions/workings (e.g. how does the GUI talk to the backend, what are the limitations), maybe with some samples (or references, i.e. “as seen in WaterObserver”). I’ve modded a game before where this was a really, rock-solid API and documentation. The game also used a similar approach to modding as Stonehearth (content-wise; it was all just .zips so you could look at other user’s stuff and learn from it). Currently, I’m somewhat afraid that a “modding guide” would only really cover the easy bits (“Create a new chair for your home! So cool!”).
So here’s where I get grumpy. If SH has strived off the path of its original “kingdom builder” approach, then that’s fine I suppose (or at the very least, not surprising to me). However, you can either have a “cutsey 3D builder” with a community that’s targeted towards that (i.e. guides/tutorials/support), or you can have people that actually write features that are missing/very much changing the system itself. Of course you can cater both, but so far I’ve seen far more on the easy-obtainable stuff than the pushing-the-borders stuff.
If the community ought to “jump in” and add features that it likes (and there’s nothing against that, really), there ought to be proper developer support and engagement to enable them to do just that. The current modding guide is a good step forward, but it’s barely scratching the surface of the tip of the iceberg that handles all the real logic.
You can’t make new features with JSON alone. It’s a nice floofy pelt around it, but the basics will still be lua and some JS/HTML - and without an explanation of those systems, I find it hard to imagine many people picking up this kind of modding. Especially if you’re going for the artsy-builder approach - “I’ve made a mod that adds space exploration, including space ships, off-world colonies, and oxygen to a game where you basically can build fancy buildings” just sounds a bit off to me.
So, that’s my concerns. For modders to effectively work on expanding the game into unknown directories, it’ll be required to have a proper documentation of some sorts, and ideally some more APIs/opening up the engine a bit, even if the business case for it can’t be seen yet. Otherwise, I don’t really see others bothering with this game to the extent that it could be.
Because at the end of the day, after the performance issues, and the not-quite-as-originally-proposedf features, and after the wonky API, and after the missing documentation, and the limited engine options, there’s still a lot of untapped potential in this project. It would be a shame if it were to be gone to waste.