Project:Base

PyL_
New member
Posts: 8
Joined: Fri Jul 13, 2018 20:04
In-game: PyL_

Project:Base

by PyL_ » Post

Hi folks,

I'm pretty new to Minetest but I am a long time player of Minecraft.
I have a pretty good experience at modding game (Just add mod to the game and make it work together, not create it).
The most common issue I found with mods is the lack of interoperability/redundancy.
It's even worst with Minetest since there are no "base" libs/mods and mods creator use various libs that we must found and download around the forum.

I searched in the forum and the only topic I found that suits my idea is the modbase experiment created by burli. But it's apparently discontinued.

For now the only base the modders have is the "default" mod from minetest_game which quite hard to modify and can contain unwanted things.
So I created this topic to present you my idea of a solid modding base and to discuss about it.

I called this project Project:Base.
Project:Base is a sub-game that aim to be :
- modulable : all content is clearly identifiable and can be easily removed (except dependencies)
- universal : provide popular resources and apis/libs.
- lightweight
- forkable : anybody can easily modify it to create it's own base

The idea behind this project is to provide a rock solid base that provide tools to people who wants to build a game or develop a mod.
This base game should provide redundant resources (e.g common ores, woods, stone, etc) and lib/api (e.g intllib, sounds, energy api, etc).

For now, the main task is to define some standards to mod implementation (e.g naming convention, folders structure, code structure) and define which lib/mod to include.
As I said I'm new to Minetest so I don't know the best practices, additionally I want the project to be community driven so I expect to develop it with the help and suggestion of all community, especially the modders and sub-game makers.

Feel free to comment and give your ideas :)

R-One
Member
Posts: 160
Joined: Wed Dec 20, 2017 23:06
Location: Nice, France

Re: Project:Base

by R-One » Post

hello, first welcome to the mintest community.

I'm also interested in game development for minetest and I share your vision of the mod default and starting from minetest_game for a new game.

I had the same questions as you and preferred to have separate functions like the player, the nodes, the entities, the tools ... etc ... etc ...

On the other hand, it is rather annoying to maintain because many mods rely on the mod default so you must follow and maintain a fork of all the mods that come from elsewhere.

I asked myself if it would be good to "compete" with minetes_game rather than contribute to the project and restructure the code? ... could it be more productive?

For example, the biomes of minetest game often have the same blocks for the field, which blocks me for a differentiated spwan of the mobs ... do I have to create a fork for that or rather to speak with the developers then to make a merge? ??

I wonder if it is not more efficient to stay focused on a project especially if the gameplay changes little in the end.

On the other hand, it would be technically possible to make new games with completely different gameplays, so yes it would deserve a new project.

PyL_
New member
Posts: 8
Joined: Fri Jul 13, 2018 20:04
In-game: PyL_

Re: Project:Base

by PyL_ » Post

On the other hand, it is rather annoying to maintain because many mods rely on the mod default so you must follow and maintain a fork of all the mods that come from elsewhere.
Workaround exists, game creators can simply include default mod when its required or a mod can be created to interface base mods with Minetest_game based mods (e.g treat iron:iron_ore as default:iron_ore)(maybe with alias or something).

I asked myself if it would be good to "compete" with minetes_game rather than contribute to the project and restructure the code? ... could it be more productive?
They will not really "compete" because Project:Base will probably include all resources and behaviours of Minetest_game to ensure compatibility.
Moreover, one of the aims of Project:Base is to split the default mod, so the result can easily be integrated to Minetest_game if creator of the project want to.

I wonder if it is not more efficient to stay focused on a project especially if the gameplay changes little in the end.
So yeah, at the begining, Project:Base will likely be similar to Minetest_game at a gameplay level but much more customizable and extendable at a code level.

Sokomine
Member
Posts: 4276
Joined: Sun Sep 09, 2012 17:31
GitHub: Sokomine
IRC: Sokomine
In-game: Sokomine

Re: Project:Base

by Sokomine » Post

