let it leave me like a long breath

it's happening again! gamedev progress post!

i'm still working more-or-less on the same project as last time. i intended to do a little more writing this month (for the barajam ff7 porn game) but i spent pretty much the entire month some degree of sick from something that may or may not have been COVID, so, you know, on the whole output has been kind of low. i'm feeling mostly better now save for a lingering cough, but i'm pretty acutely aware of how fragile 'healthy' is. welp.

anyway, on to gamedev progress!

i guess since last month i did a screenshots blog comparison, here's this month's: from this post, adding tile litter, to this post, finishing up caves. here's the archive link. this includes things like: tile decorations, slightly more involved generation layers, footing sprites, diagonal wall sprites, controller support (kind of), tile animations, walking sprites, and caves. that's actually a pretty substantial list of stuff, all things considered.

i'm pretty enthused for caves, although the part where i'm going to have to figure out how to correctly position them against cliffs is pretty intimidating, given the way the map generation works currently. i've been playing kenshi a lot, and its total lack of caves or even basements really gets to me. it leaves the world feeling a little flat, if you'll spare the pun. so i really wanted there to be the potential for all sorts of weird little cave locations tucked away. plus i'm not really sure to what degree i'm porting over the gheist & their underworld from 'the new hive' into this, so, maybe there will be some kind of huge connected underworld far beneath the surface. who can say. still no building support, which will come... at some point later on. i feel like i should actually work on game content, like npcs and mechanics, for a while just so there's something to do in the game besides walk around a barren wasteland.

uhhh i tend to keep my cards close to my chest when it comes to talking about what stuff i'm working on, maybe to my detriment when i just stop posting for x months and then post whatever huge thing i've been working on. (and/or announce i'm working on something and then immediately run out of energy for it and then stop. that's also an option.) so i don't really know if i want to post ~game concepts~ stuff about this game, or if that's something people would even be interested in hearing about.

two-week projects! it's weird when i do them these days! the weight of unfulfilled history has crushed their structure!

for the first half of this month i did a little work on an ai scheduler, in the sense of a npc action/reaction system, not like, llm generative-ai stuff. this mostly had me reading a bunch of papers about GOAP and not getting an enormous amount actually done. i wrote a little demo, but it never really worked properly or modelled the world in the way i'd want it to work

the latter half of this month was a little bit more fruitful. worked on some game stuff. specifically, the posts over on my dev screenshots blog, from this one to this one. covering: rudimentary worldgen, drawing a bunch of tile sprites, adding jumping & drawing a jump sprite, and starting (but definitely not finishing) the lighting buffer. also i restructured the worldgen code so that it was fast again & i was back to getting 56fps on the moment of chunk load. actually keeping loading fast is something i care a lot about for this thing, since i would really like this to be practically playable.

as you may have noticed, i've kinda eased back from all the hell game 2 development, mostly because i'm pretty burnt out on writing porn right now & (if you recall) after i wrote the whole scene parser thing i was like, oh yeah, writing actual content for this would involve so much writing. which is why i started messing around with the map rendering code for several months instead. so this project may or may not be the thing i dig into for the next, uh, year-or-so; we'll see. it's certainly the thing i'm working on right now.

currently the idea is kind of a redux of 'the new hive', only with actual graphics and game mechanics. the 'world map' i dumped into the game for testing is a tweaked version of the one from 'the new hive'. you know, whitesand ash wastes to the southeast, acid sea to the south, glass mountain to the northeast, rusted ruins to the west, etc, that kind of thing. turns out it's a lot more work to actually generate and render all that in (isometric) 3d vs. just writing a few lines of description. i'm kinda considering to what degree i want it to be like, porn game vs. game with monstery porn elements vs. Standard Farming Sim Heart System vs. whatever else. i mean, some of my favorite scenes to write in the new hive were the ones where you explain to the gheist how human reproduction works / the ones where the human squad leader has to explain the concept of legal marriage and divorce to you, so like, regardless of explicitness there is gonna be a certain level of sexual weirdness. but also, all of that is still undecided b/c the game as coded does not have npcs in it yet. i'm hoping to add in buildings and caves soon.

the thing with text games is that there aren't really "assets" as such. most of this two-week expanse has just been the process of drawing landscape tiles & implementing them in-game. which is critically important! but it's not really as conceptually interesting as, like, plot & gameplay design.

overall, what i did is like... drew wasteland sand tiles. drew wasteland rock tiles. drew red sand tiles. drew white sand tiles. drew rust sand tiles. drew fused glass tiles. made half-slab variants for stone block. made half-slab variants for brown stone block, & drew rotated versions of relevant sprites. drew jumping sprites for the (default, demo) pc. drew some concrete sprites. drew a bunch of wooden wall & tiled roof sprites for buildings that aren't yet in-game. drew a bunch of rock and plant decor sprites that aren't yet in-game. and did a bunch of code stuff, but it really was mostly drawing stuff.

anyway in other news i kinda did some 2-week gamedev stuff

i've been sitting on a "game test" setup for a while that has (currently) some very limited walking-around ability and also you can jump. this thing. that's also basically a summary of what i did: added in a matching 'ceiling' heightmap to go with the floor heightmap, and made it so quad generation works correctly 1. not draw non-existant tiles outside a cave map and 2. stitch together cave floors and ceilings reasonably. this actually was maybe like one or two days work in total but i stretched it out to like a week and a half b/c i was only picking at it.

also i ended up drawing a bunch of 24x24 tiles to try to replace the existing 16x16 ones, including a bunch of variants for some of them, but i didn't get around to coding those in. i think maybe the next two week project will be hooking in some more advanced texturing code so that i can actually randomly scatter tiles like that. right now all the tiles are these extremely repetitive minecraft-styled textures just because... i haven't actually drawn or assembled anything more complex. a starting goal would be to draw 2x2 tile regions for every material, plus a bunch of random misc tiles, or maybe two different versions of tiling 2x2 regions that have their quadrants individually picked... basically anything to break up the pure repetition. also making the environments themselves not just big rectangular boxes would help a lot

(visually i think a lot about like... final fantasy tactics, breath of fire 3 & 4, vagrant story, which are all games that had very limited texture space and did a lot with that. i mean, they did that by not having generic textures at all; every area in fft and vagrant story was custom-painted with mostly-unique textures. the entire idea of minecraft-style "block types" is not something those games did.)

also the end goal for the cave rendering is to be able to render both a "surface" map (floor only) as well as a "cave" map (floor and ceiling), along with liming up render holes in both to seamlessly move from one to the other. kenshi not having any underground sections really messed me up etc

or like, people talk about "game mechanics" a lot and sometimes it's easy to forget that like, "a menu" is a game mechanic. "moving around space" is a game mechanic. a game that has seamless 3d environments has constructed its "spatial navigation" mechanic differently than a game with 2d tile grids has. so all of the cave rendering stuff is a part of working on how the game presents space to the player. uhhhh we'll see how that goes

anyway like i said in the tumblr post, all that's complicated so i might just draw a bunch of tiles instead. that's easier and looks nicer.

uhhh 2 week project reportback. i actually did some recently so i'm trying to actually post about it when i do them.

