TODO

Things to do right away

Mapgen

• DecorationDef
• Add configuration for DungeonGen
• Add configuration for CaveGen
• Add Lua callbacks for DungeonGen room placement - this comes with DecorationDef, I reckon
• Make permanent solution for caves spawning inside of trees - Can do this by checking if is_ground_content, now.

MapVoxelManipulator

• Figure out a permanent, elegant solution to the walled-in cave problem - can use is_ground_content now

EmergeThread

• Figure out the thread priority mess
• Assign thread affinities for a bit of a performance boost (reduce L2 cache misses)

Other

• Merge leveldb pull request
• Add Fullbright option
• Re-do rollback to not be slow
• Fix ClearObjects
  • Add an option for active objects only
  • Unload non-persistent entities from blocks on block unload?
  • Add an upper bound to the number of MapBlocks that can be loaded at once - this is the most effective option

Big, long term goals

Lua MapVoxelManipulator Interface

Description
Practically any mod that is more complex than the little clicky thing on the end of ink pens would want to modify portions of the map. To do this, a minetest.env:set_node() call is required for each node to be modified. It does not take much imagination to arrive at the conclusion that the performance of these mods suffer accordingly, due to not only the inherent slowness of Lua, but the overhead of Lua-to-C calls, and the overhead of each Map::setNode() call. To make matters even worse, all this must be done within an envlock, leaving the rest of the server unresponsive while the Lua mods do their thing. Absolutely disgusting.
The answer is to give the Lua API the power of the ManualMapVoxelManipulator, so nodes may be retrieved or modified through a 3d array, and then blit (if necessary) back to the map.
What needs to be done

