]> git.localhorst.tv Git - blank.git/blob - doc/todo
4bbfb7dc5930f3874415114c2c8d5c4a1ddd2832
[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
24 persistence
25
26         merge IO counters, so number of operations per frame is kept
27         low, no matter what exactly is done
28
29         store some kind of byte order mark?
30
31         world and player names should be normalized so they can safely
32         be used in path names
33
34 networking
35
36         definitely needs throttling for the internets
37
38         players stats (who's connected, their ping, and game-relevant
39         things) should be sent to clients
40
41         some method for authenticating a player might be nice
42
43         maybe stale and inexistent chunks should be visualized (e.g. by
44         drawing a semi-transparent box around them)
45
46         make a chunk data counting a little safer
47
48 threading
49
50         (clientside) networking and disk IO are prime candidates for threading
51
52 launcher ui
53
54         select or create a world with configurable parameters
55
56 entity ai
57
58         pathfinding, better turning behaviour
59
60 lighting
61
62         occlusion/neighbor light mixing is implemented, but still linear
63         this could be solved by using a pre-interpolated light texture and
64         mapping light levels to coordinates on that
65
66         there's a bug where a chunk's model is not updated if its neighbor
67         changes border light levels
68         I kinda mitigated it a little for direct neighbors during linking, but
69         it still can happen in (hopefully) rare corner cases
70
71         propagation through semi-filled blocks is wonky. I worked around it by
72         having the light propagate into solid blocks, but feels like this
73         could cause some weird behaviours
74
75         entity lighting is now derived from block light levels
76         it's not interpolated and the calculation is very basic, so it
77         has some unexpected effects
78
79 gravity
80
81         now implemented as optional gravity emitter per block type
82         let's see how that pans out
83         maybe players should be given the option to switch between
84         walk and fly mode
85
86 block attributes
87
88         when blocks are not just a solid rock of color, attributes may
89         become interesting. like labels on signs and contents of
90         containers
91
92 transparency (blocks and entities)
93
94         transparent blocks because awesome
95
96 world generator that is not boring
97
98         well, it's different
99         still needs way more block types and structure generation
100         a minimum distance from origin could be interesting as well, to ensure
101         the spawn vicinity doesn't contain bloks with would be useless at the
102         beginning (if there even is such a thing), also it would encourage
103         exploration
104         biomes seem too small, maybe that will become easier to tune when
105         there's a little more diversity between them
106
107         chunk generation takes too long, it's incredibly annoying
108         should look into speeding it up and executing on a different thread
109         compute shaders might be another approach, though that would require
110         opengl 4.3, block the gpu, and generally doesn't lend itself well to
111         threading (cpu wise). It also requires servers to load GL. maybe not
112         such a great idea after all
113         using interpolation between samples of simplex noise now (big thanks
114         to notch ;) ), I'll see how that fares or can be tweaked
115
116 spawning
117
118         need a way to find a suitable location to spawn new players in
119         I imagine a "random block" function of ChunkIndex could be nice
120         (also for use with the AI spawner)
121         also, finding a spawn position for a player must no fail. after a
122         certain number of tries, the world must change to safely accomodate
123         the player.
124         chunk generation could be adjusted to make a little more room near the
125         origin (since that's where the usual spawn point will be), but that's
126         not strictly necessary and might overcomplicate the generation
127         if all fails, the spawner has to modify the world
128         how much space has to be cleared and how to make sure the spawning
129         space connects to "open space" I don't know yet, it's all a little
130         fuzzy anyway
131
132 sprite/particle system
133
134         these could help make the world seem more alive
135
136 items
137
138         items representing both blocks and non-blocks (such as tools, weapons,
139         armor), with a simpler physics simulation than entities, much like the
140         one for particles
141         they can be picked up by entities, so those should have one or more parts
142         in their skeleton to render them when they're "held"
143         players' inventories have to be changed so they select an item rather
144         than a block
145         item IDs could be the block ID for blocks, and anything from 2^16 up for
146         non-blocks