l-systems & heightmaps
okay so two week projects
these have gotten a little more difficult to write since my mastodon instance vanished into nothingness so i don't have a collection of intermediate screenshots to share
anyway uh january 14th-31st i worked on l-systems in javascript. a lot of the l-system implementations i've seen have been pretty simple ones that just allow for expansion rules, but the scientific literature on l-systems tends to use considerably more complex systems that have parameters or preconditions and postconditions or all sorts of other stuff. so implementing that in javascript in a way that wasn't a nightmare to write was a bit of an accomplishment.
also, to render l-systems you generally need some kind of turtle geometry parser, and when you get into the more complex l-system actions, like generating 3d geometry, those can get pretty complex. i ended up hooking my turtle code up to the 3 svg renderer code i was working on before this, and while that still doesn't work right (i'm still not handling my matrix transforms right, so the bsp-cutting code doesn't work correctly) it's good enough to render some stuff in 3d and have it look 3d.
february 1st-14th was kind of a mess -- i started out wanting to render houses for my hex game. i've been playing a lot of 'kenshi' recently and so i was thinking about its house mechanics -- everything is in the same global world-space, it's just that when you step inside a house it stops rendering the exterior of the house and starts rendering the inside, so you get a bit of a cross-section view. it's kind of a clever use of the fact that polygons are all one-sided in 3d rendering.
so at first i was like, sure i'll just make a custom
that got me thinking about other ways to handle things that wouldn't require quite so much custom code, and so i've tentatively settled on layered heightmaps -- basically instead of a single big heightmap for the entire world, the world has three heightmaps that might have gaps or holes in them -- one is 'the ground', the second is an inverted heightmap for the undersides of overhangs, and the third is a higher 'floor'. these are stitched together in the same way as tiles are normally stitched together, although to render good-looking transition tiles between different materials i am gonna need slightly more information. this means that the worldmap itself can support overhanging cliffs to a limited degree, without making me go full-voxel, which is something i've always wanted to avoid for this project.
it also means that for constructions i could just do something like, well, this building has its own chunk data, only it has like seven layers of heightmap rather than three. then buildings would use all the same rendering, collision, and tiling code as the worldmap, which would make coding them up a lot simpler. (this is inspired by the minecraft metaworlds mod, which solved the issues of custom airship mods not supporting modded blocks by just saying 'actually airships will just use chunks out near the world boundary at 31 million blocks away from spawn to store airship data instead of normal world data, so we won't have to think about how to serialize it at all'. turns out if you already have a way to store world geometry data, it's a lot easier to just reuse that than code something else that's a totally custom implementation.)
anyway that's not all fully done yet, and i'll have to add in a bunch more complex rendering stuff for things like 'walls that aren't a full tile thick', etc, but it's a decent start. all this chunk-generation stuff also got me thinking about one of the big remaining issues in the game, which is that it doesn't actually load chunks during the game -- you 'zone in' to a location and it loads a 6x6 grid of chunks around you, and then that's it; if you walk to the edge of the loaded zone first you walk around on invisible geometry and then you drop down to height 0 when you get to the absolute edge of loaded map data. getting map loading working would do a lot towards making this feel like an actual game.
the big issue with that has been since opengl actions can only be run on one thread, i couldn't really 'multithread' it and run map-loading ops in the backgroud. (i could run map generation in a different thread, but ultimately rendering the loaded maps would have to happen in the main thread, since that involves buffer allocations and buffer writes that can only happen in the rendering thread.) so a while back i worked on coroutines, which are a way of doing thread-like computations in a single logical thread. i got that mostly working, but i never merged it into my main project. so i also did that! there was a bunch of state wrangling involved for that, and i'm still not done with it entirely, but i got it working well enough to add an initial loading screen for the game, for when you first load in any chunks. actual background chunk loading during the game will come in a bit, maybe even later today if i keep working at it, since i still have to do some data-management code there.
anyway, that's some progress. i'm actually feeling kind of excited about this code stuff, since i've been working on 'engine' code for such a long time without any firm 'game concept' attached. but now the engine stuff is almost all done, and i'm starting to get into gameplay design finally. so that's neat. we'll see how that goes as i finish up more things; i've been kind of thinking of streaming me 'playing' the game and going over all the code stuff that went into it and what my plans for development actually are, but, well, we'll see where i'm at when all the engine stuff is done, and not just most of it.
these have gotten a little more difficult to write since my mastodon instance vanished into nothingness so i don't have a collection of intermediate screenshots to share
anyway uh january 14th-31st i worked on l-systems in javascript. a lot of the l-system implementations i've seen have been pretty simple ones that just allow for expansion rules, but the scientific literature on l-systems tends to use considerably more complex systems that have parameters or preconditions and postconditions or all sorts of other stuff. so implementing that in javascript in a way that wasn't a nightmare to write was a bit of an accomplishment.
also, to render l-systems you generally need some kind of turtle geometry parser, and when you get into the more complex l-system actions, like generating 3d geometry, those can get pretty complex. i ended up hooking my turtle code up to the 3 svg renderer code i was working on before this, and while that still doesn't work right (i'm still not handling my matrix transforms right, so the bsp-cutting code doesn't work correctly) it's good enough to render some stuff in 3d and have it look 3d.
february 1st-14th was kind of a mess -- i started out wanting to render houses for my hex game. i've been playing a lot of 'kenshi' recently and so i was thinking about its house mechanics -- everything is in the same global world-space, it's just that when you step inside a house it stops rendering the exterior of the house and starts rendering the inside, so you get a bit of a cross-section view. it's kind of a clever use of the fact that polygons are all one-sided in 3d rendering.
so at first i was like, sure i'll just make a custom
House datatype and use that for buildings and expand that as i add more building features. but then i was like... well, that would mean totally re-coding stuff like collision and rendering and texture tiling for buildings, since they wouldn't be tile-based like the world heightmap, and then probably again for whatever i'd be doing for caves or underground sections. also, kenshi has this issue where buildings can't punch through the world heightmap, so it's impossible for any buildings to have a basement.that got me thinking about other ways to handle things that wouldn't require quite so much custom code, and so i've tentatively settled on layered heightmaps -- basically instead of a single big heightmap for the entire world, the world has three heightmaps that might have gaps or holes in them -- one is 'the ground', the second is an inverted heightmap for the undersides of overhangs, and the third is a higher 'floor'. these are stitched together in the same way as tiles are normally stitched together, although to render good-looking transition tiles between different materials i am gonna need slightly more information. this means that the worldmap itself can support overhanging cliffs to a limited degree, without making me go full-voxel, which is something i've always wanted to avoid for this project.
it also means that for constructions i could just do something like, well, this building has its own chunk data, only it has like seven layers of heightmap rather than three. then buildings would use all the same rendering, collision, and tiling code as the worldmap, which would make coding them up a lot simpler. (this is inspired by the minecraft metaworlds mod, which solved the issues of custom airship mods not supporting modded blocks by just saying 'actually airships will just use chunks out near the world boundary at 31 million blocks away from spawn to store airship data instead of normal world data, so we won't have to think about how to serialize it at all'. turns out if you already have a way to store world geometry data, it's a lot easier to just reuse that than code something else that's a totally custom implementation.)
anyway that's not all fully done yet, and i'll have to add in a bunch more complex rendering stuff for things like 'walls that aren't a full tile thick', etc, but it's a decent start. all this chunk-generation stuff also got me thinking about one of the big remaining issues in the game, which is that it doesn't actually load chunks during the game -- you 'zone in' to a location and it loads a 6x6 grid of chunks around you, and then that's it; if you walk to the edge of the loaded zone first you walk around on invisible geometry and then you drop down to height 0 when you get to the absolute edge of loaded map data. getting map loading working would do a lot towards making this feel like an actual game.
the big issue with that has been since opengl actions can only be run on one thread, i couldn't really 'multithread' it and run map-loading ops in the backgroud. (i could run map generation in a different thread, but ultimately rendering the loaded maps would have to happen in the main thread, since that involves buffer allocations and buffer writes that can only happen in the rendering thread.) so a while back i worked on coroutines, which are a way of doing thread-like computations in a single logical thread. i got that mostly working, but i never merged it into my main project. so i also did that! there was a bunch of state wrangling involved for that, and i'm still not done with it entirely, but i got it working well enough to add an initial loading screen for the game, for when you first load in any chunks. actual background chunk loading during the game will come in a bit, maybe even later today if i keep working at it, since i still have to do some data-management code there.
anyway, that's some progress. i'm actually feeling kind of excited about this code stuff, since i've been working on 'engine' code for such a long time without any firm 'game concept' attached. but now the engine stuff is almost all done, and i'm starting to get into gameplay design finally. so that's neat. we'll see how that goes as i finish up more things; i've been kind of thinking of streaming me 'playing' the game and going over all the code stuff that went into it and what my plans for development actually are, but, well, we'll see where i'm at when all the engine stuff is done, and not just most of it.
