That it runs at all

A game that won’t open isn’t a game. For a few days the sixth tester package, the one for people playing on Linux, was exactly that: a file that did nothing when double-clicked and wouldn’t say why. Working out the reason was the most useful thing we did all week, and it changed how we deliver the game.

A package that wouldn’t open

On Ubuntu the package wouldn’t start. Double-click, nothing. Right-click, “Open with…”, offering only the archive manager. No error, no window, nothing to grab onto. The tester reports it, and from the outside it’s indistinguishable from “the game is broken”.

The reason was two mines on the same path. The first: the archive had been prepared on Windows, and Windows doesn’t know about Unix permissions, so the executable arrived without permission to be executed. A file that can’t be run, clicked from a graphical file manager, does nothing and says nothing. The second: the AppImage format, the one we’d chosen, needs a library that recent Ubuntu versions no longer install by default. Two different ways of failing in silence, on the same delivery.

The rule that came out of it is simple: you don’t ship a Linux package inside an archive made on Windows. And the game now comes in three formats instead of one. There’s the .deb, which installs with a double-click and adds an entry to the menu like any application: the system writes the permissions, and no external library is needed. There’s still the AppImage, for those who prefer it. And there’s a .tar.gz archive that keeps its permissions inside, as a safety net. We installed and launched the .deb on a real Linux machine: the window opens full-screen, the cover art appears, the console is clean. It actually runs.

What breaks a real playthrough

The two Linux sessions, one by Leonardo Tomassetti (William’s voice) and the other by Mario Trani on a small screen, turned up a string of flaws that had never once shown themselves on our own machines.

Picked-up objects stayed in the scene. Once you took the ratchet key, its entry kept appearing under TAKE every time you returned to the room, with a refusal where an absence should have been. It’s a venial sin and an insidious one: the interface was offering an action that no longer existed, and the player wastes time repeating it, sure they’d got something else wrong. Now a collected object stops being a target, and a container that’s been emptied stops announcing what it no longer holds.

There was the display case, which looked like it needed taking twice because it was set down on the workbench but stayed in the list. And there was a gesture that did nothing: clicking an item in the inventory lit up the frame and promised a command no verb carried out. Both are closed now, and the second put back the missing half of the command: object first, then verb, the way the old adventures did it.

From Mario came a flaw all his own, visible only as you dropped the resolution: the decommissioning notice came out shrunken, and worse the smaller the screen. The canvas was being measured with the wrong tool, the one that returns the size already reduced by the screen’s zoom, so it shrank a second time. Full-screen the flaw was invisible, which is why none of our tests had ever caught it.

Simulating a small screen

That flaw taught us something uncomfortable: we always tested at our own resolution, and problems born elsewhere stayed hidden. The ability to shrink was already there, a slider in the settings, but it spoke in percentages, and to try a 1366×768 monitor you had to know off the top of your head that it’s seventy-one per cent.

Now, in the video settings, there are four screens ready to go: 1600×900, 1366×768, 1280×720, 1024×768. The simulation is faithful to the pixel, not approximate, because the whole game lives inside a fixed 1920×1080 plane and lowering the scale reproduces exactly what a smaller screen would see. It sits in the settings and not in a hidden menu because it’s for players too, not just for us: “which screen am I simulating” is a clearer question than a percentage.

The black screen

Then came the ugly moment of the week. Checking a freshly built version, the game came up black. Not off, not in error: black, with a clean console, not a single line to report.

The game’s screen can be resized, and in one specific case that resizing could end up at zero, that is, invisible. It happened when the saved scale preference was compared against the space available in the window, and the window, at that instant, reported zero: minimised, or not yet sized by the system. Zero won over everything, and from there you couldn’t come back even by restarting. For the player, again, indistinguishable from “the game won’t start”, and with nothing to report.

There are two nets now. The cap on the scale is worked out only when the window has a real size, and a saved value that makes no sense is ignored. And the scale, whatever happens, can no longer be zero: this also gets back on their feet anyone who’d already ended up with zero written into their save, without having to delete anything by hand. It was a flaw weeks old, hidden in a line added for something else entirely. Finding it live, before a tester did, was a piece of luck we’d rather not repeat.

One build a week

All of this changed the rhythm. Until yesterday every fix became a package; now findings get fixed as soon as they arrive, but the packages get put together only once, weekly. You accumulate the work, not the flaws: when delivery day comes the game has already been in order for days, and one cumulative version ships instead of ten partial ones.

The machine that assembles the packages, meanwhile, handles Linux alone, the part that was costing us time; the Windows installer is prepared here, locally, where it’s cheaper. These are behind-the-scenes decisions, the kind you never see in a finished game, but they’re the sort of order that decides whether a one-person project reaches the end or runs aground.

Putting the hold back in order

And away from the code, the week went into putting the hold back in order. All the pre-production material (the design documents, the character sheets, the map of the ship, the texts) was taken back up, reordered and aligned with what the game has actually become, which after months of work isn’t always what the documents said at the start.

In the same motion new visual material started coming in: reference sheets for the characters, pieces the next phases will need. It’s work that won’t show up in this week’s build, but it’s what makes it possible: a game is also the ordered archive it comes out of.

A new coat of paint

And if you’re reading this on the site, you’ll have noticed it changed its face. Until yesterday it was green-on-black like plenty of others; now it’s dressed like the game’s terminal: the same cold green-aqua, an on-board clock ticking along the top, the commands framed the way they are on the bridge of the Santa Maria. The words are the same as before. The clothes changed, not what’s written on them: you read all of it as before, only now you read it from inside the ship.

Meanwhile

The week brought a package that finally opens and a handful of fewer flaws, inside a more sustainable way of working. Leonardo’s and Mario’s playthroughs are worth more than ten of our own: they let us see the ship through eyes that don’t already know where things are hidden. Thanks to both — a good part of this devlog is theirs.