make command output visible to player(s)

[blank.git] / doc / todo

diff --git a/doc/todo b/doc/todo
index 1cf7ed0a738932b89d25d8830663b557556a35b1..9df0ec47c2a0f193161f0b910ec79c923dc64d07 100644 (file)
--- a/doc/todo
+++ b/doc/todo
@@ -5,7 +5,7 @@ block placement/removal timers
 
 composite entity animations
 
-       complex entities are made up of part which have their own local
+       complex entities are made up of parts which have their own local
        transform that can be animated (like e.g. an arm or head)
 
 font rendering
@@ -19,7 +19,7 @@ font rendering
 
 command line
 
-       usefull for development and later on world administration
+       more commands pls
 
 persistence
 
@@ -28,12 +28,26 @@ persistence
 
        store some kind of byte order mark?
 
+       world and player names should be normalized so they can safely
+       be used in path names
+
 networking
 
-       write tests
-       do some manual testing
-       some more testing
-       a little optimization
+       definitely needs throttling for the internets
+
+       players stats (who's connected, their ping, and game-relevant
+       things) should be sent to clients
+
+       some method for authenticating a player might be nice
+
+       maybe stale and inexistent chunks should be visualized (e.g. by
+       drawing a semi-transparent box around them)
+
+       make a chunk data counting a little safer
+
+threading
+
+       (clientside) networking and disk IO are prime candidates for threading
 
 launcher ui
 
@@ -41,19 +55,14 @@ launcher ui
 
 entity ai
 
-       pathfinding, chase and roam states
+       pathfinding, better turning behaviour
 
-(block) lighting
+lighting
 
        occlusion/neighbor light mixing is implemented, but still linear
        this could be solved by using a pre-interpolated light texture and
        mapping light levels to coordinates on that
 
-       also: how could block light affect entity lighting?
-       maybe get the interpolated light level at the entity's center and use
-       that as the light power for the directional lighting shader and use a
-       direction that's fixed relative to the camera?
-
        there's a bug where a chunk's model is not updated if its neighbor
        changes border light levels
        I kinda mitigated it a little for direct neighbors during linking, but
@@ -63,13 +72,16 @@ entity ai
        having the light propagate into solid blocks, but feels like this
        could cause some weird behaviours
 
+       entity lighting is now derived from block light levels
+       it's not interpolated and the calculation is very basic, so it
+       has some unexpected effects
+
 gravity
 
-       maybe like light levels? should also store a direction with it in
-       that case. also, global gravity may be a world option.
-       no, per-block gravity vector is most probably too expensive.
-       better have the chunks store a few point masses (maybe blocks that
-       emit gravitation?) and calculate from that
+       now implemented as optional gravity emitter per block type
+       let's see how that pans out
+       maybe players should be given the option to switch between
+       walk and fly mode
 
 block attributes
 
@@ -77,28 +89,20 @@ block attributes
        become interesting. like labels on signs and contents of
        containers
 
-chunk traversal
-
-       maybe the chunk loader should keep an index of interesting, if not
-       all chunks by position, possibly base-relative
-
-       profiling indicates that this is not neccessary atm. maybe it will
-       when there's some more action in the world
-
 transparency (blocks and entities)
 
        transparent blocks because awesome
 
 world generator that is not boring
 
-       maybe store a min/max solidity, humidity, temperature, rarity, etc.
-       for each block type (with the option to deactivate generation
-       altogether) and use different noise overlays for each
-
-entity/world collision
-
-       first draft of entity/world collision is implemented
-       it jitters and has some surprising behaviour
+       well, it's different
+       still needs way more block types and structure generation
+       a minimum distance from origin could be interesting as well, to ensure
+       the spawn vicinity doesn't contain bloks with would be useless at the
+       beginning (if there even is such a thing), also it would encourage
+       exploration
+       biomes seem too small, maybe that will become easier to tune when
+       there's a little more diversity between them
 
 spawning
 
@@ -115,3 +119,19 @@ spawning
        how much space has to be cleared and how to make sure the spawning
        space connects to "open space" I don't know yet, it's all a little
        fuzzy anyway
+
+sprite/particle system
+
+       these could help make the world seem more alive
+
+items
+
+       items representing both blocks and non-blocks (such as tools, weapons,
+       armor), with a simpler physics simulation than entities, much like the
+       one for particles
+       they can be picked up by entities, so those should have one or more parts
+       in their skeleton to render them when they're "held"
+       players' inventories have to be changed so they select an item rather
+       than a block
+       item IDs could be the block ID for blocks, and anything from 2^16 up for
+       non-blocks