early january was working on a redone skybox shader, this time in actual glsl. historically i've been using `gpipe` for my haskell rendering, but between all the javascript webgl2 stuff i've been doing and reading some posts about performant opengl stuff, all the autogeneration happening in gpipe kind of lost its luster. also the library is ages out of date now. i want to try out compute shaders at some point! anyway you can see a bunch of progress screenshots for that on my screenshots tumblr.

late january was a little less focused but i did end up totally recoding the blackjack code for the superhero strip blackjack game thing. uh that's an old version still running the old code, so it's still a little glitchy. the older version was this mess of code that was half tweecode and half javascript and it had like four layers of indirection because i kept tweaking it. the newer code is almost entirely javascript (so i escape from the nightmare of tweecode-formatting complex code) and way simpler and more robust. it also has more real potential for multiple-player games, for like having multiple superheroes stripping at the same time, if i ever decide to write that. the real problem with that game as it stands is i gotta write like a billion little prose fragments for all the strip blackjack things; that's not something clever code can fix. a lot of the big paragraph-long chunks actually seem too long to me; i'd want a lot of the lines to be like, one or two sentences at most since you're gonna be seeing them a lot during combat. anyway i didn't actually write much new prose for it, i just fixed a technical issue. still, it's a little progress.

(i do plan on getting back on to filling prompts it's just i had a busy day and then i used the energy procrastinating on filling prompts gave me to write more for the tmnt fic and also do some coding. i've actually been kinda considering looking back through all the historic prompts i didn't fill and do one where i just write some of those, since there were a bunch of them that were solid maybes, but that'll be a different thing.)

well i did roughly do some two week projects for last month, which i guess makes this the most on-schedule i've been for these things since covid started

probably at some point i should stop opening these posts with a downer statement about how i'm stressed and haven't been doing much. well. i will keep doing that until it stops being true, i guess

anyway! i worked on some code stuff this month!

early in the month i decided to revisit one of my haskell code projects, mostly because (as i had kind of mentioned in the last post) i had been thinking about modernizing my rendering, and that would require switching over to OpenGLRaw for my haskell rendering. so i was like, well, let's look at where my code is currently at. answer: it is bad.

like, i don't really know anything about how to render, really? i have a vague understanding that modern rendering techniques are something like, shader-heavy, actual vertex buffers full of model data; all actually-mutated data is handled through geometry instancing in separate buffers than index into the vertex buffers. large buffers allocated early on and reused. idk. anyway, this code was very much not that. there was a lot of allocating perfectly-sized buffers for each new rendered thing and just stuffing vertex data into it. one of the major issues i was having with general rendering stuff is that, if you're storing raw vertex data to be rendered, and you want to update map data (b/c the pc changed it, for example) that means either totally rebuilding your vertex buffer (slow) or partially writing over some vertices (which means you have to know which vertices in your buffer correspond to what geometry & have enough room to write your new geometry in place). my understanding is a more modern approach is like, you have a vertex buffer full of world geometry options (your marching-cubes cases, or your landscape geometry chunks, or w/e) and then an instance buffer array for your actual world grid (or w/e) that just refers to whichever relevant geometry chunk, and then you can update the instance data without caring about all of your geometry, like, having the exact same vertex count, since you don't need things to line up. probably at some day i should work out how all that instanced code works, but, uh, this was not that day.

anyway previously for this project i was drawing landscape quads, one per coordinate, and then up to eight quads for vertical walls between them, which meant that it wasn't really feasible to update values (since the number of vertical walls would throw off any count; i'd have to track the relative height of every tile and its neighbor and then index into some huge offset array-- basically not something that would be fun or reasonable at all). so, first step, i was just like, okay, no, this is now fully a heightmap, and the rendering for each tile happens by drawing a quad for the floor, the left wall, and the front wall. even if the floor is flat and seamless and the wall quads are a flat line. because at least then every landscape chunk has the exact same number of vertices laid out in the exact same order, which is part of what will be needed at some point for instanced stuff. it also means it's no longer a nightmare to index into the vertex buffer array to update stuff, while i'm still using that technique.

