doc/todo

   1 block placement/removal timers
   2
   3         removal timing depending on the tool/block combination
   4         animation for remove
   5
   6 composite entity animations
   7
   8         complex entities are made up of parts which have their own local
   9         transform that can be animated (like e.g. an arm or head)
  10
  11 font rendering
  12
  13         with background now being a thing, a padding might be nice
  14         that or maybe separate bg from fg rendering
  15
  16         it may also be feasible to get rid of SDL_ttf and use freetype
  17         directly to eliminate the unneccessary surface creation
  18         ftgl might also be worth looking at
  19
  20 command line
  21
  22         more commands pls
  23         and show me their output
  24
  25 persistence
  26
  27         merge IO counters, so number of operations per frame is kept
  28         low, no matter what exactly is done
  29
  30         store some kind of byte order mark?
  31
  32 networking
  33
  34         definitely needs throttling for the internets
  35
  36         players stats (who's connected, their ping, and game-relevant
  37         things) should be sent to clients
  38
  39 threading
  40
  41         (clientside) networking and disk IO are prime candidates for threading
  42
  43 launcher ui
  44
  45         select or create a world with configurable parameters
  46
  47 entity ai
  48
  49         pathfinding, better turning behaviour
  50
  51 lighting
  52
  53         occlusion/neighbor light mixing is implemented, but still linear
  54         this could be solved by using a pre-interpolated light texture and
  55         mapping light levels to coordinates on that
  56
  57         there's a bug where a chunk's model is not updated if its neighbor
  58         changes border light levels
  59         I kinda mitigated it a little for direct neighbors during linking, but
  60         it still can happen in (hopefully) rare corner cases
  61
  62         propagation through semi-filled blocks is wonky. I worked around it by
  63         having the light propagate into solid blocks, but feels like this
  64         could cause some weird behaviours
  65
  66         entity lighting is now derived from block light levels
  67         it's not interpolated and the calculation is very basic, so it
  68         has some unexpected effects
  69
  70 gravity
  71
  72         maybe like light levels? should also store a direction with it in
  73         that case. also, global gravity may be a world option.
  74         no, per-block gravity vector is most probably too expensive.
  75         better have the chunks store a few point masses (maybe blocks that
  76         emit gravitation?) and calculate from that
  77
  78 block attributes
  79
  80         when blocks are not just a solid rock of color, attributes may
  81         become interesting. like labels on signs and contents of
  82         containers
  83
  84 transparency (blocks and entities)
  85
  86         transparent blocks because awesome
  87
  88 world generator that is not boring
  89
  90         well, it's different
  91         still needs way more block types and structure generation
  92         a minimum distance from origin could be interesting as well, to ensure
  93         the spawn vicinity doesn't contain bloks with would be useless at the
  94         beginning (if there even is such a thing), also it would encourage
  95         exploration
  96         biomes seem too small, maybe that will become easier to tune when
  97         there's a little more diversity between them
  98
  99 entity/world collision
 100
 101         I don't like the force/spring based collision response, maybe revert
 102         back to impulses
 103
 104 spawning
 105
 106         need a way to find a suitable location to spawn new players in
 107         I imagine a "random block" function of ChunkIndex could be nice
 108         (also for use with the AI spawner)
 109         also, finding a spawn position for a player must no fail. after a
 110         certain number of tries, the world must change to safely accomodate
 111         the player.
 112         chunk generation could be adjusted to make a little more room near the
 113         origin (since that's where the usual spawn point will be), but that's
 114         not strictly necessary and might overcomplicate the generation
 115         if all fails, the spawner has to modify the world
 116         how much space has to be cleared and how to make sure the spawning
 117         space connects to "open space" I don't know yet, it's all a little
 118         fuzzy anyway
 119
 120 sprite/particle system
 121
 122         these could help make the world seem more alive
 123
 124 items
 125
 126         items representing both blocks and non-blocks (such as tools, weapons,
 127         armor), with a simpler physics simulation than entities, much like the
 128         one for particles
 129         they can be picked up by entities, so those should have one or more parts
 130         in their skeleton to render them when they're "held"
 131         players' inventories have to be changed so they select an item rather
 132         than a block
 133         item IDs could be the block ID for blocks, and anything from 2^16 up for
 134         non-blocks