PROPOSAL: Game Development Base

[Sokomine]

In this thread, villages where mentionned. I'm afraid they're currently too complex for inclusion into such a project. But they may illustrate an important issue.

mg_villages tries to support as many other mods as possible. In order to do so (and to do its job), it needs to know more about nodes than the node name. It's vital to know if a node is a "surface node" - mostly default:dirt_with_grass, but default:sand may also fit. Sometimes even default:stone may be the node searched for. Games that are diffrent from MTG - like i.e. RealTest or ethereal or the like - have similar concepts but name the things diffrently. Currently, mg_villages has to know all these node names. In theory, groups may help; sadly, groups are seldom set "correctly" (for whatever correctly might mean here). With the biome api integrated into MT and becoming more widely used, I may have a chance now to identify these surface nodes besides having to list them all.

Trees are another matter. They need to be detected by mg_villages: "Ah, this is a tree trunk; remember where it is and replant the tree once the area has been flattened for the village". Wood and logs are very useful building materials. But: Mods define their own trees in their own ways. Thus, there's a complex list beeing created about what actually *is* a tree trunk, what *is* wood in which game etc. That's not good. I wrote a mod called trees_lib that's supposed to provide a general library for registering trees and providing their functionality. Trees can be registered by telling a function how the diffrent nodes (trunk, wood, leaves, sapling and fruits) shall be named, what description they ought to have, which texture, how to grow the saplings (with a schematic, L-system like in moretrees, or a function), on which nodes the sapling will grow, a function that's called before it is allowed to grow etc. Basicly, adding a tree to the game boils down to creating textures, inventing a name for the tree and fruit (if it exists), building the schematic, calling the register_tree function and making sure it spawns somehow.

Some few modders may actually have heared about the mod or read about it on the forum. But why should they use it? Anyone wishing to create a tree most likely wouldn't remember the mod, never have heared about it, or probably be just starting creating mods. Even for those who know about it, there's no good reason to use such a library. Players won't have it installed and would need to download it. At best, it'd be an additonal dependency beeing downloaded automaticly. More likely, people will refrain from using the mod because it depends on something and seems more complicated to get to run.

Those factors are not the only ones. In the meantime, the leaf decay code has been improved a lot - which I havn't included into trees_lib because nobody uses trees_lib. Existing mods that provide trees are not adopted to the lib either. And then there's the factor that the lib in itself may not be perfect and may warrant improvements (I've a tendency to write complex code; code of less experienced modders is often much easier to maintain). The api may require improvements in order to be easier to understand. That's all quite some work and may need diffrent skills.

I'm afraid that libraries are currently not usable. Their creator may use them, but that's about it. Nobody else will.

What I think could and ought to be done in order to improve the situation is:
* identify which libs are there and which could be of general use
* get the libs into a working state
* make sure everyone who just downloaded MT has these libs and will get updates (libs without textures etc. are tiny)
* discuss the APIs
* make sure mods can override libs when needed
* change existing mods that could make good use of the lib
* don't forget to document all this

All this is far below a game development base. Yet games may profit a lot from it. If you want diffrent behaviour in your mod, you don't have to change each single mod that has something in that direction - you just change/override the lib according to your needs (know what wood types exist? fine - create furniture out of each wood type easily). And there's a lot less justification for copy&paste code.

Admittedly, this is a far lower level than easy to use components for game development. But if we don't get the base - libraries - working, there's not much point in trying to create a base from even more complex constructs.

As far as mobs are concerned, some of what they need could be part of a lib. Pathfinding certainly comes to mind. Just override that with your own pathfinder if you've got something better. Mobs following a path. Sitting down on chairs (great if you know on *what* your mob might try to sit on...), sleeping in beds (there's more than the ones in default), throwing entities (arrows, energy) at poor players, jumping up, climbing a ladder, swimming, ...

[voxelproof]

@Sokomine:

Now I have much greater clarity about the issues which may hinder future development of MT games. I think we should focus on quite different matter than trying to defend MTG against disappointed kids to whom it appears (and rightly so) boring and unappealing. The whole thing is that, as a matter of fact, MT should be developed as a crafting bench for game making, and to achieve this some sort of basic inventory is absolutely necessary. At the moment MT seemingly lacks such repository of mod/game development assets and, until things are sorted out, not much can be expected from those trying to make good use of what MT provides in its current state. To put it shortly - MT badly needs clarity and consistence of the rules of mod/game creation.

[pandaro]

Hi everyone,
I am certainly not an authority, neither as a modder nor as a player, I still want to say my opinion.
I have read a lot in these years about the need and the problem of creating mods (this before, and for a long time) and games (now, and it will still take a long time to be solved).
Anyway:
Minetest is still at version 0.5, which means that the community is also at version 0.5.
This does not mean that API can not be improved, both inside the games and inside the engine (in fact it happens that a function invented within a mod is then transferred into the engine).
But I believe that the current difficulty for the community to give birth to complete and well-made games lies:
Creating a game is not a game, it requires a lot of effort and a TEAM of people who SHARE an IDEA (sorry if I screamed)
Personally, I work a lot (too much, often more than 12 hours a day) every day I visit the minetest (github) page and check what happens and the forum too. I always hope to find time to do something, and then, when I'm on vacation and I can find a couple of days ... well I don't know where to start anymore! :)
I would like to know, among the people who have been mentioned, and those who have actively participated in the discussion, and also among those who have only read it without interfering:

