Minetest is not and likely never will be a game engine

[PolySaken]

What's the key idea that comes to mind when you hear 'a game engine is the part of a videogame that manages separate game-related APIs'?
Is it 'manages'?
Or even 'game-related API'?
Nope.
It's 'part of a videogame'.
And what is minetest? Currently, it's a graphical application that runs scripts using a game engine. The existing game (minetest, not mtg) has to be manually separated from the engine if one wants to use MT as a real game engine, i.e. part of a finished game that manages everything behind the scenes, rather than an app that allows adding content to an existing game.
And when I say "existing game" I mean minetest the 'engine' not minetest_game. It might not have much content, but the things it does have (built in hotbar, life,breath,wielditem, movement system,even the crosshair) are all things that are game-specific, and put it squarely on the game side of the equation.
This to me means that 'games' for minetest are like minecraft minigames. They exist as a facet of an existing game, and so cannot truly be games on their own.

This issue could be solved by packaging minetest as a lua engine in the style of love2d, and keeping the client as an aside, but I personally doubt that will ever happen. I love minetest as a game, and have given up on the Idea of it being an engine. For this reason I lack the patience to fork it and enginify it. I'm content to use it as a game with many 'world styles' e.g. subgames, but I'll never attempt to make a true game with it.
I use godot or love2d for that, and you should too. But don't criticize MT for missing the point of being an engine like I used to (and did for the last time in this post). Love it for being a funky little game with endless customizability.

[philipbenr]

What's the key idea that comes to mind when you hear 'a game engine is the part of a videogame that manages separate game-related APIs'?
...
It's 'part of a videogame'.

No its not, please don't start your post off with a leading question. That's a way to get people mad at you for trying to put words in their mouth to build your argument. Say what you think, don't speak for me.
I truly do think of "manages separate, game-related APIs" (I would have probably just generalized to "things" instead of APIs, but whatever)

And what is minetest? Currently, it's a graphical application that runs scripts using a game engine. ...an app that allows adding content to an existing game.

I agree. I think Minetest (not minetest_game) as it currently stands isn't quite an engine but also isn't quite a game. It is currently a sandbox. And to its own end, it does a good job of that in every respect. But this is also why I have voiced support for separating the current paradigm, where Minetest has a baked in launcher as the "main menu", into a base "Minetest engine" and "Minetest Game Client", as it would clear up the distinction, as well as bring an opportunity for more QoL changes.

It might not have much content, but the things it does have... put it squarely on the game side of the equation.

I disagree. I think that the fact that its trying to act as a game engine necessitates those having features, and doesn't outright making it a game. As a "modder" or game-creator, you do not have to take advantage of those features, and can use whatever you want. But for the people that want to create a game that uses them, having those prebuilt features are helpful.

They exist as a facet of an existing game, and so cannot truly be games on their own.

You wouldn't call games made with Unity "Unity minigames" would you? There are quite a few games that use Unity and I would consider all of them games of their own. I don't see the distinction you are trying to draw against Minetest, aside from the definitions above, which I also don't agree with. I think that the playstyle that many of the Minetest games that have been created all go for some unique twist on playing with voxels and can be thought of as games.

This issue could be solved by packaging minetest as a lua engine and keeping the client as an aside

As I laid out above, I agree with that. But I think that even though this is not how things are, the blurred lines do not make Minetest not an engine (that was hard to word properly...).

And in the end, I think this conversation is fairly useless if it is just to definitively label Minetest as a game or as an engine. I don't really care about what Minetest is called. I recognize what Minetest's potential is and like to work from there. But if I had to give it a label, I would instead propose "sandbox" as a more appropriate label.

[The32bitguy]

I mean minetest the 'engine' not minetest_game. It might not have much content, but the things it does have (built in hotbar, life,breath,wielditem, movement system,even the crosshair) are all things that are game-specific, and put it squarely on the game side of the equation.
This to me means that 'games' for minetest are like minecraft minigames. They exist as a facet of an existing game, and so cannot truly be games on their own.

