Minetest: Roadmap Brainstorm

[rubenwardy]

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 purpose of this is to produce a document to communicate to contributors what certain things are more likely to be accepted, as they're wanted sooner. It's in no means a strict roadmap.

[rubenwardy]

• UI improvements - formspec refactoring and replacement, main menu redesign.
• Internal code refactoring - to increase maintainability and stability, remove code rot.
• Rendering improvements - z-ordering, glitches.

[SmallJoker]

Bug fixes & internal cleanup

• "SerializationStream", replacement for NetworkPacket and direct iostream read/write functions
• Settings hierarchy cleanup -> clear structure to replace nasty "default" fallbacks
• Unify common PlayerSAO/LuaEntitySAO/GenericCAO functions, get rid of UnitSAO

[sfan5]

(these are mostly short-term)

• Solving issue 10342
• Implementing sticky collision (alternative solution to approach from issue 9978)
• Optimizing rendering of nodeboxes (redundant bottom face, internal faces, ...)

[rubenwardy]

I fear that the things you listed may be a bit too specific and technical, but some meaning can be derived from them I guess. I've not done this before. There's probably a balance between being too specific and not specific enough

[sfan5]

If I could think of less specific goals I would have listed those instead.

[lhofhansl]

• Better shader graphics (reflective water, shadows, lighting, etc)
• Better ways to ship content (not just games, but also maps)
• Make readonly worlds and world overrides better

[v-rob]

• UI Improvements - formspec replacement (I think a rewrite is better than a refactor) and possible HUD + GUI merging
• Internal code refactoring - we've got some ugly code, #10419 was an attempt (although it appears like it caused some problems)
• Rendering problems - like translucency sorting, z fighting, and suchlike (I know nothing about how to work with this stuff myself, but seems important to me)

In other words, basically what rubenwardy wrote :)

[Andrey2470T]

My ideas:

• Formspec Replacement and Main Menu Redesign (the highest priority IMO)
• Add Help page #9942
• Dynamic environment shading, mirror reflections and more natural lighting

[HybridDog]

Here is my mustard:

• 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)
• Support tab autocompletion in the terminal (issue 6450) and in-game with SSCSM (pull 5532)

[Kezii]

I see a lot of odd or extremely specific things

• Visual design and user experience

  Problem: Minetest looks like a game thrown together in a couple of hours with opengl and glut, there is not a defined visual style, there some inconsistencies, some outright wrong decisions regarding visual ergonomics and readability. There is not a lot of thought put on making things look decent, we are lucky if something is just ugly and not outright annoying to use (for example: hard to read chat with a bland color, hard to see crosshair with poor contrast, hard to see and poorly designed nickname labels, the unintuitive register and login UI)
  The options provided in the menu UI are very limited.
  This is pushing people away from the game before they even connect to a server, I have received direct feedback about this from users.
  Proposed solution: take advice from what other games do, and try to achieve something better than the absolute bare minimum when dealing with UI elements (I'm citing again the chat situation, whose changes got some resistance, it simply looks bad to the point of being useless). The game should not look like a tech demo from 2002.
  I'd like to see focus in changing all of the things that were probably made years ago by some coders in a couple hours by splashing text or UI elements on the screen giving zero thoughts about user experience.

• Learn from others

  Commercial games spend a huge amount of resources on making things look good, consider that advice, this is what players expect and the result is often the best result.
  Minecraft is the biggest reason Minetest is relevant, provide a decent migration path from Minecraft to Minetest, Minecraft does some things wrong but a lot of things right, take note of those and focus on them all, this is what player are familiar with and expect from a quality voxel game. Do not ignore minecraft, it's outright stupid to be completely unfamiliar with your biggest (if not only) competitor.

• Increase momentum

  Minecraft has proven how much time people are willing to spend modding or developing for a little blocky game, Minecraft almost crafted a whole generation of software developers with its limited, unsupported, reverse-engineered-based modding experience.
  An open source game has an enormous potential to catch this momentum. Provide a road as straight as possible for casual modders / contributors to become active in the project, provide good documentation for contributors.
  When a pr is ignored for weeks a potential future core dev is lost, contributors risk to be burnt out rebase after rebase, or while having to fight for decent features to be merged. Having a pull request stalled for months is one of the worst indicators of an open source project's health.
  Reconsider the "one approval" thing for trivial PRs, merge right away the simple contributions that are evidently free from any side effects. Do not argue against proposed changes when the thing they are trying to change was bodged together or poorly designed in the first place (example1, example2, example3). It's a game, not a production web server, minor breaking changes are welcome if it means that something is 10% better and has a 10% more chance of keeping an user active on Minetest. A lot of the game feels unfinished and there should be pressure to change all of this disregarding the consequences, until a sufficient quality is reached.

[Kezii]

I randomly found some arguments and evidence about my first point, on another forum:
https://reddit.com/comments/j4luac

I've been working on the UI for IsoPutt for almost 4 months now. It's tedious, and can be hard to stay motivated!

But I've seen first hand how much impact this has had on the way people perceive the game. When you have an ugly menu, you kind of start "in debt" when the player makes it to the gameplay. The gameplay has to overcome that "menu debt" before it can be judged on it's merits. When you have a nice menu, players seem to have a less critical, more open, mindset.

I've noticed play testers playing longer, and expressing more joy now that I've improved the menu systems.

[Wuzzy2]

1) Better main menu (better usability, but also better-looking. Only a full redesign can be the answer IMO)
2) Completely review entities and go through all the entity/object-related issues. Objects still have, in my eperience, a lot of problems and bugs. You can't spawn entities reliably. Entity collisions seem to be unreliable (I often have mobs clip through semi-thin walls). There's a general lack of movement features (sorcerykid contributed a PR). Minetest in general is not happy when there's a large number of entities. There are no speed optimizations (to my knowledge) for simple entities that never move. There's an odd and annoying feature mismatch between non-player objects and player objects. The list goes on, and I believe this is a major reason why mobs suck so much. Maybe a big "meta issue" for entities should be created, to have all entity-related problems in one place
3) Rip out Minetest Game once and for all