(tbh graphics code is both fun and infuriating b/c it's nothing but a long sequence of figuring out Techniques. sometimes this can be fun to do a deep dive into some complicated, like, deferred rendering texture-writing shader technique, but other times it's like, okay i just totally restructured the entire rendering pipeline and now... it looks exactly the same. but trust me it's working differently under the hood. and the performance characteristics of different approaches tend to be pretty opaque unless you already know everything about how the rendering model works, which, let me tell you i absolutely do not.)

so anyway one consequence of that is that i needed to write a sprite-wrap tiling shader. since all wall quads were a single quad now, i couldn't just draw a quad for the relevant sprite using the relevant uvs, since that would just render one big stretched sprite. but i couldn't just extend the uvs, since that would render arbitrary sections of the sprite atlas. a made a tumblr post about this bit. (also on mastodon)

i also made it so i could render multiple game maps together. tbh my white whale with gamedev has been like, infinite world, seamless, with caves, with acceptable performance. i just want a game that presents as a coherent space, and it turns out that most games do not do that b/c that is kind of a nightmare. so even though this project kinda started out like, "i will just have some big 256x256 maps and you will transition between them" i very rapidly decided, no, actually i still want a single connected world. even though that's way more difficult to code than a series of maps that load and unload and that have boundaries.

so all of that... i wasn't really keeping track but let's say that took up the first half of the month timeslot. i did finish it around the 15th, so, that's good enough for me.

the second half of the month was mostly me going down a procgen dungeon generation hole again. it's very easy to do.

so the thing i want to test with this 'engine', before i get into anything really complex wrt map loading/unloading, is just like: you are on a map. there is a cave entrance in the map. you can move from the world map (which is a heightmap) into the cave map (which is a slightly different variety of heightmap) by walking into a cave entrance, which would have to be literally a hole sliced through the heightmap, either vertically by destroying a wall, or horizontally by destroying a floor. then, the connection between them would have some kinda notation in the map data, like 'hey here's a hole leading to this other map', and i'd need to generate new seamless geometry for the connection point, and handle the moment when the pc is colliding with both maps at once.

instead of working on any of that, i mostly just put together a cave map generator. whoops. i didn't even get cave rendering (with a ceiling and no 'oob' tile rendering) done! oh well i can work on that later i guess.

i posted a bunch more screenshots of this. i posted a thread on mastodon and also a tumblr post (1, 2). the actual algorithm is pretty simple -- place down various-sized cells totally randomly -- but in order to make sure each grid was fully-connected and didn't have any stranded cells i did this total-overkill bucketing floodfill pathfinding thing. it's also pretty slow, so in the future i'd probably want to limit it a bit. i didn't even get to further stages of the generation, where i would take the maximally-connected graph and then start removing edges to get something slightly less connected and more treelike. i did get enough done to actually start using the generator 'in-game'; that post was here. so i'm calling this a tentative success.

(the big step for cave testing would be, figuring out a good entry point for a given map, which would be a cell where i can attach a stairway down and have it fit into both the cave map and into the worldmap heightmap above. that's its own challenge that i did not get to at all. but before i do that i'd want to get 'cave rendering' working, so a cave actually has a ceiling and doesn't have all those floor tiles between rooms. this would also involve tweaking the collision code to handle ceilings, and also cave walls. it's all a process.)

anyway that's some progress on some stuff, which is a lot more than i've been doing lately. tbh in this post-covid world i am just a constantly-exhausted demoralized mess, which has made it very difficult to muster up the energy to care about doing anything. that'sssss life though

so gamedev stuff. i do actually have some stuff to talk about this time! idk if it really falls neatly into a '2 week project' but those are pretty solidly dead at this point unfortunately.

anyway first things first on a whim (playing more amazing cultivation simulator) i reassembled this thing. very very early on thinking about hell game 2 and also playing amazing cultivation simulator i threw together that body viewer and then later when i decided that was not in fact what i wanted to do with hell game 2 i ended up deleting it. i almost never delete code stuff since, hey, what if i want to do something with it again in the future? but this, i deleted. the only evidence i had of its existence was some real old screenshot i happened to take of it two years ago.

so, anyway, i have no clue if i'll ever do anything with that again but it's a goofy little thing to mess around with. the next thing i was going to add was species stuff and material modifiers, so if you wanted to be, like, a bull furry but also a skeleton with bones made out of obsidian and muscles made out of bound gold wire then you would be able to change the template to a bull template, strip off fur and skin layers, and do material transformations on the body. this would also handle things like prosthetics, where the various layers of your body could be made of different things.

(i had some vague idea for a xianxia-styled html game associated with that where you mostly did hexcrawl-style exploration of a big primeval forest loosely inhabited by various monster towns mostly on the river. there's a whole other demo of that but i never actually found a connection point between them. just imagine you are moving around hunting for spirit springs or alchemical reagents by yourself or with a companion. probably it would also be monster porn. you know the drill.)

anyway that was early september. mid/late september i played the wildmender demo and kind of got obsessed thinking about erosion and hydrology. as a kid i could be kept entertained by giving me a big pile of dirt and a hose so i could slowly drip water on the top and watch how water built up and soaked down / eroded through the pile. really this says a lot about me as a person.

the thing i wanted to do was run something like soilmachine. but, it requires c++ boost libraries and my ubuntu install is hopelessly outdated so i can't use apt (using ubuntu was a mistake. next time i do a system reinstall it's back to debian for me). so what's the most reasonable thing to do? totally port over the code to a different language so i can run it, of course!

at first i was going to port it over to javascript, since, webgl2, actual opengl, playable in browser, it would be a neat thing i could show off in the procjam discord, etc. the main problem with that is that the rendering technique it uses (which also seems pretty interesting, as somebody with very little knowledge of how to do efficient modern rendering) is opengl4 specific. webgl2 doesn't even expose the pointer access it would need to use its rendering techniques!

(an aside: i mentioned that webgl2 doesn't support this, and multiple people were like 'well what about using something like node & wasm to use actual c++ libraries, so you can target whatever version of opengl you want?' i didn't dismiss this completely out of hand since it seemed for a second like it would be possible -- i don't really know how wasm works but i guess it can compile all sorts of stuff to wasm, so, why not opengl? somebody had put together a demo of actually targeting a canvas with wasm opengl, so like, maybe there is some mystery thing to get a 'real' opengl context? but, no. if you dig around in the 3k+ line autogenerated javascript file accompanying that demo you'll see that the way it does it is it... gets a webgl2 context from the canvas element. so it doesn't magically break the chains of webgl2 being the only context available, it just obfuscates it. i mean i guess theoretically somebody could target webgpu but i don't think anybody does, so.)

anyway so after that i was like, well, fuck it, i'll just write it in haskell. OpenGLRaw has the entire c-level opegnl api up to 4.6, so i could use glfw and openglraw and do all my rendering that way. i've gotten a little fed up with gpipe anyway so might as well go back to raw opengl. at least then i'll be able to write my own shaders.

the main issue with that is that, if you look at the soilmachine code, it contains 1 (one) general-purpose noise-generation library (fastnoiselite) and 1 (one) very tricky pointer-based linked list datastructure (layermap) and together that was enough to wear me down a little. i did convert almost all of fastnoiselite to haskell! and i managed to replicate about half of its rendering code, including properly compiling and linking its shaders! so, a pretty decent chunk of progress given that i was only working on it for like a week. but i did not get the entire thing working.

i do kinda want to return to that, since... idk, it'd be nice to actually modernize my rendering techniques. there's plenty of cool shader stuff you can do to simplify your geometry model, which i dearly need b/c i don't know what i'm doing wrt rendering stuff. and all that hydrology/erosion stuff is just prime real estate for turning into a compute shader, if i actually knew how to use compute shaders at all. so idk if i'd go so far as actually learning how to use compute shaders (soilmachine makes a point of saying how it's cpu-only), but i do still kinda want to port over the rendering setup at least. we'll see

okay, so, i really only worked on this for a few hours, rather than a solid two weeks, but i'm still counting this as something. but that does make this more of a problem statement than something with extensive code fragments.

so, okay. several years ago i put together a skybox shader. it involved mapping the celestial sphere to a quad and doing a bunch of star rendering. sure. but while i was doing that i ended up having to confront some annoying properties of planetary space, namely, that the planet is a sphere. so the celestial sphere is a sphere, and different parts of it are visible at different locations at different times. so my shader ended up having a uniform for where on the planet you are. which, sure, reasonable. but that got me thinking about the process of actually travelling across a planet. this is kind of a classic problem, right? b/c spheres don't really map easily to data structures. there's a reason why every videogame world map is a flat rectangle, b/c spheres are connected together weirdly.

amitp has a little demo of one of the primary problems of spheres. whoops either you figure out how to distort stuff, or you have these unapproachable 'corners' of the map where reality breaks down. the stereographic projection is me going "well, let's see how you can distort stuff".

