citrons

right. the problem with them is only that they're predominantly unfinished, which is just... what happens with video games. it's just hard in general to make video games.

making video games? yeah.

pertaining to the module system, my ultimate goal would be to create a package manager and repository, but this would depend on package ecosystem/playerbase to exist first.

I feel like you're referring back to a previous conversation, but i can't remember which; could you please remind me?

consider the case of modding APIs, or breaking compatibility. whether or not a modding API is a good fit for this game specifically, I find that you have taken hardline stances on software that I disagree with in the past.

Perhaps i stated my goal wrong. Maybe a better way to phrase it would be that i want to create a game that's better at being Minecraft than Minecraft is. Or perhaps i could say that there's a certain happy feeling i used to have when playing Minecraft when i was youngerand less disillusioned with the world, and i want to be able to recreate that feeling.

I see now. that could be interesting.

If the consensus of the populace is that doing something would be the most fun, that's what should be done; if everybody's saying that something isn't fun, it should be removed; if experiments reveal that people find something more fun than expected, that should influence the decisions.

that certainly makes sense.

(I'm curious about what you specifically mean by the design goals you listed, though.)

well, I plan extensibility in the form of a module system, in which the game is constructed from modules which interact with each other by exposing public APIs and which can be used in different combinations at whim (as long as they don't conflict).

in terms of actual game mechanics, I want to design the game such that blocks in the world have interesting interactions, and hopefully emergent mechanics. my ideas hinge heavily on my reinterpretation of the voxel engine, wherein multiple blocks at once can fit within a space. this is implemented partially and inelegantly in minecraft in the case of waterlogging and slabs, but I wish to implement this generally.

I think that the main mechanics that the player will interact with to make mechanisms and generally get things done are heat and water. water, unlike in minecraft, will actually be finite and flow into different blocks akin to minecraft. heat will likely be producible by combusting fuel and by other means, and I think it will be the means to power mechanisms like pistons.

pistons will be akin to those in minecraft, but they will be much more powerful. utilizing the ability to contain multiple blocks in a space, one will be able to apply a gluelike block to the sides of blocks, which will cause them to be moved as one when pushed by a piston.

for implementing logic, my current idea is to have a funguslike substance whose stem conducts heat very well and whose head implements logic gates. the fungus would be found on the roof of a certain type of cave underground, and may be cultivated by the player once found.

pertaining to world generation, I want to feature detailed and fantastical environments. the world generation will take advantage of the "infinite" nature of the world, both horizontally and vertically. as one moves further from the center of the world, the environments become more fantastical, and as one ventures deeper into the ground, one is able to stumble upon the otherworldly. I'm not sure what should be in the sky, but perhaps there would be floating islands or celestial objects.

the inhabitants of the world, i.e. mobs, will generate with the world and not spawn spontaneously (at least, predominantly), unlike minecraft. though some might be dangerous, none of the mobs will exist simply for the purpose attacking the player (except maybe for one exception that I have in mind). I wish to have them exist in a sort of simplistic ecosystem, where the actions of the player could affect their populations.

in any case, your elaboration of your goals has given me a better idea of the project, and I think it could be cool.

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.

well, I'm not really an expert in this. I think it just comes down to being administrated well.

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.

clearly, this post doesn't exist.

oh no.

oh, true.

actually, they did exercise thread 367. also of note is that I vetted this website 127 days ago.

what do you mean? the site is vastly older than GEORGE.

well, there are some spiders that obey robots.txt.

I know this is a joke, but I think package managers should handle all installation. as such, no instructions required!

rebeccapurple

gay

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.

http://linuxmafia.com/faq/Licensing_and_Law/forking.html

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".

That sounds like an addiction to novelty.

I have no idea what you're trying to say. discovery, especially of emergent mechanics, is a major part of what can make a game fun and enduring.

"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.

why have a settings screen in your game? if you don't like the FOV, just fork it and change it.

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.

we should target specifications, certainly. if they don't meet needs, new ones ought to be made.

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.

false.

I enjoy this.