make command output visible to player(s)

[blank.git] / doc / todo

diff --git a/doc/todo b/doc/todo
index d5a961c8ae2817cafbed55644f0e48aa3e9c1c80..9df0ec47c2a0f193161f0b910ec79c923dc64d07 100644 (file)
--- a/doc/todo
+++ b/doc/todo
@@ -5,7 +5,7 @@ block placement/removal timers
 
 composite entity animations
 
 
 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
        transform that can be animated (like e.g. an arm or head)
 
 font rendering


@@ -19,7 +19,7 @@ font rendering
 
 command line
 
 
 command line
 

-       usefull for development and later on world administration
+       more commands pls

 
 persistence
 
 
 persistence
 


@@ -28,12 +28,26 @@ persistence
 
        store some kind of byte order mark?
 
 
        store some kind of byte order mark?
 

+       world and player names should be normalized so they can safely
+       be used in path names
+

 networking
 
 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
 
 
 launcher ui
 


@@ -41,19 +55,14 @@ launcher ui
 
 entity ai
 
 
 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
 
 
        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
        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
 
        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
 
 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
 
 
 block attributes
 


@@ -77,27 +89,49 @@ block attributes
        become interesting. like labels on signs and contents of
        containers
 
        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
 
 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
-       finding a spawn point which doesn't put entities in solids is
-       now a little more crucial. press N if you're in trouble
+       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
+
+       need a way to find a suitable location to spawn new players in
+       I imagine a "random block" function of ChunkIndex could be nice
+       (also for use with the AI spawner)
+       also, finding a spawn position for a player must no fail. after a
+       certain number of tries, the world must change to safely accomodate
+       the player.
+       chunk generation could be adjusted to make a little more room near the
+       origin (since that's where the usual spawn point will be), but that's
+       not strictly necessary and might overcomplicate the generation
+       if all fails, the spawner has to modify the world
+       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