this document refutes everything bmh says. read it. https://www.mozilla.org/media/MPL/2.0/index.48a3fe23ed13.txt
I do not see which of my points this file you linked refutes, nor what particular relation it has to forking. Could you please be more specific?
I suspect you may be parodying message #3800 that i sent earlier. If this is the case, i want to make it clear that the file i linked in message #3800 was not a legal document about the legal nuances of forks, as you so claimed, but instead an essay explaining how the fear of an overwhelming number of incompatible forks of a project is not upheld by reality; i would suggest you be more clear (and a little less hostile) in parodization in the future if you want them to land better. If this is not the case, ignore the preceeding sentence.
I mean, it's pretty simple: people need to be happy in order to be productive.
Well yes but they can't be productive if they're playing games.
Of course. There's a balance to be struck, and modern capitalism encourages a shitty one that leans way too heavily on productivity, leading to an overall worse society. (Besides, the reason people are productive is so that they can be happy.)
Modding APIs also bring downsides by being a complex subsystem of the project for the maintainers to deal with, taking away time that could be used to solve other problems in the software,
but it also increases the capabilities of the project by approximately ∞%!
…at the expense of taking far more time for those capabilities to come to fruition.
and (in my experience) they often lead to fracturing of a community and too many options to choose from.
this is good! i like having choices. you can always choose not to use mods
The fracturing of the community also leads to a fracturing of the effort. I would much rather have a few good choices than many bad choices.
That kind of unification of competition within a niche is exactly the type of thing that i was supporting in my original message.
That's not at all what I was referring to. Many modpacks combine many trivially related mods. It's not as fun to play with 10 mods that all overhaul, say, caves, than 10 mods that each do different things.
That sounds like exactly what i'm referring to: unification of things within a niche.
[Video games a]re meant to entertain, not be useful.
That's not how i think of it. I would say the the usefulness of video games is that they're entertaining.
If doing things differently than other softwares makes them be more entertaining, then so be it.
Of course—the rules should be broken when it's beneficial for everyone.
(Also sorry for not replying to message #3874 earlier.)
What problems do[ modding APIs] create? (You probably already said it but it would be nice to have it all in one place)
Indeed i did, in #3822:
Modding APIs also bring downsides by being a complex subsystem of the project for the maintainers to deal with, taking away time that could be used to solve other problems in the software, and (in my experience) they often lead to fracturing of a community and too many options to choose from.
ok! plugins/add-ons/mods are much easier to manage and install and use than forks. anyone can drag a bunch of files into a folder, add things they want, or remove things they dont. modularity!
Why is that worth the problems that a modding API creates?
using a modding API is a lot easier than forking an entire source tree and building the application yourself
Why is that ease worth it?
also, a lot of modding APIs present a cleaner interface than directly editing the source would.
How do they do that?
also i read the page about forking and it seems to have little relevance here. it focuses entirely on tools, that is, software which performs work. games are entirely different, because they are intended to entertain.
I really don't like the mentality that video games are somehow special pieces of software. While it's true that the purpose of video games is to entertain, that doesn't mean that a video game can completely ignore the fundamental principles of software design (i've talked about this before as a part of this thing). The idea behind the page that "a fork of copylefted software cannot survive unless it fills a niche unique from the original software" is, i think, completely applicable to video games.
folding every mod anyone has ever made back into the main branch and putting under a menu option would be hopelessly impractical to manage and it would push source tree and binary sizes through the roof, for features that a lot of players won't even use.
Exactly, which is why i don't advocate for that. Only the mods that are good and are competing in the niche that the original software fills should be merged into the original software; mods that compete in other niches could be merged into forks if they happen to be good.
Have you... ever tried to get a large group of people to agree on something? It's nearly impossible.
I know it can be difficult sometimes. But i don't think it's anywhere close to impossible.
[[]Th[]]at would seem to indicate that those forks are competing within the same niche and ought to be unified.
Not at all true, it's often fun to run many mods at once. In fact, people make modpacks to make doing exactly that much easier.
That kind of unification of competition within a niche is exactly the type of thing that i was supporting in my original message.
[…]different people want different sets of features at different times and in different contexts, so [modding APIs] make this easy to achieve.
But modding APIs aren't the only way to allow that; having in-game settings available for changing small things and forks available for changing large things are another way. Modding APIs also bring downsides by being a complex subsystem of the project for the maintainers to deal with, taking away time that could be used to solve other problems in the software, and (in my experience) they often lead to fracturing of a community and too many options to choose from.
i feel like bees apioid beeoid. also, apioforms.
Foul! No non-sequiteurs!
all reasonable discussion ended when bmh posted a link to a completely unrelated legal document about the law regarding forks in response to a valid point that a lot of forks would be an overwhelming choice to the user too
Did you read the document? This is the second time that i have asked this.
discovery, especially of emergent mechanics, is a major part of what can make a game fun and enduring.
If the desire is for emergent mechanics, what's the point in piling more and more completely new and non-emergent mechanics on top of the game through mods? Why not instead tweak and change the original game so as to allow for those emergent properties?
people would be overwhelmed with loads of competing forks? i shall actually prove you wrong by sending you to a link to a completely unrelated legal document about the legal nuances of forks!!
Did you read the page? And there's no need to be mocking.
what would be actually overwhelming is many, many competing forks, as the codebase fails to accommodate the flexibility that people desire from the game.
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.
I don't think that's true. There are many reasons a game could be worth playing—while i think that fun is certainly the most common reason, and my personal experience has shown that making a fun game requires meticulous thought, there are other reasons, like playing a classic game to understand why it's a classic, even if it's a not fun or even sometimes actively bad game.
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[…]
I suppose i am being a little pessimistic, aren't i?
in modded games (well, mostly just minecraft), I find myself changing the mods around between play sessions to create new gameplay situations and interactions.
so there's a mod called the Scrimblermod that adds an item called the Scrimbler. and then there's a mod called GlurberDeluxe that adds an item called the Glurber. the Scrimbler and the Glurber are different items that change different aspects of the game. i like both of these mods. can i use them both?
I don't have enough information to know.
#3795:
why have a settings screen in your game? if you don't like the FOV, just fork it and change it.
The settings screen does not overwhelm the player with choice, and none of the setting have a significant effect on the fundamental gameplay (generally).
#3796:
having many forks WILL in practice lead to horrible incompatbility, developers not collaborating on things or standardizing anything, etc.
how exactly would this work? what if i want to use several mods?
Why would you want to do that? (Genuine question.)
#3791:
Doesn't that risk overwhelming the player with too many choices, not all of which will be good and many of which have only slight differences from each other, in the same way as e.g. a sandbox game with a detailed world settings selector?
is this bad?
I would say so. It makes it more difficult for the player to have fun.
#3792:
why do we allow people to execute arbitrary programs on their OS? doesn't that risk overwhelming them with choice?
No. The overwhelming of the user comes when multiple entities create software in the same niche and, rather than cooperating to fill the niche most optimally, compete with each other to make their own pieces of software fill that niche, overwhelming the user with, you guessed it, too many options of which not all of them are good and many of which have only slight differences from each other.
Doesn't that risk overwhelming the player with too many choices, not all of which will be good and many of which have only slight differences from each other, in the same way as e.g. a sandbox game with a detailed world settings selector?
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.
I don't think that's really true, because this hypothetical shared code wouldn't be general-purpose.
I have had lots of fun with mods that destroy the balance/progression of games.
How did you do that?
#3771:
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.
I cannot understand how that could possibly be fun outside of the novelty that will inevitably wear off very quickly, as opposed to games that have less content with a lot of deep thought put into it that can be fun for extremely long periods of time.
#3775:
the modification API is to allow the user to have multiple modifications at once. this is the most efficient way to do that.
But if the user needs modifications, why shouldn't those things just be in the base game?
running multiple incompatible versions of the same program is quite a miserable experience.
Ah, so having a modding API is much better for storage space than needing to install multiple forks with duplicate code. I hadn't thought about that. 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?
(And on the topic of unneeded extra files, modding APIs arguably have their own issue with the fact that often, a mod can only add things to the game, not replace or remove things.)
having your favorite mods not interoperate is an unfortunate experience.
Well, i can see how a modding API would help with code interoperability, but what about gameplay interoperability? What benefit is there to playing with two different mods if they don't work well with each other? And if there is collaboration between the devs of the mods to make the gameplay of the mods work together…well, they'd probably end up with code interoperability anyways. (Though i suppose one could argue that, if the modding API's promise of code interoperability didn't exist, nobody would even try to play with both of the mods at the same time, but i think that even if that wasn't there the desire for the mods to interoperate would still exist.)
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.