]> git.localhorst.tv Git - blank.git/blob - doc/todo
ed9fdce79353570197d9cd9e5d498117b0a29516
[blank.git] / 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
40 launcher ui
41
42         select or create a world with configurable parameters
43
44 entity ai
45
46         pathfinding, obstacle avoidance, better turning behaviour
47
48 lighting
49
50         occlusion/neighbor light mixing is implemented, but still linear
51         this could be solved by using a pre-interpolated light texture and
52         mapping light levels to coordinates on that
53
54         there's a bug where a chunk's model is not updated if its neighbor
55         changes border light levels
56         I kinda mitigated it a little for direct neighbors during linking, but
57         it still can happen in (hopefully) rare corner cases
58
59         propagation through semi-filled blocks is wonky. I worked around it by
60         having the light propagate into solid blocks, but feels like this
61         could cause some weird behaviours
62
63         entity lighting is now derived from block light levels
64         it's not interpolated and the calculation is very basic, so it
65         has some unexpected effects
66
67 gravity
68
69         maybe like light levels? should also store a direction with it in
70         that case. also, global gravity may be a world option.
71         no, per-block gravity vector is most probably too expensive.
72         better have the chunks store a few point masses (maybe blocks that
73         emit gravitation?) and calculate from that
74
75 block attributes
76
77         when blocks are not just a solid rock of color, attributes may
78         become interesting. like labels on signs and contents of
79         containers
80
81 transparency (blocks and entities)
82
83         transparent blocks because awesome
84
85 world generator that is not boring
86
87         well, it's different
88         still needs way more block types and structure generation
89         a minimum distance from origin could be interesting as well, to ensure
90         the spawn vicinity doesn't contain bloks with would be useless at the
91         beginning (if there even is such a thing), also it would encourage
92         exploration
93         biomes seem too small, maybe that will become easier to tune when
94         there's a little more diversity between them
95
96 entity/world collision
97
98         first draft of entity/world collision is implemented
99         it jitters and has some surprising behaviour
100
101 spawning
102
103         need a way to find a suitable location to spawn new players in
104         I imagine a "random block" function of ChunkIndex could be nice
105         (also for use with the AI spawner)
106         also, finding a spawn position for a player must no fail. after a
107         certain number of tries, the world must change to safely accomodate
108         the player.
109         chunk generation could be adjusted to make a little more room near the
110         origin (since that's where the usual spawn point will be), but that's
111         not strictly necessary and might overcomplicate the generation
112         if all fails, the spawner has to modify the world
113         how much space has to be cleared and how to make sure the spawning
114         space connects to "open space" I don't know yet, it's all a little
115         fuzzy anyway
116
117 sprite/particle system
118
119         these could help make the world seem more alive