One of the key features of any rogue-like is it’s replayability through randomized map generation. This means that every single game has a deeply visual and mechanical difference to any other playthrough, guaranteeing (at least mathematically/theoretically) that every playthough will be different. So what was gonna be the map for my game? The seas, of course!
When I set out to design the first few paper prototypes of Clarice Clairvoyage, I had several ideas in mind:
My first few very naive ideas were largely based on the assumption that I could throw a lot of computing power or have a noise based procgen. Unfortunately due to rule #1, I had to scrap that idea.
There were also a lot of other inspirations of literal rogue or more modern twists on the rogue-like/lites such as “Enter the Gungeon” or “Spelunky”. Those ones were probably doable with simple RNG systems or using a cell based approach; however, it wouldn’t fit rule #2, because of no overworld.
I eventually settled on a circle based island generation that checks if islands are at least a certain distance apart. The island groups are similarly structured from playthrough to playthrough, to make it familiar to the player. However, they are different in function and in visuals, to keep the player on their toes! Rule #3 would be satisfied by generating the different gameplay paths separately from the actual islands, and by designating their function after the locations of the islands had been determined.
Separating those systems also makes it easier to balance or completely redo the gameplay of the world generation, which is nice if you’re not sure if that gameplay idea is the most fun.
First of all, I needed to have an inexpensive, relatively code-cheap way of rendering a bunch of islands.
I wasn’t gonna do it with either a map or sprite based approach, because I don’t have the space on my spritesheet for so many different island parts. The thing I quickly jumped on was just using simple geometry to draw the islands. The two kinds you have access to in PICO8 are of course the circ (circle) and rect (rectangle).
The process I’ve used to go about procgen is to try to define the pattern I want to replicate, and think of an algorithm/code to reproduce that. I started to think of islands as a group of circles together that form somewhat more complex shapes. Here’s what I did:
Okay, cool, now we got our island! But what about islands? It’s about time we scaled this puppy up to make several islands all with their own shape. The way I went about spreading these islands across our “map” was by using more trigonometry and more circles!
I started with drawing different circles around the (0, 0) point of my map, with radiuses in steps of ~60 pixels. I use these circles for reference when drawing the islands on top of them. Next up, I generate a bunch of islands, and try to generate them so that they’re at least a set amount apart from one another. By making this a variable, I can make the sea more dense or sparse based on what I want.
I also make sure that the islands use less of the available circle space the bigger the radius of the circle is. This is to make sure that they kind of make a triangle shape, that’s easier to navigate and implies a choice structure for the player gameplay wise.
The next step I took was drawing/generating another set of circles further top of the (0, 0) position of the map, to make the triangle into a diamond shape, so that the map returns to one final island
In the last gif you kinda spotted it already, but you see me zooming in and out. “How did he do that?”, you might wonder. Well, you’re in luck, because I’m about to tell you.
Most game engines have a form of zooming in or out through camera manipulation. Most weathered PICO8 gamedevs know, however, that the only control we have over the camera is its x an y placement. That’s it. So how did I manage to scale everything?
The trick lies in separating the thing you’re trying to render, from the actual rendering/drawing itself. I mean, this seems obvious. This is one of the reasons why PICO8 has its _draw call separated, to make sure that (manipulating) data and drawing of that data is done in different steps.
If you look at the code of the island generation, you’ll find I have two lists/tables: a points and aradiuses one. In my game, I also have a variable called zoom that ranges from 0.15 to 2 or more. When I zoom, I just scale the radiuses with zoom and, bam, we have islands appearing bigger or smaller based on the zoom value.
Another big (and very important) factor of zoom is the displacement of the objects when zooming. For this, I’m taking the centre bottom of the screen as a focus point by offsetting the final zoom location by (64, 128) and then scaling the final locations and points of the islands according to zoom.
And to top it all off, we can add just a little brown rectangle at a side of a sub-island the furthest away from the centre. And we’re done! We’ve created a little procedural sea that Clarice can sail and find spell book pages and more!
Thank you for reading my devlog! And stay tuned for the next devlog about “Generating (island) gameplay”/“Cutting code tokens” by subscribing to this thread, checking my website or following me or the game on Twitter!