![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
i'm resisting the urge to get sucked into fixing up my chunk focus change code forever. there are two or three major bugs with it (down from three or four) and while they're important to fix, they're not really critical
it makes me think of this one dungeon siege dev post ("the continuous world of dungeon siege") where they describe how there's no global coordinate space, just relations between objects in a graph, and how they pick one arbitrarily to work as the origin, and update it as the pc moves along & objects get loaded in and unloaded. and, they say, the critical point is that they want to do that origin update as frequently as possible, since it's the part that's messy & probably has bugs in it, and so the more often it runs the more chances they'll get to have bugs surface and get a chance to correct them
(the one big bug i fixed was that chunk unloading was totally broken, but currently i never actually run the code path to unload except for, basically accidentally, when a chunk is scheduled to be loaded and then told to unload before it's done any loading. so getting that to trigger involves a lot of wiggling around at the edge of chunk boundaries)
likewise all the still-existing bugs only trigger sometimes, rarely, when crossing over chunk boundaries. it's the buggiest section of the code so far, but because it runs so infrequently (maybe once every ten seconds if you're moving, as opposed to, you know, sixty times a second) it's harder to pull out the precise code paths that are problems and figure out what exactly has done wrong
this game is much simpler internally than something that would be full 3d, but there's basically no escaping how much complicated stuff you gotta do before a 'game engine' is more or less ready. let's not even start in on what all i'm gonna have to change in the rendering code before i can seamlessly update tiles for e.g., tilling them or planting things.
it makes me think of this one dungeon siege dev post ("the continuous world of dungeon siege") where they describe how there's no global coordinate space, just relations between objects in a graph, and how they pick one arbitrarily to work as the origin, and update it as the pc moves along & objects get loaded in and unloaded. and, they say, the critical point is that they want to do that origin update as frequently as possible, since it's the part that's messy & probably has bugs in it, and so the more often it runs the more chances they'll get to have bugs surface and get a chance to correct them
(the one big bug i fixed was that chunk unloading was totally broken, but currently i never actually run the code path to unload except for, basically accidentally, when a chunk is scheduled to be loaded and then told to unload before it's done any loading. so getting that to trigger involves a lot of wiggling around at the edge of chunk boundaries)
likewise all the still-existing bugs only trigger sometimes, rarely, when crossing over chunk boundaries. it's the buggiest section of the code so far, but because it runs so infrequently (maybe once every ten seconds if you're moving, as opposed to, you know, sixty times a second) it's harder to pull out the precise code paths that are problems and figure out what exactly has done wrong
this game is much simpler internally than something that would be full 3d, but there's basically no escaping how much complicated stuff you gotta do before a 'game engine' is more or less ready. let's not even start in on what all i'm gonna have to change in the rendering code before i can seamlessly update tiles for e.g., tilling them or planting things.
