Hey there! I'm working on a small PICO8 Spellcrafting & Sailing Roguelike with the working title of "Clarice Clairvoyage"!
If you get stuck you can reference the manual for help!
Gameplay
The game is centered around the concept of crafting spells by stacking different pages of a spellbook. (some of these gifs are older than others, so with old sprites)
 |  |
 |  |
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? Craft a new combination of scrolls? Solve a magic puzzle? 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 chargers with a ship she found across the seas where she might find her family and friends again!
The tech
All of the pixel and music assets are self-made, so is the code. All of the code is written in PICO8 itself and all of the PICO8'ing is done on a Raspberry Pi 400! I wanted this project to feel like a kid exploring a C64 or getting one of those BBC computers for Christmas. I was born in 1998, so I missed out on those things :)
Please let me know what you think, I'd love to hear your feedback & thoughts!
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
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:
- It had to run on PICO8, meaning the design of the system/algorithm shouldn't be too complicated or code-heavy
- It needed to fit the gameplay context of a ship and an island-y overworld
- 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:
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!
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.
If for whatever reason you do that, I still recommend reading the whole thing so that you'll know everything rather than an abridged version :)
TL;DR
- Updated Clarice's sprite
- Added Hair physics (whoooooo, fancy!)
- Lost about 1000 code tokens, meaning more space for more gameplay
- Reworked the existing spell/scroll symbols to make 'em look nicer!
New Clarice!
So, one of the first thing you'll notice in this post is the pretty GIF banner showing off a new aesthetic for Clarice! I really love how much cuter she is! I honestly didn't think I could ever come close to something being cute in pixel art; I'm a programmer nonetheless, so imagine my sense of achievement.
Funny fact: this sprite is actually inspired by the random island generation! When I was making some banners for social media and other platforms, I noticed a sprite-shaped island in the background. When inspecting that island, changed its colour and adjusted its shape, I got the new look for Clarice!
 |  |
Obviously, the silhouette of Clarice can be further improved and while making this post, I'm still thinking that there's something appealing that I didn't translate from the island onto the sprite. But that's for another update!
Hair in the wind
Some of you might've already noticed some weird new addition to Clarice, which is an extension of her hair in the game that seemingly has a life of its own.
It does! I thought I'd take a page out of the book of another great indie game which won game of the year (guess the game), and make the hair be animated based on the environment and physics of the game. Now it's only a matter of time before my game becomes GOTY /s!
So how did I do it? It's actually relatively simple, so I'll quickly walk you through what I kinda did. For those who are extra excited, you can always take a look at the actual code in the cartridge when it comes out or if you peek at my devlog over at Lexaloffle's PICO8 forums .
For drawing the hair, we're actually drawing just three small circles in pink, purple and pink again. This is to give the hair some more dimension than just 3 pink hairs. The purple circle also serves to provide some depth.
Now, we take the hair/circle that's the furthest away (aka the last one), point it in the direction of a period p and give it a radius of how far away from the character it should be. Now, when we change p, we effectively change the direction of where the hair should go:
Next up, we just place the remaining two hair circles at a fraction of the outer hair vector, and it should follow the end hair, making it seem attached. Just make sure that the fractions aren't too big or too small; otherwise, the circles of hair will disconnect.
Losing weight
 |  |
I did a major refactor of all the code to bring the token count waaay down from 7136 to 6082!
I've gutted some leftover features and dangling variables, made some code more generic and cleaned up the util functions, but dropping a full 1000 tokens while also adding hitboxes and making cool hair was beyond my expectations. Of course, we still have a long way to go with the game and having only about 2000 tokens left is still a little too close for comfort to me, so we'll see how I'll manage.
Improving graphics
Besides re-doing Clarice, I've also been busy re-doing the old assets for the spells/scrolls. The old ones were kind of just dots of colour in the middle of the page representing the element, nothing too fancy, or even exciting. I did some tests of the new versions with my friends and they seemed to think it was a major improvement on the game!
 |  |
