Minecraft is different and very, very difficult. Let’s take a look at how Minecraft handles these kind of things, as I see it:
- Minecraft sessions usually last between weeks or months (rarely even years).
- Every time a major update is released, mods have to be updated.
- Some mods have been abandoned; no new version will be available or it will be taken over but at a later point. This mod is unavailable for the new version, for the time being.
- Some mods may have some kind of “purge”, where the modder decides that the “virtual incompatibility” between versions makes a good time to start anew; refactor systems, recode some parts. This delays new versions and breaks backwards-compatibility.
- Nowadays, there’s a few designated packs or combinations that are shipped together. In order to use the new version, all mods that you want to play with need to be updated to the new version.
- Minecraft itself may introduce breaking bugs into its game itself or the API.
- Mods may now corrupt worlds. There will be a time where everybody is figuring that out with test worlds; no “productive” playing is happening
- Something may have changed (because there is no stable API yet); making mods incompatible.
- Worst case: Something hasn’t changed, but a certain function is now behaving differently, introducing weird behaviour in a mod that goes unexplained for some time.
- Players are unlikely to upgrade their worlds
- because one or more mods have not been updated yet
- because there is no backwards compatibility in one or more mods, or Minecraft itself
- because the server admin/community decided against an update (to “play it safe”)
So even if Minecraft had weekly builds, the modding community likely wouldn’t switch unless there was a real value in an update - so basically, once in a blue moon. Because of this huge inertia, they can take their sweet time. By the time they release a new version, the modders may have caught up to the last one… So the community is always waiting on the modders, not the developers.
Players have little to no incentive to upgrade to a new version, either. Whatever they want is in the modded version, so whatever little feature the developers can offer for an upgrade will not outweigh the loss of all mods.
Stonehearth is, due to its nature, very different. It cannot offer you the modding capabilities that Minecraft does. But the community is - so far - very different, too. There are very little scripted mods, most of them can work with whatever components Radiant has supplied so far.
This is a clever move: Imagine you’ve created a game and sold it before it was done. You are expected to release updates frequently that add more and more “replay value” to your product. Now you can either try to create something amazingly new and unique with every update, exclusively, or you try something different: Tune down the expectations per update, but include little bricks that can be used by others to create their own content.
The “hiatus” between large updates is therefore bridged by the community itself. And this is great: It costs you very little to nothing, and they get what they want (because they create it themselves). You can continue to work on the core while others build a bit around it to extend the game.
This is different from “Here’s the game, here’s the API, now finish our game” that is sadly so often found in Kickstarter games. The most recent failure I’ve expected, for example, was this ecosystem simulation game where the developers seemingly had the idea to create one half of the game and the community would do the other half (and the best part, they would even pay for it). It’s taking a bit bizarre turns.
However, I would argue that this is not the case. Yes, they cannot deliver on promises made and that’s somewhat inexcusable (as in, it would be wrong to say “Oh, but no Kickstarter ever does”). They have parts where they really, really need to work on - and they do. However, these changes, as is often in sofware development, are not visible to end users, and this can be frustrating. You don’t really notice the modified pathfinding for example. You may notice that pathfinding is a lot faster, or that the game seems more fluid, but there’s no visible effect. It’s not a new class or mechanic or what not that brings you an additional three hour of play value; it’s just something that allows you to play longer/with more complex scenarios.
So the problem is that their construction sites (AI, pathfinding, memory - optimization in general) are invisible. It’s not recipe balancing or something else that would have a visible effect, so it’s fully understandable that whatever is changed there has no real long lasting impact.
About the rewriting: Rewriting code can be tiresome. Really tiresome. For me, as example, it’s usually like this: I code something and there’s new features added everywhere and sometimes you need to add something but think “eh, I’ll do it prettier later”, but later you have so many dependencies on that code that changes become impossible without a straight teardown and rewrite from ground up.
So you’re doing the same thing again, but using experiences from the last time - scenarios that didn’t even turn up when it was first made. For example, I’m sure they thought of having custom trees or what not, but they needed to get some sort of terrain going as soon as possible - so it was done in the most convenient way possible (which is often not maintainable nor optimized nor anything except convenient, really). You’re using these experiences, the problems that turned up during development and integrate them.
In this example, I wouldn’t have included rivers either. A rewrite is bad enough, making sure that everything afterwards works and looks the same is a big enough challenge. You want to keep changes between versions to a minimum, which might sound weird. Imagine they’ve added rivers and now suddenly, there’s holes in the landscapes (just straight down missing terrain all the way down). What’s going on? Is it the new terrain code? Is it the river? Is it something else?
So when rewriting, you’re usually aiming for “the same thing as before, but prettier”. Once you’ve got that, and it works fine, you can think of adding things. Because during the rewrite, you knew that this would be done soon after, so your rewrite, although it doesn’t contain it, has been built in a way to incorporate it easily enough.
In this case - and disclaimer, I know nothing about the actual new terrain stuff - I wouldn’t have included rivers, but maybe added some sort of functionality that allows to alter certain parts of the terrain after it was created. It could have been used for water straight away (lakes, as it is). So whenever I go back and add rivers, I could plug into whatever generates lakes and use it to generate rivers easily.
Of course, if you’re not rewriting properly, then yes, we’re doing exactly what you’re saying: We fix something by doing it again, only to notice that it wasn’t done good enough, so we start from scratch a third time. Third time’s a charm, eh?
(with that said, poor