let it leave me like a long breath

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.