October Update

Hello again, everyone!

This was a fairly busy month for me, but I managed to still make some progress on my projects! The big update is about Stackamsels, that is now closer than before to being in a releasable state (though there's still work to do), but I also added a lot of interesting things in Project Mirabelle to develop one single test feature, and made a little bit of progress with Galactic Empire.

And of course, there's another big announcement about the ways to talk with me, due to recent changes happening with Discord.

Here's the summary of today's blog post:

Blog renaming

So, you might (or might not) have noticed, but I renamed this blog from "Project Mirabelle Blog" to "Sleepy Place Blog" (and I changed its url from /project_mirabelle_blog/ to simply /blog/).

This isn't actually a big change, it's just a more accurate reflection of a shift towards what this blog post is.

Originally, this blog was exclusively about Project Mirabelle because it was a way for me to POSSE (Publish on my Own Site, Syndicate Elsewhere) my ongoing progress about that specific project. Prior to starting this blog, my progress about Project Mirabelle was posted only on Discord (and even more worryingly, was spread over several Discord servers). But then, back in january 2025, I felt that relying on a single website I didn't own or control as the only way for people to know about what I was doing was a bit risky, especially in a space where platforms love to delete your things just because they don't like it. I didn't take this decision for any particular reason related to Discord (not at the time at least), but because we all saw what happened to Tumblr, then Facebook, and then Twitter, the "threat" of not owning my own content was everlooming anyways.

So I whipped together a quick blogging "framework" (barely a thousand lines of node.js, really) in half a day and then spent the rest of the weekend creating backdated "blog posts" that summarized the past year and a half of work. This was about summarizing my instant message ramblings and re-hosting the images and videos that only the Discord servers had stored, ranging from the start of the project to the start of this blog in January 2025.

After this, I tried to make the Project Mirabelle blog the first place where I'd post updates, following up only afterwards with posting my blog posts to my usual Discord haunts. My idea was simple: every "relevant" image or video that I posted publicly on Discord about the project should make its way to the blog (if it wasn't posted to the blog first). I have no idea how it was received at the time and I still don't really know how people feel about it nowadays, but I feel like having a real "home" for my updates was better overall.

As months and years went on, this whole thing shifted. First, I got a bit more "cautious" about the blog posts I made, trying to avoid "microblogging" about Project Mirabelle and making combined blog updates instead. Second, mentions of other projects started leaking into these blog posts. The main topic was still about Project Mirabelle, but my main focus still is about Project Mirabelle anyways, so that ended up being more of a representation of what was happening with my personal projects anyways.

With these recent monthly updates, I felt like calling the blog "Project Mirabelle" was less and less true since, in addition to writing about other projects, I was talking more and more about "random things". Ever since then, I've thought about renaming the blog, but it never really felt like the right time to do so.

It's now the right time ; because there's another change that I made to the blog (and my website as a whole), which I'll talk about now:

Fluxer alternative to Discord

My website and projects ended up, a bit by accident, very Discord-centric.

It started with me making the Bondage and Damsel in Distress games list in August 2023. This project is a way to replace the spreadsheets that floated around the DiD Games Discord server, listing games that are DiD-centric and that people would constantly ask recommendations about. The spreadsheets worked, but the contents were often outdated, leading to several "alternative" spreadsheets being shared around to "add more content" that also ended up abandoned after a bit. My goal with the games list was therefore to give everyone a way to build a "better" version of that spreadsheet, except that this version would be "up to date" due to it being dynamically edited by everyone who wanted to add to it (even if it's often just me maintaining the site, it's not only me that can do it and that helps a lot). And (like all of my random projects), it ended up as a page here on sleepy.place just because I could easily host it here.

