SEEDS: A Space Game Whose In-Game Computer Is a RISC-V VM Running Real Linux

Most games with an 'in-game computer' fake it. The terminal is a scripted widget, the commands are a lookup table, and the moment a player types something the designers did not anticipate, the illusion breaks. If you want players to actually write code inside your game, you have two realistic options. You can invent a toy language and VM, which players then have to learn from scratch. Or you can ship a real machine.

SEEDS, from Against All Odds, took the second route. Its in-game computer is described by the developers as a complete 64-bit RISC-V virtual machine running an unmodified Linux kernel and a slightly modified Alpine Linux distribution. It is not a side gimmick. The same VM runs all in-game programs, including the research system planned for story mode.

That is an unusual architectural bet for a terraforming sandbox set on a stranded planet deep in space. It has consequences for how the game is built, what players can do with it, and what can go wrong. This piece walks through what is actually shipped, what is promised, and the engineering trade-offs that come with putting a Linux box inside a game world.

What the game is, and what ships today

SEEDS is in Early Access and, by the developers' own description, not feature-complete. The current build is an open-ended sandbox. You can terraform and reshape the planet's surface, add water, deploy machines that restore atmosphere and nutrients, place plants and decorative items, and watch plants grow and animals roam. You can fly the spaceship around the planet and out to the asteroid belt, ride a hoverboard, and explore alongside ROBO unit RB-23, your companion on the planet.

Survival and story modes are listed as coming soon. Both are planned to keep every sandbox feature but tie them to progression and make them more demanding. Story mode follows a protagonist named Naxiah and a narrative the studio calls Echoes Beneath the Sands, with more than 30 hours of story promised. Optional hazards such as asteroids and drone and alien invasions can be switched on, but a fully peaceful playthrough remains available.

New features go first to a smaller circle of beta testers before landing in the Early Access build. That release pipeline matters for the in-game computer specifically, because a real operating system inside a game is exactly the kind of component that surfaces edge cases only under wide use.

What 'a complete 64-bit RISC-V virtual machine' means

The phrasing is specific, and each part of it carries weight. 'Complete' implies the emulated machine is capable enough to boot a general-purpose kernel, not just execute a restricted instruction subset for scripts. Booting Linux requires more than integer arithmetic: the kernel expects privilege levels, virtual memory, interrupts and timers, and some form of console or display device to talk to.

'64-bit' means the guest is RV64 rather than the 32-bit RV32 variant. That matters for compatibility. Mainstream distribution packages for RISC-V target 64-bit, so choosing RV64 lets the game lean on an existing userland rather than cross-compiling and maintaining its own.

What the studio has not published, at least on its game page, is how the emulator is implemented: whether it interprets instructions or translates them, which ISA extensions it supports, how much guest memory it exposes, or how it is scheduled against the game's frame loop. If you are evaluating SEEDS as a programmer rather than as a player, those are the questions to ask before planning anything heavy on it.

Unmodified kernel, slightly modified Alpine

The split between the kernel and the distribution is the most telling engineering detail. An unmodified Linux kernel means the studio did not fork Linux to fit its emulator. Instead, the emulator presents hardware that a stock kernel already knows how to drive. That is the sustainable direction: kernel forks rot quickly, and every security or bug fix upstream becomes a merge job.

Alpine is a sensible choice for the userland. It is small, built around a minimal base, and ships RISC-V 64 builds, which keeps the disk image and boot time manageable inside a game that also has to stream terrain, simulate an ecosystem and render a planet.

The modifications to Alpine are described only as slight. In practice, that is where a game would hook in its own programs: startup scripts that launch the in-game applications, the arcade and puzzle games, and whatever glue connects the VM's display output to monitors in the base and spaceship. Players poking around the filesystem should expect to find studio-specific pieces layered on top of an otherwise recognisable Alpine install.

The VM as the game's program runtime

The key design decision is that the VM is not a separate toy. It runs all in-game programs. Today that includes small games playable on the monitors in your base or spaceship, plus chess and a certain kind of block-stacking game on the hologram table inside the base. In story mode, research is planned to run on the same machine.