[paramat]

I will add extra points to this comment as i think further about this:

• Make MTEngine game-neutral, remove the focus on MTG:
  No longer ship MTE with MTG. Ship with no games. Main menu redesign to clearly guide users to the CDB to download a game. List of higher-quality 'featured games' on CDB.

[nerzhul]

For my part:

• better graphics, mainly the water reflexion and the light to permit far more modern & nicer game (on PC)
• high level API for NPC in games (yeah the NPCs is what make the game live :) )
• formspec be mostly client side not server side

@SmallJoker i don't understand your point about network packer, we need to serialize everything inside it, or if you want a real change you can try protobuf which is an industry standard in network protocols nowadays, but that requires a breakage

[benrob0329]

I would like to see:

• More focus on Minetest as a content distribution platform for independent games (namely main menu improvements and better support for game-specific mods)
• Improved Graphics Pipeline (bugs, performance, and flexibility)
• Continued general improvements and code maintenance

[Zughy]

• New main menu
• Better entities
• Progressively detaching from Irrlicht

[v-rob]

A very general summary of the most popular ideas so far:

| Roadmap Idea | Supporters |
|---|---|
| UI Improvements/Main Menu | 8 |
| Rendering/Graphics improvements | 7 |
| Internal code refactoring/changes | 5 |
| Entity improvements | 5 |
| Content-related changes | 4 |

This shouldn't be taken as what the roadmap items are specifically, but just as a general idea of what people think should be on the roadmap. It's very general as ideas had to be grouped, e.g. content distribution was grouped with removing MTG. The final roadmap should be more specific.

Other ideas are only supported by one or two people (unless I missed something), so I didn't put them on this list.

[KaylebJay]

If I had to choose just one improvement, it would be entities. The current entity is very laggy, both for the client (visual) and to the server. Making them less heavy would mean that a lot of things in minetest could be accomplished that are currently unfeasible due to lag reasons. UI improvements are great, yes, but they don't change gameplay. And since particles are currently just 2D entities ...

I would also like to see the gnarly list of get_bone_position-related problems fixed one of these days.

Graphics are nice, yes. But eye-candy isn't exactly the most important thing in minetest's current position. I remember the days when you could run minetest on a Raspberry Pi and even multiple local clients would have no troubles with lag. Minetest needs optimization and refactoring before we get 'water reflection' and fancy stuff such as this. Moving out of Irrlicht is certainly one of the things that needs to happen, or most of us won't see any of these fancy graphics without getting a new PC.