• The API for this needs to be well thought-out - no afterthoughts or hacky looking pieces.
• The central structure of the VoxelManipulator will be the data itself - a 3D array (in Lua, a table containing tables containing tables of MapNodes), or even better, just one huge array, leaving the modders responsible for finding the index within the array (the latter would surely improve performance).
• An API to simply read blocks of map to an array without any intentions of modifying it. An envlock would only be required when initially reading from the map to the VoxelManipulator.
• An API to read blocks of map, then blit back to the map when done. An envlock is required throughout the lifetime of the object (unless you're not concerned with the contents of the map being modified in between the mod doing so).
• An API to create a blank VoxelManipulator, perhaps filled with CONTENT_IGNORE, to which the mod sets only some blocks, and is blitted back to the map (CONTENT_IGNORE nodes aren't set, obviously). Here, an envlock would only be required when blitting back changes.

Voxel Area Entities

Description
How cool would it be to build a full-sized boat in Minetest, and then drive it around the ocean? That's one example of something that would be possible with this feature.
Voxel Area Entities are moveable ActiveObjects whose mesh and texture is user-modifiable via setting MapNodes in it. This is an extremely powerful feature, and while perhaps not of extreme difficulty to implement, there is very much to be done.
What needs to be done

• A new derived SAO and CAO (they would need to be treated fundamentally differently), along with setNode() and removeNode() calls.
• A derived VoxelManipulator class, perhaps called ObjectVoxelManipulator, which will be used to manipulate them.
• These types of objects have meshes, and will need to be updated in MeshUpdateThread along with MapBlocks.
• Some way to store these in the map. Perhaps these objects will get special non-block-ID keys in the map DB.
• A decent way to serialize these objects. This detail in particular will require special attention.

Envlock Scope Reduction

Description
Envlock needs to be put on a diet. Seriously. This is believed to be the primary reason for perceived unresponsiveness in Minetest - solving this would help matters immensely.
What needs to be done

• Add a thin abstraction layer for atomic operation intrinsics.
• Replace Environment operations that require concurrency but are simple enough with the said atomic operations and clever ordering.
• Add a thread-safe hashtable structure to be used instead of std::map (or core::map) where locks would be needed, make use of this.
• RCU for Map things - big structures such as MapBlocks could benefit from Read-Copy-Update for synchronization. This is the biggest change, but the reward would be immense.

SSE/AVX Perlin Noise

Description
Calculation of perlin noise maps are embarassingly parallel. Using SSE or AVX for the gradient map methods will speed up computations by a factor of 4 or 8. This is not needed anytime soon, as perlin noise is very cheap currently.
What needs to be done

• Finish implementing it
• Test
• Do the same for NEON on arm

Mapgen V7

Description
The highly anticipated, next-generation biome-based map generator, what more is there to say?
This "big feature" has a higher priority than the others, since it is mostly done already and is in high demand from the Minetest community.
Mapgen V7 is fully described here
What needs to be done

• Polish code up
• Add biome Voronoi diagram generator
• Add all Minecraft biomes
• Implement DecorationDef
• Nether and aether biomes - should handle this case separately from biomes, probably, calls to each their own respective generateTerrain().

Mapgen V5

Description
Revival of the 3d perlin noise-based generator that produced excellent looking terrain. Used to be very slow, which is the reason why it was ultimately dumped for V6 - this is no longer a problem with the new perlin noise map functions, which are insanely fast. celeron55 specifically requested to be the one to do this.
What needs to be done

• Class-ify the V5 mapgen code. Create noise objects and handle parameters in the constructor, destroy noise objects in the destructor.
• Replace all NoiseBuffer calls with array accesses to the 3d noise result array
• Replace lighting and liquid updates with calls to the parent Mapgen class' updateLiquid() and updateLighting(). Replace cave, dungeon, and tree generation with the appropriate generalized calls too.
• Overall code cleanup would be nice in addition.

Pre-generate world

Description
What needs to be done

Store block differences only

Description
Instead of storing everything in the database, only store the changed mapblocks (or even only modified nodes?). This would save a lot of space.
What needs to be done

• Change the mapblock saving code to only save modified blocks.
• Change the mapblock loading code to mapgen, and then load changed blocks.

Rivers

Description
Add rivers to map generator.
Did some work on rivers alongside Mapgen V7. Unexpectedly, applying logarithm to terrain height seems to work rather well for this. For 1 < x < 0, log(x) returns a steeply decreasing negative number, below the typical water_level. The rather short interval in which this result occurs draws an outline between higher regions of noise. Unfortunately, the overall level of quality of rivers created with this method is low. Rivers tend to be in a closed loop, vary too greatly in width, and don't branch off to other streams.

• 

  Rivers generated using the logarithm method.

• 

  An attempt at superimposing rivers onto normally-generated terrain

• 

  Another screenshot from a different position of the same map

What needs to be done

• Find an algorithm to produce nice rivers (Lightning fractal algorithm is a decent candidate)
• Find a way to make them completely connected from block-to-block (difficult)

Add colorlike to node param types

Description
Add a field like facedir, wallmounted, and liquidlike called colorlike that will allow the user to register a set of colors so that the color of some base node is modified on draw. This would save many textures and node definitions.
This field would be (part of, at least) param2 in a MapNode. If colorlike is specified on its own, then it can define and use up to 256 colors. If used with facedir or wallmounted, then, it can only define and use 8 colors.
What needs to be done

• Store a color LUT with the ContentFeatures for the defined node that is to be passed along from Lua when registering the node.
• Figure out how to draw these colors in inventory screens and what not without having to prerender more textures
• Bump ContentFeatures version

TODO in minetest_game

To do immediately

• Add snow, dirt_with_snow, ice
• Change desert_sand texture to that of sand
• Use VanessaE's lightened sand texture for regular sand
• Add VanessaE's sandstone brick node
• Make gold not look like American cheese
• Use VanessaE's 16x textures for bronze

Gameplay mechanics

• Beds? Need to think about this one more.
• Enderballs (or at least the teleportation aspect of it in something else).

Add things to surface

(so we do have something else than mining)

• Farming.
• More trees.
• More plants like cacti/papyrus. Grass and junglegrass in jungles is added, do we need more?

Sounds

Collect some (not annoying) sounds from somewhere and add them in.

• a sound pack would be good

See also

• Terminology