- How many of you have already published a game?
- How many have taken a fair number of mods and merged into a game?
- How many have dreamed of creating a beautiful and original idea, but then they realized that it was not possible on their own?
- How many have a game, which works, and which is used on more than one server? and how original is this game? or is it just the union of many mods?

I say again, I want to create a game, I dream of making my game, but I can't by myself.

Where is the place where those who want to create a game meet and say:
I want to create a game:
rpg,
coop,
with experience,
trading,
quests,
and monsters (when they are ready engine side)
and other things.

who does this?

[ShadMOrdre]

TL;DR

In response to the above comments.

All the specifics regarding various gameplay attributes, functionality, or other issues are beyond the scope of this proposal. Town building, biomes, NPCs intelligently existing within the game world, these are all topics that are specific to the game being discussed, but are not as relevant in this discussion.

This is not to dismiss those opinions, but to keep the conversation on point.

Sokomine,

What I am trying to accomplish would actually make many of the issues you describe either moot, or more easily handled. How many mods replicate code to simple seperate the mod name from the node name? How many variations of that code exists? Which is the most efficient code? Is the code compatible with all other mods? Does the code silently override something, or redefine something, or otherwise affect how other mods interact with any given node? These are the types of issues I would like to address with this proposal.

What if all mods registered all items to a central "game" object? How much easier would it then be to simply find the nodes needed, manipulate those nodes as needed, and any other action that code would need to execute? Wouldn't it be easier to create mods and games if there were an actual standard, a base that is not MTG, that does not perpetuate the design issues related to the fact that MTG is really a dev tool more than a game?

I seriously question why there needs to be a bed API. Shouldn't the "sleep to skip night" or "sleep to heal" functionality be the actual API. Does MTG really need to provide an API for registering a new bed, when it lacks an API to manage nodes, or entities, or crafts, or ............

As for the trees lib example, I chose to not use it simply because I'd rather my PC process as little as possible to decrease lag and jitter. I instead opted to create lib_ecology. The trees schems exist as lua tables, load rather speedily, and are far easier to update in a text editor than trying to manipulate .mts files. There are currently over 50 types of unique tree definitons, and I have to ask....

Moretrees provides at most 10-12 trees, essentially spends most of its time generating biomes for mgv6, and just runs horribly. All for 10 - 12 trees.

lib_ecology uses the built in decoration code to spawn tree schems on ores that are used a base dirt for ecosystems. Biomes now have variety. Real variety. A single biome can contain numerous ecosystems, so walking in a desert isn't just sand and cactus anymore. You might be in a rocky, gravelly part of the desert where there is absolutely no life, or you might be near an oasis, surrounded by abundant desert life, but you are still in the same singly defined desert biome. One of several desert biomes defined, so this desert will look different to that desert, and the ecosystems within will be completely different.

Soon to be posted updates to lib_materials allow me to more easily find and identify those nodes that break the norm, or otherwise act in unexpected ways. No longer will my mods need to figure out which mod provides the node and which mod provides the functionality, and .....

I also agree that library type mods do not really find wide distribution. IMHO, this is solely due to mod authors not even providing an example. For the few library mods that I use, they came with content. The example mod. Enough to get me hacking. And enough new content to make downloading the mod desirable. Without that example mod, the library sits in code limbo, never finding use, never being investigated to find if there could be a use, and so on.

Some of these library mods are too useful to let slip through the cracks. Some need updating. Either way, there should be a resource, a singular source of libraries providing valuable code and functionality, well documented, and heavily encouraged by the mod community and the core team.

As such, I'd like to identify the absolute basics of what is required to create an MT game. I'm aware of the folder structure, but that is not what I seek. I refer to the player, the hud, and the world. Can I put a player in world, with not a single mod? If no, then what does that mod need to contain? And please, do not point me to minimal or default. I'd like to keep my sanity, and I've looked at them enough to know that what is being done, is not as complete a package as is should be.

Shad

[rubenwardy]

No centralized name management. This allows several mods to have the same name, creating confusion and leading to mistakes.

ContentDB does in a pragmatic way - ContentDB forbids mods from sharing the same name, unless they are a fork. Unfortunately, games are mostly exempt from this rule. Perhaps we should be strict about this with newer games, or require games to update to remain on CDB

[LMD]

I think we should just continue to develop high-quality mods which are configurable & expose a decent API.

[PolySaken]

I think we should just continue to develop high-quality mods which are configurable & expose a decent API.

...And then collect the best ones together into a single package for new devs to use. Good idea!
lol

[LMD]

Yeah, everbody OFC is free to create modpacks with them.

I, for one, think MTG mods are a decent base for creating games. They are overall very well-maintained, polished, and battle-tested.

[ShadMOrdre]

And that collection of battle tested mods is the actual base that I use, and am actively refactoring into the topic name.

PROPOSAL: Game Development Base.

A base of mods, battle tested, updated, and offered as a base upon which to write mods. But mods that are not hard coded to MTG, as most of those battletested mods are. Instead...

Mods that are written in such a way that they truly are modular. Want that mod. Get that mod. Dependencies are irrelevant.

See this post. It's essentially the same conversation.


Shad