In our last update, we were preoccupied with the identity of our heroes—Aric, Mira, and Dawn—and the struggle to ensure the Narrator recognized them correctly. We were teaching the engine how to see them. Now, we are teaching the engine how to respect the consequences of their existence.
The transition to v0.5.0 is less about a “big release” and more about bringing order to the chaos. We have officially moved to a unified engine. Whether you are playing on your desktop or via an Android device, the heart of the game—the logic that drives the world—is now one and the same. We’ve effectively bridged the gap between two different interfaces, ensuring that the adventure doesn’t change just because you switched screens.
But a unified engine is useless if the rules remain a mess. This is why we’ve introduced the Combat Arbiter. While the Narrator continues its improvisational dance, providing the prose and the atmosphere, the Arbiter has taken over the “hard” math. It handles enemy encounters, calculates official hits, and resolves damage. This separation ensures that while the story can be as fluid and unpredictable as a DM’s whims, the mechanical outcomes remain consistent and fair.
To make these mechanical moments feel less like a spreadsheet and more like a tabletop session, we’ve brought the dice into the light. We’ve implemented shared animated 4d4 dice. The logic is synchronized: the numbers are calculated by the Arbiter, but the visual ritual—the slow roll, the staggered stops, and the golden flash of a natural 4—is shared across both platforms. It’s a small touch, but it turns a calculation into a moment.
We’ve also refined the Validator. It’s getting smarter at distinguishing between a player’s intended action and the natural movement of NPCs or companions. We’re trying to prevent those frustrating moments where a simple sentence triggers a cascade of unintended rule checks.
As for the technical side, the numbers are encouraging: 376 pytest cases passed and a successful Android build. It’s a solid foundation, but we aren’t claiming victory just yet. We still have significant manual work ahead of us: we need to verify the APK signature, conduct full manual playtests of the combat loop, and ensure our new save-migration system—designed to protect your progress from the 0.4.1 era—works flawlessly in the real world.
The engine is unified. The rules are being codified. Now, we see if the story can keep up.
Building a simulation is a continuous process of refining small details. With the core systems of NEREIDS (the project formerly known as SUBSIM) now functional, our focus has shifted toward the command console. We’ve been spending time moving away from generic UI elements and toward something that feels a bit more cohesive.
Interface Refinement & Visual Assets
If you’ve been following the progress, you know the SEAFLOOR station was a major milestone. While it works, it still feels a bit like a prototype. We’ve been working on replacing those placeholder elements with custom-designed assets. We’re adding dedicated textures for knobs, sliders, and various status displays, along with more defined framing for the UI panels.
The goal isn’t just aesthetics, but creating a more integrated “hardware” look. We’ve also introduced specific color-coded modes for the SEAFLOOR interface to help make the different operational states a bit more distinct at a glance.
Control Updates
We’ve also added a small quality-of-life feature to the vertical controls. A right-click on an active vertical slider (like the HEAVE control) will now trigger a quick reset, snapping the value back to zero. It’s a simple change in the code, but it makes navigating the controls a little less tedious once it’s fully integrated into the game loop.
What’s Next?
The pieces are all there in the repository, but they still need to be brought together. Our next step is to run the whole thing in Godot to see how these new assets and controls actually behave in a real gameplay scenario. Once we’ve had a chance to play around with the implementation and ensure everything is stable, we’ll move toward the next official release.
In our first Devlog, we discovered that giving an AI the ability to improvise a world is relatively easy.
Getting it to remember that world is considerably harder.
Apparently, pictures have the same problem.
Meet Aric, Mira and Dawn
Every Dungeon Master needs some characters to make their life unnecessarily difficult.
Ours currently has these three.
Aric is our human knight and player character.
Mira is an elven scout travelling with him. She has already demonstrated the useful ability to notice things Aric doesn’t — which also means our Dungeon Master has had to learn that sometimes she should roll the dice, not him.
And Dawn is Aric’s horse.
Dawn should theoretically be the easiest of the three for an AI to understand.
She is a horse.
This assumption turned out to be optimistic.
Aric
Aric. Human knight. This is what he is supposed to look like. Please remember his face. It will become relevant shortly.
Mira
Mira. Elven scout, archer and companion. Also, definitely this person.
Dawn
Dawn. Horse. So far, arguably the easiest member of the party to recognise consistently.
Then we asked ComfyUI to illustrate the adventure
This is where things become interesting.
AERIS can take what is happening during the adventure and ask our local ComfyUI setup to turn the scene into an image.
The results can be surprisingly good.
They can also be surprisingly confident about things that never happened.
Aric and Mira during the adventure. Probably. At least there are two people.
The problem isn’t really generating a nice-looking fantasy image.
Modern image models are already rather good at that.
The difficult part is something much less spectacular:
Making Aric still look like Aric.
And Mira like Mira.
And keeping their equipment, clothing, position and even the number of people in the scene reasonably connected to what is actually happening in the game.
Apparently, “Aric standing next to Dawn” and “Aric riding Dawn” are two entirely different concepts.
Who knew?
Character consistency is more of a suggestion
And if we let the process wander far enough, eventually we get something like this:
Aric, Mira and… we’re going to need to check the guest list.
It’s a perfectly respectable fantasy image.
There is only one minor problem.
We have absolutely no idea who these people are.
Somewhere between the game state, the scene description, the image prompt and the diffusion model, our cast appears to have been quietly replaced.
Nobody informed the Dungeon Master.
Pictures need a memory too
And this brings us back to exactly the same problem we encountered with the Dungeon Master itself.
Something being plausible isn’t enough.
A new image can be beautiful, atmospheric and completely believable as fantasy art while still being wrong for this particular adventure.
So we’re experimenting with more consistent character descriptions, explicit scene information and a small quality-control step that can check whether the generated picture actually resembles the world AERIS intended to illustrate.
We’re not trying to make every image identical.
Variation is part of the fun.
But slowly, we’d like Aric, Mira and Dawn to stop feeling like three prompts and start feeling like the same three characters travelling through the same world.
The world can be improvised. It shouldn’t be randomly replaced.
Which, now that we think about it, is pretty much what we’re trying to teach AERIS in the first place.
Dawn, meanwhile, would presumably just like everyone to stop using her for software testing.
All images in this post were generated locally with ComfyUI.
When we started experimenting with AERIS RPG, the idea sounded fairly simple:
Put a local language model behind a fantasy RPG and let it be the Dungeon Master.
Easy.
Well, no.
It turns out that getting an AI to write like a Dungeon Master is surprisingly easy.
Getting it to behave like one is something else entirely.
A story generator isn’t a Dungeon Master
A language model is perfectly happy to describe a dark forest, an abandoned village or a suspicious-looking stone.
And it’s often very good at it.
But a Dungeon Master does something more interesting.
Imagine the DM casually mentions a lantern appearing at the top of an old ruined tower.
Maybe it was just atmosphere.
The player, however, stops.
“Who lit that?”
And suddenly the lantern matters.
Perhaps the DM had absolutely no idea who lit it five seconds earlier. That’s fine. A human DM can improvise an answer, connect it to something else happening in the world and continue.
But from that moment on, the answer becomes real.
The player saw the lantern. Someone — or something — presumably lit it.
Whatever the DM invents next must now coexist with everything that has already happened.
This is the part of tabletop role-playing that interests us.
Not generating an infinite amount of fantasy text.
Improvising a world and then respecting what has become true.
AI has a conveniently flexible memory
Our artificial DM is quite capable of improvising.
Sometimes a little too capable.
Tell it that the player has cut a tripwire and it can produce a lovely description of the trap being disabled.
Come back a little later and there’s always the possibility that our enthusiastic Dungeon Master will dramatically discover…
…the same tripwire.
Apparently it repaired itself while nobody was looking.
Funny during development.
Probably less funny after ten hours of adventuring.
So AERIS is slowly becoming a hybrid.
We want the AI to remain free to invent characters, places, events and consequences. But some things cannot remain merely suggestions floating around inside a language model.
If the player takes an object, somebody owns it.
If Aric gets off his horse, he is no longer riding it.
If something is broken, opened, discovered or destroyed, the world should remember.
And if an apparently meaningless lantern becomes important because the player decides to investigate it, perhaps that lantern deserves to become part of the world’s history too.
The complexity should be in the DM, not in the rules
This has led us to one of the principles we’re using while developing AERIS:
The complexity should be in the DM, not in the rules.
We don’t want to solve every possible problem by building an enormous traditional RPG engine underneath the AI.
The rules should remain relatively simple.
The difficult part should be teaching the artificial Dungeon Master when to improvise, when to remember, when to ask for a dice roll, when to accept what has already happened and — perhaps most importantly — when not to invent something.
We’re still figuring that out.
And occasionally breaking it.
Then we gave it pictures.
Because apparently one AI-related problem at a time wasn’t enough.
AERIS can also ask ComfyUI, running locally, to generate an image inspired by what’s happening in the adventure.
Sometimes the results are surprisingly atmospheric.
Sometimes we get this.
One of AERIS’ early attempts at illustrating a medieval village. Everything looks perfectly normal. Please do not count the wheels.
Image generation, as it turns out, has its own interpretation of world consistency.
We’re working on that too.
The man lying next to the cart was unavailable for comment.
All of this runs locally
There is one additional complication.
We’re deliberately trying to do all this on our own hardware.
The Dungeon Master currently runs as a small local language model. ComfyUI generates the images locally too.
The machine responsible for this technological revolution is equipped with an Intel i7-8700, 32 GB of RAM and an NVIDIA RTX 2070 with 8 GB of VRAM.
So… not exactly an AI supercomputer.
That’s intentional.
There are already plenty of fascinating AI projects demonstrating what can be achieved with enormous models and expensive GPUs.
We’re interested in a slightly different question:
What can you build with the computer you already have?
A lot of people interested in local AI don’t have a high-end GPU sitting under their desk. Neither do we.
If we can eventually get a convincing artificial Dungeon Master, persistent world, locally generated illustrations and an actual playable RPG running on this machine, that’s arguably more interesting to us than discovering that it works on hardware costing several thousand euros.
So far, the answer seems to be:
quite a lot, provided you’re willing to argue with an AI about horses, daggers, previously cut pieces of string and the generally accepted number of wheels on a medieval cart.
The RTX 2070 has not been consulted about any of this.
We’ll keep experimenting.
Next time, we’ll introduce the three unfortunate individuals currently being used to test all of it:
Back in 2020, we wrote on this website about experimenting with an RPG. Six years later, apparently we still haven’t learned our lesson.
So we’re doing it again.
This time we’re experimenting with AERIS RPG, a small project built around a simple question:
Can a local AI actually behave like a Dungeon Master?
Not just generate fantasy text, but improvise, react to the player, remember what happened and somehow keep an adventure coherent while the player does everything the DM wasn’t expecting.
We’re building and testing it on very ordinary hardware — an old i7-8700, 32 GB of RAM and an RTX 2070 with 8 GB of VRAM.
In other words, definitely not an AI workstation.
And that’s part of the experiment.
There are plenty of impressive things being done with expensive GPUs and enormous models. We’re more interested in discovering what someone with an ageing gaming PC, some free software and an unreasonable amount of curiosity can do with this technology.
So far?
More than we expected.
We’ll occasionally post our experiments here: AI Dungeon Master problems, local LLMs, generated characters and scenes, things that unexpectedly worked and, almost certainly, things that spectacularly didn’t.
No promises. No roadmap. No revolutionary AI claims.
Just two amateurs, one increasingly worried RTX 2070, and an RPG experiment.
the deadline of MC sudoku publish will be delayed by a couple of days (maybe one week…).
We apologize for the inconvenience, but it’s for a good reason…
We’ve just implemented a powerful new feature: leaderboards!!!
Thank to silentwolf backend for Godot (Yes! MC Sudoku is developed with this outstanding game engine!) we’ve been able to implement leaderboards in the app without recurring to Google Service. We don’t exclude to use Google services in the future, but currently we saw some limitations that SilentWolf hasn’t.
Leaderboards for MC sudoku are more complex that we could imagine. We think we implemented them quite good, at least for a basic approach, but we need some time for beta-testing.
In a next post, we’ll try to focus a little bit more on the leaderboards mechanism, but for now here’s a quick screen-shot taken from the French version!
after a quite intense developing sessions, thanks to all the support we received from our beta testers (thank you all!!!), we’re quite proud to inform you that the first “production” release of MC Sudoku is on final approach!
Here’s some screenshot taken during gameplay!
We’ve not reinvented the wheel, but we’re quite proud of the result obtained for our first “game” app!
The launch date is expected by january ,4th…
May the New Year bring new opportunities and happyness to all of you!
if you’re here, then maybe you are one of the beta testers that is testing the release of MC Sudoku.
This is our first game and we apologize in advance if there’s still a lot of things to do! We’re quite noobs! 😉
We know it’s not an outbreaking new genre game, but we decided to start with something we like and that can give us the chance to focus on developing and designin the basic of an app rather than been forced to thing at a brand new gameplay… But trust us… we got something in mind for the future!
But now lets focus on you: you’re here (we hope!) to help us in reaching a better app, so feel free to share your opinions, suggestions and tips in the comment! They’re unvaluable for us!
Somebody could even think that we’re dead…. but nothing could be more wrong. We’re still here and we never stopped thinking about developing some software.
But life sometimes requires attention on some things and others tend to be taken apart. But now it’s time to come back on the floor! Or at least we are seriously engaged in doing so.
Well. Maybe just the perception of time passing by pushed us to come back, maybe amplified by the COVID pandemic. Who knows… but we started to develop a new app. And we began also to update the old ones!
This time it’s a game guys! A so called RPG! No intention to spoiler too much, but we intend to publish a series of post, a short of develop diary to laugh of in the future and share our progress with whoever interested nowadays.
The game development started almost five months ago. Together with the start of pandemic.
At the moment we’ve almost finished the plot and started scripting and coding. We’ll give more details about everything in the next posts.
By now, here’s a screenshot of one of the last scene we have developed, it take place in the Blindcrow Woods, a mystical and dangerous ancient woods full of magic and mysteries. Are you capable to recognise the game engine?