It would be great to have a common base. It just doesn't seem as if there's much support for it :-(. Some people even porpagate new "games" which do not even include default nodes and thus make it very difficult for modders to operate. It's annoying to have to deal with default:dirt, mod1:some_dirt, mod2:we_named_dirt_diffrently_again, mod3:this_is_also_dirt_somehow etc. These games are a pain for exchanging schematics as well. Mods need some materials in order to craft what they provide.

Libraries are sadly also something that's extremly rare. Most mods aren't complex enough in code to profit from them. About the only lib that seems to be more present is the intllib for internationalization. Other libs are usually disregarded. In most cases it might be due to the modder not knowing about the lib or fearing that a mod that depends on another one gets too complicated for the users. The new contentdb might help a lot here.
A list of my mods can be found here.

Orby
Member
Posts: 85
Joined: Sat Aug 18, 2012 03:59
GitHub: orbitaldecay
IRC: orbitaldecay
In-game: Orby
Location: Baltimore, MD

Re: Project:Base

by Orby » Post

This has been brought up a few times before and I think it's an excellent idea. I'd certainly be willing to contribute time to such a project. I think part of why there are so few quality games is that authors often get bogged down reinventing the wheel. MTG isn't the best place to start when you want to write a new game; there is a lot of code there that you would want to rip out if writing a game from scratch. This basically leaves people who want to write a game starting with nothing and spending a lot of time just implementing basic systems.

User avatar
TumeniNodes
Member
Posts: 2941
Joined: Fri Feb 26, 2016 19:49
GitHub: TumeniNodes
IRC: tumeninodes
In-game: TumeniNodes
Location: in the dark recesses of the mind
Contact:

Re: Project:Base

by TumeniNodes » Post

I'm working on 'default', being solely mapgen materials/code (the natural base stuff for the world)
A Wonderful World

PyL_
New member
Posts: 8
Joined: Fri Jul 13, 2018 20:04
In-game: PyL_

Re: Project:Base

by PyL_ » Post

Some people even propagate new "games" which do not even include default nodes
I think it's mostly because the default game does not fit with their needs. Sometimes it's easier to start from scratch than try to understand and modifying default mod.

Libraries are sadly also something that's extremely rare
Yes, nevertheless there are some interesting libs that deserve to become a reference.
I think the main problem is the lack of support for this libs and their visibility in the forum. I found some libs for biome, mobs, even "dimensions" but this libs are hidden in the mass of the mods. Maybe we need to create another category in the forum specifically dedicated to libs ?
I think part of why there are so few quality games is that authors often get bogged down reinventing the wheel.
Totally agree with you. But again, I think it's mainly because of the lack of normalization/libs/monolithic default mod.
I'm working on 'default', being solely mapgen materials/code (the natural base stuff for the world)
I will definitely create a GitHub repository to share my work. I already separated most of the default mod in many small one (e.g one for iron, gold, dirt , etc) and it work quite good (some few bugs appear but I only spend one day on it).

Additionally I think about making three games out of this project : a minimal version (like you want to do, only required materials for mapgen), a "playable version" (something like minetest_game, maybe keep the same content and behaviours) and an extended version (with a lot more content, still playable but designed for modding).

User avatar
DrFrankenstone
Member
Posts: 231
Joined: Tue May 24, 2016 05:36
GitHub: treer
Location: Australia
Contact:

Re: Project:Base

by DrFrankenstone » Post

PyL_ wrote:The most common issue I found with mods is the lack of interoperability/redundancy.
Is the addition of another modpack the right approach for increasing interoperability?

I had a mod that needed vines, and there are several modpacks already that implement climbable hanging vines which grow, so it contained a list and used the first type of vines it found present. The result is a Minetest mod that works whether you're playing MineClone 2, Minetest_game, whatever.

What if Project:Base was a modular system for increasing interoperability via abstraction instead of figuratively adding yet another implementation of "vines" etc? Then any mods built on Project:Base become interoperable with the other mods the server selected, dependencies become swappable or optional, and similiar items/blocks aren't doubled up when combining mods.

It could also guarantee a large number of block aliases for a building base of "common ores, woods, stone etc" for any dependent mods to use, as not every mod providing blocks registers them.

You can't do everything with a compatibility layer, but it does seem to be underutilized for mod interop.

(I just copy-pasted abstraction code into a new mod while thinking "there should be a common library for this")
Last edited by DrFrankenstone on Tue Jul 17, 2018 12:41, edited 1 time in total.

PyL_
New member
Posts: 8
Joined: Fri Jul 13, 2018 20:04
In-game: PyL_

Re: Project:Base

by PyL_ » Post

Abstraction is definitely the way to go, and will certainly be implemented in a early form to ensure compatibility with mod based on default or mineclone for example.

However it can be very useful to add mods too. To take your example with vines, if many mods need vines, why not adding a stand-alone vines mod that can be easily editable and usable so modders don't need to spend time any more to implement their own vines or to detect already existing vines.
To take the general case, if a resources is used by many mods (an ore, a wood, an item), it can be interesting to add it to the mod base. intllib for example will be added to Project:Base because most of the mod use it and it's the best way to go for localization.
Another advantage of this is if you find a way to improve a mod (let's say you improve the code of furnace mod) the improvement is directly applied to mods that depends to it.

User avatar
DrFrankenstone
Member
Posts: 231
Joined: Tue May 24, 2016 05:36
GitHub: treer
Location: Australia
Contact:

Re: Project:Base

by DrFrankenstone » Post

I didn't mean to not implement anything - providing modular implementations allows the option of having a fallback if there's no other mod providing the thing the mod wants.
PyL_ wrote:why not adding a stand-alone vines mod that can be easily editable and usable so modders don't need to spend time any more to implement their own vines or to detect already existing vines.
Because if the Project:base doesn't first detect already existing mods then the mods built off it would create games containing multiple kinds of the same thing. With vines, that's fine - plant variation is good, but having two kinds of same-metal ingots that craft different items, or two kinds of books that each require their own kind of bookcase isn't as good. If the idea is not to be used with prior mods then will it be helping interop/redundancy?

But don't read this as discouragement - it was just idle speculation on a post which was calling for ideas, and has its own limitations and drawbacks.

PyL_
New member
Posts: 8
Joined: Fri Jul 13, 2018 20:04
In-game: PyL_

Re: Project:Base

by PyL_ » Post

I get your point and I will definitely think about a mechanism to handle this issue in the best way.

That being said it's a quite easy for a game creator to remove the iron ore mod if another mod add it too and maybe add aliases to ensure compatibility.

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

Re: Project:Base

by Wuzzy » Post

I don't think doing a “base” game is a good idea.
This approach has been tried and failed a couple of times in the past, actually. We had a couple of “base games” which all mysteriously disappeared into irrelevancy.
The problem is, these base games are never generic enough to be useful for modding, they usually just end up becoming normal games. Reusing code from these base games is rarely really that helpful.

I'm more for loose collections of mods, in which each mod does one specific task well and they don't open the gates to Dependency Hell. A mod that aims to be generic is good when it can just be dropped in into your game without much fuss.

I also don't think it is that important to have a shared repository, actually. Many modders are not so collaborative and mostly stick to their own projects.

What I do think is important, however, is that modders should follow some basic simple rules to ensure the best interoperability.
E.g. ...
- Triple-check your dependencies
- Try to use established groups. This wiki page might help: https://dev.minetest.net/Groups
- Document your own groups in the dev wiki if they are meant for wider usage
- Don't pollute the global namespace; make everything local by default, only use global variables if you really have to
- Check of what has already been done before reinventing the wheel
- https://dev.minetest.net/Mod_interoperability

User avatar
Linuxdirk
Member
Posts: 3217
Joined: Wed Sep 17, 2014 11:21
In-game: Linuxdirk
Location: Germany
Contact:

Re: Project:Base

by Linuxdirk » Post

Wuzzy wrote:- Document your own [...]
... EVERYTHING.

Your functions, your loops, your important variables, your files. Document the shit out of it! If you establish an API: Document all API calls with examples.

PyL_
New member
Posts: 8
Joined: Fri Jul 13, 2018 20:04
In-game: PyL_

Re: Project:Base

by PyL_ » Post

I'm more for loose collections of mods
I totally agree, and that's the point of this project, the term "game" can be misleading because it refer more in a collection of basics and inter compatibles mods more than a truly playable game like minetest_game or mineclone.

My aim is to provide a collection of mods that can simply be copy/pasted into a new game. So all the game that use this mods will be build on the same "base". So most of the mods developed for a game based on Project:Base will be compatible (or easy to adapt) with other games based on it.
Basically Project:Base aim to be a collection of mods (e.g one that add iron, another that add oaktree, ...) that is standardized and optimized.

But I need to start somewhere so I took the minetest_game (which is currently the most popular base for mods) and try to split it in small parts. I think it's a good test to see potentials benefits of this project.
Building a copy of minetest_game is beneficial since the mods based on it will be instantly compatible with this base.

For now most of the minetest_game is splitted into small mods which have few to none dependencies.
Many modders are not so collaborative and mostly stick to their own projects.
That's a shame :/
Maybe a project like mine can change that. If modders have a common collection of mods, they maybe team up to bring common needed resources to this collection.
For example if two mods based of Project:Base use uranium ore, developers could collaborate to add a standalone uranium ore to this collection and use it as a common base.

User avatar
Linuxdirk
Member
Posts: 3217
Joined: Wed Sep 17, 2014 11:21
In-game: Linuxdirk
Location: Germany
Contact:

Re: Project:Base

by Linuxdirk » Post

PyL_ wrote:My aim is to provide a collection of mods that can simply be copy/pasted into a new game. So all the game that use this mods will be build on the same "base". So most of the mods developed for a game based on Project:Base will be compatible (or easy to adapt) with other games based on it.
Basically Project:Base aim to be a collection of mods (e.g one that add iron, another that add oaktree, ...) that is standardized and optimized.
You mean like the currently existing default?

PyL_
New member
Posts: 8
Joined: Fri Jul 13, 2018 20:04
In-game: PyL_

Re: Project:Base

by PyL_ » Post

Not at all since default is all-in-one mod, it's not a modulable collection of mods.

Astrobe
Member
Posts: 571
Joined: Sun Apr 01, 2018 10:46

Re: Project:Base

by Astrobe » Post

I believe MTG isn't a bad starting point unless you do something exotic. It's not that hard to modify it, I've modified it a lot for my game. But I the end of the day, there are more parts that are left untouched than edits.

Also, it seems to me that most mods only depends on default for the existence of some nodes. I think often they could omit the dependency declaration because the loading order isn't important (e.g. the does spawn a stone node at some point, but "default:stone" doesn't actually need to exist when the mod is loaded).

PyL_'s work is interesting, cause I felt that default could actually be split in several parts. For instance I think books and bookshelves is a good candidate; sapling and tree grow maybe also (although a part of it should become an library that allows to additional growing trees like you add slabs and stairs). Burning and cooking times maybe. It's a lot of work with only long term value, unfortunately. It would allow mods to make more accurate dependency statements, which will help with reuse.

As for libraries I believe the first step to encourage them is to have a separate forum section for them.

Sokomine
Member
Posts: 4276
Joined: Sun Sep 09, 2012 17:31
GitHub: Sokomine
IRC: Sokomine
In-game: Sokomine

Re: Project:Base

by Sokomine » Post

PyL_ wrote: Maybe we need to create another category in the forum specifically dedicated to libs ?
A forum category alone won't help much. What we need for libs is a way to make sure that the player who wants to install a mod has the necessary libs. There's depends.txt, but...players and modders are reluctant to use that for libs. It increases complexity for the player, will lead to more questions, having to keep track of the libary mod as well (might also get abandomed), and leads to far fewer people installing and using the mod. Maybe the contentdb can help. But I don't think that's enough. Most libs are very small. They ought to be bundled and be part of all games.
PyL_ wrote: I think it's mostly because the default game does not fit with their needs. Sometimes it's easier to start from scratch than try to understand and modifying default mod.
If it acts like dirt, looks like dirt - why a new name for it? I wouldn't mind if those games would provide their own default mod - which defines default nodes in the way the game likes them to be.
DrFrankenstone wrote: I had a mod that needed vines, and there are several modpacks already that implement climbable hanging vines which grow, so it contained a list and used the first type of vines it found present. The result is a Minetest mod that works whether you're playing MineClone 2, Minetest_game, whatever.
That's a good approach and works to some degree. Trouble is: There are...many...mods. Keeping track of all of them, of changes in each one, is...very time-consuming. It's a workaround, but...not comparable to the convenience of a library. Which we could have...but in practice don't have in MT.

When my trees_lib was finished, MTG had already switched to new growing methods for saplings, and leaves in particular where handled completely diffrent. It'd be possible to adjust it to the methods newly introduced into the engine - and thus do that on one palce alone instead of in every mod - but nobody seems to be intrested in a library.
A list of my mods can be found here.

User avatar
Linuxdirk
Member
Posts: 3217
Joined: Wed Sep 17, 2014 11:21
In-game: Linuxdirk
Location: Germany
Contact:

Re: Project:Base

by Linuxdirk » Post

Astrobe wrote:I think often they could omit the dependency declaration because the loading order isn't important (e.g. the does spawn a stone node at some point, but "default:stone" doesn't actually need to exist when the mod is loaded).
Yeah, but then you need to check if default:stone is available when you want to spawn it and react properly when it is not available. With the dependency on default you are safe because you know default:stone is there.