namely, the use-case i'm thinking about involves walking around on the surface of a planet (not flying in orbit or digging to the core), and it involves (hopefully) a big planet, something where you can't just represent every point on the planet as 'distance from the center of the planet' and still end up with good fidelity at the surface (i think astroneer's planets, while quite big, are all still small enough to be stored directly as distance-from-core points). one of the major things i wanted to maintain was having the y axis as 'global up', even though... there's no such thing on a planet. because it's round. so a mapping from a sphere to a plane seems like a good candidate for something.

so, theoretically i could have some kind of graph-based setup for the actual world geometry, whether that's a cube or a rhombic dodecahedron or a collection of triangles with linked edges or w/e, and store them as 'flat surfaces' with edge connections, and then when rendering them i'd convert the points to 3d and then flatten them. this is the part i'm least confident of, since if i convert them to full 3d then this is the classic floating-point-precision-loss example: having two small numbers that you add a huge number to and then subtract out the same huge number later. but assuming that works, then you get some easily-storable data structure for your heightmap points (or w/e), and a projection that can use those points (albeit with some distortion).

what i actually did:

sphere render

i remembered how to render a point sphere. if you look in the source there is code to make any size/fidelity point sphere

a stereographic projection of those points

currently fixed to the 'north pole' but i think what i've written is a fully-general stereographic projection function, so it should be possible to use any point for the 'pole' and have the projection plane fixed to be perpendicular to that on the opposite side of the planet

projection with lines

the other things i would've done if i had kept working on this:

• make it so you can actually 'drive' around the planet and spin the projection correspondingly
• actually make this into triangles so you can see, uh, an actual plane landscape here, instead of a dizzying point cloud
• redo all of this in webgl so it's all done in-shader, in a vertex shader
• write the inverse transformation so you can start with a point in the projection and get back the relevant point on the sphere, which would make all the smooth curves actually show up in the projection (and also solve the problem where the pole point turns into a point infinitely far away in every direction. that's projective geometry for you!!)
• figure out how to do this on a planet-scale planet (this is the big one obviously)

i just have these dreams of making a planet that's 1:1 scale of the earth that you can walk anywhere on and have an accurate celestial sphere above.

i didn't get an enormous amount coded these two weeks since i'm also doing nanowrimo (it is going okay; i am mostly writing turtle porn). but i did manage to fix an old busted part of the code.

so last two-week segment i rewrote the shader. this time i got growth ticks working again, and got plant pollination and spreading working, so basically "the rudiments of plant simulation". i also added in decor objects, which are like plants but they don't actually grow. presumably some of them would be stuff you could harvest or collect or build or w/e in the future. this also revealed some remaining issues with the shader, because currently tile occupants are rendered at the same depth as the tile they're on, which leads to a problem where the occupants end up rendered behind the tile, so it looks weird and bad. i think the most principled solution to this is to have 'depth' vary across the tile, so literally as a tile is drawn its depth value will vary based on the y coordinate of its rendered position, which would mean that tile occupants would be able to occlude it correctly. something like that. but i didn't get around to that so i'll have to do that later.

i posted a bunch of screenshots over at mastodon. here are some of them:

1. #1
   
2. #2
   
3. #3
   
4. #4
   
5. #5

oh yeah also i added some very basic 'tile inspection' tools. there's a magnifying glass icon you can click to inspect a tile's material properties + any occupants on it. the plan is to eventually add things like nutrient levels in the soil to control plant spread (to have plants die from overcrowding, etc), and to have those values impact growth levels. this probably means drawing a huge complex spritesheet for each plant to handle things like "stunted growth, growth stage 3" "normal growth, bonus yield" etc for all relevant attributes for a given plant. we'll, uh, see how that goes.

oh boy code reportbacks

i'm trying this again! or, specifically, i've been getting frustrated with not making progress with various projects, again, so i decided to try something like a year-long dev cycle for _something_. i have some kind of 'engine' in place here but i've been really bad at fleshing that out with any content, so i was like, well, i might as well try to focus on doing something, anything, with this code over the course of a year, and see where it ends up at the end of that. (arguably one of the big issues here is that i don't have a clear goal in mind so i don't really have the motivation to move towards that goal instead of randomly picking at disconnected problems. anyway.)

but anyway so the thing i worked on for the past ~2 weeks (since the 24th) was mostly rewriting the shader. shader stuff is always kind of fun. for a very long time i was using the ancient fixed pipeline that forces you to use, you know, 3d coordinates + color + texture uvs + normals as your inputs, and first switching to modern shaders was kind of wild since... you can do anything. this one polygon piece on shaders got spread around social media recently b/c people objecting to some people saying the liquid was "fake", as if polygon representation of liquid surfaces is more 'real' than shader representation of liquid surfaces. as computing tech has gotten faster i've seen raycasting shaders become more mainstream, so you get more volumetric clouds or w/e but you also get more false geometry where you do raycasts from the polygon surface down to an implicit surface defined by some displacement values or w/e. so with a shader you can genuinely do anything.

anyway this isn't really anything like that! or rather, so, the old shader was all in 2d: i'd precompute the screen position of tiles, in pixels, and then have the shader just convert those into positions in the opengl -1–1 cube. this was mostly because before i was rendering everything in canvas, which did take the 2d screen position, so that was the quickest way to switch over to webgl. but now that it's a shader, i could do all sorts of stuff! notably i wanted two major things to be possible: camera rotation (not animated, just, it being able to happen without needing to totally reconstruct all the render buffer coords); and fragment dropping of stuff that occludes the player, as in "stop rendering things in front of the player", if they walk behind a big wall or w/e. (i didn't end up actually implementing either of those things, but i did all the infrastructural work so that now they're fairly minor tasks instead of needing to, uh, totally rewrite the shader.) the main thing there was that i'd need to send block data in 'world coords' to the shader, rather than in 'screen coords'. this is a very common thing to do in video games! you usually have, you know, a camera matrix that transforms coordinates from world space to perspective space and then to screen space. it was just very funny to have the same thing apply to this 2.5d isometric setup. yup, still need a camera matrix, although it ends up looking a bit different than a "normal" one.

this also meant splitting off some data. like i won't get into the super low-level details here but since each tile is actually a bunch of vertices that are positioned differently, i needed some other values to properly size and scale them, and those needed to be different than the world coords since you don't want to like, rotate the sprites, just the tiles that are represented by sprites. this is all basically a very specific application of sprite billboarding. but it's been very funny to me to isolate all these sub-values like "post-transform pixel displacement" or "size multipliers" from the actual raw world coords, since... yeah, it's a shader. you can dump in whatever information you want and alter it in any way you want.

anyway so now the shader looks identical to the old shader, but it does actual 3d calculations, which means i should be able to just change around the camera matrix uniform to rotate things (in discrete chunks of 90°, this isn't magic) or add in a 'focal depth' uniform to do clipping or cut-away renders for when the pc walks behind a wall or w/e else. so that'll all be neat! it also vaguely makes steps towards there being custom lighting, which is something i'd like to do at some point, but here i have a 32-color palette and so trying to respect that with lighting opens up a whole world of nightmarish post-processing paletted shaders that i really don't want to get into right now. suffice to say there are some options.

well this is gonna be a weird reportback

i had been feeling frustrated with all the coding, and also pretty burnt out on writing porn stuff. and i keep still reading bad progression fantasy stuff. so i decided to write my own bad progression fantasy, just to try out some serial writing. so far it's going okay. i've been mostly sticking with 2k words a day 5 days a week, which is... a whole lot of writing. it's been fairly easy to maintain just because: i do not actually care about quality here. "writer's block" for me has always been about feeling like the words i write are bad, & here it's like... yeah like nearly everything on royalroad is bad. when my story first got approved it was approved right after somebody's "diary of a wimpy kid" erotic martial arts fanfiction, featuring explicit scenes of a 4 year old erotically drinking milk. the entire genre of progression fantasy is intensely formulaic. who cares about quality.

anyway my story is a "dungeon core" story, which i've always found to be a very funny subgenre because it inevitably ends up being like a mix between telling somebody about rearranging a terrarium and a text-only let's play of a game that doesn't exist. (tbh some of the most interesting stories on royalroad, conceptually, are the ones that are literally writeups of a play-by-forum game. people have put together entire custom rpg systems for polling audience response & rolling skill checks as part of writing the story. it ends up being, well, like a writeup of somebody's d&d campaign: kind of interesting but also wildly flouting every guideline for how to construct a narrative b/c the author has no clue where anything is going. definitely an interesting creative artifact though.)

also while i'm talking about this i might as well repeat, again, how wild it was to stumble across the progression fantasy genre? because it made me go, "oh, this is the genre of story that HPMOR was". at the time, reading HPMOR, i kept being like, "what are these narrative decisions that yudkowsky is making; this is a weird glimpse into a bizarre mindset of how fiction is written and engaged with". like his whole thing of how all the characters need to be cool and super powerful because it's impossible to empathize with anyone who is weak and has problems. or how it presented this idea that fiction is entirely about setting up a series of problems for your protagonist to solve so you can vicariously enjoy solving problems. yudkowsky explicitly said "oh yeah i wanted to have a bit where harry didn't win immediately but i thought that would be too alienating and boring for people to read". it was just this collection of downright grotesque ideas about the purpose of fiction, and it was singularly bizarre.

and then i found out it was an entire genre of fiction!! which made HPMOR less a singular bizarre artifact and more deeply pathetic (it's still the most prominent product MIRI has ever released, etc). like imagine putting your full effort into trying to save the world and all you can produce is some miserably formulaic power fantasy harry potter fanfiction.

anyway i don't exactly know how long i'm going to keep writing this thing, & i'm gonna try to actually finish it up soon, since the longer it goes on the less likely i am to actually finish it, and also if there's one thing i've learned from reading an enormous amount of royalroad fiction it's that once things hit the like, 300 chapter mark they have usually bled themselves dry of all their fun premises and after that point it's just grim power grinding for the next five million chapters.

(also on a somewhat-related note i've been reading through the start of berserk and that's also a fun look into the nature of serialized media. kentaro miura said like, "oh yeah when i started writing all i knew was that guts was really angry; i didn't know what he was angry about". griffith as a character was invented three or four chapters in; chapter 1 of berserk is just guts being super cool with an auto-crossbow. all the actual plot and characterization slowly evolved out of a need to keep producing more chapters on a fixed schedule.)

so aiming to place my serial writing on a scale between berserk and "the legend of randitly ghosthound", currently on chapter 1918 of miserable litrpg grinding, i would say i hope to rank somewhere in the middle.

anyway my dumb dungeon core story is over here and you can read it if you want to, but i wouldn't necessarily recommend it.

i guess it's time for another 2-week project reportback. still working on asteroid garden. this week: not so much progress, though. i added in some minimal support for 4 plants on a single tile, and they all grow properly and the like, and then i mostly didn't work on it until a few days ago, when i added in the basics of more complex plant growth systems. currently, plants can't really do anything aside from grow, and _minimally_ i wanted them to be able to produce pollen and produce seeds. (it's always botherered me in the various harvest moon etc games that buying seed is a huge part of the mechanical cycle of a small home farm. like, you can just... harvest seeds from your crops. a lot of seeds in fact!)

but anyway that code isn't working fully yet, & i have no real clue how to integrate that into the chunk loading issue -- since pollination is something simulated, so if a chunk gets unloaded with flowering plants on it there's not really any principled way to see if anything happened while the PC was gone aside from stepping through every missed tick until the chunk is up-to-date. and since pollination can occur across chunk boundaries... basically, completely unsurprisingly, simulation in a world where you have to keep loading bits in and out is a nightmare.

that doesn't really even get into the realm of some plants producing, uh, produce. i guess each plant species would store produce lists at various growth stages, & each plant instance would roll those values as they grow, etc.

that being said, i am as always feeling kind of burnt out on everything, so, who can say if i'll keep working on this.

2week project reportback

these two weeks ended up being kind of a grab-bag of stuff. still didn't get around to implementing Basic Farming, but i did get a bunch of related stuff done.

i made a git repo for this a while back and now i can just refer back to my old commit messages to see what i actually did in this 2-week chunk. that's good b/c otherwise i'd totally lose track of time.

i added a pixel offset for tile materials, so now stepping onto tilled ground lowers the pc & cursor, which is a nice little graphics effect. i also made the 'height border hilight' color a material value rather than it being a single hardcoded color, so now they look a little better.

i fixed (i think) the major crashing bug, which was that sometimes when you were moving around, usually when you were crossing over two chunk boundaries in very close proximity, there'd be some error in the loading code that would totally crash the 'main loop' of the game. i tracked it down to being an issue with the chunk unloading code, which currently only runs in very specific conditions. it turns out that code was totally busted and in addition to causing a crash it also destroyed the entire load queue due to a backwards logic check (when a chunk was unloaded, it erased the load info for all chunks aside from itself, instead of erasing the load info for itself). so i fixed that up enough that i think i fixed the bug, but since i'm still not calling the unload chunk code ever i can't be sure it's actually robust. but it seems to work for now, so that's a big improvement

i added item action callbacks! it's all still very simple so far, but if you open the inventory, press a keyboard number while hovering over an item to put it on the hotbar, and then close the inventory and select that hotbar item, and then you click on the ground, it'll run the 'terrain action' callback for that item, if one exists. currently the only one that exists is for the hand hoe, which will till moondust into tilled tiles. (there's also currently no distance limitation or animation for this) so it's primitive but it does work.

(this involved a huge rewrite of the rendering code btw, since previously chunks were rendered 'all in one' and changing any tile would require rerendering the entire chunk. i really wanted to avoid that, so i wrote this whole indexing system, that lets me update/overwrite old tile data as necessary. then, after i finished it all i saw some people talking elsewhere about implementing instanced rendering and i was like "oh yeah it would've been a much better idea to handle this by just making all the rendering indexed". so that kind of sucked the wind from my sails a little, but, oh well i can instance the geometry later, and in the mean time i don't really have to think about it.)

probably the most noticeable change is that i fixed a bug where i allocated the render buffers to be 10x the size they needed to be. this reduces the initial 'load time' of the game drastically. whoops.

i also tweaked the worldgen -- i had been pretty unsatisfied with the other tiles i was using, and i wanted something that fit in more than random splotches of half-finished tiles. so i made a 'dark' tile type and i made that generate in big splotches, and then i added in some rudimentary blending/overlay code so that nearby tiles got some overlay sprites attached. i have some screenshots of that on my code screenshots tumblr.

i also just today tweaked the interface code a little -- there's a persistent issue with picking form elements that i won't get into the details of since it's a thicket of interface stuff. suffice to say i fixed one of the major issues with the interface code, but there are still two other major ones that make them frustrating to use.

so all-in-all between the render and the interaction changes i've set myself up for being able to easily add in tile occupants soon, which should be nice. feeling a little burnt out on this project right now though, since i still don't really have a coherent vision of what the actual gameplay loops should look like, so it's hard to see a path forward from what i have into a 'fun' 'game'. but i guess if i keep working on it i'll probably get somewhere

i'm still uploading the draft versions online, so, the latest version is now up over here if you want to see what i have so far.

so another 2 week project reportback.

after the prior two projects i kept working on the same thing.

(i've been wanting to work on another bigger project, but i've also been frustrated with always stalling out on bigger projects because there's so much stuff to manage in them. working on this project has been a nice compromise, in that there's not really a lot of graphics stuff to manage wrt pixel art, and so that's gotten me to get past the most tedious parts of 'engine-building' and into stuff that's at least something like 'gameplay'. so at this point hopefully it's clear that i'd like to turn this into an actual game that people can play, at some point.)

so previously, i redid the canvas code rendering as webgl2, and that made everything much faster, so that i was no longer struggling to cram in optimizations to keep the framerate above 30fps. now it's 60fps all the time.

what i focused on for this two-week stretch was menus. interactivity in games is mostly clicking on things in the environment, but just as important is 'clicking on ui elements', and so that means i needed to code in some proper ui elements.

i posted some early 'form' screenshots on tumblr, and some other stuff on mastodon. i got the 'new game' character creator working! i mean, it doesn't work in-game yet since i'm not writing the generated sprite to a texture & then using that for the pc sprite, but i don't think that'll present a technical challenge so it should be fairly simple to do later on.

i also separated out the 'inventory' handlers from the rest of the 'game interaction' handlers (stuff like 'use keyboard to move around'), so i could properly push and pop opened ui elements ingame, etc, etc.

i also fixed some major bugs with my map code, so now it's finally nearly acceptable performance-wise. it'll be a few more steps before it's all really ready to go, but it's a big step. i also did some bookkeeping stuff like setting up a git repo so that i can actually remember what i've been working on.

i've definitely entered the stage of development where what i need are assets. theoretically the next thing i'm gonna be working on is simple 'farming' gameplay -- time, plant growth, tile interaction like e.g., tilling ground or watering it -- and what that needs more than logic is roughly a billion game assets for each stage of growth, etc, etc. i've been trying to make the assets somewhat polished to keep training my pixel art skills, and also so the screenshots i produce look kind of nice, but it'll definitely be tempting to just add some scribbles to the asset pages while i work on gameplay stuff.

anyway we'll seeee how things go

i actually do have a 2 week project to talk about now, which is weird

anyway so after the past 2 week project post i kept working on the map thing (actually further updates have broken the old version linked in that post, so uh keep reading to see the new demo)

so i was complaining about framerate issues and somebody (ogrumm) suggested i try out webgl. previously i'd been sticking strictly to the 2d canvas rendering model, since uhhh i got really fed up with opengl code, but since the alternative was "totally recode it in haskell" i decided to give it a try. originally i started out with a completely separate game file that i was gonna slowly port everything over to, until i realized, oh right, actually the program only calls render functions in three or four different places. all i'd have to do would b pull that code out into a separate 'rendering framework' to isolate it, and then write a separate webgl rendering framework to handle webgl rendering.

there were some wrinkles based on the differences in the rendering models, but ultimately it was just about that easy. after that i finished working on the map loading code -- it was this horrible ad-hoc mess based around two separate 9-item arrays that tracked a 3x3 grid of loaded chunks, and it had a switch with custom cases for every kind of chunk movement that could happen that manually shuffled the array indices around and loaded in new chunks. it was a total mess.

anyway i ended up cutting all that code out and replacing it with a super generalized layer-based system that should be suitable for all future map generation. there are still some bugs to work out, and i'm not actually using the full abilities of the load framework, but it's a much better foundation to work on vs. the old code. the current demo is over here, though it's already kind of outdated (i've changed the code to prioritize nearer chunks to load first, & expanded the loaded area to a 5x5 section, which reduces the frequency of map updates, etc). i also turned off the pixel zoom so i could more easily see just how the move code works.

the main issue right now is that i set it to never fully unload chunks, just unrender them. this is so the tile picks (the placement of craters &c) don't end up randomizing again if you leave and revisit a chunk, but it also means theoretically you could wander around until the page has thousands of chunks loaded and it all gets incredibly sluggish. i mean, there's that issue and then there's the issue where sometimes it'll error out on chunk moves for some reason; that hasn't been happening frequently enough for me to be able to usefully diagnose it.

anyway i'm feeling kind of optimistic about this project. i feel like the biggest pitfall i have for projects is hugely biting off more than i can chew, and with this it's all very limited. i mean, the other biggest pitfall for me is that i always push off pinning down mechanical decisions forever because i never have a precise idea of how the player would actually interact with the game world, but hopefully here i manage to overcome that too.

so far the idea i'm having for this game is a kind of maximalist farming/town building game in the vein of dark cloud 2, taking inspiration from stuff like breath of fire (elaborate fishing minigame, etc). we'll see how that idea evolves as i (hopefully) keep working on this project. a lot of my game ideas previously have been grounded in this concept of like, survival games are really absurd b/c the first thing a person would do if they were airdropped into pristine wilderness is die from starvation & exposure; ideas about needing a whole village of specialized labor to even approach self-sufficiency. that is not this game concept. this game concept is a lot more relaxed. it's "what would a farming game look like if you didn't have any inventory limits and didn't have to buy seeds all the time".

something i've wanted to do for these 2-week projects for a while is work on a single overarching project while focusing on specific aspects. i've written up a list of Mechanical Interactions for the game, from things like interface (title screen, item hotbar(?), inventory) to landscape alteration (tools to adjust tiles, maybe raising or lowering terrain, etc) to more abstract things like "exploration" (actual interesting things generated, to give you something to find). hopefully that helps focus my work & doesn't just pin me down under a giant list of intimidating stuff to do. i mean really the hopeful thing is that i don't just implement menus and some basic tool code and then give up on the project; that's kind of been the historical trend. but i'm trying to actually focus on one or two projects now, instead of having a billion that never get anywhere.

i guess if nothing else i wrote a fairly full-featured isometric rendering engine for html5; that's something that might be useful to other people at least.

lol 2 week gamedev project reportback

so early march i finally finished and released the new hive 1.1 patch & in the time right after that i decided to pick on some other projects. one thing was working on the old 'hell game 2' demo that i think i posted here once months ago (if not well i've been working on a hell game 2 demo); that's actually now up over here. it's basically just an engine demo but i reimplemented the whole event framework & body tree editor & got that working and wrote some starter events. really the huge thing there wrt engine coding is figuring out the challenge/combat mechanics, since that's an entire microcosm of interactions. it really made me think about how... in practice, the game is mostly event text. but in terms of code, or interface, the challenge page and the body editor page are these huge complex uis, since they have to display a bunch of state and let you alter them in complex ways. the body editor is basically as complicated as a filesystem tree navigator, since it ends up doing the same thing: hierarchically display information for viewing and editing. and it turns out that's kind of a big thing to do

anyway so i got all that working

and then i ended up working more on that 'realtime' javascript canvas renderer. my progress with that is currently up over here, which is basically just a very basic movement demo. i'm kind of impressed at how much progress i made (adding sprites and textures does a lot for 'game feel') but at the same time all the code is an ad-hoc mess and performance is starting to really take a hit due to the way the rendering is organized, and also there are a bunch of weird visual glitches that occur solely because of some of the rendering optimizations i made. currently i'm seriously tempted to recode it all in haskell or something, but that would mean, uh, totally rewriting all that code.

still, it's been nice to actually work on a fun project like this again. graphics code is always kind of fun because there are actual results that you can see; so many of my coding projects end with a big library of inscrutable code.

so i think i'm done taking prompts now (though they've all tapered off anyway). i'm gonna slog through a final few fills but on the whole i'm pretty pleased with writing the first 10-or-so fills in like, 7 days. at one point i had apparently averaged something like 4,000 words a day, which is totally wild.

anyway in other news

i'm retroactively saying the stuff i was working on over the past week-and-a-half is a two-week project, which means i need to write a reportback about it

well, one thing i did was upload my actual '2 week game projects' (a very tiny subset of my 2 week projects generally) to my server so it's possible to actually look a them. fun fact the haskell ones are unnavigable because they're cabal code project directory structure, but since i have directory index listings turned off it's impossible to look at any of the code unless you already know the filenames. also, that directory contained my RSA keys for the git repo, which i uploaded on accident. they're deleted now & looking at the log files nobody ever hit them (how could they; see above), but, whoops.

anyway the thing i was working on recently was, first, 'clicker', which was basically doing a slight recode of an old game project i had sitting around. it's not really "playable" but it has some half-coded 'mechanics' in it. but more centrally i also coded up 'tavern' which was my latest adventure using the javascript map framework i've written. this time i tweaked it to support real-time movement and rendering, which was fun. it actually gave me a bunch of ideas for how to handle interface stuff in other game projects, since... ui is really hard for me and requires a whole different way of thinking about things. i don't know if i'll revisit that concept specifically, though really at this point it's less a "concept" and more a "map demo".

increasingly i've been wanting to focus back down on at max two projects, & just cast off everything else. i've been playing dwarf fortress again, & as usual i really want to have a project like that, that has a 20+ year timeline and a near-infinite well of content to implement. i generally get discouraged by the troughs in the middle of development and give up on anything before i get anywhere near the point of being able to layer systems on top of each other, but... i mean, why not focus on one thing, i guess.

anyway we'll see how that goes :V

okay let's do this

things, as always, are incredibly hectic and stressful, because have you seen the world lately, but the only way to do something is to do something, so

the two-week projects continue to be very erratic, but i have (kind of) done some lately.

october 15-31 i worked on a prototype 'dungeon core' game that i never really got very far with -- what i have is up here & it was mostly editing & refining the javascript map system i coded up in some prior projects. a lot of it ended up being UI coding.

november i decided i was going to do nanowrimo. at first i was gonna try to write it all for 'a night at the gold saucer', which is a kind of goofy faux-rpg ff7 fangame that has about 50k words of content in it now. it had around 35k at the start of november, and i hit the nanowrimo goals steadily for the first week before abruptly collapsing from ennui since it turns out i'm not actually internally-motivated to work on a dumb ff7 fangame.

(really the game is a joke? not in like a denigrating way, just, it's very funny to think about a lit-rpg porn game, & my issue was basically that okay sure funny joke but i don't want to actually flesh that out into an 80k game or w/e. i might come back to it at some later date since there's a decent amount of stuff there, but tbh given the copyright issues and my inability to host it on ao3 make me less likely to finish it, since... uh porn is having a rough time on the internet these days, much less porn that contains scary taboos + copyright-infringing content.)

so after that i dug up 'the new hive' and started working on the 1.1 patch again. i made a patreon post about it + posted a patreon-only demo with the added stuff. as usual progress is kind of slow, in part because even though i only have like, five sex scenes before it's "done", there's such a huge list of things i'd like to fix+add that it's kind of paralyzing. ultimately i gotta pick some stuff to finish and then finish it, but that's a little challenging to actually do.

anyway so september 15-30 i actually started working on haskell game projects again for a bit -- one of my _actual_ two-week game projects was a total stripping-down of my game code that, among other things, removed my FRP setup. i wrote some things about it in my game dev log when i tried to port that code back over to the big project, which was mostly just a frustrating mess since that required totally rewriting a huge chunk of code, & i never really did figure it out. so this november while doing all that writing i also started picking at rewriting my forms code only without the FRP structure, and after a bunch of rewriting i got the absolute rudiments working. no clue if anything will come out of that, but it's nice to have a more solid foundation to work on things in haskell.

these days i've been wanting to work on a bigger project, but it's kinda hard to square that with how working on any specific project just makes me feel bad with how unfinished it is. i tend to have a pretty glacial rate for projects, in part because it's difficult to actually work on a thing steadily in a way that has any visible result, and recently it seems like i've hit this point of like, frenetically rewriting code (see above re: forms) while still making very little external progress. part of that is just the nature of writing code -- it turns out that, yeah, there's an enormous amount of code you have to write to do anything -- but part is definitely the bad habit of restarting projects, or spreading energy out over a dozen different things, or not working on anything for weeks and then feeling like it must be very difficult to do since after all you haven't made any progress in weeks, etc.

well, that's where i'm at right now. we'll see how things are in two weeks, i guess.

oh yeah i guess i should make a proper reportback

the problem with working on javascript games is i immediately want to work on 3d stuff, and i don't really want to work on 3d stuff in javascript. so for this 2-week project i ended up recoding a bunch of my haskell game code to be simpler and more robust. well, 'more robust' is still up for debate i guess.

this time i actually posted the code, although it's not really in much of a state to use yet.

at first i looked at a few other FRP libraries to see if anything was better than reactive-banana, but ultimately i came to the conclusion that i think FRP is a poor suit for real-time game programming -- yampa or dunai, two other haskell FRP libraries, seem to be designed for physics use since they have more involved timing-based continual integration code, which is neat, but the task of saying "i have certain code i want to run normally, and different code i want to run when a menu is up" seems near-impossible, so while it might be a good suit for using in my 'physics' update, it seems like a bad choice for handling basic event IO.

so i ended up removing all the FRP code and just writing my own input/render/physics loop with no library help aside from some TVars & TChans. this, in turn, ended up simplifying my state & rendering code a lot, since a big part of getting that to work with my other haskell project was managing the render updates within the game state, since all that ran in IO and not the GLFW gl context monad.

(the rough concept for this 'engine' was something based on breath of fire 3 or 4, with free movement and maybe some light platforming. i didn't get around to getting the platforming part working since i stopped around when i needed to start doing collision detection, but this turned out well enough that i'd like to revisit it again in the future and actually try to put together a simplistic game out of it.)

well back on the microgames saddle

this two-week project i made this thing, which is less a 'fun playable game' and more the bare-bones pre-alpha of one. starting with the isometric renderer i worked on last time, i expanded that to 3d and made rendering more efficient, and then also implemented something like a minimal tweecode so i could write text and have it automatically laid out in canvas. in between doing that i wrote up some minimal simulation logic and had it play out across the generated maps, as the player plants stuff.

i'm using signed distance fields to generate the 'asteroids' (& there's a lot of room there for more interesting generation -- there are a bunch of more complex SDFs i could use, or more interesting ways to glom them together, or use them to determine different materials)

in terms of gameplay there's not really much going on & nothing ties together. the idea was that you'd start 'shipwrecked', kind of washing up on an asteroid hanging off a single plank, with one plant cutting to your name. then you'd plant the star grass on the asteroid & have it spread so that you could harvest another cutting. you'd also have (or be able to make) a mana condenser, which would be something you could place in the environment and have it suck up all mana on that tile and store it. the idea was that you could unlock further plant seeds by condensing the right kinds of mana, or by having plants mutate or crossbreed.

so the 'first stage' would always be a barren rocky asteroid of the style the game currently generates, and you'd be starting with only 'star grass', and you'd be stuck there until you could build up to the star grass mutating into a star tree (so you could harvest it for some wood, which you'd have to do several times so it's more like, gotta make a grove of trees and sustainably harvest from that) as well as like, using the fire mana put off by the star grass to generate ashmoss spores, planting ashmoss, having it survive and mutate into ash ferns, doing the same with cyclone reed, and using the wood and optionally the ash ferns, cyclone reed, and lumenrot to make a boat that you could store further cuttings in and sail off the asteroid.

after that there would be other asteroids with other materials (ice and metals, mostly) that let you produce/hybridize/mutate other plants, until you have a big enough collection that you could actually terraform an asteroid. the idea was that... so, as you play, the plants release 'life' mana into the ground, in addition to releasing mana clouds of various types into the void. somewhere inside each asteroid there was gonna be an invisible 'heart' or 'vein' tile, and it was gonna hungrily suck up mana. each asteroid would have some saturation level, like ~1000 mana or so, where after eating that much mana the heart was gonna start emitting mana instead, and that would be what would qualify as 'terraformed'. i'd need a more involved growth system for that to mean anything -- currently life mana is a useless byproduct from plant growth, but it would make more sense if plants both emitted it while growing and absorbed it for a growth boost, or something like that, so that having all the life mana drained out from the ground would kind of suck / having a constant source of life mana would noticeably speed growth.

likewise i had kind of envisioned three basic 'types' of plants: ground cover, like grass, plants that would be bushlike/treelike, and vining plants that would grow on tile walls. they could coexist in the same tile, & part of the game would be planting things three-sisters like that mutually support each other. (right now the four plants all absorb an element until they're grown, at which point they emit a larger amount of the element. that's fine for starter stuff but i'd want the later stuff to be much more complex.)

also there was gonna be some kind of 'crafting', in that you could both harvest cuttings and store them on your boat, or harvest parts of the plants (which might require doing it at the right growth stage, and might slow the plant's growth or kill it if done excessively) which you could use to build stuff on your boat. so like, process the cyclone reed into fibre thread that you could use to make simple sails, that kind of thing. a big, built-out boat would basically be a whole ecosystem unto itself since it would also be full of mana crystals and plant cuttings and gardening stuff.

there was gonna be some light story/plot stuff w/ dialog from the 'main character' but that was all pretty hazy and unformed. anyway none of that got done! but basically all of it is doable if i just keep picking away at it. really, the big thing was assets. it's all well and good to be like "okay this plant has 6 growth stages and mutates into 3 different other plants, and also for visual variety each of all of these plants should have at least 3 different sprites for each growth stage" but uhhh then there are already dozens of sprites to draw. and it's not like these are complex sprites (22x22 base size, palette of 64 colors) but having to draw a billion different things definitely was a bit of a stumbling block. i'm not actually an artist here.

still, this was a bunch of stuff to get working in two days, even if it wasn't really a full 'game'. i'm definitely gonna come back to this at some point in the future and add in some of the stuff outlined here. just not right now

(it's actually kind of funny to me the degree to which working on the isometric code here reminded me of hell game. it has the same fundamental set of issues -- picking, layering sprites correctly, rerenders being expensive -- and when i was thinking about how to make cursor movement faster i was like "wait, didn't i have this exact issue in hell game?" and then i remembered what i did (partial rerenders around the cursor, using a clipping mask) and just did the exact same thing here. i'm kind of curious about what the hell game map code would look to me now, but that seems kind of like a nightmare given how messy it's likely to be. not that this code isn't messy, it's just uhhh messy in a different way)

okay, project reportback. for the first time in uhhhhh a while.

so i started working on microgame projects this month. or like, this last week, really. the first one was a redux of that old twine farming sim(?) game of mine, 'farm game', but this time with actual sprites and interface and stuff. i posted it on itch.io. i kind of debated expanding it some and adding in some of the village/exploration stuff from the unfinished sequel twine game, but i decided that if i do that it at least won't be right now.

(incidentally it is kind of wild to see just what gets posted on itch.io? i guess i've gotten fairly used to 'the new hive' getting a stable 200-400 hits a day, for years, without me ever really updating it. it's a fairly big project, it's perpetually in the first page-or-two of various nsfw/gay/text-game/free tags, it's not super popular but it's regularly getting hits and plays. meanwhile, posting this farm thing on itch made me realize that oh yeah nearly everything that gets posted to itch is tiny microprojects or test games that get maybe ~100 views in 'recent' before sinking like a rock and never being seen again. kind of grim, actually.)

after that i pulled out another game idea and didn't get anywhere near as far with it. what i did is over here, and isn't really a 'playable game'. i mostly just threw together an isometric renderer and drew some sprite stuff, with a very short foray into dungeon generation and mob actions. (there's no attacking; you can just move around, and i didn't finish the mob move ai, so they just continually pathfind to be near to the pc and occasionally overlap each other.) i reread some old unangband blog posts about monster ai, but i didn't really fully implement that. mostly it got me thinking about the mechanical distinctions between a 'roguelike' and a 'tactics' game, since they share an enormous similarity, and it mostly comes down to 'multiple move actions', 'more of a focus on character skills and complex ranged attacks', and of course, 'monsters give xp'.

originally the gamedev challenge thing was supposed to be two-week game prototypes, which i never was any good at, but now three years in i'm kind of considering actually trying to make a game prototype every two weeks, instead of some sliver of library code. we'll see!

---

(okay actually i kind of want to talk more about the second project, the tactics/roguelike one. if you look at the game source there's actually a whole bunch of comments about ideas, b/c it wasn't _really_ a tactics game or a roguelike game or anything like that. really i had read several ff7 fanfics, 'rock bottom' and 'the fifth act', which are both like... ff7 back-in-time fix-it stories with major appearances from crisis core characters. but also both of them include sequences that are just like, oh yeah monsters are an issue here. either you have missions to kill monsters that are nesting near/in cities, or you have to hunt them to sell their parts for money, whatever.

so i was thinking of a game that's a tactics-style game that's just as much about monster butchery as it is about killing the monsters. gotta dissect the corpses and harvest the valuable parts, gotta cart those around to sell to somebody, gotta help supply the apothecary so they can keep making potions. so i was envisioning some kinda game where your player character was pretty overpowered, but basically every kind of attack harms some resource -- use fire or lightning spells to kill a monster and whoops that pelt is useless now. crush a monster and hope you don't need its bones for anything because they're ruined. frozen to death? that wrecks all the organs. and so on and so forth for the various kinds of resources and damage types, where everything damages something, and so each battle is less about wanting to avoid death (although that would also be a concern) and more about avoiding wrecking the rare materials a monster corpse provides.

i was also kinda thinking of a skill system somewhere between ff7-style materia links and the ffx sphere grid, where you have some kinda web of nodes and links, and you slot your skills into there, and depending on what's adjacent you get various synergies -- just [fire] gets you a simple short-range fireball, but place it next to [chain] to get chain-fire, or [power] to get a bigger aoe blast, or [arc] to get a cone of fire, or [sweep] to get a broad melee fire-hit that also does slashing damage, etc. and there would be butchery skills too that would harmonize with attacks or modifiers in different ways, and so forth and so on.)

ultimately that's a bit of a big idea for one week, but the good thing about these two-week projects is w/e, i don't have to really think about wasted potential because uhhh it was a two-week project anyway. and anyway, for the next idea i have i'm probably gonna reuse this isometric grid math, just slightly tweaked.