What's the point of libre video games having modding APIs when, being libre, people could instead fork them or submit patches?
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.
#3766:
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.
Would they work as forks of the original game?
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.
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.
the modification API is to allow the user to have multiple modifications at once. this is the most efficient way to do that.
#3770:
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?
So why not have forks then?
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?
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?
why do we allow people to execute arbitrary programs on their OS? doesn't that risk overwhelming them with choice? clearly, the only good way to install new software is by forking the OS.
#3790:
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.
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?
why have a settings screen in your game? if you don't like the FOV, just fork it and change it.
having many forks WILL in practice lead to horrible incompatbility, developers not collaborating on things or standardizing anything, etc.
"well I don't want to use more than one mod at a time" is not really a justification for this.
#3794:
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.
That sounds like a rather pessimistic prediction.
"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.
what would be actually overwhelming is many, many competing forks, as the codebase fails to accommodate the flexibility that people desire from the game.
http://linuxmafia.com/faq/Licensing_and_Law/forking.html
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.
That sounds like an addiction to novelty.
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.
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".
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!!
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.
Why not instead tweak and change the original game so as to allow for those emergent properties?
So... make a mod for the game? That seems to be exactly what you described.
Why not instead tweak and change the original game so as to allow for those emergent properties?
So... make a mod for the game? That seems to be exactly what you described.
No, i meant that the original game should be changed, by means of e.g. submitting a patch.
please log in to reply to this thread