celeron55's roadmap

For people working on the C++ code.
celeron55
Administrator
 
Posts: 443
Joined: Tue Apr 19, 2011 10:10

celeron55's roadmap

by celeron55 » Sat Apr 26, 2014 12:05

This is a roadmap created and maintained by myself, which attempts to pick out things that will make Minetest progress forward. To a certain direction, without spinning in random circles. This is some kind of a continuation from http://c55.me/blog/?p=1491.

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 Minetest, 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.

Get a release out that contains multiple subgames
  • This is important as it pushes the best content to the average users.
  • The most interesting content is made by individual people, not a committee.
  • Subgames need to have descriptions that can be easily viewed in the menu so that new users can understand what the subgames are about.
  • Ideal menu:
    • 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

Goal 2


Focus on these kinds of gameplay
  • 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 Minetest 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.

Implement Voxel Area Entities
  • 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 Minetest is about.
  • Planning here http://dev.minetest.net/TODO#Voxel_Area_Entities and here http://irc.minetest.ru/minetest-dev/201 ... #i_3669359

Make Lua map generation non-blocking
  • 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).

Overally fix non-blocking technical issues
  • Things that don't prevent playing the game, but make it a lesser experience are often ignored.
  • Measure and fix rendering bottlenecks: viewtopic.php?p=133347#p133347
    • Texture switches (i.e. use generated texture atlases; most important)
    • Data transfer to the GPU (add "Store vertex buffers on GPU" to be a user-visible setting)
    • Implement hiding of nodeboxes that are buried underground at mesh generation (What is the effect on performance? Are there other similar things?)
  • Pay some attention to SQLite
    • Determine whether sqlite_synchronous=0 can be used by default, and do so if possible
    • Enable locking so that the database cannot be opened by multiple instances of Minetest
  • 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.
  • Mod security sandboxing (server-side) should be set up. It should be complete, but as unobtrusive as possible.
  • Some kind of built-in profiler should be made where at least in singleplayer games the client could easily show how much processing time each mod approximately uses in ABMs, entities and global ticks.
  • There are only tens of bugs. Fix (or wontfix) them before there are hundreds! https://github.com/minetest/minetest/is ... state=open

Some general guidelines
  • Networking: The low-level protocol implementation is bloated and not ideal. See extra information in spoiler below. Packet handling, serialization and cross-version compatibility should be made more easily reviewable and more noob-proof.
  • 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.ru/minetest-dev/201 ... #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
+ Multithreading part of the modding API
+ Mod security sandboxing
+ Networking
+ Miscellaneous


Goal 3


???

Goal 4


Profit!
Last edited by celeron55 on Thu Mar 19, 2015 09:56, edited 6 times in total.
Reason: Fix rendering of log link
 

celeron55
Administrator
 
Posts: 443
Joined: Tue Apr 19, 2011 10:10

Re: celeron55's roadmap

by celeron55 » Sat Apr 26, 2014 13:10

Things that I have left out of consideration for now. I'll see at some point if there is something to point out in these:
  • Server administration and hosting
 

celeron55
Administrator
 
Posts: 443
Joined: Tue Apr 19, 2011 10:10

Re: celeron55's roadmap

by celeron55 » Fri Dec 12, 2014 18:48

Old:
Networking: Mostly fine on the lower level, but packet handling, serialization and cross-version compatibility should be made more easily reviewable and more noob-proof.

New:
Networking: The low-level protocol implementation is bloated and not ideal. See extra information in spoiler below. Packet handling, serialization and cross-version compatibility should be made more easily reviewable and more noob-proof.
+ Networking
 

celeron55
Administrator
 
Posts: 443
Joined: Tue Apr 19, 2011 10:10

Re: celeron55's roadmap

by celeron55 » Tue Mar 17, 2015 10:10

I split Goal 1 into 1 and 2 to prioritize subgame descriptions. It has been delayed for way too long already.
 


Return to Partly official engine development



Who is online

Users browsing this forum: No registered users and 1 guest