![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
okay i might be calling the latest gamedev thing a little early. more details on that later on in the post, but first i gotta explain what the current gamedev thing is about.
if you've been following my rarely-updated code screenshots blog you may have seen a bunch of posts over the latest few days. that's what i've been working on!
now let me tell you what all those inscrutable hexagon graphs are for.
okay so a year or so ago i was captivated by this video (relevant portion beginning @ 1:36), where somebody outlines a map generation system built around subgraph identification and expansion. this might sound a little gimmicky or overly-specific at first, but actually if you're familiar with l-systems, this is actually the next step above them -- where an l-system can identify a structure in a tree and substitute values to grow the tree, this graph system does the same thing with a subgraph in a graph. so it's an extremely general and powerful system for procedurally generating, uh, graphs. (and only slightly hampered by how an aspect of it is known NP-complete. this isn't as important as it sounds, given in practice the subgraphs matched on will be trivial)
let's talk about dark cloud. dark cloud is a ps2 game, kind of a successor to 'soul blazer' on the SNES, where you go around doing dungeon crawls to undo seals on parts of towns, which you then reconstruct. there's also dark cloud 2, also known as 'dark chronicle', that takes the basic concept and executes much better.
what i consider kind of formative to my opinion of dark cloud, moreso than actually playing it, is this e2 writeup, which i'll excerpt part of here:
(my understanding is that that's actually slightly incorrect -- rather than 'three rooms' it's actually two room templates: one a room of {3,5}x{3,5}, optionally with a pillar/hole in the middle OR a 'brain' dividing wall; the second template being a much larger room with random pillars/holes scattered inside it.)
of the many things dark cloud 2 did better than dark cloud is that it used different dungeon generators for each area. some of the areas did have pretty generic mazy maps, but others had much more unique generators. the chapter 3 'starlight valley' area is near and dear to my heart, and its dungeon was a series of forking canyon paths on the edge of gorge above a river, with bridges connecting back and forth across in spots. not necessarily better, but definitely novel.
i've written before about how procedural generation sucks and is fundamentally about reusing content. this graph system is, among other things, a generalized system to make dungeon maps in a certain 'style'. use a base graph and expansion deck that's canyon-themed to get a canyon-style map. use a base graph and expansion deck that's swamp-themed to get a swamp-themed map. this is one way to use the same system to make different "feeling" maps.
now, i wrote all that code like a year ago. but. the one part i didn't write was the code to embed the generated graph. a graph is just a mathematical object: a list of nodes and connections between them. if you want to draw one, you need to have a function that maps each node to a position, and (ideally) that'll be a function that makes the graph look nice, instead of a tangled mess. this is actually pretty tricky to write, and my understanding is the standard method is to basically treat it like a physics problem: nodes all repel each other, and the edges between nodes are springs that pull those nodes together. add them all into a big physics simulation, and keep adding forces randomly near edge intersections until they're all resolved. that's... really complex to code from scratch, and physics is really not my domain at all, so for a long while i let that code languish with no possible way to draw any of it, and it was only recently that i was like "oh hey i could try printing those graphs onto a grid". so that's what i did.
this is something that's still really unfinished -- i only have one set of expansion rules, and it would be good to add more control options for how the expansion rules are selected (currently it just rolls randomly to pick one and sees if it can find an embedding), but getting it working this much has taken the code from "not usable" to "usable", so, that's a pretty good step.
(i was actually considering using this for a procedurally-generated dark souls/bloodborne kind of game -- making one big graph that would be the "world map", and then making each node of that big graph into an area using an area-specific expansion deck. that would be an entire separate endeavor though -- all i've really done in this week is make the structure; making a good expansion deck enters into the realm of game design & is an entirely separate challenge. but it's... not a 'goal' exactly, but something i'd like to get this finished enough to do.)
BUT ANYWAY, that's really neat and i'm definitely going to revisit that code later, but in the moment i got just about as much of the main goal as i think i can get without a lot further effort, so i might stop working on it early and start on the next thing. b/c i'm currently in the middle of a big expansion of the hell game body system, and kind of longing for writing for a less mutable body. i threw a tiny twine demo together in a few hours (mostly debugging/trying to remember how twine worked) earlier today, and i think the next gamedev project is gonna be, you know, an actual game, rather than more working on weird library code. so that might be a three-week project. i'm not gonna commit to that without a little more time for deliberation, but, that's what i'm thinking about doing now.
if you've been following my rarely-updated code screenshots blog you may have seen a bunch of posts over the latest few days. that's what i've been working on!
now let me tell you what all those inscrutable hexagon graphs are for.
okay so a year or so ago i was captivated by this video (relevant portion beginning @ 1:36), where somebody outlines a map generation system built around subgraph identification and expansion. this might sound a little gimmicky or overly-specific at first, but actually if you're familiar with l-systems, this is actually the next step above them -- where an l-system can identify a structure in a tree and substitute values to grow the tree, this graph system does the same thing with a subgraph in a graph. so it's an extremely general and powerful system for procedurally generating, uh, graphs. (and only slightly hampered by how an aspect of it is known NP-complete. this isn't as important as it sounds, given in practice the subgraphs matched on will be trivial)
let's talk about dark cloud. dark cloud is a ps2 game, kind of a successor to 'soul blazer' on the SNES, where you go around doing dungeon crawls to undo seals on parts of towns, which you then reconstruct. there's also dark cloud 2, also known as 'dark chronicle', that takes the basic concept and executes much better.
what i consider kind of formative to my opinion of dark cloud, moreso than actually playing it, is this e2 writeup, which i'll excerpt part of here:
There are 207 dungeon floors in Dark Cloud, 100 of which are optional post-game bonus action in the Demon Shaft. That still leaves 107 dungeon floors to hack, each at least once but probably many times as you build up your weapons or, no, wait, that's all there is to do in Dark Cloud. Just keep this number in mind as I describe a typical dungeon floor and multiply this excruciation by 207.
First, I would do great injustice to this game if I did not elaborate on its random dungeon generation engine. You see, I love games like the old AD&D Forgotten Realms game Dungeon Hack or the updated Blizzard Entertainment Diablo series. These games invent layer upon layer of randomly generated dungeon for you to explore and plunder. Quite literally, this is an unlimited adventure. This is a key feature for replayability, and I looked forward to its implementation in an action-RPG like Dark Cloud.
But apparently, someone forgot to explain the mathematics of probability to the designers. If you design an array of, say, 1000 different types of rooms to be spread along winding corridors -- you're going to get 207 levels of intrigue and danger and surprise at every turn! However, the designers chose a smaller number.
Much smaller.
Keep guessing.
They chose three different rooms to repeat for 207 floors.
I still get angry thinking about this.
Three rooms. You'll know it when you come to them. The first is a square room, with or without some obstruction in the middle. The second is a much larger rectangular room with maybe a couple obstructions scattered throughout. The third is what I like to call the "brain room" -- a room shaped like two hemispheres of the brain connected by a narrow corpus collossum. That's it. Each area has a different tileset, different monsters, and a different character-specific door lock. But that is the entire game right there.
So essentially, you are playing the same dungeon floor over and over again -- each with slightly more difficult monsters.
(my understanding is that that's actually slightly incorrect -- rather than 'three rooms' it's actually two room templates: one a room of {3,5}x{3,5}, optionally with a pillar/hole in the middle OR a 'brain' dividing wall; the second template being a much larger room with random pillars/holes scattered inside it.)
of the many things dark cloud 2 did better than dark cloud is that it used different dungeon generators for each area. some of the areas did have pretty generic mazy maps, but others had much more unique generators. the chapter 3 'starlight valley' area is near and dear to my heart, and its dungeon was a series of forking canyon paths on the edge of gorge above a river, with bridges connecting back and forth across in spots. not necessarily better, but definitely novel.
i've written before about how procedural generation sucks and is fundamentally about reusing content. this graph system is, among other things, a generalized system to make dungeon maps in a certain 'style'. use a base graph and expansion deck that's canyon-themed to get a canyon-style map. use a base graph and expansion deck that's swamp-themed to get a swamp-themed map. this is one way to use the same system to make different "feeling" maps.
now, i wrote all that code like a year ago. but. the one part i didn't write was the code to embed the generated graph. a graph is just a mathematical object: a list of nodes and connections between them. if you want to draw one, you need to have a function that maps each node to a position, and (ideally) that'll be a function that makes the graph look nice, instead of a tangled mess. this is actually pretty tricky to write, and my understanding is the standard method is to basically treat it like a physics problem: nodes all repel each other, and the edges between nodes are springs that pull those nodes together. add them all into a big physics simulation, and keep adding forces randomly near edge intersections until they're all resolved. that's... really complex to code from scratch, and physics is really not my domain at all, so for a long while i let that code languish with no possible way to draw any of it, and it was only recently that i was like "oh hey i could try printing those graphs onto a grid". so that's what i did.
this is something that's still really unfinished -- i only have one set of expansion rules, and it would be good to add more control options for how the expansion rules are selected (currently it just rolls randomly to pick one and sees if it can find an embedding), but getting it working this much has taken the code from "not usable" to "usable", so, that's a pretty good step.
(i was actually considering using this for a procedurally-generated dark souls/bloodborne kind of game -- making one big graph that would be the "world map", and then making each node of that big graph into an area using an area-specific expansion deck. that would be an entire separate endeavor though -- all i've really done in this week is make the structure; making a good expansion deck enters into the realm of game design & is an entirely separate challenge. but it's... not a 'goal' exactly, but something i'd like to get this finished enough to do.)
BUT ANYWAY, that's really neat and i'm definitely going to revisit that code later, but in the moment i got just about as much of the main goal as i think i can get without a lot further effort, so i might stop working on it early and start on the next thing. b/c i'm currently in the middle of a big expansion of the hell game body system, and kind of longing for writing for a less mutable body. i threw a tiny twine demo together in a few hours (mostly debugging/trying to remember how twine worked) earlier today, and i think the next gamedev project is gonna be, you know, an actual game, rather than more working on weird library code. so that might be a three-week project. i'm not gonna commit to that without a little more time for deliberation, but, that's what i'm thinking about doing now.
