This is very true, there’s another issue though. I’m not complaining or anything, but just so you’re aware, you already have a full-time dev, I don’t track my time closely, but I put in roughly 40hrs a week on DDA nights and weekends, but about 90% of my time goes to review/merge/test of other people’s work, leaving me little to no time to work on large features.
The Z-level thing for example is deceptively simple, currently the game tracks a 131x131 square area roughly centered on the player. Inside this area we do line-of-sight, dynamic lighting, scent diffusion, field propogation (fire, smoke, etc), active item updates (draining flashlight batteries, burning fuses on dynamite), vehicle movement, monster/NPC AI and interactions. This is basically all of the game logic.
To make z-levels work the way we want, this dynamically-updated area has to be turned into a 131x131x21 area.
Step one is making the changes to expand the area, this is a TON of detail work, because pretty much all the code assumes that there is NO interaction between Z-levels.
That’s the easy part, at this point the game will run roughly 20 TIMES SLOWER*, then we need to do [MAGIC PROGRAMMING STUFF] to make it go fast again.
In parallel with [MAGIC PROGRAMMING STUFF], we have to figure out how to actually display and interact with a 3D environment in a roguelike, which is mostly unheard of, we’ll have to INVENT new ways of interfacing with the game in a way that doesn’t make the game as difficult to play as QWOP (or worse, DF*).
The features we want are fairly straightforward and well-understood (other than the UI part, the hard part there is precisely in planning it), but will take a huge amount of detail and optimization work to implement.
- 20 times slower is optomistic actually, because we have various algorithms we run that are barely sub-exponential, which means that increasing the number of tiles processed can increase the amount of work by a factor higher than one, e.g. it takes 520 line-drawing operatons to do LOS checking now (we draw a line to each tile on the border of the 121x121 square, so 120x4 lines(the corners are shared, so 120 instead of 121)), but in 3D, we have to draw a line to each square on each face of a 121x121x21 regular hexahedron, meaning… drumroll (121*121)2 + (11921)*4, or 39,278 lines 0_0 So with a naive approach, that operation will take 75 TIMES as long to execute, and is already highly optomised to make dynamic lighting work, a few months ago I added optimzations to it that made it do something like 10x faster, but that won’t be enough for 3D.
**I keed, I keed, I love DF, it’s great, but we have different priorities, so we can’t steal Toady’s UI, damnit.
