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

Clarice Clairvoyage Devlog #2

Alright! So time for the first update on the devlog, excited! Soo… I stream every two weeks, today was one of those weeks, so you can even watch this devlog in the four hour long stream version where I actually implement these features. In this stream I also go into a little bit of detail on how I did the procgen for the islands. I’ll try to do a devlog on how I did those somewhere in the future when I actually fully finish the island’s gameplay functionality as well. Now, to get into the things I’ve actually done. Steering the boat with magic A core part of the game is the magic system that the player uses to fight enemies. I wanted to make more use of this systems besides combat, and one of the first places I wanted to do this, was in the steering of the boat. The boat has the functionality of transporting the player from each “choose-your-own-adventure” styled island to the next, while occasionally encountering a group of enemies. However, I didn’t want the player to just control the boat by tugging on a steering wheel (or whatever you call that on a boat), but instead to use a spell to do it instead! For now, it uses any form of the “beam/ray” spell that I already implemented, but my plan is to make a “wind direction” spell for this specific task that the player can use. How it technically works, is that I just take the angle from the spell direction when it’s being cast, the mast object then uses this angle to lerp towards (making that satisfying turning animation). After that is done, I make the actual ship in the overworld turn as well, but at a slower rate so that the player has a chance to see it happen as well (plus a boat is very heavy so needs more time to rotate). Technically I can also make the boat representation of in the player’s view rotate, however, since the game relies on a grid of spells with close coordination of the player with those locations I’ve decided (for now) that the boat in the player view doesn’t rotate with the actual rotation of the ship. Docking a ship to an island So another challenge for today was making this ship actually stop at one of the island if a player desires it. To do this, I actually found a whole laundry list of bugs in my rendering code for the sea, but I’ll skip over that for now. If you feel like watching me struggle with that for about an hour, check out the stream (link somewhere above). After fixing those bugs, the implementation is somewhat simple: I start with getting the closest dock, so I just have to run a calculation for it, instead for all. Then I just take the distance between the ship and the tip of the dock, see if it's within a certain actuating distance and start to slow the ship down. This actuating distance is just the radius away from the dock, at which I want the ship to start to slow down. I can make this bigger or smaller dependent on how easy I want the ship to dock.Once the ship is within that distance, I divide the actual distance to ship by the actuating distance, causing it to start at 1.0 at the edge of the actuating distance and getting closer to 0 when approaching the point. Then I just make sure that below a certain threshold that percentage is always 0, causing the boat to be at standstill. To leave the dock, I just turn of that threshold, and the ship will start to move further away from the dock edge, slowly speeding up again! ...

February 20, 2021 · Bram Dingelstad

Clarice Clairvoyage Devlog #1

Hey there! I’m working on a small PICO8 Spellcrafting & Sailing Roguelike with the working title of “Clarice Clairvoyage”! Gameplay The game is centered around the concept of crafting spells by stacking different pages of a spellbook. You’re outfitted with a few basic pages, but you get access to more as you fight enemies and sail the sea! There are a bunch of different spells that are the result of many types of combination, so experiment away to see if you can get more power of more utility out of every little spell....

February 19, 2021 · Bram Dingelstad