[rubenwardy]

When I say graphics improvements, I don't mean fancy graphics - I mean fixing broken and badly performing rendering. See z-order glitches, slow particles, and such. On the hierarchy of needs, fancy graphics comes later

[lhofhansl]

On reflection I agree with the entity-sentiment (laggy, collision is slow and buggy).

[Anulo2]

• Better entities
• Detaching from irrlicht
• New main menu

[TheTermos]

If I may, I'd vote on internal code refactoring/changes because other stuff depends on it.

Let's take those entities, some prerequisites to start working on improving them:

• increase position precision to 64 bit - this change probably affects most code files
• give the server authority over player's movement - this is a big one and the devs seem to try not to notice the problem, but that's what's required for proper player-entity and player-player physical interactions.

[lhofhansl]

@TheTermos Can you elaborate on your second point?

[TheTermos]

In short: clients would ask the server politely to move their players for them instead of doing the move themselves and just telling the server authoritatively their whereabouts.

One problem with current solution described here: #9806,
but there are more, e.g. hackability.

[Andrey2470T]

• increase position precision to 64 bit - this change probably affects most code files

Hmm, but why would you need so high position precision? I would suggest to increase maximum up to 32 bit. The current precision is 16 bit (if I don`t mistake).

[v-rob]

• increase position precision to 64 bit - this change probably affects most code files

Hmm, but why would you need so high position precision? I would suggest to increase maximum up to 32 bit. The current precision is 16 bit (if I don`t mistake).

That is, change entity position from 32 bit (float) to 64 bit (double) to stop inaccuracies at high values, not the size of the Minetest world.

[devshgraphicsprogramming]

Properly thread your engine so it scales ;)

[v-rob]

Newly updated chart:

| Roadmap Idea | Supporters |
|---|---|
| Entity improvements | 9 |
| Main Menu/UI Improvements | 9 |
| Internal code refactoring/Irrlicht detachment | 8 |
| Rendering/Graphics improvements | 7 |
| Content-related changes | 4 |

I think that, since the discussion seems to be winding down, we can probably make a roadmap out of what we have.

[paramat]

v-rob,
It seems you are not suggesting this, but your previous comment can be misinterpreted, so i should clarify to everyone that this roadmap will be decided by the core devs, not by democratic vote.
However it is good to have input from non-core-devs in this issue and we will consider their comments.
Perhaps there should be another table created from core dev suggestions?

Also, tagging the only active core dev who has not yet commented @pyrollo

[v-rob]

No, wasn't suggesting that at all. Core dev specific list:

| Roadmap Idea | Supporters |
|---|---|
| Rendering/Graphics improvements | 5 |
| Internal code refactoring | 3 |
| UI Improvements | 3 |
| Entity improvements | 2 |
| Content-related changes | 2 |

[jamesalexanderstevenson]

Nice to see where our priorities lay

On Wed, Oct 14, 2020, 11:08 AM Vincent Robinson [e-mail]
wrote:

No, wasn't suggesting that at all. Core dev specific list:
Roadmap Idea Supporters
Rendering/Graphics improvements 5
Internal code refactoring 3
Main Menu/UI Improvements 3
Entity improvements 2
Content-related changes 2

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/minetest/minetest/issues/10461#issuecomment-708466354,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AQE7PPR7KAFI2K7BELYQFCDSKW5HZANCNFSM4SDFESZQ
.

[Ekdohibs]

For my part:

• Rendering improvements and bug fixes (z-order, transparency, nodebox optimization, (harder, maybe?) dynamic node shapes)
• UI improvements ("fast" dynamic formspecs, avoiding prediction lag for item movement and node placement/destruction; would mainly be fixed by proper SSCSM)
• Better content: more gameplay in _game, recommendations for other high-quality games.

[qawsedrftgzh]

Im not really knowing thing about minetest is buikd:
• Shaders: water reflections, better lighting
• new liquid concept
• support for other languages (Ich möchte endlich ß benutzen können)

[paramat]

I think we should wait longer (perhaps another 2 weeks?) to hopefully get some input from the remaining active core dev @pyrollo

Although long inactive i will also tag the remaining engine core devs @celeron55 @sofar @ShadowNinja

[CasimirKaPazi]

