What is recommended as a base for a subgame and one other Q

Icalasari
Member
 
Posts: 17
Joined: Tue Sep 23, 2014 05:29
IRC: Icalasari
In-game: Icalasari

What is recommended as a base for a subgame and one other Q

by Icalasari » Fri Sep 30, 2016 00:12

It's an end goal of mine to eventually make a subgame (may never happen, may end up rapidly getting to it, but reguardless, it's an endgoal), but while I may be no where near the point of worrying about that (I'm still on making basic nodes and hopefully crops), I'm still curious as to a few things:

What exactly is the recommended way of handling a base for a subgame? Do people tend to rely on default for maximum mod compatibility? Do they alter default a lot and have the suvgame just use those names internally for mods? How far does it go - Replacing dirt and stone? Replacing ores? Disabling the base biomes? I know subgames can change a lot but it's more... If one wants it as an endgoal, what is the norm for how much of default one overwrites eventually, assuming the type of subgame is a standard survival/creative rather than a super specific type?

And also, how do most subgames start? From scratch? Evolving from a modpack? As collaborative or as one man projects?
 

User avatar
Wuzzy
Member
 
Posts: 2161
Joined: Mon Sep 24, 2012 15:01
GitHub: Wuzzy2
IRC: Wuzzy
In-game: Wuzzy

Re: What is recommended as a base for a subgame and one othe

by Wuzzy » Fri Sep 30, 2016 13:46

What exactly is the recommended way of handling a base for a subgame?

There is no universal recommendation, so I just give my own opinion:

If you want to make a subgame from scratch, I would recommend to see mods as modules. Roughly one functionality per mod. I promise you this will ease your life very much.

Also, take your time to look around for mods which do what you need before programming your own mods. Look for frameworks before writing your own. Here's a list: http://dev.minetest.net/Mod_interoperability

Maybe I should write a list of mods which almost all subgames would “want” to have sooner or later. Like a mod which adds the player model which is not called “default”: viewtopic.php?f=11&t=10349&hilit=playermodel

Minetest Game's approach is to make a very bloated mod called “default” on which many mods depend. It's bloated because it contains way too many nodes, items, player model, HUD defintions, ABMs, biomes and whatnot. IMO this is not the best approach since if you only need a node from default you have to pull in Everything And The Kitchen Sink®. But it is this way now and I don't think Minetest Game will change this in the long run. When working with Minetest Game or one of its forks, we have to live with that.
Do people tend to rely on default for maximum mod compatibility?

No. Mods only depend on mods because they require something from that other mod. This is the only reason for dependencies. Note that any additional dependency is reducing compability, so you generally want to keep dependencies low.
In fact, default is just a mod like any other, there is nothing special about it. Default is a mod from Minetest Game which contains a lot of basic stuff like node definitions, ABMs, even the player model, and more. Some mods depend on default, but you do NOT need to depend on it if you don't need anything provided by this mod.
In general, mod developers should be encouraged to add as few dependencies as neccessary and try to make the remaining dependencies optional, if possible. And this includes dependency on the default mod. It is possible for mods to don't depend on anything, not even default. One example is a mod which only adds a few chat commands.
I argue that a hard dependency on default is rarely neccessary. Many mods depend on default only for adding crafts. But all dependencies which are only added because of crafts can always transformed into optional dependencies. If default is there, add the craft, if it is not there, add no craft (you still have the item definition).

Do they alter default a lot and have the suvgame just use those names internally for mods?

Again, it depends. For subgames which have been forked from Minetest Game, they usually tend to alter the default mod, sometimes just a bit, sometimes more.
Luckily, most Minetest Game forks tend to keep the core nodes and items and I am not yet aware of compability issues with other subgame. I think compability issues depend more or less on the subgame itself. Ask the subgame author for help.
For mod developers my recommendation is that whenever you depend on default you should specify from which subgame. As an user, it is generally safe to assume that “default” means “default from Minetest Game” if not specified otherwise.

My recommendation for subgame authors who create Minetest Game forks is to avoid removing default stuff for compability, but if they plan to heavily modify default or any other of the core mods beyond recognition, it might be better to rename the mod for clarity.
Another strategy might be to try to avoid modifying default and instead put your additions (e.g. new nodes) into a new mod instead.
But I also opine that compability should not always stand in the way of innovation. If you want to make a truly innovative subgame which will be incompatible with most default-depending mods, well, go for it. Maybe one day other mods will appear which depend on your subgame mods specifically. But I would strongly recommend to use more unique / different mod names to reflect the differences; this will also be important for dependency management.

How far does it go - Replacing dirt and stone? Replacing ores? Disabling the base biomes?

Theoretically, all of the above, and more. Some subgame modify default just a little bit, other subgames modify it more heavily. Subgame authors are free to do anything, including ignoring all conventions whatsoever. In practice, I haven't seen a Minetest Game fork which replaces dirt or stone but it would certainly be a valid use case. Adding different biomes is common. Ores are usually just added upon and not replaced, probably since the default ores are often desired. But there's no guarantee. It is important to keep in mind that there is no “subgame standard” or anything like that.

what is the norm for how much of default one overwrites eventually, assuming the type of subgame is a standard survival/creative rather than a super specific type?

There is no norm.
I think overwriting a few nodes should be safe, but removing nodes could be dangerous unless compability is not a goal (in which case I would recommend changing the names of the “offending” mods).
I'm creating MineClone 2, a Minecraft clone for Minetest.
I made the Help modpack, adding in-game help to Minetest.
 

Icalasari
Member
 
Posts: 17
Joined: Tue Sep 23, 2014 05:29
IRC: Icalasari
In-game: Icalasari

Re: What is recommended as a base for a subgame and one othe

by Icalasari » Sat Oct 01, 2016 00:20

Wuzzy wrote:If you want to make a subgame from scratch, I would recommend to see mods as modules. Roughly one functionality per mod. I promise you this will ease your life very much.


Already been doing this, just going to take practice to figure out which stuff best groups together

Also, take your time to look around for mods which do what you need before programming your own mods. Look for frameworks before writing your own. Here's a list: http://dev.minetest.net/Mod_interoperability


Generally how I learn with programming. Playing around with existing things, then seeing what ways I can recombine them and push them. That link will come in handy, thanks

Minetest Game's approach is to make a very bloated mod called “default” on which many mods depend. It's bloated because it contains way too many nodes, items, player model, HUD defintions, ABMs, biomes and whatnot. IMO this is not the best approach since if you only need a node from default you have to pull in Everything And The Kitchen Sink®. But it is this way now and I don't think Minetest Game will change this in the long run. When working with Minetest Game or one of its forks, we have to live with that.

...

No. Mods only depend on mods because they require something from that other mod. This is the only reason for dependencies. Note that any additional dependency is reducing compability, so you generally want to keep dependencies low.
In fact, default is just a mod like any other, there is nothing special about it. Default is a mod from Minetest Game which contains a lot of basic stuff like node definitions, ABMs, even the player model, and more. Some mods depend on default, but you do NOT need to depend on it if you don't need anything provided by this mod.
In general, mod developers should be encouraged to add as few dependencies as neccessary and try to make the remaining dependencies optional, if possible. And this includes dependency on the default mod. It is possible for mods to don't depend on anything, not even default.

...

I argue that a hard dependency on default is rarely neccessary. Many mods depend on default only for adding crafts. But all dependencies which are only added because of crafts can always transformed into optional dependencies. If default is there, add the craft, if it is not there, add no craft (you still have the item definition).


Doesn't that cause issues then with ores, crops, etc.? I know there are ways to define stuff more generally (e.g. charcoal that uses wood group rather than specific tree based nodes), so I'm guessing there are ways around that?

Again, it depends. For subgames which have been forked from Minetest Game, they usually tend to alter the default mod, sometimes just a bit, sometimes more.
Luckily, most Minetest Game forks tend to keep the core nodes and items and I am not yet aware of compability issues with other subgame.

...

My recommendation for subgame authors who create Minetest Game forks is to avoid removing default stuff for compability, but if they plan to heavily modify default or any other of the core mods beyond recognition, it might be better to rename the mod for clarity.

...

But I also opine that compability should not always stand in the way of innovation. If you want to make a truly innovative subgame which will be incompatible with most default-depending mods, well, go for it. Maybe one day other mods will appear which depend on your subgame mods specifically. But I would strongly recommend to use more unique / different mod names to reflect the differences; this will also be important for dependency management.

...

Theoretically, all of the above, and more. Some subgame modify default just a little bit, other subgames modify it more heavily. Subgame authors are free to do anything, including ignoring all conventions whatsoever. In practice, I haven't seen a Minetest Game fork which replaces dirt or stone but it would certainly be a valid use case. Adding different biomes is common. Ores are usually just added upon and not replaced, probably since the default ores are often desired. But there's no guarantee. It is important to keep in mind that there is no “subgame standard” or anything like that.


I am a touch bit confused. If they are depending on dirt and stone nodes (e.g. ore generation, farming), is that not a dependency requiring Default itself? Or is it a case of copying over some of the default subgame, only taking what is needed and cutting out what isn't? If the latter, then I take it the default subgame isn't as intertwined as I thought it was? Guess that misconception is probably from following Minecraft so long - Kind of used to the stories of how it's this horribly intertwined mess that is taking years just to untangle that I was mistaken when looking into Default

I think overwriting a few nodes should be safe, but removing nodes could be dangerous unless compability is not a goal (in which case I would recommend changing the names of the “offending” mods).


Overall what I'm gathering from that is, even at an early stage, try to code it so it's as light but robust as possible, e.g. Safe to assume recipes dependant on water or mobs that spawn on dirt will work as it's such a key thing that it failing more likely means a modder is not going for compatibility, recipes that involve say bottles in a mod that relies heavily on them I should have it include my own bottles, and if it's something like a recipe or two that involve torches but are not key elements, I should have it set up so it just doesn't show up

Also gathering that compatibility should be a secondary concern if it's something that would add massively to the experience

Thanks for the tips and help
 

User avatar
Wuzzy
Member
 
Posts: 2161
Joined: Mon Sep 24, 2012 15:01
GitHub: Wuzzy2
IRC: Wuzzy
In-game: Wuzzy

Re: What is recommended as a base for a subgame and one othe

by Wuzzy » Sat Oct 01, 2016 18:18


Doesn't that cause issues then with ores, crops, etc.? I know there are ways to define stuff more generally (e.g. charcoal that uses wood group rather than specific tree based nodes), so I'm guessing there are ways around that?

I am not sure what you are talking about. But I am not saying that hard dependencies are always a no-go. Sometimes, hard dependencies are simply unavoidable when the mod would simply not work at all without a particular mod, or the mod would be very pointless/useless without it.


I am a touch bit confused. If they are depending on dirt and stone nodes (e.g. ore generation, farming), is that not a dependency requiring Default itself? Or is it a case of copying over some of the default subgame, only taking what is needed and cutting out what isn't? If the latter, then I take it the default subgame isn't as intertwined as I thought it was? Guess that misconception is probably from following Minecraft so long - Kind of used to the stories of how it's this horribly intertwined mess that is taking years just to untangle that I was mistaken when looking into Default

It's simple: Recipes can ALWAYS be optional because you only register the recipe if you have the required items (read: mods which add those items) available. Otherwise, you simply don't add the recipe. Yes, your item will be uncraftable then but remember it will still be possible to obtain it in creative mode. Other mods might add their own ways to obtain the item “legally”. There are a lot of possibilities. This approach simply allows for lot of flexibilty while still allowing a sane default behaviour.
I use this strategy for many of my mods, for example the teletool mod. Here, the crafting recipe only exists if particular mods are enabled, otherwise only the tools are registered but no crafting recipes.

Thanks for the tips and help


Remember, this is just my opinion. A lot of stuff you'll do will depend on what you want to achieve with your subgame. You have to set priorities.
I'm creating MineClone 2, a Minecraft clone for Minetest.
I made the Help modpack, adding in-game help to Minetest.
 


Return to Subgame Discussion

Who is online

Users browsing this forum: No registered users and 2 guests

cron