It is not hard to remove most of those elements if one has spent some time with the API. There are examples of the hotbar, health and wielditem being changed.

Hotbar:
https://github.com/GreenXenith/visualbar
https://github.com/GreenXenith/oddbar

wielditem:
https://content.minetest.net/packages/Z ... n_shooter/

Life can be manipulated through `minetest.register_on_player_hpchange()`

NodeCore has also reworked most of those elements such as breath.

[The32bitguy]

I mean minetest the 'engine' not minetest_game. It might not have much content, but the things it does have (built in hotbar, life,breath,wielditem, movement system,even the crosshair) are all things that are game-specific, and put it squarely on the game side of the equation.
This to me means that 'games' for minetest are like minecraft minigames. They exist as a facet of an existing game, and so cannot truly be games on their own.

It is not hard to remove most of those elements if one has spent some time with the API. There are examples of the hotbar, health and wielditem being changed.

Hotbar:
https://github.com/GreenXenith/visualbar
https://github.com/GreenXenith/oddbar

wielditem:
https://content.minetest.net/packages/Z ... n_shooter/

Life can be manipulated through `minetest.register_on_player_hpchange()`

NodeCore has also reworked most of those elements such as breath.

[LMD]

This to me means that 'games' for minetest are like minecraft minigames. They exist as a facet of an existing game, and so cannot truly be games on their own.

No. Minetest has some very game-specific parts, which we modders often encounter as we implement nonstandard games. That comparison is way too extreme though.

This issue could be solved by packaging minetest as a lua engine in the style of love2d, and keeping the client as an aside, but I personally doubt that will ever happen. I love minetest as a game, and have given up on the Idea of it being an engine. For this reason I lack the patience to fork it and enginify it. I'm content to use it as a game with many 'world styles' e.g. subgames, but I'll never attempt to make a true game with it.
I use godot or love2d for that, and you should too. But don't criticize MT for missing the point of being an engine like I used to (and did for the last time in this post). Love it for being a funky little game with endless customizability.

This ultimately depends on your definition of "engine". Wikipedia for instance says:

A game engine, also known as a game architecture, game framework or gameframe, is a software-development environment designed for people to build video games

According to this definition, Minetest can undoubtely be considered an engine - there is no fundamental difference between a standalone executable and a Minetest (sub)game, other than the used environment being different (Minetest vs. OS).

Every game engine only allows for a certain level of abstraction; this one [Minetest] is particularly specific. IMO the customizability is enough for MT to be considered an engine and not a game, despite it not being a library to be depended on by your client/server scripts. Personally I like having a single client and a moddable server implementation.

[PolySaken]

You wouldn't call games made with Unity "Unity minigames" would you? There are quite a few games that use Unity and I would consider all of them games of their own. I don't see the distinction you are trying to draw against Minetest, aside from the definitions above, which I also don't agree with.

The difference being that unity has no built-in game mechanics or content. The only thing minetest lacks in terms of game content is more defined nodes and items.

[PolySaken]

The purpose of this topic is to push the Idea that minetest doesn't need to work for more than one type of game, and should focus on providing the best tools for that one type. It's not about the definition of 'engine' vs 'game'.

[goats]

Big generic game engines aren't the only engines which exist. E.g. Rockstar built game engines in-house which run certain types of games (like some GTAs), but can't just be generalized into make-any-kind-of-game-you-want-on-it. Loads of games have been built this way, with the engine reused for similar games. And these have almost zero separation between engine and game even programmatically, never mind from a user or outside developer perspective.

So no, Minetest doesn't have to work for more than one type of game (with the caveat that it clearly does to an extent, given some of the games which have existed for Minetest). Maybe you could have chosen a different title and initial argument more clearly expressing "The purpose of this topic is to push the Idea that minetest doesn't need to work for more than one type of game" if seeking to avoid a conversation at cross-purposes with the intent. Although... i am so far unaware of anyone making the argument that it should be a generic all-purpose engine.

You are clearly both intelligent and knowledgeable. You easily could have led that first post with the content of your last post. :D