• More freedom for games to manipulate everything. It's hard to create a game that works outside of the Minecraft box. Many things are assumed to be a certain way and can't be changed at all. Uforun was such an attempt that failed (beside other reasons) because running into engine limits very early. For the roadmap game creators should be encouraged not to work around the limitations but to point them out and collect them. It's actually a low hanging fruit, as it's not about adding something new, but to allow to configure existing aspects.
• Entities/mobs. Has been mentioned before.
• Movement and fighting system. If you ever played OpenClonk, the movement is smooth and fighting in multiplayer is really fun. In MT those things are very cumbersome and feel stiff. I don't know what exactly has to change here, but this is an overlooked area that needs more attention. This again is a reason Uforun never even made its first steps.

[pyrollo]

Sorry, been away for a few weeks.

I have many though about what could be changed in minetest, unfortunately they almost always end up in an incompatible stuff (map storage, light management...). Focusing on compatible stuff:

Ingame graphics: I have no clear idea how to improve that but Minetest looks more and more as an old fashioned game. I feel moving toward an Irrlicht separation would have two benefits: more code genericity, be able to switch to another engine.

Code organization: There is to much imbrication making evolution difficult (example: liquid management in map management). I once started to work on a threaded map management (save thread, mapblock mutexes) but it was impossible. Also some source files are obese.

Game generic: There are still too many hardcoded game related stuff in engine: liquid management (once again), sky (improved but still limited), mapgen, and maybe more.

[Kezii]

I have many though about what could be changed in minetest, unfortunately they almost always end up in an incompatible stuff (map storage, light management...).

Please focus on incompatible stuff, we don't need a shitty but backwards compatible game, we need a good game, it's not a production web server

Thanks

EDIT: it's not meant to you personally pyrollo, it's just this general idea of avoiding breakage that's just wrong, minecraft breaks stuff every year and nobody cares if the end result is a better product

[pyrollo]

Please focus on incompatible stuff, we don't need a shitty but backwards compatible game, we need a good game, it's not a production web server

I agree with you. I dream of a MTv6 without worrying about compatibility but, there is a risk. It would be awful to end up with a badly maintained MTv5 and an incompatible and incomplete MTv6 in parallel.

EDIT: it's not meant to you personally pyrollo, it's just this general idea of avoiding breakage that's just wrong, minecraft breaks stuff every year and nobody cares if the end result is a better product.

No pb, I clearly understood :)

[hecktest]

Performance, stability.

You can code your way around most issues in the engine, but not if the engine screeches, crashes, burns and cries for mercy when you try to do the most basic things. The draw distance is abysmal, the framerate doesn't match the visuals, there are visible holes in the map where there shouldn't be any, things that should be culled are still being drawn, I/O is blocking the lua server step, the emerge queue is choking, the client discards nearby blocks only to re-request them over and over, entities are not guaranteed to load on time, and raycasts fail due to obscure reasons.

All the pie in the sky features are worthless if they're built on a foundation of fail. I try to fix what I can but we need more hands on this deck in particular. Formspecs can wait, there isn't much wrong with them. Anything that can be solved with luajit and some creativity should be put on hold to pay back all the tech debt. 5.4 is very stable compared to 5.0 but there's a lot left to do.

6.0 could be the breaking do-everything-right version (with less hardcoding in particular) but work on it shouldn't even begin until 5.x is truly no-bullshit stable.

[GenshinMT]

I have many though about what could be changed in minetest, unfortunately they almost always end up in an incompatible stuff (map storage, light management...).

Please focus on incompatible stuff, we don't need a shitty but backwards compatible game, we need a good game, it's not a production web server

Thanks

EDIT: it's not meant to you personally pyrollo, it's just this general idea of avoiding breakage that's just wrong, minecraft breaks stuff every year and nobody cares if the end result is a better product

@Kezii Correction: This is not meant to be a full game, it's a project with the sole purpose of being a game engine for games made by the community.

Even took a screenshot of the home page image to confirm.
https://cdn.discordapp.com/attachments/306656385754464258/768217246057103420/Screenshot_at_2020-10-20_16-58-42.png

In other words what we really need is a clean/functional/optimal game engine to work with in order to make amazing games for this engine.

Regarding to compatibility, compatibility shouldn't be a focus if this project keeps encouraging users to update their clients and pushing more features for newer client versions which leads to possible incompatibilities for older clients.

