This looks really cool. You can see the potential when you consider how automation works in games like “Stationeers” (which allows the player to automate stuff using a mips-like assembly language called “IC10”). A huge limitation in stationeers is the cap on the length of IC10 scripts you can write, so having such a flexible automation platform baked into the game is really awesome.
Best of luck with the game! I am watching with interest and will for sure get it when it hits early access.
If you made the game multiplayer, you could enable in-game networking so players could develop ways to communicate with each other via the galactic internet. Watch as they write new applications to chat and share updates with each other about the planets they are terraforming.
We already have a co-op mode, but it's still in alpha testing mode. It most likely will be in Early Access from the start.
Multiplayer is something we really want to do, but takes some planning and time, so it isn't our focus currently. So this will be more like an update once the final version is released.
Co-op mode integration and networking is based on BeRo's RNL, which is also FOSS:
<3 This game sounds amazing. Even if you didn't have fully-fleshed out multiplayer, an in-game network that connects everyone's terminals could lead to some incredible organic developments within the game's community. Just connect everyone and let them figure out new ways to interact with each other.
> our entirely in-house game engine PasVulkan, which powers SEEDS, as well as our RISC-V emulator PasRISCV, are both Free and Open Source Software (FOSS)
A few things about our RISC-V 64-bit emulator. Please forgive me, if I make some mistakes, but I'm not the expert on this.
First, PasRISCV not only emulates userspace (RV64GC usermode), but a complete, modern machine (SMP/MultiHART, RV64, full RVA23.1 including Hypervisor, Crypto, Vector stuff, etc.), which is capable of booting a normal Linux kernel (either using direct OpenSBI -> kernel boot, but currently everything has to be in the initrd then), or using U-Boot (OpenSBI -> U-Boot -> kernel).
The emulator uses a hybrid of interpreter with a tracing JIT. Currently, the JIT is limited to host x86-64. About 99% of all instructions and are supported by the JIT. For example, the host FPU is passed through to the guest. But PasRISCV also supports an optional stricter FPU mode, where with soft floats and interpreter only, because IEEE754-2008 has specific rules, that don't exist on the x86 architecture.
Disk images are provided either using VirtIO-Block or NVMe via PCIe. We can either use disks in normal read-write mode, or also in read-only mode. This allows us to have a root partition, that we can overwrite with game updates, and have a user partition, where custom player stuff is stored. We also can mount host dirs as external paths/mounts over VirtIO-9P or VirtIO-FS, which is especially useful for development because this allows us to compile guest tools directly on the host system.
To display graphics on our virtual game screen(s), we currently use a framebuffer device (via SimpleFB with a custom MMIO framebuffer). But PasRISCV also supports other graphics "adapters", such as VirtIO GPU (with EDID, 2D, and experimental 3D/virgl support), or using PCI emulation (bochs-drm and Cirrus-DRM). We have some custom shaders modifying the framebuffer output, so that we can add some retro FX like scanlines, phosphor glow, etc.
The emulator also has audio using emulated CMI8738 and FM801 cards (both with OPL2/3 support), as well as Intel HDA and VirtIO-Sound. Our little space game (Space Prowler) inside SEEDS has a title tune which is made using PCM+OPL3. I coded a small tracker, which runs in a plain Linux console, so I can even compose inside our game on its 80×50 (640×400px) framebuffer console, albeit it's a bit cumbersome. I'll release the tracker as FOSS when we have a bit more spare time, as I need to make it a bit more user-friendly.
We use vsock (Linux virtual sockets) to interface with the game outside of the emulated machine. We use a small serialization format (basically something similar to binary JSON) to communicate bi-directionally, like you'd expect over normal network. We have a small priority queue and message referencing for urgent and request-response communication. For example, the client to display a planet sphere on the in-game computer can ask for updated positions of e.g. terrain or all animals.
The emulator embeds its own disassembler and debugger, and also can act as gdb server, which means you can use your favourite debugging tools, as long as it speaks gdb's server protocol.
It has real network support through a Slirp-like usermode NAT (without using external libs) which supports IPv4 and IPv6. We can run APK's update and install directly on the emulated machine.
Our game uses a slightly modified Alpine Linux 3.23 and custom kernel build, but a recent stock Alpine image also runs without problems.
PasRISCV is licensed under the permissive zlib license.
If you have any questions, I'm sure BeRo is happy to answer questions with far more detail than I could. :)
Ooh cool. Suggestion - you could set up deep space relays with very long latency to IPv6 routers. So there could be some outward facing connectivity, but it would just be, you know, slow. Until the player researches Ansible tech, obviously
Do you have a blog post about this? The link is to the home page and doesn't mention anything! Sounds super interesting but the landing page reads like survivalcraft in space #1001
Hey, thanks for asking! If you scroll to the bottom on the homepage, there's a bit of info, and we also have some information on the Steam page of the game.
We plan to do a series of blog posts with technical information about the game and its internals, but right now, we're busy preparing for an Early Access release.
Free Pascal or Delphi? I tried FP a while back and felt that the language had really stagnated (e.g., variables can only be declared at the top of scope like C89).
We mostly use Free Pascal (works fine on Linux and cross-compiling for Windows). But during development we also sometimes use and test Delphi builds on Windows.
Well, hypothetically speaking, as you would need a complete stack down to Vulkan for the game itself on this machine, and we still would need to sandbox the guest machine, but apart from that nothing speaks against a thin wrapper, that passes through native RISC-V instructions to the host machine. So while it doesn't as of now, it may in the future.
I imagined a space game based on a bit similar approach but the caveat is "technology to make stuff deep space radiation resistant also limited the available compute", and the player has capability to
So your airlocks, space station and ship subsystems and similar devices would run just on small microcontroller sized chips (8-64kB sized ones, with slow clocks) and player that invested in that given skillset could essentially hack them and modify or replace the programming, and have access to a bunch of languages, from assembler, thru rust to something more high level/easier to use like BASIC/MicroPython.
They could also acquire disassemblers, the basic ones would just give them assembly code (which might be enough if they want to just re-program a lock), the advanced ones would also get actual high level source code (just a bit of smoke and mirrors so player doesn't have to stare at assembler or build code from scratch every time). And basically play hacker but on actually running systems, OR re-tune their ship's engines (it could even go to fun stuff like "there are 5 models of this engine, all just software locked into given power level", akin to real life car ECU tuning).
There would be bigger systems, but they would be bulky from shielding so it would be often mainframe-like system of station having one big core computer with a bunch of dumb terminals, that player could also fuck around with, like installing a password sniffer. Or having it trigger something when certain character accessess it.
Cool, and quite reminiscent of 0x10c: https://en.wikipedia.org/wiki/0x10c
That is one game I was so looking forward to. So very excited about this!!
Unfinished, indeed.
Sadly! But you can run the many DCPU emulators, interpreters, and assemblers on the SEEDS computer to interact with the planet.
This looks really cool. You can see the potential when you consider how automation works in games like “Stationeers” (which allows the player to automate stuff using a mips-like assembly language called “IC10”). A huge limitation in stationeers is the cap on the length of IC10 scripts you can write, so having such a flexible automation platform baked into the game is really awesome.
Best of luck with the game! I am watching with interest and will for sure get it when it hits early access.
Thanks for your kind words and wishes!
I actually never played Stationeers, but sounds interesting, despite the limitation. I'll check it out sometime.
This is absolutely wonderful and I can't wait to play it!
Selfish question -- will you be releasing on GOG or Itch?
Hey! Yes, we plan to release the full version on GOG.
If you made the game multiplayer, you could enable in-game networking so players could develop ways to communicate with each other via the galactic internet. Watch as they write new applications to chat and share updates with each other about the planets they are terraforming.
Hey, thanks for your suggestions!
We already have a co-op mode, but it's still in alpha testing mode. It most likely will be in Early Access from the start.
Multiplayer is something we really want to do, but takes some planning and time, so it isn't our focus currently. So this will be more like an update once the final version is released.
Co-op mode integration and networking is based on BeRo's RNL, which is also FOSS:
https://github.com/BeRo1985/rnl
<3 This game sounds amazing. Even if you didn't have fully-fleshed out multiplayer, an in-game network that connects everyone's terminals could lead to some incredible organic developments within the game's community. Just connect everyone and let them figure out new ways to interact with each other.
I saw this on the steam page:
> our entirely in-house game engine PasVulkan, which powers SEEDS, as well as our RISC-V emulator PasRISCV, are both Free and Open Source Software (FOSS)
Can you link to PasVulkan and PasRISCV please?
PasRISCV: https://github.com/BeRo1985/pasriscv
pasriscvemu: https://github.com/BeRo1985/pasriscvemu
PasVulkan: https://github.com/BeRo1985/pasvulkan
POCA https://github.com/BeRo1985/poca
BeRo of farbrausch is 1/3 of our team. :)
(edit) added a link to POCA, the scripting language, as it's relevant, too
I had the honor of briefly being in the same demogroup as BeRo long ago, and he's absolutely one of the most incredible developers I ever met!
That he truly is!. I'm sure he loves to hear that and I tell him you said hi. ;)
ps: 0ok or farbrausch?
I added a little information about PasRISCV here:
https://news.ycombinator.com/item?id=49939720
A few things about our RISC-V 64-bit emulator. Please forgive me, if I make some mistakes, but I'm not the expert on this.
First, PasRISCV not only emulates userspace (RV64GC usermode), but a complete, modern machine (SMP/MultiHART, RV64, full RVA23.1 including Hypervisor, Crypto, Vector stuff, etc.), which is capable of booting a normal Linux kernel (either using direct OpenSBI -> kernel boot, but currently everything has to be in the initrd then), or using U-Boot (OpenSBI -> U-Boot -> kernel).
The emulator uses a hybrid of interpreter with a tracing JIT. Currently, the JIT is limited to host x86-64. About 99% of all instructions and are supported by the JIT. For example, the host FPU is passed through to the guest. But PasRISCV also supports an optional stricter FPU mode, where with soft floats and interpreter only, because IEEE754-2008 has specific rules, that don't exist on the x86 architecture.
Disk images are provided either using VirtIO-Block or NVMe via PCIe. We can either use disks in normal read-write mode, or also in read-only mode. This allows us to have a root partition, that we can overwrite with game updates, and have a user partition, where custom player stuff is stored. We also can mount host dirs as external paths/mounts over VirtIO-9P or VirtIO-FS, which is especially useful for development because this allows us to compile guest tools directly on the host system.
To display graphics on our virtual game screen(s), we currently use a framebuffer device (via SimpleFB with a custom MMIO framebuffer). But PasRISCV also supports other graphics "adapters", such as VirtIO GPU (with EDID, 2D, and experimental 3D/virgl support), or using PCI emulation (bochs-drm and Cirrus-DRM). We have some custom shaders modifying the framebuffer output, so that we can add some retro FX like scanlines, phosphor glow, etc.
The emulator also has audio using emulated CMI8738 and FM801 cards (both with OPL2/3 support), as well as Intel HDA and VirtIO-Sound. Our little space game (Space Prowler) inside SEEDS has a title tune which is made using PCM+OPL3. I coded a small tracker, which runs in a plain Linux console, so I can even compose inside our game on its 80×50 (640×400px) framebuffer console, albeit it's a bit cumbersome. I'll release the tracker as FOSS when we have a bit more spare time, as I need to make it a bit more user-friendly.
We use vsock (Linux virtual sockets) to interface with the game outside of the emulated machine. We use a small serialization format (basically something similar to binary JSON) to communicate bi-directionally, like you'd expect over normal network. We have a small priority queue and message referencing for urgent and request-response communication. For example, the client to display a planet sphere on the in-game computer can ask for updated positions of e.g. terrain or all animals.
The emulator embeds its own disassembler and debugger, and also can act as gdb server, which means you can use your favourite debugging tools, as long as it speaks gdb's server protocol.
It has real network support through a Slirp-like usermode NAT (without using external libs) which supports IPv4 and IPv6. We can run APK's update and install directly on the emulated machine.
Our game uses a slightly modified Alpine Linux 3.23 and custom kernel build, but a recent stock Alpine image also runs without problems.
PasRISCV is licensed under the permissive zlib license.
If you have any questions, I'm sure BeRo is happy to answer questions with far more detail than I could. :)
Ooh cool. Suggestion - you could set up deep space relays with very long latency to IPv6 routers. So there could be some outward facing connectivity, but it would just be, you know, slow. Until the player researches Ansible tech, obviously
:) Watching the pings time out would be highly dissatisfying, though.
Do you have a blog post about this? The link is to the home page and doesn't mention anything! Sounds super interesting but the landing page reads like survivalcraft in space #1001
Hey, thanks for asking! If you scroll to the bottom on the homepage, there's a bit of info, and we also have some information on the Steam page of the game.
We plan to do a series of blog posts with technical information about the game and its internals, but right now, we're busy preparing for an Early Access release.
https://store.steampowered.com/app/5186640/SEEDS__Echoes_Ben...
I added a little information about PasRISCV here:
https://news.ycombinator.com/item?id=49939720
I took the time and wrote a proper blog post describing our RISC-V emulator and a few other things at a high level:
https://againstallodds.games/blog/2026/10/03/our-risc-v-emul...
(We've switched the URL to that from https://againstallodds.games/ by submitter's request.)
> Object Pascal
Free Pascal or Delphi? I tried FP a while back and felt that the language had really stagnated (e.g., variables can only be declared at the top of scope like C89).
We mostly use Free Pascal (works fine on Linux and cross-compiling for Windows). But during development we also sometimes use and test Delphi builds on Windows.
We always make sure, it compiles with both.
https://en.wikipedia.org/wiki/0x10c
Still got three dark-blue 0x10c T-shirts in my drawers. ;)
Does the RISC-V code run natively when game is run on a RISC-V host?
(which is gonna be most hosts in a few years)
Well, hypothetically speaking, as you would need a complete stack down to Vulkan for the game itself on this machine, and we still would need to sandbox the guest machine, but apart from that nothing speaks against a thin wrapper, that passes through native RISC-V instructions to the host machine. So while it doesn't as of now, it may in the future.
I imagined a space game based on a bit similar approach but the caveat is "technology to make stuff deep space radiation resistant also limited the available compute", and the player has capability to
So your airlocks, space station and ship subsystems and similar devices would run just on small microcontroller sized chips (8-64kB sized ones, with slow clocks) and player that invested in that given skillset could essentially hack them and modify or replace the programming, and have access to a bunch of languages, from assembler, thru rust to something more high level/easier to use like BASIC/MicroPython.
They could also acquire disassemblers, the basic ones would just give them assembly code (which might be enough if they want to just re-program a lock), the advanced ones would also get actual high level source code (just a bit of smoke and mirrors so player doesn't have to stare at assembler or build code from scratch every time). And basically play hacker but on actually running systems, OR re-tune their ship's engines (it could even go to fun stuff like "there are 5 models of this engine, all just software locked into given power level", akin to real life car ECU tuning).
There would be bigger systems, but they would be bulky from shielding so it would be often mainframe-like system of station having one big core computer with a bunch of dumb terminals, that player could also fuck around with, like installing a password sniffer. Or having it trigger something when certain character accessess it.
I'd play that, depending on the actual programming language used inside the game.
> to change and automate your world.
In what ways?
For example, shaping the terrain and placing items. Our automation is in its early stages, basically a proof-of-concept.
Our main focus lies on manually shaping the ground, placing water and plants, growing things, at least for the current sandbox mode.
But then again, this may change, depending on the interest of the players.
Oh, excellent. I will jam that sucker full of Hilbert curves.
I'm sure little aliens will like and explore it thoroughly. :)
[dead]
[flagged]