OverviewMinetest for me is being able to make your own voxel game without having to write your own game completely from scratch. A domain-specific game engine. I'd like to see features which improve the possibilities of Minetest as a game engine.
I am concerned about quality-assurance and general code quality in Minetest. Due to the lack of automated testing and volunteer testers, small regressions regularly happen.
I'm also concerned about the onboarding of new contributors. We lack effective and accurate documentation, and many are scared away due to code rot and inefficient core developer communication. The engine is also messy and overcomplicated in places.
Specific PRs to work onTo do
- A GUI replacement - I'd like to add a new way to create GUIs, which is themable and consistent. See https://github.com/minetest/minetest/issues/6527
- World-specific settings. Both /set and settings:set() will now set the world config, not the global config
- Automatic testing to stop regressions on the Lua API
- Callbacks on key change (for get_player_controls changes)
- Rewrite the main menu to make it easier for games to customise it, and also make it better by default
- Make all controls rebindable
- Add rebindable actions for server and client-side scripts. They will be able to register actions with default keys, the user can then rebind. The action will then be triggered and sent when the key is pressed. Android clients will have an on-screen button added
- Remove tools. Allow nodes and craft items to do anything a tool could
- Deprecate player attributes, and use the same API as node/item metadata
- Add damage reasons
- depends in mod.conf
- Add a way of downloading mods and games from the menu
Code Quality and Ease of ContributionMinetest has an issue of contribution rot. This is primarily due to how time-consuming reviewing code can be, especially if complex.
- Aim to have 100 or less open PRs by the end of December.
- Improved unit testing, as mentioned above.
- Make sure that PR authors are aware at all times of the status of their PRs, by using labels.
A note on Client-side ScriptingI am very disappointed with CSM in its current form. The client-side scripting that was promised to us would have been a way to increase the possibilities of server mods by allowing them to send the code to the client. The current CSM is aimed at client-provided mods, which is something I do not think should be developed.
Please note that I dislike the term CSM, as it's a side-effect of having client-provided mods. Client-side scripting feels more accurate to me
As a general rule, client-side modding should only be for latency-sensitive use cases. This includes client-side prediction and audiovisual effects.
Please see the Client-scripting plans dev wiki for some thoughts by hmmmm and est31 on what client-side scripting should be.
Client-side scripting should allow custom drawing of GUI elements, for example for computer mods, advanced inventories, and things we haven't thought about yet.
Client-side scripting would also be able to locally control entities and perform client-side prediction on them. This will allow carts without any lag, and other types of entities such as Advanced trains
Any replies related to CSM or client-side scripting should be directed to the relevant discussion thread.