Of course it would be better if stone nodes (default:stone, the cobblestone, and the stuff you can craft from them) were an own mod so you can depend explicitly on this instead of "everything from default even if I don't need 99.9% of it."

User avatar
texmex
Member
Posts: 1753
Joined: Mon Jul 11, 2016 21:08
GitHub: tacotexmex
In-game: tacotexmex

Re: Project:Base

by texmex » Post

I for one is quite interested in this project as I’m tired to create unloading schemes for taking out parts of default that I don’t like to have in my game.

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

Re: Project:Base

by Wuzzy » Post

I take the opportunity to highlight https://dev.minetest.net/Mod_interoperability once again.

This page lists a lot of “API mods”. Please add your own here, too.

User avatar
texmex
Member
Posts: 1753
Joined: Mon Jul 11, 2016 21:08
GitHub: tacotexmex
In-game: tacotexmex

Re: Project:Base

by texmex » Post

@PyL_
How do you plan (or do you plan) to keep the project base up to date with default and/or Minetest Game?

As an example, burli's project was ideal for me and my project but it wasn't (perhaps wasn't supposed to be) kept up to date with new features of MTG, hence I quickly went back to MTG as base project because I could get more nifty core features for less work.

Astrobe
Member
Posts: 571
Joined: Sun Apr 01, 2018 10:46

Re: Project:Base

by Astrobe » Post

Almost by definition: MTG has to use it.

User avatar
rubenwardy
Moderator
Posts: 6972
Joined: Tue Jun 12, 2012 18:11
GitHub: rubenwardy
IRC: rubenwardy
In-game: rubenwardy
Location: Bristol, United Kingdom
Contact:

Re: Project:Base

by rubenwardy » Post

I'm looking for a good way to improve MTG's default, as it's currently a massive obstacle to inter-game modding. Not sure how to do it cleanly without some breakages. I'd argue that some breakages will be worth it in the long run
Renewed Tab (my browser add-on) | Donate | Mods | Minetest Modding Book

Hello profile reader

Astrobe
Member
Posts: 571
Joined: Sun Apr 01, 2018 10:46

Re: Project:Base

by Astrobe » Post

Sokomine wrote:
PyL_ wrote: Maybe we need to create another category in the forum specifically dedicated to libs ?
A forum category alone won't help much. What we need for libs is a way to make sure that the player who wants to install a mod has the necessary libs. There's depends.txt, but...players and modders are reluctant to use that for libs. It increases complexity for the player, will lead to more questions, having to keep track of the libary mod as well (might also get abandomed), and leads to far fewer people installing and using the mod. Maybe the contentdb can help. But I don't think that's enough. Most libs are very small. They ought to be bundled and be part of all games.
What you want is an in-game package manager. Something that download mods on your request and download its dependencies as well.

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests