FOSS gamedev and creative worlds

As far as I understand Minetest should be an Open World Voxel Game Engine. But it looks like more like a game engine for Minecraft like games. A lot of things I would expect in the "game part" are hard coded in the engine.

For example the map generation is not necessarily part of a game. Also crafting, biomes and so on

Let's assume that I want to create a voxel based game that is not the millionth version of Minecraft, I don't need a procedural mapgen and no crafting. I don't want a menu where I can select server, mods, subgames or mapgens. The game should be stand alone.

I had to remove all the code I don't need. Wouldn't it be better to move game specific code to dynamic link libraries and drop them into a game folder? This would make it easier or even make it possible at all to use Minetest for more than Minecraft clones

Just some thoughts

If you are going to make specific "game part", you'll need special c++ programming skills anyway.
Be more specific in your questions and you get better answers.

It's not a question, just some thoughts how I understand the Minetest game "engine"

I agree, that there are a surprising number of hard-coded features in the Minetest engine that should be separated either into dynamically linked libraries or game-specific LUA mods. Just perusing through some of the source files like content_sao.cpp, mapgen.cpp, etc. it's abundantly clear that the engine is not as extensible nor scalable as it could be.

A lot of the things that are in the engine can also be done in lua, like mapgen, however doing so has a huge performance impact. You can make lua mapgens, but they're going to be very slow, for instance. Having them in the engine doesn't mean you can't do it in mods/games.

content_sao can't be done in lua, since it's protocol stuff to manipulate players and entities. You can control all the aspects of players and entities in lua, so this isn't a valid criticism. It would not make sense to mod the protocol in lua, since this would make clients incompatible with different servers.

Almost everything you list can be modded, perhaps everything. I think you're overthinking it.

And no, making everything a DLL isn't better either.

I don't talk about modding. I talk about hard coded functions that are not necessary for each game, but are hard to remove.

And to be honest, LuaJIT is fast, but trying to do everything in Lua is impossible.

sofar wrote:And no, making everything a DLL isn't better either.

Why? I can remove it if I don't need it or can replace it

burli wrote:

sofar wrote:And no, making everything a DLL isn't better either.

Why? I can remove it if I don't need it or can replace it

because of the problems of DLLs. Are you really complaining about the size of minetest download being 30mb? The DLL's aren't even the biggest part of that.

You can't just use the same DLLs for each version of minetest either, so you'll end up with having an untenable mess for maintainers and distributors. Of course, if you build minetest yourself, you can do this actually, a lot of optional functionality already is in DLLs.

Please re-read my post. At no point did I suggest that any specific features are better be implemented in LUA, nor did I even suggest that moving everything into a DLL is better. My point was that modular software is more scalable, more extensible, and easier to maintain. I was not suggesting interchangeability across different engine versions either, obviously.

Just for sake of a rudimentary example, let's say I want to change the ACTION text that appears in the debug log when a player is punched. Logically, this could (and even should) be accomplished in LUA, since that is how nearly all debug output is typically generated. But, not in this case. It is hard-coded into C++ source, thus requiring a complete re-build of the entire engine to override this single text string.



I cannot imagine how there there would be significant performance penalty by having this debug output within a LUA callback function (where it clearly belongs) rather than incorporated into a monolithic executable file. But I've seen stranger things in my life, so I guess anything is possible.

Indeed the engine is not as universal as some think, and some devs realise this.

paramat wrote:Indeed the engine is not as universal as some think, and some devs realise this.

That's the point. Minetest is an engine for Minecraft like games, not an universal voxel engine

sorcerykid wrote:Just for sake of a rudimentary example, let's say I want to change the ACTION text that appears in the debug log when a player is punched. Logically, this could (and even should) be accomplished in LUA, since that is how nearly all debug output is typically generated. But, not in this case. It is hard-coded into C++ source, thus requiring a complete re-build of the entire engine to override this single text string.

Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.

Code: Select all

                setHP(getHP() - result.damage);

                if (result.damage > 0) {
                        std::string punchername = puncher ? puncher->getDescription() : "nil";

                        actionstream << getDescription() << " punched by "
                                        << punchername << ", damage " << result.damage
                                        << " hp, health now " << getHP() << " hp" << std::endl;
                }

I cannot imagine how there there would be significant performance penalty by having this debug output within a LUA callback function (where it clearly belongs) rather than incorporated into a monolithic executable file. But I've seen stranger things in my life, so I guess anything is possible.

try an actual functional change as a good example what is wrong with the current model. The above example is really just a terrible choice.

Just because Minetest has features for Minecraft-like things (crafting, items, etc.) does not mean they should be removed. I would not advise to remove, let's say, support for inventories or crafting. Just don't use these features.

But yes, the “bias” towards Minecraft-like games is pretty obvious. But it's not surprising as Minetest started out as a clone of “InfiniMiner, Minecraft, and the like”.
If you look at the list of subgames (http://wiki.minetest.net/List_of_Subgames), you notice most subgames are sandboxes. Only the minority belong to different genres. But at least it shows that non-sandboxes are at least possible.

But yeah, some kinds of games are pretty hard to implement with Minetest right now: Any game in which you need predefined, static or mostly static worlds, as opposed to procedurally generated worlds. That is, games in which those worlds are an essential part of the game itself. The support for static or predefined worlds is very poor

This makes it hard to make adventures. This is mostly a main menu problem, I guess.
All you could do is building your adventure world and then distributing both subgame + world. This is basically what I did with earlier versions of my Tutorial subgame. If it would be a game, it could be seen as a mini “adventure”. However, this is just a giant hack: The player can't just restart the game, or have multiple save states, the player is stuck with a single world, and the only way to restart is to delete the world and download the original world again.

Jump'n'Runs would be a similar use case, but with a different challenge: In Jump'n'Runs, you often have multiple distinct levels which you often play in some order. This would translate to multiple worlds in Minetest. I hope you get the idea.

And of course, a world selection would barely make sense for an adventure game.



Interesting thread. Can you name some other concrete use cases which you think Minetest should enable (but they aren't possible right now)? Or name a concrete shortcoming of the Lua API, where it is dripping with “the Minecraft bias”. xD

sofar wrote:try an actual functional change as a good example what is wrong with the current model. The above example is really just a terrible choice.

If you prefer functional changes, take the mapgens which I think could certainly be adapted as shared libraries as they are technically an extension of the core engine. Improvements to the mapgens would no longer mandate building a new executable every single time (and vice-versa, of course), assuming the API is standardized. This allows for better compartmentalization of feature sets: rather than regarding the Minetest code-base as one gigantic monolith of a system, it is subdivided into a hierarchy of modular components.

While it might not seem like a problem worth addressing now, I can assure you that as MT continues to mature with each successive release, it is going to become increasingly burdensome to maintain the "do everything as one gigantic engine" software model.

sorcerykid wrote:If you prefer functional changes, take the mapgens which I think could certainly be adapted as shared libraries as they are technically an extension of the core engine. Improvements to the mapgens would no longer mandate building a new executable every single time (and vice-versa, of course), assuming the API is standardized. This allows for better compartmentalization of feature sets: rather than regarding the Minetest code-base as one gigantic monolith of a system, it is subdivided into a hierarchy of modular components.

While it might not seem like a problem worth addressing now, I can assure you that as MT continues to mature with each successive release, it is going to become increasingly burdensome to maintain the "do everything as one gigantic engine" software model.

But a dynamic library model as such only makes sense if the library is going to get used by many binaries, and it comes at a cost: (1) extra dynamic link time, (2) the requirement to use a very strict API, just to name the two most important options. Also, creating dynamic libraries requires extra work to make portable.

In reality, mapgens are only ever going to get used by minetestserver. The cost you are asking for just isn't worth it. The current model allows a flexible API that can change when needed, and only focuses on maintaining the Lua API, and allows C++ mapgen rewrites as often as needed.

And this goes for a lot of components that are part of the C++ engine. That's why there is no C++ API for minetest. That's why it's an engine with a Lua API only. That API supports all the things everyone is asking for, and hides the nitty gritty bits so they can change without repercussion.

I agree dynamic libraries have benefits, I've used many in the C projects I've worked on, and created a few myself - they serve an important function in the OSS ecosystem. But unless you're making something with a stable API that has 2 (binary program) users from a different source tree, it's unlikely that you're doing yourself a favor.

As for the current model not going to be maintainable forward: That is a valid concern, and the engine devs are well aware of it. I think everyone tries to make sure we don't add large new code blocks for no reason, and it's a fair assumption that the engine isn't going to take on whole new large blocks of code. Most of the changes I see coming by are small incremental features, fixes and the occasional cleanup to make things more maintainable.

Wuzzy wrote:Interesting thread. Can you name some other concrete use cases which you think Minetest should enable (but they aren't possible right now)?

I don't talk about specific games or genres. What I mean is, that it is difficult to use the Minetest Engine as an "engine". Of course I can modify the source code, remove what I don't need, add what I want, but if I want to upgrade the engine to a newer version I'm screwed.

I don't know, but I guess that the devs don't need to modify the Irrlicht code again and again if they make an update. They might have to modify the Minetest code to adapt the changes from the engine, but I'm sure they don't have to touch the engine code itself.

maybe compiler flags to disable parts of the code would be helpful.

After much lurking, and seeing many frustrating threads like this complaining about Minetest's shortcomings, I've come to the conclusion that no amount of improvements to the modding API could possibly make Minetest better. There needs to be improvement on the content creation side: more people who are willing to work inside of the limitations of the current Minetest modding API.

Why? Because modding Minetest is easier, more fun, and more likely to produce a tangible final product that can guide further Minetest development. Meanwhile, half-baked, unimplemented coding ideas for the Minetest engine like "make it possible to get rid of the main menu" or "refactor mapgen into dlls" are likely to end up being examples of Future Coding.

There are also many other things people can contribute besides code which will all help to make Minetest more fun: graphics, music, sound, building, writing, and so on. After all, isn't the end goal of all of this to make Minetest as a whole more fun? Not just to create a game engine?

Fixing bugs, exploits, and idiosyncrasies is always nice, because they improve existing Minetest experiences. Certain ambitious ideas like client-side scripting are widely desired, but will take a long time to implement, and very few of us have the expertise for that kind of stuff.

For those of you who are interested in Minetest modding, I encourage looking to the Minecraft modding community to see how they have used Minecraft as a game engine on which to create their own "games." I highly recommend one of direwolf20's modded let's play series.

If you're interested in non-sandbox subgames in particular, consider doing some research into Minecraft minigames which are popular on servers like Hypixel, or perhaps check out the maps section of minecraftforum.net and look for playthroughs. I can't recommend any from personal experience, but I assure you there's a lot of them.

asanetargoss wrote:After much lurking, and seeing many frustrating threads like this complaining about Minetest's shortcomings, I've come to the conclusion that no amount of improvements to the modding API could possibly make Minetest better.

I come to the conclusion, that the modding API lacks of lot of features. As I mentioned before in another thread a lot of good modders left the community because they can't realize their mods

I want to make survival harder by adding heat and cold damage, but all I can do is checking if I walk on snow, grass or sand. It may work for snow and ice, but on sand or grass I can only guess if it is a hot or cold region. I also have no idea if I swim in tropical or arctic water. And if a mod adds new ground nodes I'm totally screwed.

It is also nearly impossible to make a good mapgen. Of course I can write one in Lua, but because of worse performance and memory issues it doesn't make sense for a real game. I had to fork Minetest and add my own C++ mapgen or I need to hope that the core devs add my mapgen to the core. It is not possible to add high performance mods in an easy way.

asanetargoss wrote:There needs to be improvement on the content creation side: more people who are willing to work inside of the limitations of the current Minetest modding API.

I want to create content, but I can't create the content I would like. There are to many limitations

burli wrote:I come to the conclusion, that the modding API lacks of lot of features. As I mentioned before in another thread a lot of good modders left the community because they can't realize their mods

I want to make survival harder by adding heat and cold damage, but all I can do is checking if I walk on snow, grass or sand. It may work for snow and ice, but on sand or grass I can only guess if it is a hot or cold region. I also have no idea if I swim in tropical or arctic water. And if a mod adds new ground nodes I'm totally screwed.

It is also nearly impossible to make a good mapgen. Of course I can write one in Lua, but because of worse performance and memory issues it doesn't make sense for a real game. I had to fork Minetest and add my own C++ mapgen or I need to hope that the core devs add my mapgen to the core. It is not possible to add high performance mods in an easy way.

I want to create content, but I can't create the content I would like. There are to many limitations

Well, if you have sufficient C++ experience to make your own mapgen, then all the better for you!

But here's the thing: no matter what feature gets added to core, it's not helpful unless somebody uses it. Preferably more than one somebody. Modders leave the community because they can't realize what they want to realize, but the problem is they want different things and yet don't have the time or the power to change core to suit their needs.

Rather than just create a mapgen that suits your needs, ask what other modders want in a mapgen, and expose those features to Lua so those modders don't have to write their own mapgen. I can't imagine such a mapgen not being added to core.

A Minetest function for getting the temperature and humidity would certainly be useful, but perhaps not worth writing an entirely new mapgen for. But if you were to add other things that the worldgen simply lacks at a fundamental level, that would be different. I could imagine a few: a new biome system that isn't confined to a voronoi diagram, lua hooks for getting the biome at a position, a way to register biome parameters other than temperature and humidity with their own distribution, or ways to control or modify terrain in an abstract way.

But remember it's just an API; it's how you use it that makes a difference. Minetest will always have limitations.

Do minetest.get_heat(pos) and minetest.get_humidity(pos) not work?

zing269 wrote:Do minetest.get_heat(pos) and minetest.get_humidity(pos) not work?

No, removed a few versions ago