Not all of 'em are perfect or super descriptive for the spell they're representing, but it's a good start!
Thanks for reading my devlog of this week. If you liked it (or if you didn't) or you learned something from it (or you're thinking you already knew this, but still think it's interesting): leave me a comment, show me your support! It really keeps me going with this project, honestly (kinda the only thing that keeps me running tbh)!
Thaanks, and see you next week!
~ Bram
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!
TL;DR
- Made a generator that creates the encounters, loot, crafting, puzzle & "rare" islands
- For now, I've decided to stop with streaming the gamedev
- Made a bunch of small tweaks to docking
- Made a road map towards the first few public builds!
Making an adventure generator
So first off, last week was the beginning of making an "adventure generator". This is the system that is responsible for bringing together most of the gameplay systems together in Clarice Clairvoyage. The purpose of this system is to generate the function of each island on the map making sure that the gameplay experience from island to island is consistent in difficulty. If there are any dependencies for particular bosses or puzzles, those are made available for the player through this system as well.
 |  |
This is basically a small layer on top of the island generator, also made with RNG that gives islands a function and makes them interact differently when you dock with them. For now, I've decided on several types of islands (which are color coded in the gifs):
- Combat
- Crafting
- Puzzle
- Story/Choice
Combat
This type functions a little bit differently than other islands: it isn't an island! The way that this island works is that it actually changes itself into an enemy ship and starts patrolling nearby islands. When Clarice gets too close, these ships will engage her and start jumping ship to attack her! So try to either stay away, trick them or be ready to fight!
Crafting
While the scroll/spell stacking works temporarily in combat, you can use a crafting island to permanently craft a resulting spell out of two scrolls! You can also choose to make a temporary spell a permanent one! You can only craft once per island, so make your choice carefully!
Puzzle
The puzzle island is a way to blow off some steam and get to do something else than fight. I need to invent a whole lot to make this work, but the idea for now is to make a small machine out of scrolls that have a part missing or is broken in a way that the player needs to fix. Kinda like a broken magic driven Rube Goldberg machine!
Story/Choice
As another option that isn't combat, sometimes you'll get a little text prompt with a little narrative and a decision that needs to be made. Depending on your (previous) answer(s) you might have a different outcome! Different loot, perhaps a sneaky way not to fight the boss? Who knows?
I haven't implemented most of these systems listed above, so for now it's more of an overview of what I plan to put in. I'll get to balancing the system that assigns these adventures to these islands!
Stopping with streaming (for now)
Maybe some of you have checked out a past VOD of my stream or maybe even watched live at some point. If not, I streamed some gamedev of Clarice Clairvoyage every 2 weeks on Saturday. However, mostly due to the tiring effects of the stream, but also due to lack of interest from people, I've decided to discontinue it for now. I might switch over to videos instead, like Alain is doing (great videos, btw!), or get back to streaming, if there is at least some demand for it.
Small fixes, tweaks & looking forward to a beta!
I also ran into some problems with docking, so I made a little debugger for it. Turns out I had the non-scaled/non-zoomed coordinate system mixed with the scaled/zoomed coordinate system. My bad!
In the previous gifs you also saw some grey outlines: this is because I experimented with some fog of war mechanics! Don't have anything to share on that yet. In the next couple of weeks I'll get to making some big steps toward a build that you guys can try out! So stay tuned!
 |  |
A big thanks to all the people on TIGSource that have left nice comments and having read it. At the time of writing I'm at 923 views on TIGSource, so thanks! Also, if you're a casual dweller or lurker that has checked in multiple times, let me know what you think! I noticed that not a lot of people comment over here at the PICO8 forums. So if you're reading this, feel free to leave a comment! I love to know what you think!
For this week, I want to share some progress on the adventure system I'm working on. Last week, I shared the barebones version of the overall system, so now I want to zoom in on two sub-systems that I made!
Story and narrative
Any good story has a narrative and some good world building to get you into the game. Clarice Clairvoyage should be no different. In order to make story segments work, I need to have several things setup: a way to store stories, a way to render them & a way to interact with them.
For this system, I chose to use a long array/list/table of multiline strings. Every "story" (meaning a small interaction per island) is basically 6 items out of that list. The only thing I need to do is take a random starting point that is dividable by 6 and run a piece of code that interprets those items. That sublist consists of:
- Prompt
- The correct answer(s)
- The success message
- The failure message
- Success entity (scroll/other adventure/ability/etc)
- Failure entity (remove spell/combat/lose health/etc)
 |  |
Then, I render some text and give the player the option to craft a spell based on their current inventory of scrolls/pages. When the spell is cast, it's revealed to the player if they used to correct spell for the situation. In reality, I'm looking at the 6 items to check if the result matches one of the expected ones. When it does, I give the player a reward otherwise the fail condition is met and run.
I can use this system to do small one-off choices like this, or to provide a deeper lore to the game!
Crafting
Another important part of the game is being able to craft spells together permanently. Yes, you can combine spells at any point of the game, but longer chains take time (which you won't always have)! Besides that, it's nice to sometimes not have to combine all the parts of complex spells. Some spells aren't even possible without a crafted component involved! Another use for the crafting island is a way for you to make your consumable spells permanent. Consumable spells will have a whiter looking scroll instead of the current color and can only be used once, instead of repeatedly. So will you use this spell once? Or will you wait until you come across a crafting island?
I'm already working on another overarching system that's a little bit more complicated which I'll cover next week: puzzles! I found out that the systems I'm showing you have a lot of similarities, which means smaller and more efficient code and more tokens! I'm currently hiking against a strong 7200/ą8192 tokens! Which is getting too close for comfort.
Next week, I'll share more about puzzles and saving some space off of the cartridge.
Thanks for reading!
~ Bram
First off, I want to thank everyone that's bringing the view count of the TIGSource post to ~1400 views & the follower count on Twitter to 50! I appreciate it, if you've been following along since the beginning, but havent left a comment yet, please, let me know what you think! I'm getting closer to making a playable version and with the people that commented will surely be the first few that I'll contact for a playtesting session!
TL;DR:
- Made a generic puzzle system that combines scrolls/spells
- Found out that all other (non-combat) systems can be replaced with that system
- Reduced code size by a lot
- Getting closer to all the systems being feature complete, and therefor to testing!
This week I want to focus on some improvements on one of the final systems that the player gets to interact with. Funnily enough, this system turned out to be so generic, that its gonna replace all of the other non-combat systems reducing code!
Puzzles & Rube Goldberg machines
I'm gonna go ahead and say it: I've never designed puzzles. Puzzles are hard to quantify for me yet, since I haven't spent a lot of time working on them or understanding what makes a good puzzle. Because of this skill limitation I wanted to tackle this problem from another direction. Turns out, the spell & scroll system that I have is enough of a puzzle for the players by themselves (based on player testing). Finding another puzzle mechanic would also cost a lot of code space, which I don't have.
Then I remembered about Rube Goldberg machines. You know, the ones you see on Youtube? It's basically a long string of cause and effect that bring small interactions together into a big chain of events. These machines are interesting to watch, because it's not immediately clear to what is going to happen or what is going to be the effect of some part of the machine. And here's where I found out a cheap alternative to puzzles: Make a bunch of Rube Goldberg machines, but just with pieces missing!
- I can dynamically remove scrolls from a puzzle to the scrolls that the player already has
- The player can learn new spell combinations through solving a puzzle
- It brings another layer to the spells that the player has in their inventory
Making the system
One of the first things that came to my mind, is that I can use the PICO8's still empty Map Editor to make these machines. Technically, I have all of the sprites as a single tile, meaning I could put them into this map editor and interpret them in code later. This means that I didn't have to give up more space in the form of data on the code side, keeping this system relatively lean for the amount of content it will give to the game.
The next thing was about making the puzzle "resolve" or "work". I decided on using a thing called "movers". For now they're just arrows pointing in 2D directions (Up, Down, Left, Right) that push an adjacent piece to that direction. This would cause certain scrolls to overlap and them to combine, using the already available combo system.
Optimising systems with the puzzle system
As soon as I got the movers into the puzzle system, I noticed something: the puzzle system was a seemingly complete version of a spell combining system. But up until this point I had used custom systems (that take up a lot of code) for the crafting and story systems. If I make a custom puzzle for both crafting (meaning max 2 spells) and story (meaning put any spell without knowing what it should resolve to) I can reuse the puzzle system for those systems as well, I just need to evaluate the results differently! For crafting, whatever the result is of the two spells, you just get as a new spell while removing the two parts. And for the story, I just check the result with the desired story outcome! The result is that I can delete a lot of code that was unnecessarily complex!
I still have to perfect a lot of parts about the puzzle system as well as the other sub systems in the game, so we're still relatively far away from a public build.
Public build + some thanks
I've decided I wanted to make a little deadline for myself, so as of this post I'll try to get a playable build ready for Mid April! And with that I want to thank all of the ~1400 views on the TIGSource post as well as the 50 followers on Twitter. If you're not already following, I'd really appreciate if you do, it helps out a bunch for the project in the long run. Also, if you're a regular on this post, please leave a comment to let me know what you think! Do you guys prefer the general overlook format of these posts? Would you guys prefer a technical deep dive? What should my next post be about? Let me know!
Anyways, thanks you so much for taking the time to read this post!
~ Bram
Hey guys, I took some time off last week to enjoy Easter with my family. I also didn't have enough content since I worked a bit more on the puzzle system. So without further ado, let's get into this week's devlog.
TL;DR
- I worked on enemies in the overworld; ships that sail towards you if you get too close
- I dusted off some of the enemy code and simplified it
- Made some plans to expand the game outside of PICO8
- I got vacation, so I can work more on the game for the next 3 weeks
Combat encounters and how they happen
Unlike all of the other calmer and more puzzle-like adventures in the last few instalments of the devlog, the ones that I've worked on this week are little bit more hectic for the player: combat.
In Clarice Clairvoyage, you encounter enemies on the seas and fight them with your deck of spells. This is the only part of the gameplay that happens in real time and where the combining of spells needs to happen quickly, or you might not make it! In order for the combat to have a real place in the game, I've decided to represent combat not with an island, but with other ships instead!
|  |
With an updated render call to make the ships point towards their target, they already feel much more alive!
Encounters with enemies
As soon as one of these ships gets really close, you can expect to be boarded. But boarded by what? Or by who? That's the job of the encounter generator. I basically made a list of all of the enemies available in the game, and gave them a score. When starting an encounter, I have a simple "enemy budget" that determines the difficulty of the upcoming fight. For now, a higher budget means more difficult enemies or simply more of them.
Another problem I keep running into is the amount of tokens I'm allowed to use, so making the enemy code smaller and better is a priority now. This is why I decided to remake most of the enemies that I made in the past, although their behaviour and looks don't change: a lot has changed under the hood to make it more simple and less verbose in code.
| |
Once they're boarded, it's either you or them, so prepare to stack some spells and let them know what it's like to fight against a wizard apprentice! It was really fun to see the mermaid work again; I didn't expect it to work as good as it does after a quick simplification. The enemy code is still one of the biggest and chunkiest parts of the code, so I might need to a whole lot more of simplification to make it work.
Modding PICO8 into something bigger
Okay, so I've talked a lot in the devlog about building a game within the constraints of PICO8. Honestly, it's been very fun and a little overly ambitious thus far. Clarice Clairvoyage is a game that works with several somewhat complex systems that are hard to keep under 8192 tokens of code. This is why I've decided to continue the actual full game development of Clarice Clairvoyage in PicoLove, a Love2D implementation of PICO8. This means that I get to keep working in the same APIs and aesthetic as PICO8, but take a lot more liberties when it comes to the programming of the game.
I won't do this yet, as my goal is still to make the demo of the game fit in these 8192 tokens. Instead, the additional content that the systems need (like additional spells, stories, enemies etc.) are being added in the "full" game later on. This basically means modding the PICO8 fantasy console to have a little bit more RAM and ROM. I pray that the PICO8 purists forgive me!
Vacation
I got three weeks off from my regular day job! This means that for the next three weeks I'll be able to dedicate a lot more time to development of the game. Like I said in my last post, I'm trying to have a playable demo ready somewhere mid April, so that goal is still in place. I'll be posting the same amount (once a week), however it will likely just either have more content, or more condensed content.
Thank you for reading!
~ Bram
Hey everyone. I'm a little late on this week's update; should've probably posted it this weekend. I was busy making the game and taking a little break, so it got postponed to today!
TL;DR
- Reworked spells to be more unique and bind more to gameplay ideas
- Redid a bunch of world/map rendering and enemy code to conserve precious code tokens
- Added an anchor to stop the ship at any moment and an animated sail!
Reworking spells
Some of the feedback I got from early playtesters is that the spells didn't feel or act unique in the game. So rather than relying on very similar spells to do similar things, I decided to divide the spells with different kind of functions and make sure that every element has a particular kind of gameplay flavour. Besides that, I also wanted to do a pass on the spells in general to see if I can small-ify the code a bit to conserve tokens.
I ended remaking the "Missile" spell to only work with the single fire element and made the other single element spells have radically different functions, rather than an elemental version of the missile. This also further divided the flavour of fire in gameplay, as it's not the primary element needed to do an attack. This makes sure that the different elements will communicate their function to the player and that a potential combination with fire can result into an attack spell! Also, the double fire spell results into a fire-y wave of flames! It doesn't move the sail anymore, since that functionality is dedicated to the air element!
For double water spell I decided to go back to an ice spell. This basically re-uses the fire-y flames-like spell with a colour change and temporarily freezes enemies in place, which gives you some time to combine your next spell or get away from a sketchy situation!
 |  |
For the rock element I chose to use a more defensive flavour. The original "steel" spell that I had did something similar, but now I decided to make that the base effect for a single element rock spell. If you recast the spell you just add +1 to your shield capacity! However, your shield capacity is still determined by the amount of rock spells that you have!
For a double rock spell I decided to do something a bit more funky. Double rock yields sand and when used, it slows down time! I haven't implemented this yet, but this should be one of the more interesting spells to pull off!
 |  |
Redid rendering of islands, enemies, etc.
I looked into some of the code that I used to render the islands in the overworld and figured that it used too many loops in a row. I flattened those loops and took back some tokens! I also slightly reworked the way that the data is generated for the docks and the islands themselves. This caused a lot of headache and some reimplementation of those features to use the new data format.
I also went over all the different enemies, figured out what they had in common and started stripping all sorts of code and smaller features that are either unnecessary or don't contribute anything to the gameplay. I also decided to scrap the blob enemy, as it was a little too similar to the zombie enemy.
In the end, it gave me a lot of tokens that I can use to make the rest of the game better, so yay!
Pretty sails and anchor! Oy, matey!
Some of the other things that you might've seen already in the previous gifs are the new animated sail and anchor. The anchor was a small addition to give the player a way to see when the ship is coming to a stop and give the ability to make the ship move when the player desires it.
 |  |
[hr]
That's all for now! Thank you so much for taking the time to read my devlog again. If you haven't already, please follow either me or the project on Twitter! Hopefully by the end of this week/next week I'll have a demo ready that y'all can play!
See you then!
Hey everyone!
It's great to be back making games full-time again! Since my last post back in April a lot has happened in my personal life. I had to recharge for a while and make some decisions to be happier overall. This decision has led me to get back into making videogames full-time! So without further ado, let's jump into it!
TL;DR
- Made general improvements to the game and did bugfixes
- Reworked the start of the game
- Added music
- The PICO8 version is gonna release soon & I'm working on a demo release in the near future!
General improvements to gameplay & bugfixes
When I left the game, it had a lot of functionality and semi-polished ideas that needed a lot of work in order to be reliable. Last week, I've been busy trying to pick up this work and make the game playable without running into a game breaking bug or small inconvenience. Some of these additions, fixes and changes include:
- A redone sail animation to work with the actual wind direction
- A fix for the boat turning fully for a < 5 degree turn (doing a full 360 every time)
- A fix making enemies spawn a little bit more consistent
- Make docking easier by just colliding with islands
- Screenshake when you use spells
- Reworked cloud animation in map view
These changes make the game a lot more coherent, robust and finished.
 |  |
Reworking the start of the game
A lot of work has been done to make the beginning of the game a lot more straightforward and easy to get into. The original design had the player choose from an array of randomized spells to add to their spell book. Most playtesters found this confusing and after evaluating the design, it was actually pretty obsolete. Now the player has the ability to add 1 spell to their spell book to improve their changes of navigating the harsh seas. After a first play through, the player has access to more advanced, but one-time-use spells.
Added music
I finally got over my irrelevant fears related to making music. I haven't done a lot of music making ever but I decided that this is the game where I wanted to give it a shot. This week I took that shot and got some really decent sounding tunes. They're not the best in composition and they could use a little bit more work to feel like really nice and coherent songs, but the base vibes are set!
The title track is meant for the opening sequence of the game where the player gets their impression of "Clarice Clairvoyage". Hopefully, this track will set up the expectations of the game!
This track is meant for most of the travel and sailing gameplay. This tune is accompanied by a soothing sound of waves in the game, to give the player the feeling like they are really out there, commanding their boat towards adventure.
The future, demos & more
So, now that we have most of the game ready, what are we waiting for? Well, a couple of things.
The game is still limited to the inherent limitations of the PICO8 console. Hopefully, I can release the PICO8 version of the game with most of the gameplay in there soon. Afterwards, I plan on porting the game to Love2D where we can fully explore the possibilities with the spell system and Clarice's world.
When that happens, I'll be ramping up to making a full demo of the (eventual) Steam release of the game. We're currently working on getting everything ready for the Steam page launch. When I need your help, I'll let you know!
Thank you for reading; I would really appreciate if you follow me or the project on Twitter.
You can also shoot me a message over there. Also, I'm available for hire on your Godot projects, so hit me up if you need help!
I had a really good time finishing up on the PICO8 version of Clarice Clairvoyage the last few weeks.
In this post I'll quickly go through the last things I tidied up and about some of the next steps for the project. I won't be sharing the builds of the demo just yet since the Steam page isn't live yet and I want y'all to be able to wishlist it immediately if you enjoy the game :)
TL;DR
- The demo is ready to be played and will be released soon!
- The project will be ported to another engine & is gonna be generally improved
- An extended version of the demo will be available later this year/beginning of next year
- I need you to follow me or the project on Twitter
The demo is ready!
Last time I needed to finish up on some smaller things before the demo was ready. Since then I rewrote and reworked the adventure system and reward generation. After that it was mostly about balancing the enemies and rewards so that the experience becomes enjoyable, accessible and a little bit spicy in difficulty. I also rewrote some of the music for the gameplay and added a bunch of sound effects for spells and other happenings in the game. I really learned that adding smaller sound effects and screenshake can be the difference between a fun little interactive toy and an engaging game or experience.
 |  |
Afterwards, the main priority was smoothing out the gameplay and polishing the living crap out of it. I also looked critically at some parts that I can improve for the sake of performance. I felt like a 90s programmer trying to get every ounce of performance out of an NES game. I added a few tricks like low quality rendering of certain elements when spells are used (you can guess which elements if you'd like!).
Porting the rest of the game & other future plans
It comes to no-one's surprise that there's only so much game you can cram into a PICO8 cartridge before you run out of space. I'm happy to share that the current cartridge of Clarice Clairvoyage uses all 8192 tokens it has available to it. With some updates here and there there might be a token removed, but the idea still stands: the game is too big for further expansion on PICO8.
Therefor, I've decided to port the game to another engine to keep adding content such as spells, enemies and puzzles! The base gameplay isn't going anywhere though, so if you like the PICO8 version, chances are you're gonna love the full game as well.
I'm still evaluating some choices for porting, mainly Love2D with PicoLove or using Godot with a Lua extension to handle some of the leftover gameplay code from PICO8. Who it'll be I'll announce in another post, but I assure you it's gonna be worth the switch!
All of the art, music, design and programming was done by me in the PICO8 version of the game, on a Raspberry Pi 400. And although I love getting my hands dirty and challenging myself, the rest of the development will include a lot more talented artists that can make prettier and nicer sounding things than me. A bigger version of the demo will be released at the end of this year or the beginning of the next. Besides that, I'll be switching to my Macbook Air for the rest of development which has a slight performance increase over the Raspberry Pi ;)
Thank you all so much for following me along thusfar
If you're not already following me or the project on Twitter, you should! I really need your support over there. You'll also be in the loop on when the Steam page goes live so you can further support me!
If you're reading this on the PICO8 BBS forum, this will be my last devlog on here since my PICO8 journey ends here. However, I'll be back in a few days/weeks to share PICO8 cartridge with you!
Thank y'all so much!
[Please log in to post a comment]
