Log In  

Clarice Clairvoyage - Spellcrafting & Sailing Roguelike!

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.

Every island there is adventure waiting! Will you get a new spellbook page? Perhaps a talk with a stranger? Who knows!





Her story

The game takes place through the character of Clarice Clairvoyage, a young mage in training who is the only one left after a small crisis hits her home island and all of her friends and family are abducted, never to be seen again. In her bravery, Clarice collects what's left of her home and with an old ship she crosses the seas where she might find her family and friends again!

State of the project

I started this project in mid-winter last year. I'm planning on keeping the project relatively small and short, hopefully being done before the end of this year. It's not my full time job to work on this, nor do I have a lot of funds or time to spend on it, so progress will undoubtably be slow. I've already started to get the game out there and I'm trying to let it get known amongst some roguelike enthusiasts or other indie game players.

There's no playable build as of now, but I'll work hard to have at least something playable in the near future. If you're interested in looking at some of the development, I also stream some of the gamedev from time to time, so check out my Twitch to see when you can join me on the next session!

If you have some advice on the project, or if there's something you want to critique, feel free to leave a reply, email me or reach out on Twitter!


Cart #clarice_clairvoyage_2-0 | 2021-02-20 | Code ▽ | Embed ▽ | No License
2

Heads up, the game is far from a playable state, I just wanted to kind of start a devloggy kind of thing on this forum!

Please let me know what you think, I'd love to hear your feedback & thoughts!

P#87936 2021-02-20 16:49 ( Edited 2021-02-27 15:05)

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!


That's it for today, I might do another small update tomorrow or go a little bit more indepth on the island generation soon.

Thank you so much for reading, feel free to leave a comment if I'm a little vague or if I didn't write something clear enough. Also feel free to message me any time, on any platform with questions!

Cheers

  • Bram
P#87937 2021-02-20 16:50
1

This game looks really cool. Good luck :)

P#87940 2021-02-20 16:58


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:

  1. It had to run on PICO8, meaning the design of the system/algorithm shouldn't be too complicated or code-heavy
  2. It needed to fit the gameplay context of a ship and an island-y overworld
  3. Every playthrough needs to be different in gameplay outcomes

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:


Cart #procedural_islands-0 | 2021-02-24 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA
4
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!

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!


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!

P#88256 2021-02-27 15:04 ( Edited 2021-02-27 16:53)

[Please log in to post a comment]

Follow Lexaloffle:        
Generated 2021-02-28 06:00 | 0.025s | 4194k | Q:46