This has a clear upside for the studio. Every in-game application is just a Linux program. It can be written in an ordinary language, debugged with ordinary tools outside the game, and dropped into the image. There is no bespoke scripting engine to maintain and document for each new feature.

It also has a cost. If research progression depends on programs running inside an emulated machine, then emulator correctness and performance become gameplay correctness. A guest process that hangs, a filesystem that fills up, or a player who deletes the wrong file can, in principle, interfere with progression. How the game defends against that, with snapshots, read-only system partitions or a reset option, is something to watch as story mode lands.

Programming it in the language of your choice

Because the guest is real Linux, the studio states that you can program the computer in the language of your choice and run your own programs on it. This is the payoff of shipping a real OS instead of an invented one: players do not learn a game-specific dialect, they use what they already know.

The phrase 'language of your choice' should be read sensibly. What is available out of the box depends on what is installed in the image, and what can be added depends on whether the VM has any route to install packages or import files. A RISC-V Alpine system can in general run interpreters and compilers built for that architecture, but which ones SEEDS ships with is not listed on its site.

A practical workflow for anyone serious about writing code here would be to check the shell first: what interpreters exist, whether a compiler toolchain is present, how much free disk and memory the guest has, and whether files persist across save games. Those four answers decide whether you are writing quick shell scripts or porting a real project.

The roadmap: automating the sandbox from inside

The most interesting promise is what comes next. The developers say that later you will be able to influence and automate your sandbox from within the computer. That turns the VM from a curiosity into a control plane for the game world.

Doing this well means exposing game state to the guest through some interface the guest can address: a device, a file, a socket or a memory-mapped region. Each choice shapes what players can build. A file-based or device-based interface would let any language that can read and write files drive the planet, which fits the 'language of your choice' promise. A narrower API would be easier to secure and balance, but less flexible.

The design tension is obvious. Terraforming machines, plant placement and atmosphere control are core progression in survival and story modes. Letting a player script them from Linux could trivialise the challenge, so expect limits, costs or mode-specific restrictions. In the pure sandbox, where freedom is the point, full automation fits naturally.

Why a real ISA beats a toy CPU

Games with programmable computers have historically used invented architectures or high-level scripting sandboxes. Those are easier to control and cheaper to run, but every program has to be written for that one game, and the ecosystem stays small.

RISC-V changes the economics. It is an open specification with a compact base instruction set and optional extensions, which makes it one of the more approachable real architectures to emulate. More importantly, it has upstream Linux support and existing distributions, so an emulator author who gets the hardware model right inherits an entire software stack for free.

That is the bet SEEDS is making: spend engineering effort once on an emulator faithful enough to boot stock Linux, and in return get a programmable computer that players already know how to use, and that the studio can fill with ordinary programs instead of bespoke scripts.

Where this approach does not fit, and what to watch for

Putting a Linux VM inside a game is not free, and it is not the right call for every project. The trade-offs worth keeping in mind:

• Performance budget. Emulating a 64-bit CPU competes with rendering, physics and ecosystem simulation for the same host cores. Expect the guest to be far slower than native code, and do not assume compute-heavy workloads will be practical.
• Progression integrity. When research and, later, world automation run on a player-writable OS, a broken guest can mean a broken save. Look for how the game isolates system files and recovers a corrupted VM.
• Accessibility. A real shell is a gift to programmers and a wall to everyone else. Most of the game must stay playable without touching it, which the current design appears to respect by putting games and tools on top of the VM rather than requiring players to type commands.
• Balance. Scriptable control of terraforming machines can collapse difficulty curves. How automation is gated across sandbox, survival and story modes will decide whether it enriches or flattens the game.
• Early Access volatility. The VM's interfaces, image contents and automation API are still evolving. Code you write against the in-game computer today may need changes as features move from the beta circle into the public build.

For studios considering the same idea, the lesson is narrower than 'ship Linux in your game'. It works when the computer is central to the design, when the team is prepared to own an emulator as a long-lived component, and when the game has a plan for players who will inevitably try to break the machine from the inside.

This article draws on How to print without a newline or space and answers to it (1, 2), on the Stack Exchange network, licensed under CC BY-SA 4.0.