[The32bitguy]

The purpose of this topic is to push the Idea that minetest doesn't need to work for more than one type of game, and should focus on providing the best tools for that one type. It's not about the definition of 'engine' vs 'game'.

What is that type exactly?

[philipbenr]

You wouldn't call games made with Unity "Unity minigames" would you? There are quite a few games that use Unity and I would consider all of them games of their own. I don't see the distinction you are trying to draw against Minetest, aside from the definitions above, which I also don't agree with.

The difference being that unity has no built-in game mechanics or content. The only thing minetest lacks in terms of game content is more defined nodes and items.

The way I see it, both Unity and Minetest are used for making a game. Unity gives you ways to make models, meshes, etc. to make your in-game content. Minetest gives you the abilities to make voxels, models, etc. and the minetest_game uses this and makes the voxels/models many people know as Minetest (or rip -off Minecraft if you so please). The paradigm is the same, even if the specificity and target final product at which they do it is different.

The purpose of this topic is to push the Idea that minetest doesn't need to work for more than one type of game, and should focus on providing the best tools for that one type. It's not about the definition of 'engine' vs 'game'.

That is painfully unclear in the OP, as I still don't get where you are getting the idea that Minetest was pushing for more than one game type in the first place, (hence my jump to thinking this was about labels). I think that Minetest largely caters towards sandbox style games, with options for creators to go out of their way to make other things. And since it is an open source project, people should be able to contribute to it what they want. Minetest is a melting pot of ideas, not really a focused project with an end goal from what I can see. So if someone wants to make a directed game with a goal, let them contribute to make that a reality.

