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 part which have their own local
   9         transform that can be animated (like e.g. an arm or head)
  10
  11 textures
  12
  13         okay, now I need a better solution for the crosshair ^^
  14
  15 font rendering
  16
  17         with background now being a thing, a padding might be nice
  18         that or maybe separate bg from fg rendering
  19
  20         it may also be feasible to get rid of SDL_ttf and use freetype
  21         directly to eliminate the unneccessary surface creation
  22         ftgl might also be worth looking at
  23
  24 command line
  25
  26         usefull for development and later on world administration
  27
  28 audio
  29
  30         do the sources thing right™
  31         (or at least in a way that it doesn't error out on shutdown :P )
  32
  33 persistence
  34
  35         merge IO counters, so number of operations per frame is kept
  36         low, no matter what exactly is done
  37
  38         store some kind of byte order mark?
  39
  40 block asset loading
  41
  42         parameterization of chunk generator should be less static/dangerous
  43
  44 networking
  45
  46         exchange of chunks and entities
  47
  48 launcher ui
  49
  50         select or create a world with configurable parameters
  51
  52 entity ai
  53
  54         pathfinding, chase and roam states
  55
  56 (block) lighting
  57
  58         occlusion/neighbor light mixing is implemented, but still linear
  59         this could be solved by using a pre-interpolated light texture and
  60         mapping light levels to coordinates on that
  61
  62         also: how could block light affect entity lighting?
  63         maybe get the interpolated light level at the entity's center and use
  64         that as the light power for the directional lighting shader and use a
  65         direction that's fixed relative to the camera?
  66
  67         there's a bug where a chunk's model is not updated if its neighbor
  68         changes border light levels
  69         I kinda mitigated it a little for direct neighbors during linking, but
  70         it still can happen in (hopefully) rare corner cases
  71
  72         propagation through semi-filled blocks is wonky. I worked around it by
  73         having the light propagate into solid blocks, but feels like this
  74         could cause some weird behaviours
  75
  76 gravity
  77
  78         maybe like light levels? should also store a direction with it in
  79         that case. also, global gravity may be a world option.
  80         no, per-block gravity vector is most probably too expensive.
  81         better have the chunks store a few point masses (maybe blocks that
  82         emit gravitation?) and calculate from that
  83
  84 block attributes
  85
  86         when blocks are not just a solid rock of color, attributes may
  87         become interesting. like labels on signs and contents of
  88         containers
  89
  90 chunk traversal
  91
  92         maybe the chunk loader should keep an index of interesting, if not
  93         all chunks by position, possibly base-relative
  94
  95         profiling indicates that this is not neccessary atm. maybe it will
  96         when there's some more action in the world
  97
  98 transparency (blocks and entities)
  99
 100         transparent blocks because awesome
 101
 102 world generator that is not boring
 103
 104         maybe divide into biomes and add special features like
 105         settlements, ruins, all kinds of interesting stuff
 106
 107 entity/world collision
 108
 109         first draft of entity/world collision is implemented
 110         it jitters and has some surprising behaviour
 111         finding a spawn point which doesn't put entities in solids is
 112         now a little more crucial. press N if you're in trouble
 113
 114 better noise
 115
 116         current simplex noise implementation repeats itself pretty quickly