1 block placement/removal timers
3 removal timing depending on the tool/block combination
6 composite entity animations
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)
13 with background now being a thing, a padding might be nice
14 that or maybe separate bg from fg rendering
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
23 and show me their output
27 merge IO counters, so number of operations per frame is kept
28 low, no matter what exactly is done
30 store some kind of byte order mark?
32 world and player names should be normalized so they can safely
37 definitely needs throttling for the internets
39 players stats (who's connected, their ping, and game-relevant
40 things) should be sent to clients
42 some method for authenticating a player might be nice
44 maybe stale and inexistent chunks should be visualized (e.g. by
45 drawing a semi-transparent box around them)
49 (clientside) networking and disk IO are prime candidates for threading
53 select or create a world with configurable parameters
57 pathfinding, better turning behaviour
61 occlusion/neighbor light mixing is implemented, but still linear
62 this could be solved by using a pre-interpolated light texture and
63 mapping light levels to coordinates on that
65 there's a bug where a chunk's model is not updated if its neighbor
66 changes border light levels
67 I kinda mitigated it a little for direct neighbors during linking, but
68 it still can happen in (hopefully) rare corner cases
70 propagation through semi-filled blocks is wonky. I worked around it by
71 having the light propagate into solid blocks, but feels like this
72 could cause some weird behaviours
74 entity lighting is now derived from block light levels
75 it's not interpolated and the calculation is very basic, so it
76 has some unexpected effects
80 now implemented as optional gravity emitter per block type
81 let's see how that pans out
85 when blocks are not just a solid rock of color, attributes may
86 become interesting. like labels on signs and contents of
89 transparency (blocks and entities)
91 transparent blocks because awesome
93 world generator that is not boring
96 still needs way more block types and structure generation
97 a minimum distance from origin could be interesting as well, to ensure
98 the spawn vicinity doesn't contain bloks with would be useless at the
99 beginning (if there even is such a thing), also it would encourage
101 biomes seem too small, maybe that will become easier to tune when
102 there's a little more diversity between them
104 entity/world collision
106 I don't like the force/spring based collision response, maybe revert
111 need a way to find a suitable location to spawn new players in
112 I imagine a "random block" function of ChunkIndex could be nice
113 (also for use with the AI spawner)
114 also, finding a spawn position for a player must no fail. after a
115 certain number of tries, the world must change to safely accomodate
117 chunk generation could be adjusted to make a little more room near the
118 origin (since that's where the usual spawn point will be), but that's
119 not strictly necessary and might overcomplicate the generation
120 if all fails, the spawner has to modify the world
121 how much space has to be cleared and how to make sure the spawning
122 space connects to "open space" I don't know yet, it's all a little
125 sprite/particle system
127 these could help make the world seem more alive
131 items representing both blocks and non-blocks (such as tools, weapons,
132 armor), with a simpler physics simulation than entities, much like the
134 they can be picked up by entities, so those should have one or more parts
135 in their skeleton to render them when they're "held"
136 players' inventories have to be changed so they select an item rather
138 item IDs could be the block ID for blocks, and anything from 2^16 up for