I created this because nobody else really is in the position of making a global roadmap. These are not the only things that matter, but these are things that definitely do matter.
This roughly follows something that I consider to be the original spirit of Luanti, altough I do have to wiggle my original ideas around quite a bit to make them make sense on what we currently have. I have hard time figuring this out, but this appears to be the best way to make the community work together and the best way to use my time.
It is highly unlikely that I will personally implement more than a minor part of this, so feel free to consider this to be a guide in whatever you do. If you think something should be added or removed from here, throw me a message. I will probably try a few different formats for this and settle with something during the upcoming months.
Goal 1
Modders: Give feedback to the core developers (including me)- Modders mean those who make subgames or individual mods.
- The engine's purpose is largely to provide a good platform for the content that runs on it, be it subgames or individual mods, and one of the first steps in figuring out what features to add is to hear about what modders would imagine having use for.
Goal 2
Maintain features and art styles for gamesAfter a decade of existing, MT has come far enough that some games want to maintain their function and art style.
Games should be able to maintain their function and art style without players having to change settings.
This means that if something is added or changed in the engine that makes a game work differently or look different by default, the game should be able to change it back to how it was, without having to beg the players to change their settings. This usually means the server, as configured or commanded by the game, sending a setting or option to the client, and the client disabling the new feature or going back to old functionality when so instructed by the server.
Usually the way to do this is using the ObjectRef client control interfaces, like ObjectRef::set_sky(). This puts games first, which is the goal. I recommend not to negotiate generic settings between the server and the client. The hierarchy is hidden in a system like that, and it pushes people into not designing things with care.
My UI ideals
- When starting MT, ideally the user should be faced with a choice between connecting a server, and choosing between locally installed subgames. The "connect to server" option can be just a pseudo-game. (this is what everyone is already really doing, but the menu just doesn't represent it well at all.)
- When picking one, the choice is locked in the next screen. The next screen should contain a back button for going back to the game selection screen.
- The "connect to server" option would have a hardcoded about box explaining it, and the games would have whatever they specify in a file added for this purpose
- Voxel-based mechanisms that work well in multiplayer environment
- This works well together with the moddability and people have been playing with mesecons, pipes and whatnot for a long time already.
- Defending against computer-controlled enemies
- Defending instead of attacking puts much better use to the aspect of building things... at least until VAEs exist!
- PvP is generally very hard to balance without making it boring
- Many types of this require a world that is more fully in an active state than how Luanti currently works.
- Currently it is assumed that every game wants to maximize world size and player count by taking away from other things, which is not right.
- It should be possible for a mod or game to pick the tradeoff between world size, active entity count, individual entity performance and the resulting maximum player count.
- That is, moving chunks of voxels on which you can build on like the static world, and which otherwise work similarly too.
- This is the only logical extension of the modifiable world mechanic. There's no excuse for this not to be implemented at least in the long run.
- Well, actually, I lied. The other logical extension is making things buildable in finer detail, but that is not what Luanti is about.
- VAEs could have their own Lua environments for API compatibility and performance reasons, or
- a 4th coordinate, w, could be added to all positions. This was deemed as the better option in preliminary discussions.
- These can also be used to make multiple worlds, or partition the main world into superchunks for scaling of a large server. Here's the hype word: MMORPG
- Planning here https://web.archive.org/web/20241014174 ... a_Entities, here http://irc.minetest.net/minetest-dev/20 ... #i_3669359 and here https://irc.minetest.net/minetest-dev/2 ... #i_5835581
- The map generator has become very nicely moddable with Lua, and is fast enough in what it does.
- The issue is that the map generator causes the whole server to halt almost all processing when it is running.
- -> Create some way that makes this not be an issue. Eg. something like register_mapgen_thread("mapgen.lua"), which would operate in it's own environment on an API that only exposes LVMs.
- Some other kind of threading model for mods could work instead of this, but they are likely much more complicated to create, and may not give much practical benefit (only downsides due to complication).
- Things that don't prevent playing the game, but make it a lesser experience are often ignored.
- Measure and fix rendering bottlenecks
- Build system could use a clean up. Big or small, doesn't really matter; but don't break things.
- I would like a /contrib directory for things that someone volunteers to maintain when the core team doesn't want the overhead, and from which things can be moved out if they become widely used.
- There are only hundreds of bugs. Fix (or wontfix) them! https://github.com/minetest/minetest/is ... state=open
- Client UI: Keep it generic and customizable so that it works for any game and any server.
- Pull requests: If you test a pull request, always comment on it saying that you did so. The amount of testers is a very important factor in deciding whether to merge or not.
- Maintain fork-friendliness in everything including versioning of things. See http://irc.minetest.net/minetest-dev/20 ... #i_3654822
- If you want to focus on exploration of the infinite world, you have to put way more effort into emergent generation and active systems in the world in order to actually have infinite things in there. With almost any fixed selection of static things, it's incredibly bland. For the king of this stuff, see Dwarf Fortress.
- Don't mind the lesser visuals and take full advantage of them in how they make creating unimagined things easier. There are enough games in this world that focus on visuals by taking away from everything else, or by making everything else harder to do.
- If you make game content, read this: viewtopic.php?p=139470#p139470
Voxel Area Entities
Spoiler
This is a thing that people will absolutely love and which provides a huge amount of gameplay value unique to this genre.
There are various ways to make these unnecessarily hard to implement in a fully functional way. This is a way which makes them fairly easy to implement, without any real drawbacks:
Allocate an area of the world to be used for VAEs. For example a 64 node wide slice at the -Z "face" of the world, maybe padded a bit from the edge so that lighting and other things don't freak out. There is completely unused space there as left out by map generation. A check in the regular sending of map data should be put in place to prevent sending stuff from that specially allocated area.
This allows all functions that handle nodes to behave like nothing special was happening; for example furnaces and mesecons will work fine, as far as mods are concerned.
A new ServerActiveObject is created. The server needs a way to keep track of what chunk of nodes belongs to the object. Map sending has to be modified to send the relevant pieces of map from the specially allocated area to clients that see the VAEs.
A new ClientActiveObject is created. The client has to be able to render the allocated piece of the world at the object's position.
They should probably be initially allocated as simply one MapBlock per VAE. It provides enough room to make most things and is very simple, and allocating less than that may not make sense at all.
Falling nodes might be implementable as VAEs; that way they could fall in chunks too in some cases.
There are various ways to make these unnecessarily hard to implement in a fully functional way. This is a way which makes them fairly easy to implement, without any real drawbacks:
Allocate an area of the world to be used for VAEs. For example a 64 node wide slice at the -Z "face" of the world, maybe padded a bit from the edge so that lighting and other things don't freak out. There is completely unused space there as left out by map generation. A check in the regular sending of map data should be put in place to prevent sending stuff from that specially allocated area.
This allows all functions that handle nodes to behave like nothing special was happening; for example furnaces and mesecons will work fine, as far as mods are concerned.
A new ServerActiveObject is created. The server needs a way to keep track of what chunk of nodes belongs to the object. Map sending has to be modified to send the relevant pieces of map from the specially allocated area to clients that see the VAEs.
A new ClientActiveObject is created. The client has to be able to render the allocated piece of the world at the object's position.
They should probably be initially allocated as simply one MapBlock per VAE. It provides enough room to make most things and is very simple, and allocating less than that may not make sense at all.
Falling nodes might be implementable as VAEs; that way they could fall in chunks too in some cases.
