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.
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.