Basically, let people do what they want to do with the engine. There is a large enough userbase, with enough programming competency to decide what they want in the engine and what they don't want. And it appears they are just going to continue with the voxel sandbox paradigm. If you don't like that (which it makes no sense why you wouldn't considering you are this active on the forums), go use the engines or libraries you mentioned to make your own version.

[sorcerykid]

The purpose of this topic is to push the Idea that minetest doesn't need to work for more than one type of game, and should focus on providing the best tools for that one type.

From what I understand Minetest is first and foremost an open-world voxel game engine which provides a robust framework for modularized scripted game development. And in that respect, it accomplishes its intended purposes remarkably well.

My virtual nightclub game, for example, is so far removed from what Minetest was originally envisioned to be used for (i.e. strictly sandbox survival and creative gameplay inspired by Minecraft), that I'm thankful that in its current incarnation the engine affords customizability sufficient for a variety of innovative game designs. Personally, I see this as a strength rather than a weakness.

[Minsc]

Some quick thoughts (which turn into longer).

- I made a post in a topic yesterday mentioning how Minetest could be rebranded to more accurately reflect to new people it's a voxel game engine and not Minecraft. This is based on what I've read about MT over the past year and a half. I admit I did not reread much discussion on the topic and it's been well over nine months since I've done so.

- I come from an average MineCraft background and have made the attempt to manage a server and install mods. I would not call myself a coder as I have not gone beyond changing some values and copy/pasting some code.

- This morning I took a closer look at the main menu of MT. The wording is to install a game and select a world for said game. The minetest.net homepage literally says "An open source voxel game engine." as the first line of the description. These are the things I base calling MT a game engine on. I fully understand people can have different views as to what a game engine is.

- The Build Engine which made games like Duke Nukem 3D comes to mind. In it a person will lay out different points to be joined which creates a sector. This sector can be raised, lowered, angled, etc. to create a game environment. Enemies can be placed, sectors can be manipulated to create things like doors which can be opened/closed and scripted events can be created to make big changes to the environment through some sort of of logic process (I do not remember the terms of magic things which make it all happen.)

Looking at the popular MineCraft a person can easily call it a voxel game engine of sorts. All the building blocks for making a game are there via the placement of blocks, redstone logic and command blocks. From my limited understanding there are big limits to how much a person can stray from the MC core.

Minetest, from what I understand, does not have these limits (obviously it has the limit of not being a polygon 3E engine) and is specifically designed to be highly customizable. Since I'm not a developer I can only parrot what I've read on the main page or what developers themselves have said.

As an average person (who played MineCraft), I am reasonably convinced to call Minetest a voxel game engine. The biggest knock I can see to MT is it lacks the front end GUI polish the average person would look for.

My two toonies.

---

The purpose of this topic is to push the Idea that minetest doesn't need to work for more than one type of game, and should focus on providing the best tools for that one type.

From what I understand Minetest is first and foremost an open-world voxel game engine which provides a robust framework for modularized scripted game development. And in that respect, it accomplishes its intended purposes remarkably well.

My virtual nightclub game, for example, is so far removed from what Minetest was originally envisioned to be used for (i.e. strictly sandbox survival and creative gameplay inspired by Minecraft), that I'm thankful that in its current incarnation the engine affords customizability sufficient for a variety of innovative game designs. Personally, I see this as a strength rather than a weakness.

I'll have to check out this virtual nightclub game to see how it strays away from Minecraft.

[rubenwardy]

The difference being that unity has no built-in game mechanics or content. The only thing minetest lacks in terms of game content is more defined nodes and items.

There are different types of game engine. Unity is a general-purpose game engine. Minetest is a specific-purpose game engine, and that's fine

[emperor_genshin]

I'll say this again.

Minetest is considered to be a game engine despite relying on a specific game engine like Irrlicht because it welcomes the creations of community custom made games which necessarily doesn't mean that you have to stick to default mod soup to make a full game, only lazy peple do that.

You can write your own game, rules and logic without the need of default MTG stuff. If that's not how a game engine suppose to be treated then I don't know what it is.

[rubenwardy]

a specific game engine like Irrlicht

To be pedantic - Irrlicht isn't a game engine, it's a 3d rendering library. It doesn't even have support for sound

[runs]

The difference being that unity has no built-in game mechanics or content. The only thing minetest lacks in terms of game content is more defined nodes and items.

There are different types of game engine. Unity is a general-purpose game engine. Minetest is a specific-purpose game engine, and that's fine

Polysaken and you get the point. Minetest is a SPECIFIC ENGINE. And that's the problem sometimes.

And sometimes developers don't understand that.

To give an example, if Minetest is to make voxel games, there must be a function that allows me to make only square nodes (minetest.register_node). Some developers would say no, that function should not exist, Minetest is an engine, there should not be such a specific function. When in fact in this case a compromise solution has been adopted, by default the nodes are square, but other solutions are supported.

The problem is to seek compromise. There are some specific characteristics that should be integrated in the engine and not in the lua-mod part. If your purpose is not general it is inevitable.

[philipbenr]

Polysaken and you get the point. Minetest is a SPECIFIC ENGINE. And that's the problem sometimes.

And sometimes developers don't understand that.

To give an example, if Minetest is to make voxel games, there must be a function that allows me to make only square nodes (minetest.register_node). Some developers would say no, that function should not exist, Minetest is an engine, there should not be such a specific function. When in fact in this case a compromise solution has been adopted, by default the nodes are square, but other solutions are supported.

The problem is to seek compromise. There are some specific characteristics that should be integrated in the engine and not in the lua-mod part. If your purpose is not general it is inevitable.

I don't see what the problem with having a specific engine is. There is an audience that wishes to design games that have specific features in the Minetest engine. The developers sometimes have all the time, ability, desire, and patience needed to implement it. (I'm not going down the road of flame-the-developers, so I will leave this above point as it is. Other topics from the past are better suited for that discussion, not this one, so I would ask that you do not try and argue it here.) And largely as a result, the Minetest community gets the features in the engine, allowing them to make the content they have.

Maybe what I am missing is in your last statement, as I don't understand it either.

[cuthbertdoublebarrel]

Polysaken and you get the point. Minetest is a SPECIFIC ENGINE. And that's the problem sometimes.

A dedicated engine designed for a specific "type" of game ?
Or a universal engine capable of creating all types of games ?
set up a vote for yay or nay runs lets sort this once and for all .
whoever has the least votes split .

