I don't really agree with you about what many of the problems with minecraft are, how software should even be structured in general, or why people play video games at all. so, I don't think that we could agree on a direction or a design for such a thing, if I were to help.
I also aim to create a minecraftlike, and my design goals are for it to be very extensible and implement the mechanics I would like to see in a minecraftlike, as well as world generation that begets interesting and strange environments. I haven't, however, made very much progress at all on my own project, so regardless of the direction of your project, I probably wouldn't be of much help anyway.
my project doesn't aim to replace minecraft. I don't really think that goal makes sense, and I don't think such a goal would result in an actually good game. if you make a new game, it's a new game. a game which is different does not replace minecraft by definition. this is why people play different versions of minecraft. sometimes I want to play minecraft 1.8. sometimes I want to play the latest version of minecraft, or with mods, etc. sometimes I want to play minetest. you don't seem to comprehend that people want to play different kinds of games at different times, as when I pointed this out to you before, you called it "addiction to novelty".
it would be a different story if the goal was to attempt to reimplement minecraft as an open source piece of software, which would be venerable. there is already a project to do this, called mineclone, which is made in minetest. however, there are many deficiencies yet that prevent it from acting as a complete replacement for minecraft.
official documentation takes effort to produce and is thus often not provided. wikis are an effective way to collaboratively produce content and can be quite high quality if done right.
I feel like there isn't anything hard to understand about the fact that different people want different sets of features at different times and in different contexts, so they make this easy to achieve. it seems like you're just refusing to understand this.
I don't really want to take the time to read this right at this moment, but I don't have any problem with forking. I also don't have any problem with people being "overwhelmed with choice".
"being overwhelmed with choice" is hardly ever a real problem. what would be actually overwhelming is many, many competing forks, as the codebase fails to accommodate the flexibility that people desire from the game. of course, some people would probably eventually fork it and add an actual API, as this is the sensible thing to do.
you are failing to understand that the very specific (and to be honest odd) way that you like to play video games is not the way that other people do necessarily. this is quite evident. you are wondering why people do things a certain way, but refusing to actually accept the answer. you seem to think that a game must be composed entirely of things that are meticulously and perfectly designed to interact with each other, that if it isn't perfect, it isn't worth playing. that's not really how many people enjoy video games.
you're also taking quite a pessimistic point of view of mods' ability to work together. it is incredibly realistic for two mods that are not written with each other in mind to work quite well with each other, especially if there are robust APIs that facilitate their interaction.
it is a fun and genuinely great thing to be able to arbitrarily combine mods and sets of features. in modded games (well, mostly just minecraft), I find myself changing the mods around between play sessions to create new gameplay situations and interactions. and it's just a useful pattern in general! modularity is not at all unique to games. monolithicity generally produces inflexible software.
this is especially the case in sandbox games, wherein it is often quite fun to have tons of random cool content, irrespective of if the individual components are necessarily designed to work with each other.
So what's to stop the forks from collaborating so as to separate some of that duplicate code into a separate library that both the forks use?
you're basically describing a modding API/the game being factored out into an engine.
What benefit is there to playing with two different mods if they don't work well with each other?
mods don't have to be explicitly programmed to work together to so from a gameplay perspective, especially if they pertain to unrelated parts of the game. even if they don't entirely work with each other from a gameplay perspective, it can still be very fun to play. I have had lots of fun with mods that destroy the balance/progression of games. just because something is not perfect does not mean it's not worth playing.
the point is quite clear. running multiple incompatible versions of the same program is quite a miserable experience. having your favorite mods not interoperate is an unfortunate experience. as for submitting patches to the main game, this is not applicable for certain mods. many of my favorite video game mods definitely would not ever belong in the main game.
you could ask the very same question for proprietary games. in the case of minecraft, there was once a time when things like forge did not exist, so to make mods, people decompiled the game, made the modifications they wanted to make, and published the modified classes. to play the mods, people could just extract the classes into their minecraft jar. however, much like multiple incompatible forks of the same software, this does not provide good interoperability or a good user experience, so mod loaders and APIs were developed to provide this.
hello. there are reasons that johnvertising uses an iframe— for instance, scorecounting and general ominousness via the nonspecificity of the set of all johnvertisements. additionally, additions and even alterations to existing johnvertisements occur frequently.
I enjoy your presence, and I'm not sure why you're leaving. taking a break from things can be healthy, but it doesn't seem like you plan to do that.
do fare well, in any case. <3
