+++ /dev/null
-block placement/removal timers
-
- removal timing depending on the tool/block combination
- animation for remove
-
-composite entity animations
-
- complex entities are made up of part which have their own local
- transform that can be animated (like e.g. an arm or head)
-
-font rendering
-
- with background now being a thing, a padding might be nice
- that or maybe separate bg from fg rendering
-
- it may also be feasible to get rid of SDL_ttf and use freetype
- directly to eliminate the unneccessary surface creation
- ftgl might also be worth looking at
-
-command line
-
- usefull for development and later on world administration
-
-persistence
-
- merge IO counters, so number of operations per frame is kept
- low, no matter what exactly is done
-
- store some kind of byte order mark?
-
-block asset loading
-
- parameterization of chunk generator should be less static/dangerous
-
-networking
-
- write tests
- do some manual testing
- some more testing
- a little optimization
-
-launcher ui
-
- select or create a world with configurable parameters
-
-entity ai
-
- pathfinding, chase and roam states
-
-(block) 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
- it still can happen in (hopefully) rare corner cases
-
- propagation through semi-filled blocks is wonky. I worked around it by
- having the light propagate into solid blocks, but feels like this
- could cause some weird behaviours
-
-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
-
-block attributes
-
- when blocks are not just a solid rock of color, attributes may
- 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 divide into biomes and add special features like
- settlements, ruins, all kinds of interesting stuff
-
-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
-
-better noise
-
- current simplex noise implementation repeats itself pretty quickly