[runs]

Polysaken and you get the point. Minetest is a SPECIFIC ENGINE. And that's the problem sometimes.

A dedicated engine designed for a specific "type" of game ?
Or a universal engine capable of creating all types of games ?
set up a vote for yay or nay runs lets sort this once and for all .
whoever has the least votes split .

It doesn't matter what it is. The important thing is to look to the future.

Minetest is cool, ContentDb is wonderful as a mod manager. But people don't believe it. They are self-conscious. They must get out of that pit to progress.

[emperor_genshin]

Here's what you don't seem to understand runs.

You can make your own game without the need to use MTG, the option is there (look at warr1024 and jordach's current projects).
Minetest has no backstory to even be considered a full specific game, at the moment it's treated as a open-source sandbox canvas for content creators. and MTG seems like a blank canvas when you look at it closely.
A core API is there for a reason. to make lives easier for those that wants to make a game (kind of like how Roblox handle their crap).

Like ruben specified, Irrlicht is not a full game engine since it handles graphics only.

Im not saying that mod soup is bad, but it's a thing that has been heavily done and practiced. Most minetest games currently rely on certain mods, and that's completely up to the user using this software.

Tbh no matter what you think. minetest screams "Canvas", which is what a game engine suppose to be.

[v-rob]

Minetest is about:

• Messing around
• Being able to do crappy but interesting stuff which nevertheless is enjoyed by other people
• Not taking anything seriously
• Doing this in a voxel-based multiplayer sandbox game.

c55.me/blog/?p=1491

Honestly, I don't see why it matters whether Minetest is a game or an engine or neither or both. In reality, it's a giant mess of C++ code that does 3D stuff with cubes and moving objects that can have its behaviour changed with Lua code which is conducive to making 3D sandbox games, better known as Minetest.

I mean, it's not wrong to want Minetest to be more general, e.g. removing/making optional the default health and damage system, because it's easier to mess around when there's less stuff built in. Moving towards allowing more stuff to be done in Lua is admirable. But in the meantime, why does it really matter exactly what Minetest is? Use what potential it currently offers, and also work on it to make it offer more potential.

[cuthbertdoublebarrel]

Polysaken and you get the point. Minetest is a SPECIFIC ENGINE. And that's the problem sometimes.

A dedicated engine designed for a specific "type" of game ?
Or a universal engine capable of creating all types of games ?
set up a vote for yay or nay runs lets sort this once and for all .
whoever has the least votes split .

It doesn't matter what it is. The important thing is to look to the future.

Minetest is cool, ContentDb is wonderful as a mod manager

no its a totally crap mod manager take a look at a proper frontend launcher .
https://forum.zdoom.org/viewtopic.php?f=44&t=36410

[LMD]

Honestly, I don't see why it matters whether Minetest is a game or an engine or neither or both. In reality, it's a giant mess of C++ code that does 3D stuff with cubes and moving objects that can have its behaviour changed with Lua code which is conducive to making 3D sandbox games, better known as Minetest.

Magnificient. The only accurate description I've read so far.

[CalebJ]

But in the meantime, why does it really matter exactly what Minetest is? Use what potential it currently offers, and also work on it to make it offer more potential.

precisely! ^

[Termos]

A game engine, also known as a game architecture, game framework or gameframe, is a software-development environment designed for people to build video games

According to this definition, Minetest can undoubtely be considered an engine

The key here is "designed to build video games", so providing game building environment has to be the primary focus - not the case here. MT implements all the basic specific game mechanics and some of them can be bypassed, others nor so much, Suggestions of ditching those mechanics in favor of providing the means of implementing any mechanics by the users are often turned down by the staff on the basis that could upset the players.
Engines don't have players, games do.

Initially Minetest was clearly designed as a clone of another game, only somewhat more moddable. Yes, since some time ago there have been declarations of the intention to turn it into an engine, but little has been done about it, and if you ask me achieving such a goal isn't possible within this particular project.