Lovely lady into cute and cozy things, coffee, books, games, and music. Also lead engineer for Slime Rancher 2.

 

🏳️‍⚧️ Trans 🏳️‍🌈 Gay ♾️ Neurodivergent

 

All views are my own.



dphrygian
@dphrygian

I've been looking for a good way to prescribe some kind of gated level flow through my generated maps, as the first step toward doing interesting generated missions. I got the idea this morning to hijack my portal tagging system by adding a secondary tag—which I'm calling a "color" because I'm essentially using this to do map coloring—and then colorizing any downstream sectors and portals that are generated by expansion through the colorized portal.

So in the image above, I've started with 8 seed rooms: three red rooms to the north, three blue rooms to the south, and two chokepoint rooms in the middle, which act as adapters from the blue side of the map to the red side. The portal colorization ensures that the red and blue rooms can't join to each other directly, only via those chokepoints. I also added a validation step to ensure that all rooms of a color are connected without visiting any other color. (That's not strictly necessary, but I think it makes sense for my purposes.)

This test map looks like a bad Team Fortress level or something, but the potential for high-level layouts that can be used in concert with gating mechanisms to make interesting procedural missions is pretty exciting to me!


You must log in to comment.

in reply to @dphrygian's post:

On a past project with procgen tile-based levels, the portals were part of our tiles and we could specify portal types for similar effect. A woody outdoor region could lead into a tunnel system (or into more woods instead), the tunnels could lead into a cavern (or to more tunnels, or back out to the woods), and the cavern could lead back out again, all just by setting different portal types. I think we also would tweak spawn ratios or max count by tile type in a config for each proc ruleset so we'd be more likely to get the flavors we wanted

Edit for additional info: we didn't use this for the sake of gated level flows. For that we relied more on dynamic objective spawns within the map. Power harvester requires batteries, big bads drop batteries, go hunting till the power harvester is charged, now extraction is available. The proc gen nature still meant sometimes weird/bad results, so the metagame was less about a single pass through a procgen level and instead about repetition to grind and farm

That sounds similar to what I did on Slayer Shock (including a woods-to-caves scenario), and I'll probably continue to lean on portal types where it makes sense for environment transitions. For this new project, I desperately wanted a way to model high-level layouts without the added content burden of different tiles with different portal types.

Oddly, this is exactly the sort of thing I see in my head when thinking about compiler flows for code that must do long-latency operations (e.g. network requests or fetching stuff from disk). So the gates are the requests, and they take a long time, but if you make sure you start them all the same time, they happen in parallel.

So you want to do all the blue tasks, then start all of the gates, wait for them, and then do all the red tasks.

In this case it's fairly obvious, but as soon as you have multiple tasks ("gates") some of which are dependent on the results of previous gates, the optimal path is not obvious. Also in code we have loops with gates inside the loop, and we have some gates take longer than others (disk versus network)