]> git.localhorst.tv Git - blank.git/blob - doc/todo
1b7d9b01802bd504521b68e7086cf10f43b4a07a
[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         world and player names should be normalized so they can safely
33         be used in path names
34
35 networking
36
37         definitely needs throttling for the internets
38
39         players stats (who's connected, their ping, and game-relevant
40         things) should be sent to clients
41
42         some method for authenticating a player might be nice
43
44         maybe stale and inexistent chunks should be visualized (e.g. by
45         drawing a semi-transparent box around them)
46
47 threading
48
49         (clientside) networking and disk IO are prime candidates for threading
50
51 launcher ui
52
53         select or create a world with configurable parameters
54
55 entity ai
56
57         pathfinding, better turning behaviour
58
59 lighting
60
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
64
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
69
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
73
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
77
78 gravity
79
80         now implemented as optional gravity emitter per block type
81         let's see how that pans out
82
83 block attributes
84
85         when blocks are not just a solid rock of color, attributes may
86         become interesting. like labels on signs and contents of
87         containers
88
89 transparency (blocks and entities)
90
91         transparent blocks because awesome
92
93 world generator that is not boring
94
95         well, it's different
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
100         exploration
101         biomes seem too small, maybe that will become easier to tune when
102         there's a little more diversity between them
103
104 entity/world collision
105
106         I don't like the force/spring based collision response, maybe revert
107         back to impulses
108
109 spawning
110
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
116         the player.
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
123         fuzzy anyway
124
125 sprite/particle system
126
127         these could help make the world seem more alive
128
129 items
130
131         items representing both blocks and non-blocks (such as tools, weapons,
132         armor), with a simpler physics simulation than entities, much like the
133         one for particles
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
137         than a block
138         item IDs could be the block ID for blocks, and anything from 2^16 up for
139         non-blocks