We’re sorry for any disruption this caused. The version number remains unchanged, but the loading issue affecting some save files has been resolved. Here’s a quick word from our Developer:
Hi everyone,
My name is Piotr, though I usually go by my nickname: Pindwin. I lead the technical side of Inkborn’s development, and I thought you might find it interesting to learn what this hotfix is about.
Working on an Early Access title comes with many challenges, and one of the biggest is maintaining backward compatibility while releasing updates, some of which change how your game save is structured. With every update, we need to be extremely careful not to break existing saves. Normally, that’s something you do every few months - not every few days! To stay safe, we built automated systems that compare old saves with new ones, tests that try updating the game save mechanically, and so on. These have worked flawlessly, until now.
And that’s because there’s another challenge in Early Access: rapid change. Last week, when we released Endless Mode, we fell into a trap of our own making, related to how we handle save files. So how did this happen despite all our checks? The short answer: a fixed buffer size.
Inkborn uses a binary save format: each game entity is packed in memory as tightly as possible. Your cards, quotes and ideas, the generated map and shop content - all of that gets an identifier, which we later use to write and recognize the whole card. For example, Greatnib has an identifier of 5, so when we save Greatnib-related info, we don’t write the whole card, we just take 5 as a starting point and apply changes from there. The process is a little more complex, but you get the idea.
This approach keeps even large decks very compact, which makes the game load faster and run smoothly. But—yes, there’s a “but”. This whole process uses a buffer. Think of it like a trolley you use to carry items into storage: you fill the trolley, unload it, and repeat.
In our case, the buffer organizes the save file (the “storage room” in this example). We fill it with different types of items: cards, quotes, enemies, and write them to the file one type at a time. We calculated that even if a player maxed out the entire game, a 4KB buffer would be enough for each item type. So we hardcoded it to use 4,096 bytes of RAM as that trolley.
And then came Endless Mode.
One of the most memory-consuming things we store in a save is statistics. We use them for balance: if a card overperforms or underperforms, we know where to adjust. For ease of analysis, this is one place where we store the names of cards, not just numbers - so the data is easy to read on graphs. One of these stats is every card a player picked during a run. Stored in a memory-heavy way. In a run that can now go endlessly...
Boom. That’s the buffer overflowing-cutting off the card name mid-save. The result? Corrupted saves, which usually show up as combat not ending and the game failing to return to the journey map. If you try to load that save, the game crashes and gets stuck on loading.
The fix? Allow the buffer to grow if needed (from my experience, this happens around Endless 5). Unfortunately, it also means removing some of your old Endless runs.
This probably isn’t the last odd issue caused by unexpected interactions, but we’ll do our best to keep them unnoticeable. ;) I hope sharing their origin stories makes for an interesting read. :)
~Piotr (Pindwin)
❤️ Stay close to Us ❤️
【𝙳𝙸𝚂𝙲𝙾𝚁𝙳】💬 https://discord.gg/UytR7dgwtx .【𝙵𝙰𝙲𝙴𝙱𝙾𝙾𝙺】📰 https://www.facebook.com/acramdigital .
【X】🦾 https://x.com/acramdigital .
【𝚂𝚃𝙴𝙰𝙼】🕹️ https://store.steampowered.com/dev/Acram/ .
【𝚈𝙾𝚄𝚃𝚄𝙱𝙴】🎞️ https://www.youtube.com/@acramdigital6748 .
【𝙸𝙽𝚂𝚃𝙰𝙶𝚁𝙰𝙼】📷 https://www.instagram.com/acramdigital/ .
Changed files in this update