Hey there! I'm working on a small PICO8 Spellcrafting & Sailing Roguelike with the working title of "Clarice Clairvoyage"!
This is a relatively old version of the game. I'll remove this message if it's up to date!
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!
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 game is made using PICO-8 a small retro gaming console that never existed. 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 :)
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.
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!
Also, follow the project on Twitter!
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!
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!
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
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 :)
- 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!
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.
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.
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!
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!
- 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):
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!
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!
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!
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:
- 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!
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!
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!
- 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!
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.
- 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!
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!
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!
- 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!
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.
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!
[Please log in to post a comment]