To reach a balance between spam protection and ease of use, I decided to use Discord as the "account system" of the games list. It has worked extremely well so far, and the games list has been fairly popular in various circles without having any spam issues (so far, fingers crossed that it holds ; I have tools to deal with it if it happens but I'd rather not have to).

A few months after making the games list, I added an experimental Multiplayer mode to Project Mirabelle as a way to play around with networking game code and just to see if I could do it. Again, this required me to have some sort of account system, but since I already had the code to handle that through Discord from the games list, I just literally copied chunks of that code and integrated it into a small routing server for Project Mirabelle.

And so, I ended up relying on Discord accounts for everything multiplayer.

However, you might be aware of the recent issues with Discord. The most blatant one (and the most impactful one) is the push towards mandatory "identity verification", where Discord requires giving either your ID or a video of your face to another, for-profit company in order to access some of their features. Now, I don't know about you, but given that I'm paying $0 to use Discord or that "age verification" system... I'm not really sure how they're going to use that to make profit without using the "identity verification" stuff I'm giving them. And I'm not waiting to find out to who they are planning to sell my identity to in order to make their money.

The other semi-pressing issue with Discord is their upcoming Initial Public Offering (IPO).

Financial details here: An IPO basically means that Discord will stop being a "private" for-profit company (where the CEO decides where and how to make money), and will instead become a "public" for-profit company (owned by "the public" who buys part of Discord's control as "stocks" on stock exchange markets). Now, Discord was already venture-funded (basically, private investors giving money to the company in exchange for getting some shares "for free" when it does a IPO), so the CEO was obligated to go public from the start, but the main issue with an IPO is that after it happens, the CEO of the company no longer has any power in how to run Discord in order to make it a better place for people to hang out in. Instead, after the IPO, the CEO will be obligated to pick whatever option that leads to the most short-to-medium term profits for the Discord shareholders.

Again, if that's a lot of financial mumbo-jumbo to you, the summary is that after this famous IPO, then Discord will legally have to extract as much money from you and your data as it possibly can.

Not a comforting thought, especially right after they tried to get your personal data such as who you legally are and/or what you actually look like.

Now, maybe all of these things happening to Discord aren't a dealbreaker for you, and maybe having everyone else there is too convenient and the threat too "vague" for you to want to leave Discord. But what's important to me is that you have options when using what I create, and options that (ideally) don't force you to give data to a company that legally has to extract as much money as possible from you. If I want to be cynical about it, I'd say that I don't want to force you to make Discord earn a lot of money without Discord even giving me a share of that money ; but I'm more idealist than that and I just would prefer that you don't have to do it just because extracting money like that is a slimy practice that I dislike.

The issue is that, well, Discord is kind of the only game in town today in terms of seamless instant communication for communities with flexible memberships (lots of words to mean "Discord-like servers"). Historical alternatives like Discourse, Matrix, Mumble, or Teamspeak are clunky because they're so decentralized, "professional" tools like Slack are expensive (and also uncomfortable and too decentralized to be useful here), and the only real "direct competitor", Stoat (formerly Revolt), never really picked up steam (in addition to stability issues) to really become a viable alternative, in my opinion.

Fluxer is trying to be another player in the "Discord clones" space, but also something else that's a bit more than "just" another player. In some ways, Fluxer is to Discord what Bluesky is trying to be for Twitter ; an alternative that's providing the same features, built by people who know what they're doing, without the same immediate risks that the existing player has, but with the additional characteristic of trying to build technology in a way that would prevent them from creating these risks in the future. Bluesky does that through the AT protocol, and by fragmenting its core technology into non-profits such as the PLC Organization (an association in Switzerland that isn't affiliated with Bluesky), and the "credible exit" principle where they're built in a way to make attempts at enshittification very, very expensive for their company. Meanwhile, Fluxer is doing that through being a private, sustainable for-profit "pop and mom shop" business model without VC funding nor public trading, adding easy self-hosting abilities, and ongoing integration with the polyproto protocol to seamlessly join communities hosted by other companies than Fluxer.

I'll talk more about the technical and social details of these protocols (and other alternatives for both Discord and protocols who aren't relevant here ; I didn't miss Armada but I can not recommend or promote using it at the time) in a future dedicated blog post about federation and decentralization in the era of for-profit censorship, but that's not really a point I want to make here anyways.

My main point is simply: Fluxer is trying to be a better, healthier Discord, and so far, I have reasons to trust it more than Discord (or Stoat) about its ability to both become and stay a better Discord. All it's missing is for people to join it.

And that leads to something simple. Starting now, you can now login to the games list or to the Project Mirabelle multiplayer mode using either Discord or Fluxer. The additional good news is that I set up the code so adding new login systems beyond these two is (relatively) trivial to do, and so if other options become relevant later, I could simply add them.

In addition, I now have a Fluxer community for both Project Mirabelle and the sleepy.place projects in general beyond just Project Mirabelle. I'm not yet sure of the fate of my existing Discord server ; I am keeping it around for now, but I'm also debating switching everything to readonly and redirecting people to Fluxer right away. What's sure is that, the moment Discord refuses to let me use its services to post about my own projects without providing it with either my ID or a scan of my face, I'm not using it anymore. I'm just already pre-emptively taking steps to ensure that it will disrupt my interactions with everyone that would want to talk with me as little as possible.

It's unfortunate (and annoying) that I, and really that we, have to prepare to move away from Discord. It really managed to revolutionize instant communication, in a way that's overall positively impactful, and sometimes for much more than "just" gaming. But no public for-profit hyperscaler can stay good forever, as we learnt over and over again, and the best we can hope for is to pick solutions that don't have the same risks in the future.

Stackamsels Progress Report

For those who have only heard about it in passing, or as a reminder because it's been a while, Stackamsels is a small top-down incremental game where you drag damsels around to process and sell them, and then use the money to capture more damsels and increase your profit.

It's nothing groundbreaking, but I think it's a pretty cool little project. Also, it has a lot of great art drawn by NightingaleTide.

Over the past week(s), I have done some work on Stackamsels. My goal was to try to "finish" it, by adding the main features that were obviously missing and "polish" the entire experience. I didn't manage to actually do that before moving back to other things, but I'm closer than before to having it done at least!

The five main changes I did were:

I added the "bike" and "motorbike" vehicles (that Tide drew and animated literally years ago, but that I never came back to implement):

I reworked the existing machine assets to make them prettier once zoomed in instead of being heavily pixelated as before:

I added a new "early game" way to ship damsels through delivery trucks, removing anything that looks like it could be automation until you unlock it in the late game (that truck's artwork is mine, hence why it looks a bit wonky):

I also added a new "vibrator" item and associated effects/facial expression that can be used to increase the sell price of a damsel (itself being sold for a price):

And finally, I did some work on drop shadows to make the items and damsels "appear" like they're floating above the ground when you pick them up:

This means that I'm close to having "everything done", but I'm also not that close to complete it. The tasks left to have Stackamsels ready for release are mostly one "big" feature that I want to finish, and then they are mostly a lot of details that I've been dragging my feet about.

These tasks are:

It's not really that complicated, and really, it shouldn't be that much work (except for the sounds, I'm sure I'll need help with that), but I just haven't gotten around to doing that just yet. I'm taking a break from Stackamsels at the moment, but maybe soon, hopefully!

A short Galactic Empire remake update

I unfortunately don't have as much to say about the GE remake as I hoped I would by now. The summary of this month so far is that:

I unfortunately don't have much to showcase visually for this update, except for this meme idea I posted about as a response to something else:

This was mostly just done as a meme, but also a showcase of what I can make happen quickly after the internal work I did earlier. Pretty sure it won't actually be in the game, but who knows. Maybe I'll get bored enough one day to actually find a way to make fishing happen and have it "make sense".

Project Mirabelle x Bondage Idler minigame

So, first, here's a quick anecdote about this very blog post. I was "supposed" to release it a week ago (or at least, I was aiming for that), and I had almost everything written down and was ready to do so. And then I had an idea of something to do that would be cool and that I would like to showcase for this post. I thought it would take me only a few hours to make, so it should be fine to do that real quick before publishing the blog post, right?

Yeah, that worked out as you'd have expected.

A few years ago, I made a game called Bondage Idler that's a pretty simple incremental idle game about an explorer wandering through a dungeon and stumbling upon either loots or traps. It's visually very bare, with the entirety of the "graphics" being the map UI and one single three-frame animation that you see on struggle, but that project was more about the concept than the visuals anyways.

So, my idea was to recreate Bondage Idler but inside of Project Mirabelle. And this is now done:

The main difficulty of recreating it was, unexpectedly, the number of missing assets in Project Mirabelle. Indeed, in order to make it happen, I had to create all of the binding variants in Project Mirabelle to handle showing them in the game. Such as "wrists and legs tied", or "only knees tied".

This required adding four new "packs" of animations, so this took some time.

But then, I had another issue. In the original Bondage Idler game, the bindings are split between "arms" and "wrists", with both being able to be undone separately. I could "work around" it a bit by requiring the arms tie to be removed before the wrists tie (because I had the wrists tie ready), but it wasn't really a "nice" experience to use the existing boxtie stuff and then transition to a wrists tie after undoing it.

So I just added a brand new type of tie instead: an elbow tie.

This required creating the new binding assets, weightpainting it, doing all of the morphs to handle the various appearance modifications, and another three new "packs" of animations to handle all of the related poses, so this took quite a bit of time as well.

And finally, I needed even more assets for the blindfold/gag struggle animations with hands untied

Well, saying "finally" is maybe a bit too optimistic. I did need to add some prototype mittens (again, to match the Bondage Idler mechanics)

As well as some world assets such as chests

This was then enough to actually recreate the entire game inside of Project Mirabelle. That "reconstruction" work took me about half a day, which was my original guess, but it did need everything else to have been created first.

You can play the "test map" here if you want to, however, please note that this is very much a test/debug level thing and not complete in any way. It's not just that you might encounter bugs (you might/will do that, of course), it's more that this will probably not really be "fun".

But I think that there's potential there, either by reworking the "loot table" and powers in several ways, or maybe by adding some new mechanics to it (such as interesting visual powerups, or an endurance system, or some survivor mechanics where you have to avoid enemies chasing you in the dungeon).

I'll leave you with a short video of me playing through the prototype so far!

Ramblings: Difference between game and sofware code

So, as a lot of people might expect, videogames and software are similar in many ways but also very, very different. This specific point came up in at least five different situations over the past few months for me, so I thought that I could write up something about it real quick to both put my thoughts down somewhere, and also maybe help other people develop their own point of view about it.

First, some clarification about what I mean: while "software" is usually referred to anything written using computer code that can then be modified only by changing that code, and while "videogames" are a specific kind of software, here I do mean "software" as saying "software that's not a videogame". I'm talking about email websites, word processors, drawing softwares, 3D softwares, game development studios (like Unreal, Godot, Gamemaker, Unity, or RPGMaker), web browsers, operating systems, simulation tools, chat clients, etc etc...

In a way, the distinction and the line to draw here is more between "software to execute a specific task" vs. "software as artistic expression by itself".

Putting it this way should make what I explain afterwards pretty obvious, but also, that's kind of the point I wanted to put forward anyways. So if you agree with that, with videogames using the concept of "software" differently than anything else, then that's excellent! Do read on if you want more details though.

So, the first, and central, difference between games and software is the rate of change for both of them. While software is rarely ever "done", especially today with auto-updates and security patches, games are even more different in that potentially anything could be changed without making it lose its main goal of being art. Movement code, interactions, weapons, UI, everything in a game could change at any time for any reason, and it would be the right call to do so because of that change matching the vision behind the art better - or because that vision evolved through playtesting! This means that games are "flexible" by design, they need to adapt to any future idea easily.

By contrast, software often has one theoretically "good" solution, and then the goal of any future changes are to strive to reach that solution. UI redesigns are not often done because of some artist's vision for what that UI should look like, but because that UI is a "better", "clearer" solution to providing users with the features they want to access. Of course, sometimes the change is due to a new vision, but that's because all software is art ; the main point is that this is much, much less frequent for non-game software compared to games. Instead, software aims to be "stable": reduce risks, bugs, crashes, and usability issues, and once these are reduced, make sure they can't reappear.

So, software aims to be "stable", but games aim to be "flexible".

The second difference, which is more minor and technical but also related to this first point, is that software code is written to be read and understood later as changes need to be made, while game code is written to be discarded when it doesn't fit its purpose anymore. The so-called "read-write ratio" of game code is actually insanely small compared to the "expected" 10-to-1 ratio of other software, and that means that game code is "allowed" to be messy or repetitive or just ugly in general because it's not really meant to be re-read and modified, instead, it's supposed to serve its purpose and then to be thrown away.

Then, as yet another difference, you get to testability and testing, and I think that's where the difference in goals has the most impact. Modern software (hopefully) has automated tests ; basically a series of small "programs" that takes part or all of the software and run it through some known "scenario" to see if it actually behaves correctly in this specific scenario. This takes the form of "unit" tests (basically, tests running tiny little pieces of the software's code to see if they work), or "end-to-end" tests (tests that take the software as a whole and "pretend" to be a human clicking on buttons to see if it does exactly what it's supposed to do). These tests are very useful, essential even, to make sure that the software works and keeps working in the future, but importantly, they're "fragile": tests (especially "end-to-end" tests) will absolutely break and stop working if you change the parts of the software that are being tested, at which point you have to delete the old tests and write new ones instead, hopefully without making mistakes and testing the software incorrectly. And this means that rapid changes make tests more or less useless, since you'd just add twice the amount of work for barely any benefit. This is why games very rarely have automated tests, as opposed to software.

The final thing is the amount of "specific" code present in games, compared to "reused" code in software. Of course, both software and games heavily reuse code made by other people ("other people's code" is often called either "libraries" or "frameworks" depending of the technical details of how it's used, and both of these are used a lot in games) ; but when creating "new" code specifically for the project at hand, software code tends to be reusable while game code tends to be specific. This again relates to the very first point, where games are flexible while software is stable, which means you're more likely to change any part of the game at any point and shouldn't spend time on architecturing it correctly, while you can take care of keeping your other software's code "clean". But here, more specifically, that means that a game is more like an experimental art piece made of a collection of "one-shot" code, while software is more like a modern building requiring solid code foundations and reusable standardized pieces being used everywhere.

To summarize, then:

And that's the major difference between writing game code and software code.

Now, one last thing, here, that's relevant to my own projects. I have talked before about adding tests to Project Mirabelle, and creating reusable structures for the map format, and a lot of other things like that. This seems quite opposed to what I said right above, right?

Well, that's why Project Mirabelle is first and foremost a game engine, and not really a "game" per se. If anything, the bondage idler minigame inside of Project Mirabelle that I talked about above is much closer to "game code", which means it's around 2500 untested lines of code that aren't meant to be easily "maintained", but can easily be changed if I need to do so. Project Mirabelle as a whole, however, is about taking these bunch of lines of code, and turning them into code that can be reused (by other people, but mostly by me) later as a "framework" to build a game with.

By opposition, my other projects, like Stackamsels or Galactic Empire, don't have any tests and barely any reusable components, with both having lots of almost copy-pasted code all over the place just to handle minute difference of behavior between the two cases. Again, this is the more "normal" way to make games, and this is something that allow both of them to be developed and improved much "faster" than Project Mirabelle is (when I work on them). That's the main point of writing game code this way, after all, so it's a good thing I have some "sane" game projects that actually rely on that.

Games I've Played: Tomb Raider (2013)

Earlier this year, i've decided to try actually playing through the first game of the "new" generation of Tomb Raider games: the 2013 game that was called "Tomb Raider" (confusingly so, but also, unfortunately, a normal practice at the time).

I had seen a bunch of gameplay of it from wayy back when it came out, and I do recall the core of the story beats, but I was still a bit hazy on how it all played out. Given the recent popularity of Lara Croft with the upcoming Legacy of Atlantis game, given a fanfic I read that involved the characters from this specific "reboot" series, and given that I remembered the game having some "stealth" sections that I wanted some inspiration from, I did want to play the 2013 opus myself to see what it's like today.

It's a somewhat interesting game, but not really that special either: the game is more than ten years old, and it shows. I haven't actually progressed that far in the game (I'm about 40% of the way through, I believe), but at this point I won't finish it anyways.

The stealth sections are "interesting" in the way that they showcase how AAA cover-shooters do their own style of stealth, but that's really really not interesting gameplay, and more of a "least hard to play" kind of stealth gameplay instead. It's insanely forgiving, to the point where I can see the hand of the designer that tries to make you feel like you're hidden without needing you to actually do work to stay hidden, and it's carried a lot more by the scenario and the environment than by the player's actions. There's a reason these stealth sections are short in Tomb Raider, because they can't be longer than that without boring the player (and probably blowing up the budget of the game) ; though, impressively, they do work very nicely, and it's honestly a bit uncanny to see that kind of subpar gameplay feeling "good" to play through after reading and learning so much about how to design good stealth gameplay.

The platforming kind of plays itself, where you have some pathfinding to do but not enough depth to make it a part of the gameplay you'd remember. Same with the rest of the game, really ; you're lead forward by lit up paths and markers (we're fortunately not quite at the "yellow paint" era yet, but this game is nearly going there and it shows). The "open-ish world" sections are empty and under-exploited. And the cutscenes are pretty well made, I guess, but they're unfortunately quite dated in terms of SFX (as is the whole game), and so it really doesn't have the impact today than it would have had at the time.

Given that the only things I don't remember are details of the story, I'm not invested enough to keep playing through it controller-in-hand. I might just watch a playthrough of the second half of the game to catch up on it.

I don't think I regret trying to play it, but that's more of a "me" thing than anything. Unless you're a hardcore fan of the character/series that somehow hasn't played this opus, I don't think you're missing much by not experiencing this game holding a controller. Just watch a playthrough instead, probably.

Conclusion

For the people wondering, no, the "drafted section" I talked about last week wasn't about testing ; it's still drafted and has been pushed back one more month. I think it'll be the right time to publish it then (I should have all of my thinking "done" at that point), but we'll see. I have also added a second draft rambling to next month's blog post plan, so I should have content to talk about at least :)

I'm probably still going to be busy next month, unfortunately, which is especially annoying because I have commitments on personal projects that I haven't really been able to motivate myself to start on ; so I end up only doing things when they grab all of my focus. As we're coming up on November which is usually my "worst month", it's very likely that I'll just slow down anything related to personal projects altogether, but I'll just take things as the days go. And in any case, I'll let you know about anything worth talking about in the next blog post!