Minetest Forums

https://www.youtube.com/watch?v=VpP8n0uuSjI
If and should Irrlicht become an issue, then these other open source game engines should give you another chance at glory. I favor Godot above the other ones. Just look at the massive potential that one has...

Godot does look pretty awesome! Calinou is actually one of the contributors to it.

However, the way it does things is incompatible to Minetest. It's a GUI-focused game engine, like Unity

i was playing with godot a few months ago, and made a testgame, but got tired of its messing programming (deleting a script file can also mess up the project even it is empty). but it's recommended to try, and always make backups, to not let mistakes ruin your projects.

the big pros with it is that you own the game you creating with it, not like unity or udk where you have to pay big amounts of money to use them commercially.

AiTechEye wrote:i was playing with godot a few months ago, and made a testgame, but got tired of its messing programming (deleting a script file can also mess up the project even it is empty).

I used to have trouble with that, but now I remember to do all deletions from inside the ide.

LOVE godot! It's great fun to develop with, though I still tend to use vim for most of my editing. Sadly, it revealed a major weakness in my game design strategy -- it does no good to have an awesome development platform if you can't think of any good games to make with it. : )

I have managed to piece together a neat little dungeon game, but I can't distribute it since I don't have the rights to the artwork I used. It's easy to find open code, it's a lot harder to find free art.

I think one of the next major pieces that MT needs is to expand on the ability of users to add new content dynamically in the game, and for that the engine needs to support loading new assets as the game is running. Right now this is a limitation of Minetest - it needs a server restart to add a texture, a model or anything else like that. Whatever next engine will replace the current core, it should allow fonts, textures, sounds and models to be dynamically added to the game as it is already running.

If godot can do that, well... maybe I'm interested, but any switch really needs to be an incremental evolution, and not just a small step ahead.

I think proper lighting an physics are more important than allowing to load new assets on runtime.

LinuxDirk, I think it's both. Your ideas and sofar's are essentially the same level of importance in my view.

Lack of dynamic lighting and dynamic assets arguably account for the two biggest shortcomings of Minetest that are holding it back from being a truly "killer-app" -- or at least relevant in the highly competitive field of 3D game engines. I say this as both a mod developer, a game designer, a server operator, and a player. If we had those two improvements alone, the possibilities would be unimaginable.

Very good. I see many posts here. What do you think of some of the other game engines talked about in that video? Let me list them:
Spring
Panda 3D
Xenko
Luxe

Linuxdirk wrote:I think proper lighting an physics are more important than allowing to load new assets on runtime.

That is important, but I wouldn't sacrifice the fact that MT can send assets to the client when it connects to the server. Then you're just making another MC with better lighting, and killing the one thing that makes MT what it is.

Note: I'm not sure if godot or other engines do this. I suppose they don't and leave it up to the game developers.

sofar wrote:I wouldn't sacrifice the fact that MT can send assets to the client when it connects to the server.

Of course. That’s THE main Feature of Minetest. I was more thinking of sending assets being sent to clients that were not loaded on server start and are added on runtime. Like new textures created in the client and uploaded to the server (for example a mod that adds banners without a bunch of entities needed).

This would be a nice addition but physics and lighting are even nicer.

There wasn't any stable release of Irrlicht for almost 3 years and keyboard handling in Irrlicht 1.8.4 is terrible. So I'd appreciate migrating to another engine.

Hume2 wrote:There wasn't any stable release of Irrlicht for almost 3 years and keyboard handling in Irrlicht 1.8.4 is terrible. So I'd appreciate migrating to another engine.

It's worse than that - the last irrlicht release which added any features was 2013 - 5 years ago

Wow, I knew Irrlicht was past its prime, but this is ridiculous. I have mad respect for the authors of the Irrlicht platform. It was obviously a major undertaking and groundbreaking achievement for FOSS. And of course it served as a catalyst for the development of Minetest. But I think it's best to move on, all nostalgia aside.

