example.com/path/to/article
000 points · username · 0 hours ago
example.com98 points · 37 comments · 20 days ago · nor-and-or-not
We're a tiny indie studio, all with a background in the demoscene and for about 3 years now we're developing a space planet terraforming game called SEEDS - Echoes Beneath the Sands.
Our protagonist Naxiah is stranded on a small, desolated planet. You're working for an intergalactic distributor of seeds and terraforming equipment, to kickstart new planets in far away galaxies. You must deliver seeds and utilities to an unchartered region, but on your way, you crash on a small planet. Luckily, you have some equipment with you in the ship, so you're able to spawn a base and survive. But for how long? And is the planet really deserted..? :) Well, of course not, there are aliens and other space creatures. And of course, there's ROBO RB-23, which accompanies your adventure.
The game is written in Object Pascal and uses our own game engine PasVulkan, our own physics engine, as well as our own RISC-V 64-bit emulator PasRISCV. We love to build stuff, a lot of these things are FOSS.
The emulator is quite complete (even with RVV, but that's way too slow emulated to be useful) and runs a stock kernel (6.18.3 as of today). We're using Alpine Linux for our base distribution. All our in-game programs to interact with the planet are native RISC-V Linux programs.
We also have our own (free and open source) scripting language POCA (class and prototyped based, JS/Lua inspired, which makes it quite easy for us to script things like HUD, animal behaviour, our story flow graph, etc.
We have most of the wiring ready for players to be able to program and reshape and populate the whole planet in automation, although it's not our primary concept for the game (building stuff by hand, making the planet beautiful is also fun). As it's a normal Linux system, you'll be able to use Ruby, Python, or even Rust, C, C++, and Go to change and automate your world.
We're also thinking of making a bunch of small games which you can play inside the game, in the base on a computer, on an arcade machine, or in the spaceship. And of course, it also runs DOOM. We already prototyped a small 2D space shooter and a small arcade game, both playable within the game. We also feature a table with hologram games to be played, e.g. chess and a certain block game. We also plan to make this hologram game engine available from the computer, which means, you'll even be able to program own hologram style games.
We generally want to make the in-game computer more hackable in future, so that people can create and share their own little games.
Currently, it's only a sandbox game (with beginnings of automation), to build stuff with our pre-made items. You can also assemble these to other, ready-made and shareable bigger items. This is the foundation for us to further develop survival and complete our story mode.
Our game is still under active development, and we finally got our Steam page ready. We have tons of other things planned, but right now, it's more about polishing and quality for the Early Access.
You can watch some videos and screenshots on our website. And we'd love to read your thoughts about his. It has been quite a ride, so far..
AntiRush
seanhunter
Best of luck with the game! I am watching with interest and will for sure get it when it hits early access.
azalemeth
Selfish question -- will you be releasing on GOG or Itch?
verst
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?
hexapus
nor-and-or-notOP
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. :)
vessenes
sippeangelo
HexDecOctBin
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).
pinewurst
snvzz
(which is gonna be most hosts in a few years)
PunchyHamster
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.
gavmor
to change and automate your world.
In what ways?
[deleted]