Roadmap brainstorm (5.8+)

[Zughy]

It's been ca. 2 years since the first roadmap came into play. Considering that priorities could be different compared to two years ago, please list 3 things that you think should be prioritised in the medium-long term.

These are typically higher-level goals rather than individual features. The new roadmap will come into play with MT 5.8.

[Zughy]

My two cents:

UI Improvement

Although PRs like #12480 are heading in the right direction, I think a lot of work shall be done still when it comes down to chat and main menu (see #10372 for the former and #6733 for the latter). A bad UI/UX means a bad first impression, which means that people will be skeptical and more hard to convince

Different dimensions (#4428)

I can't stress enough how much of a game-changer this is. Right now people can't instantiate disposable worlds (e.g. dungeons, mini-games, events) and, for anyone who wants to create the illusion of different dimensions, they must stack them one on top of the other. Which I find very unpractical

Prioritise bugfixes

Right now there are 305 confirmed bugs. I know it's more thrilling to implement a new feature rather than to fix a bug, but I think that a clean desk makes working easier than a messy one. In these last months we've started gaining control of PRs (we used to have 150+ PRs, now we have 80) and issues (1100+, now less than 1000): if we can gain control of bugs too, I'm prone to think implementing new features will be a lot easier than it is now. And people will be in general less stressed, which is always a good thing ❤️ In short: crap first, then fun

[appgurueu]

Entity Performance Improvements

Entities are required for most interesting things in the game. Unfortunately, Minetest can only handle very few entities very well. Networking should be optimized to only send changes (for properties for example); the API should be optimized to allow getting/setting single properties efficiently. Spatial indexing should be used to speed up range- and raycast queries. Rendering should batch entities of the same visuals to reduce drawcalls.

Network Encryption

The conflict with performance is not really there, and encryption is a basic thing for (1) privacy and (2) security as admins might want to interface with the server without risking others hijacking their sessions.

(SS?)CSM

This carries over from the old roadmap. Modders need to be able to control client code to some extent. CSM capabilities must be vastly extended for this to be useful. A low-level 2d & 3d rendering access would be great; only then will we slowly approach being a game engine.

[cranezhou]

minetest game engine could be used for Education.
What is the latest status of framinetest ? (https://framinetest.org/en/)
Try to get the feedback from the teachers and the junior, senior and university students groups.
Then we may be able to find the users to drive the development team to move on their roadmap(s).

Good design, technical enhancement and user(ui) experience are very important.

Data Privacy (GDPR) and Users Login Agreement are also very important.
Is there a gap between the Commercial Products and Open Source Products ?

[Wuzzy2]

1. The focus should be on fixing bugs, preferably ancient bugs that are many years old. It WILL pay off in the long run. This is easier said then done so additionally I propose that a proper priotization system is established. Most bugs have NO priority assigned to them.
   Each bug could roughly be rated by severity, it is a rating that roughly describes how painful this bug is to players, users, modders, devs, etc. The severity levels must be defined by clearly determinable and reproducible criteria so it can be quickly assigned by reading the text alone (in most cases) and to avoid endless arguments whether a bug is of high or medium severity. The current label system of "high priority", "low priority" and "(no label)" is too vague and needs change. I propose the levels "critical", "very high", "high", "medium" and "low". Why two high priority levels? Because "high priority" is currently used for only the SUPER important things. Therefore, all the important but not SUPER important things drown in the ocean of unlabelled issued. The label for medium is added because this weird implication of "no label = medium" is very annoying.
   Another method to get the bug count down is to require a minimum of information of the reporter. If the bug reported is too vague, poorly written and the reporter does not reply after X days, just close the bug. It makes no sense to keep bad bug reports open forever because they MIGHT be true. Just close them, otherwise they just clog up the system

2. Define backwards-compability rules and take them seriously. In my opinion, I would like to see more strictness. Avoid breakage, even small ones, like the plague, EXCEPT for major releases in which it is allowed. A game written for 5.6.0 should still work perfectly in 5.10.0 without ANY additional work from the developer required. Minetest was pretty compatible in the past versions, but it was not perfect, so I like to see affirmation for strong backwards-compability. Also, breakage should really only be considered when all other possibilities have been exhausted. PRs should also be rejected on the basis of them breaking stuff for no good reason. Before a non-major release, all bugs labelled "Regression" must be fixed (if this rule is not already in place).

3. Main menu rework, both in terms of looks/graphics as well in usability because it is a visual abomination that looks like a tech demo

[rubenwardy]

Just a reminder that bugs are not subject to the roadmap, bug fixes are already prioritised and any related suggestions should be discussed elsewhere

Policies on breaking changes is also a process thing not a roadmap thing

[appgurueu]

@Wuzzy2 I believe the purpose of this issue is to determine which feature requests to prioritize for 5.8.

[ghost]

I believe the purpose of this issue is to determine which feature requests to prioritize for 5.8.

Err, Zughy also mentioned prioritizing bug fixes, but now that I read rubenwardy's post, fair enough complaining.

[cranezhou]

Sorry, my comment may be a little high level which caused the confusion.
By the way, personally I think the minecraft may also have a lot of lessons, which minetest could learn from.
Thank you very much for your understanding and support. 🙂

[oong819]

Optimize RAM Use
majority of Minetest's games crash when i load a world with it because of RAM overflow, the same thing happen on some big mod and too many mods installed, Minetest with me are not devices friendly, i have 1,5 GB RAM and can play similar game normally

More Beginner Friendly
when i start playing Minetest, i dont evem know how to fly and grant privs, i think Minetest should have a tutorial world for hard things like:
Commands
Controls
PICK UP CART ON MOBILE
Introducing Minetest Game and Content DB
..v..v..
Beginner is likely to only play MTG and think Minetest is a game not game engine

Children Friendly Features
to keep our babys brain clean, add things like:
Editable client side chat filter
Add "Family Friendly" certificate for server that are family friendly (probally need a strict rules for this)

[appgurueu]

majority of Minetest's games crash when i load a world with it because of RAM overflow, the same thing happen on some big mod and too many mods installed, Minetest with me are not devices friendly, i have 1,5 GB RAM and can play similar game normally

This sounds like (1) memory leaks in mods and/or (2) the LuaJIT 1GB memory limitation, both of which aren't really issues Minetest can fix (well, the latter can be fixed by using PUC Lua 5.1 or applying a certain patch to LuaJIT, both at the cost of performance)...

[oong819]

majority of Minetest's games crash when i load a world with it because of RAM overflow, the same thing happen on some big mod and too many mods installed, Minetest with me are not devices friendly, i have 1,5 GB RAM and can play similar game normally

This sounds like (1) memory leaks in mods and/or (2) the LuaJIT 1GB memory limitation, both of which aren't really issues Minetest can fix (well, the latter can be fixed by using PUC Lua 5.1 or applying a certain patch to LuaJIT, both at the cost of performance)...

i rather live with limited mods than device got piping hot

[AFCMS]

SSCSM

We really need this. Both as modder and game developer.

• Animated HUDs (without fulfilling the server's bandwidth with HUD_CHANGE packets)
• Client generated formspecs (fixing pandorabox inventory taking 5 seconds to update the crafting guide search)
• More fluid controls (W-tap sprinting, like in the mcl2 CSM)

Would improve server's performances and global user experience.

Should be really prioritized IMO.

CSM

CSM have only few use-cases at the moment.

You can definitely make great things, but it is still much less powerful than it should.

CSM would need exactly the same permissions SSM currently have on the host machine: access to insecure env, http API, filesystem, etc

What could be done by just giving CSM as many permissions as SSM:

• Discord RPC
• RGB Driver
• etc

#12398

Main Menu

Current main menu is really really ugly. Recently, a big (+1M) french youtuber made a video about minetest, and his first reaction when starting the game was "Its ugly".

Main menu have a BIG impact on how users see Minetest, its in fact the part of minetest you see the most often in your minetest journey.

It is kinda weird to see how beautiful the i3 mod is compared to the actual main menu...

[Desour]

Server-Sent-Client-Side-Modding (SSCSM)

We need this, e.g. for more dynamic visuals/audio and responsive game mechanics.

General Improvements

Changes that make minetest work significantly better than before in some regard. In other words, changes that resolve a problem that is not necessarily a bug, without creating new real problems by design.
This includes, e.g.:

• Graphics performance improvements.
• Better client startup performance (joining servers takes too long).
• Network encryption iff it works well.
• Much requested uncontroversial features, like tracker music support.

Internal Refactoring

This includes things such as dropping non-SDL drivers, getting rid of the BS factor, reducing the use of owning raw ptrs, and other things that do not affect gameplay.

[sfan5]

Dehardcoding

This describes taking an - often client-side graphical - feature that is fixed into the code and adding an API for it so it can be controlled from Lua, a simple example is #2139. Others would be the upcoming camera API, wieldhand animations, object death response and lots of subtle things that are currently client-side settings.
For this to happen efficiently the affected features should be collected in a list first, reading the source here can help spot a lot of harcoded things.

Performance and general improvements

This applies especially to graphics where often a "simple" shader-first rewrite could raise the performance from 'terribly bad' to 'blazing fast' (e.g. particles) but also applies to other parts of the code (e.g. SAO collision detection).
This section can also include "changes that resolve a problem that is not necessarily a bug, without creating new real problems by design" as @Desour put it. Though I would count code architecture improvements under here too.

<free spot>

dunno

[Wuzzy2]

I like dehardcoding a lot, the more is left up to mods, the better. Maybe even add a new label to mark issues/PRs about dehardcoding. I could help with adding the label to issues (once the label exists, I don't think I'm allowed to create labels).

And there is already a list of hardcoded features, you can find it at https://dev.minetest.net/List_of_hardcoded_features.

[TurkeyMcMac]

I don't have much of a roadmap myself, but I think increasing performance is a good goal, especially as someone without a powerful computer. For my part, there are several places in the backend where easy performance gains are possible. There is also rendering etc. which I haven't worked on but which I hear is ripe for performance improvement.

[HybridDog]

Graphics: Use spherical harmonics for shading

This shading method is described in the An Efficient Representation for Irradiance Environment Maps paper.
In minetest node sides are currently darkened in this ordering (from darkest to brightest): -Y < -X = X < -Z = Z < Y. Diffuse shading with spherical harmonics could be considered a generalisation of this directional shading to any normal vector (instead of only unit directions).

• Currently the sky has weird bands, looks like a cube, and the sky colours unexpectedly change when the player rotates the camera. The sky background could be replaced by or augmented with a shader which uses spherical harmonic functions as an implicitly defined environment map.
• The diffuse light of nodes in shadows could be calculated with spherical harmonic functions. Currently the nodes in shadows are simply darkened, which is unrealistic because the sky is blue and not grey. The colour should only be white if the yellow sun light mixes with the blue sky light, or if there is a grey cloudy sky. The method explained in the above-mentioned paper could be used to give the shadow a brightness and colour according to the surface normal vector, and the spherical harmonic coefficients from the sky background can be re-used (except that sky light must not come upwards from below for shading). The sun would be a simple directional yellowish light source.
• Currently in a cave, the darkening of node sides is the same at each position (if we ignore the separate darkening caused by param1 light values). It could be possible to calculate spherical harmonic coefficients for each vertex using the param1 values of the vertex's 8 neighbouring nodes (the 2x2x2 block) and interpolate these coefficients along the node surface when shading. I assume that the param1 values in a 2x2x2 block of nodes approximate the direction to the light source in the corresponding vertex. This approximation would be encoded in the spherical harmonic coefficients. In comparison to shadowed sun light, the spherical harmonic coefficients would be different in each fragment.
• Proper normal mapping could be added to Minetest if diffuse spherical harmonic shading is executed in the fragment shader and directions to light sources are approximated sufficiently well by the spherical harmonics.

Graphics and mapgen: Support stochastic texture sampling for tiles and mapgen noise

A simple and efficient algorithm is described in the High-Performance By-Example Noise using a Histogram-Preserving Blending Operator paper and some additional details in a technical chapter.

• If stochastic texture sampling is supported in tile definitions, it should be possible to create nodes whose texture does not tile and nonetheless looks like the input texture. This can be very useful for natural nodes such as grass and dirt.
• Stochastic texture sampling can also be used for texture-based mapgen. It may be possible to implement it in a mod, but the mod would need a PNG decoder and Minetest currently only offers a minetest.encode_png function and no decoding. In comparison to Perlin noise, the noise generated with stochastic texture sampling would look like the input texture (but does not repeat), so a user could draw a heightmap with custom details/patterns in an image editor and these details/patterns would then be visible and spread around in the generated map in Minetest. On the other hand, with Perlin noise, a user would need to implement desired patterns with potentially complicated code and a lot of trial-and-error.

Again

• Fix unexpected client-side node dis- and reappearing problems: Make dig and placement predictions more robust (issues 7602, 7098, minetest_game/2270) and fix the mapblock border x-ray problem (issue 5842)
• Implement SSCSM (Server-Sent Client-Side Mods) in a sufficiently secure way
• Support tab autocompletion in the terminal (issue 6450) and in-game with SSCSM (pull 5532)

[fluxionary]

i'm going to put a single suggestion here, as a request from a large number of players on the your-land server.

improve support for touch-screen (mobile) users.

computers w/ keyboards are becoming less common, and more and more people can only play the game on their phones or tablets. if we want the playerbase for this game to continue to grow, this is something that we cannot afford to ignore. i (unfortunately?) don't own such a device that can play this game, so i have to speak from anecdotes, but it seems that the touch/mobile experience is lacking in a lot of respects.

players complain that GUI scaling is terrible. scrolling various things is terrible. using modifier keys is terrible. here's some existing bug reports that i've just dug up, w/out fully understanding them:

• Android: Can't use sneak/aux while digging or punching
• Allow switching between touchscreen and other input on Desktop and Android
• Add API to get user input mechanisms (ie: touchscreen? gamepad? keyboard?)
• Android: bad GUI scalling / poor use of available touch screen
• this is just from one page, there are many more

as a mod writer, i wish i had a mechanism to even detect a player's display size and input capabilities, and react to that, but instead i just have to use formspec and pray that it'll be visible.

as i dislike writing any UI that isn't a programmatic API, this is not an issue i want to deal w/ myself. however, i feel it is incredibly important for the future of the game.

EDIT:

if i'm going to list 2 other important features that the game needs, it'd be SSCSM (for anyone mentioning UX, responsiveness is one dimension this game can be horrible about, and the only real solution to that is some sort of SSCSM. of course it needs to be secured), and then optimization of client-side handling of entities (i.e. having a few hundred signs in a single area shouldn't cause FPS to crater, particularly if the player can't actually see any of them).

[velartrill]

i'd personally like to see SSCSM entirely replace formspecs, and for the latter to be deprecated (possibly reimplemented as a wrapper around the notional new lua UI kit to avoid maintaining multiple GUI subsystems indefinitely). i recall seeing discussion/preliminary work being done on this a year or so ago but i don't know what became of that. formspec programming is just miserable, among the worst experiences i've ever had building interactive GUIs. storing cached formspecs as strings in node metadata is a particularly unpleasant pattern i would like to see the end of. (ive designed & implemented a handful of UI toolkits before so i have some suggestions on this topic, and would be happy to do some of the design & coding if others agree with me on this.)

but, i'd be happy just to see some level of SSCSM in 5.8. my UI suggestion might end up being a better fit for a later version, depending

[Wuzzy2]

As much as burning formspecs to the ground is a noble goal, this is not that simple. Tons of games and mods depend on this, so a complete removal means breaking almost all games and mods ever made. Nothing short of a hard fork will get you there. A full removal of formspecs is not going to happen.

[velartrill]

@Wuzzy2 which is why i never suggested such a thing. "deprecate" does not mean "excise"

[Zughy]

Since I can't vote for bugfixes, I'd say Android improvements as well, I 100% agree with @fluxionary .

Anyway, this is the summay for now (I've not counted @Desour second point, because it's actually more points: please pick one)

Proposal	votes
SSCSM	6
UI/UX improvement (esp. main menu)	5
Performance	4
Refactoring/dehardcoding	2
Android improvements	2
Different dimensions	1
Better entities	1
Network encryption	1
Minetest for education	1
GDPR compliance	1
Define backwards-compat. rules	1
Family friendly features	1
Rendering improvements	1

I invite the other core devs to express their points as well: @rubenwardy @celeron55 @v-rob @lhofhansl @x2048 @SmallJoker

[nerzhul]

My 50 cents, i put it in touch like every roadmap

• better enties, with more intelligent API to transfer actions from server to client. We should not have for example to run per movement code server side and set each movement to client, a jump should be a jump, a move from A to B if using the path finder should use path finder on client. Obviously with entity pos resync every 5 sec or something. This world is so boring because we don't have more high level API :) look at all those minecraft things (breaking, obviously, if a server uses it)
• Multiple maps, with different mapgen for example (breaking, obvisouly, if server has multiple layers
• Refactoring, clearly, those Server, (Local)Player, Game and Client classes are always too heavy, we should find better objects
• Performance, i agree, it should come from refactoring too. Maybe we can have measures on the code. C++ is less natively tooled than rust, golang and java unfortunately
• WASM moding ? (it's more a tought, not sure it's possible easily for our game with good security)

[ghost]

These are the three things I would like to see for 5.8:

• SSCSM
• Resource packs (Like texture packs, but can also change sounds, models, and even overwrite some code if the subgame allows it.)
• Light can be decided by subgames (MineClone 2, for instance, could have Minecraft-like lighting.)

[michieal]

My first Suggestion is the Revamped UI for Minetest.
My second suggestion is Tips during the loading screen.

[michieal]

Third Suggestion is Support for larger structures being spawned. That way, we can make something larger than a small building.

[fluxionary]

Third Suggestion is Support for larger structures being spawned. That way, we can make something larger than a small building.

that can already be done via schematics. how large were you thinking? you can manipulate dozens of mapblocks w/ worldedit w/out much issue, and hundreds if you're willing to wait a bit.

or were you thinking large procedurally generated structures? that's also quite possible already, though i don't think anyone's made a framework for generating such things easily. there's existing opensource code for minecraft that someone could use for inspiration if they want to design such a mod.

edit: fair warning, you might also have problems w/ #9357 depending on exactly how you try to load/generate things

[ghost]

My second suggestion is Tips during the loading screen.

#13058

[ghost]

As much as burning formspecs to the ground is a noble goal, this is not that simple. Tons of games and mods depend on this, so a complete removal means breaking almost all games and mods ever made. Nothing short of a hard fork will get you there. A full removal of formspecs is not going to happen.

An api for drawing to the screen like the love2d api Would be enough, then a formspec compatible implementation can be build ontop of this.
Alternatively this can simply like sidebyside with the current api. FOr my part I have my own lua UI toolkit i'd love to use for minetest but it really requires a more direct api like the one of garrys mod or the aformentioned love2d one.

The priorities I'd like for my gamemode to work better are mainly stuff that has been talked about above.

• Dehardcoding engine behaviour (like adding random inventory lists to the player, playing the red damage animation even if falldamage is 0 etc.)

• A direct api to draw to the HUD and to implement inventories etc. like mentioned above

• A way for gamemodes to more directly influence game settings in the scope of the game (Like item time to live) without affecting other games

(also different dimensions would be awesome to implement, I'd definetely make use of them. but you asked for three items so :)

[lhofhansl]

+1 on entity improvement:

• better attachment, without jitter or rubberbanding (two separate issues)
• better path prediction on client and server
• performance, especially collision detection with many entities
• proper player_pos when attached
• better camera control
• entity path apis
• etc

Entities (especially attachment) are so bad it's almost comical.

Also

• larger viewing distance... Needs client-server network rework (i think we in have driven the current architecture as far as we can)
• making sense of the various distance settings. It's very confusing to a new user.
• remove unneeded config config options, calculate them instead
• multi-threaded Lua map gen
• better graphics like reflective water and godrays

[Zughy]

Hear ye, hear ye!

After having talked about the roadmap in a couple of meetings, we've basically agreed to keep the roadmap as-is:

• Rendering/Graphics improvements (2 votes)
• Internal code refactoring (4 votes)
• UI Improvements (8 votes)
• Object and entity improvements (5 votes)

About the point with more votes (SSCSM, 9 votes), there seems to be the will to work on it (#13046 (comment)), but at the moment it's not considered as urgent as the rest.

Thank you everyone for your feedback and see you in a couple of releases!