Time and time again we hear about technical obstacles imposed by Irrlicht, simply to bring Minetest up to speed with modern 3D gaming standards. For sake of example I was investigating how hard it would be to implement several new features to formspecs on the CPP side, and I found out that in every case it was overly complicated because of design limitations or shortcomings of Irrlicht :( If this is what's holding back progress, then it seems like it might be wisest to start researching and evaluating alternative platforms. i imagine with enough active contributors, a complete transition away from Irrlicht could theoretically be possible by Minetest 6.0.

sorcerykid wrote:Time and time again we hear about technical obstacles imposed by Irrlicht,

Heck! Irrlicht isn't even capable of properly accepting keyboard input. (Number block or every layout not basically being QWERTY).

sorcerykid wrote:a complete transition away from Irrlicht could theoretically be possible by Minetest 6.0.

Unfortunately this is VERY unlikely.

Isn’t it pretty clear at this point that Minetest will live and die with Irrlicht? On that note, instead of dreaming of engine switches, why not look to upgrade to the improved IrrlichtBAW fork instead?

Hypothetically - It would really suck if IrrlichtBAW perishes for the same reasons that Irrlicht dies.

For that very reason, It should be a well-supported decision with multiple people committing to doing the work (even if it takes a long time, obviously) so that there isn't any debate about the decision after the work is done whether it should be accepted or not (because some stuff will break, for sure).

My personal finger-in-the-wind says ogre3d, but, I know peanuts about 3d rendering engines. It appears OgreV2 however may pose problems for Android, though. Still it looks like the better platform with longevity.

Isn’t it pretty clear at this point that Minetest will live and die with Irrlicht?

I totally understand that it's unlikely core devs would have the incentive to transition to another platform, because so much of the code-base depends on the Irrlicht framework already. But at the same time, is it worth banking everything on a product that has 5+ year feature release cycles and is quickly becoming obsolete? That's a rather grim outlook, particulary since there are more viable open-source 3d engines available right now that are keeping much better pace with emerging, cutting-edge technologies.

Don't get me wrong, if there was some way to salvage the investment in Irrlicht (such as migrating to the BAW fork) that would be great. But I have to wonder if the writing is already on the wall for that entire project and its derivatives. Waiting it out, just to discover one day that Irrlicht is officially abandoned is a pretty risky move. Perhaps I'm just the sort of person that likes to always have a contingency plan or at least some type of backup insurance policy. What's the saying again -- don't put all your eggs in one basket? :)

texmex wrote:Isn’t it pretty clear at this point that Minetest will live and die with Irrlicht?

I honestly don't think that this is the case. I doubt that Minetest would die at all, for the very simple reason that Irrlicht effectively already is dead, and somehow MT lives on still. The thing that worries me is the increased strain it will cause for new features in MT that people are (rightfully) asking for.

Wasn't the goal once to create a "compatibility layer" between Minetest and whatever graphics engine will be used so the engine can be changed and all that has to be altered in Minetest is the part between Minetest and the engine?

So before changing the engine everything in Minetest directly related to the engine should be moved to said "layer". Then switching the engine should be easier.

Irrlicht is not dead. It's alive, as a zombie, but still alive. I've checked its webpage.

It's fast, so Minetest is fast. I love it. It's a vintage thing. Cool.

Migrate to another engine? Be realistic, Minetest has a lack of features long time requested, even under the current gloomy Irrlicht status. So it would be almost impossible a engine rework to another platform.

I bet to support Irrlicht, the base, solid, is still there. And to spend efforts to improve Minetest better than a migration.

Runs, I think the thing people are saying is that a lot of those long-requested features and long-standing bugs are down to Irrlicht, and there's little chance the situation will improve without moving to an engine that doesn't have Irrlicht's flaws and limitations.
A glance at the commit log suggests to me that it's basically a one-man project at this point, and it's more or less in maintenance mode, with no serious development going on.

Once again, I hear a lot of talk, but I don't see any code. If you want it to happen, make it happen. That's why we have free software.

I think it be best to stick with irrlicht. If worse comes to worse, we could in theory fork irrlicht. especially if at such a time we have a proper team of graphics devs.

Some may argue we should write our own graphics engine, or switch to another, but honestly, with the amount of work we'd need to do, we might as well just fork irrlicht.

IMO there's plenty of things minetest needs more than a graphical coat of paint:

- Server Sent CSMs will greatly improve performance for things like weather effects, where raindrop entities could be entirely Client-side, meaning the server end only needs to tell the client-side code to start the rain effects.

- A proper dynamic animation system would be a huge help for developers of mob frameworks, and even game developers who want say, PS1-style characters. even Minetest Game could use such a feature, so that both it and mods that affect the default player, could say, have the player model's arms hold a steering wheel when attached to a car.

- giving mods the ability to control the camera, both relative to the player and with fixed coordinates. this could allow many things. such as cut-scenes in games using predesigned maps, or even just being able to zoom the camera out when a player's model is larger than the usual 1x2 nodes. the latter could arguably happen even with the default game. i.e. the player is driving a car.

Overall, switching engine's now, when irrlicht is still quite usable for minetest, and taking into account features like Voxel Area Entities and Server Sent CSMs still not being here, i think it be a huge mistake to jump ship now.

thomasthespacefox wrote:Some may argue we should write our own graphics engine, or switch to another, but honestly, with the amount of work we'd need to do, we might as well just fork irrlicht.

But why keep beating a dead horse? Irrlicht development basically stopped. There are many smaller specialist engines available (and some top-notch commercial ones), the era of general purpose open source graphics engines is over.

Even if this will cause a metric shit-ton of work: writing an own engine is the route Minetest (that is a specialist engine already) should go. This means, re-inventing the wheel in some places, but eventually making Minetest into a full-featured voxel-based graphics engine would be the best thing. 100% control means 100% of the features the devs like can be added without being limited some outdated 3rd-party code. (UI, input, lighting, physics, animations, runtime content loading, etc.)