[Pevernow]

1.Support ime input method(Many Asian languages will be able to input,such as Japanese ,Chinese, Korean and so on.)
2.More emphasis on performance, users can selectively move part of the rendering calculation to the GPU.
3.Better shaders (water reflection, dynamic shadows, PBR)
(Even ray tracing like "seus PTGI")

[Kezii]

@Kezii Correction: This is not meant to be a full game

That doesn't make any difference whatsoever, I could have been referring to any game that is supported by minetest, if I want a good "game", and that game's code is (overall) 95% contained in the minetest engine, it's minetest's job to be good for the game to be good. Final users click the "minetest" icon to play a game, even if you delude yourself in thinking that minetest's only users are game developers.
The points discussed in this thread, apart from internal code refactoring, are all going to have an impact on final games, so it's irrelevant if minetest ships a game or not. Why are you even telling me this

[LoneWolfHT]

Please focus on incompatible stuff, we don't need a shitty but backwards compatible game engine, we need a good game engine, it's not a production web server

I think this is what they think you should have said?

[LoneWolfHT]

• Easier & faster installation/updates (Windows installers + Update checker)
• Any of Jordach's PRs
• Network efficiency and performance in general
• Graphics part of the Modding API

[HeadClot]

Just thought I would chime in on this.

• Virtual Reality support Via OpenXR. (#8586)
• General Performance improvements and optimizations for both the server and Client.
• Visual improvements such as PBR

[qawsedrftgzh]

It would also nice to have a Minetest port based on WebGL so that you could play minetest in a browser and give new players a “free trial”, because many people with windows really don’t like to install things.

[Pevernow]

Or try another rendering engine (like OGRE-next)
It will bring minetest support for input methods (IME) and more rendering methods (like gles3 and Vulkan and driectx11)
It also supports webgl well and is IOS compliant.

[runsy]

* high level API for NPC in games (yeah the NPCs is what make the game live :) )

The right-click patch is already available... please review, now. Thanks. :-)

[paramat]

pyrollo,

Game generic: There are still too many hardcoded game related stuff in engine: liquid management (once again), sky (improved but still limited), mapgen, and maybe more.

Jut wondering how (apart from Mapgen V6 which i would love to remove) mapgen is 'hardcoded game related stuff'?

[runsy]

My brainstrom, my neurons are actually going to explode:
General:

• Do what you want, but do it right.
• More speed, I want Minetest fast as a comet.
• More agility, the development is rheumatic. Total awakening.
  Specific:
• The formspec are a little poop, let them get better.
• I want more utilities and features for modders. I want more and more.
• NPCs. I want to see thinking and walking things.

[TheTermos]

Here's a nice item for the list, only if you're serious about trying to make it an engine:

• reactivate MTG
• cut out game specific crap from the engine
• reimplement said crap in MTG (might require extending the LUA interface in some cases)

[daretmavi]

EDIT: it's not meant to you personally pyrollo, it's just this general idea of avoiding breakage that's just wrong, minecraft breaks stuff every year and nobody cares if the end result is a better product

@Kezii
I think this is the worst think on Minecraft.
Different Minecraft modding APIs, mods not working between versions, ...
You always have to use another MC version for different mods, not all mods are updated, ...
This is not the way Minetest should/can go.

There are not so many developers and users in MT as MC has. If you break their work with every MT version, they will just stop doing it.

[pyrollo]

Jut wondering how (apart from Mapgen V6 which i would love to remove) mapgen is 'hardcoded game related stuff'?

Sorry @paramat I missed your post.

I had tree things in mind:

• Not being able to totally switch off mapgen stuff (even singlenode) for already generated map. At minimum we have mapgen thread generating empty blocks (single node mg). It could be good to have a mode with no thread, just loading empty blocks (or with a defined node) if they are not in database. This is very close to single node except that it would be synchronous, and with possibility of not saving any generated mapblock.
• The second thing is outdated as I just tested. I thought it was mandatory to define some minimal nodes set (stone, water, ...).
• Third is more vague. Notions of dungeon / water / lava / humidity / ore that can be found in code seems to me game related. All right, it can be changed by settings and I don't exactly know how it could be done in another way. Maybe have a Lua driven mg with all bulk computation in c++ side (I thought about that for grunds mod, part of calculation could be moved to c++ primitives).