Clarice Clairvoyage Devlog #5

For this week’s update I don’t have a lot to share, since I took some time off last weekend to do some other stuff. Sometimes that has to happen too, so as a little reminder to other indiedevs out there reading this, don’t forget to take a break from this stuff from time to time! We tend to forget how tiring this can get. So take a vacation/break from this stuff for a while as well, if you get the chance!...

March 12, 2021 · Bram Dingelstad

Clarice Clairvoyage Devlog #4

Hey, so this week’s update is gonna be about a lot of things, but before we start: I noticed that my devlogs are getting somewhat longer. So to start countering that, I’ll be including a TL;DR at the top of the post, so you can still get what this week was about, without reading my wall of text. ...

March 6, 2021 · Bram Dingelstad

Clarice Clairvoyage Devlog #3

So I kinda teased last time about a devlog on island generation. I kinda shortly touch on the subject when I talk about the procgen, and obviously some work has already been done, as seen in the gifs. Why does my game need procgen? 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! The rough ideas and sketches 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. Implementing island generation 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 island**s**? 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! Placing the islands 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 Zooming 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! ...

February 27, 2021 · Bram Dingelstad

Managing (side)projects

I’ve always had a soft spot for working on something that I thought was a good idea. I have loved the idea of being a little inventor since I was a kid. Being a programmer that gets to work on all kinds of systems or wants to build a lot of them, I found myself clutching this fantasy every single time when starting another project. But how do I make sense of them? Have I started too many? Why aren’t any of them finished? And why do I feel so demotivated to work on any of them, even though I really want to work on one? ...

February 21, 2021 · Bram Dingelstad