itch.io

It's *definitely* changed a lot since this devlog!

A small recap:

• It's no longer my own custom engine, but RPG Maker. It's also no longer realtime action, but turn based. (these two decisions were made as one, when I decided I didn't really have the means to pursue a game of that scope and needed to simplify in order to make it something I could feasibly accomplish)
• There's actually a playable demo! It's currently Patreon only, but in about two weeks (Sept. 6th) it will become live with the start of SAGE 2024 for everyone else to play too! This I think kind of vindicated my decision, since the changes to the project let me really focus and actually get a demo out the door. (fwiw I am also going to be trying to get the demo on Steam)
• (also yea there's a Patreon where you can get builds & see stuff like concept art early, as well as more in-depth devlogs)

Anyway...

It is extremely unlikely that I will be able to port it to Dreambox, as it is implemented with RPG Maker MZ (written in JS and HTML5). I would need to rewrite the game from scratch in order to do this - it's possible, but would be a significant effort and tough to really justify as it wouldn't really benefit me in a whole lot of other ways.

Hello!

I am using the AdvSaveHandler plugin in conjunction with the CLI cook tool for my game Foxblade Fable, which I distribute via Itch.IO.

I primarily work on Linux, and I noticed that on Linux when launching a game from a Flatpak version of Itch.IO, rather than putting the save folder in the user's home directory Flatpak will instead redirect those paths to a temp directory (at least by default - you can manually grant home directory permissions to the Itch.IO app, but frankly I would prefer my game run out of the box without nasty surprises like losing save data)

To improve this, I ended up tweaking AdvSaveHandler myself to support the XDG base directory specification - it's an extremely simple change: instead of just using the home directory, it will instead use $XDG_DATA_HOME, or fall back to $HOME/.local/share otherwise (which the spec defines as an appropriate default for $XDG_DATA_HOME).  The change looks like this:

if (process.platform == "linux") {
    home = process.env.XDG_DATA_HOME || path.join(systeminternals.homedir(), ".local", "share");
}

Now when launching on Linux, it will either put its folder in ~/.local/share, or it will put it wherever $XDG_DATA_HOME is defined (when running under Flatpak Itch.IO for example, the save game folder is put in ~/.var/app/io.itch.itch/data)

Hm, that could be tough - later on I can give cross-compiling to Mac a shot, most of what I'm using should have native libs for Mac, but I don't have a Mac machine so I won't be able to test any of it fwiw.
(worth noting that I'm also working on an HTML5 port of the runtime which'll run in Electron or even in a browser, so that might be another option for ya)

Hm, maybe I scuffed something up when building. Gimme a bit and I'll try and see if I'm doing the self contained build correctly.

No you're not missing anything, usage docs are still lacking right now & in dire need of some attention (I've just been really busy with other stuff, so I haven't been able to dedicate as much time as I'd like to projects like this)

For what it's worth you have three ways of loading an ISO into Dreambox:

1. You can drop the ISO onto the window
2. You can use the `--startcd [path/to/iso]` (or `-s [path/to/iso]`) commandline option
3. You can use the `--faststartcd [path/to/iso]` (or `-f [path/to/iso]`) commandline option, which is similar to startcd but also skips the boot animation

Additionally, for keybinds, they are stored in a config JSON file created when you first start Dreambox. On Windows, that will be located at `C:\Users\[username]\Documents\SavedGames\dreambox\dreambox-savedata\AllPlayers\config.json`. On Linux, I *think* that would be something like `~/.local/share/dreambox/dreambox-savedata/AllPlayers/config.json`? I can verify on my laptop in a bit.

FWIW the default keybinds are:

Also, for what it's worth, a few useful hotkeys you may want to know:

• F1 ejects the CD and restarts the console
• F2 restarts the console, but does not eject the CD
• F3 ejects the CD, but does not restart the console
• F4 dumps loaded audio samples to WAV files for debugging

Good news, .NET has an option I can take advantage of called "self-contained builds" which means Dreambox should now bundle the .NET runtime instead of relying on it being installed. Maybe give it a shot and see if it works now!

You asked for a Debian version, there is a Linux version which should work on Debian. I'm sorry you have to go through extra steps to get a working runtime environment, but that's kind of how the cookie crumbles when you're using Linux.

At the moment that's probably the best I can do for you. Getting a version that doesn't depend on the .NET runtime would probably involve rewriting the whole thing in a language that isn't C#, and considering I have made a grand total of $6 ever on Dreambox that's probably not super feasible for me. I also don't have access to Chromebook hardware, and do not plan on obtaining one, so a native app is also probably off the table.

Try './dreambox' instead? (dot forward slash)
At least on Linux Mint, just typing 'dreambox' has the same effect, but './dreambox' works

The officially supported language is Rust, and is the language covered by the tutorials here:

https://dreambox3d.dev/getting_started

However, Dreambox games use WASM binaries, and so technically anything that compiles to WASM can also be used (including C or C++ via Emscripten). In fact, a set of C headers are provided in the Downloads section which you can reference to link to Dreambox APIs.

However, it is worth keeping in mind that rather than taking a raw WASM file, Dreambox games actually consume CD ISO files, which embed a "main.wasm" in the root directory and any other files referenced by the game, so the C/C++ route will involve some extra steps to bundle everything as an ISO file. Meanwhile, the Rust tools provided above will handle all of these details for you

I can look into it, but I don't have access to a Debian machine right now. I'm not super sure what would prevent the Linux version from running in Debian though for what it's worth, are you running into specific problems?

Probably not as it stands?

Right now the whole thing is built on a couple of underlying frameworks: .NET core, wasmtime, and FNA. All three of those are likely to pose issues with porting to the Wii, not least of which is FNA - as it is an open-source implementation of XNA which mainly targets modern rendering frameworks (D3D11, OpenGL 3.x, Vulkan, etc), using lots of features that just wouldn't work on a fixed function pipeline like the Wii. I get the feeling that a dynamic JIT compiler based runtime (WASM) may also pose a few issues.

That said, it *may* be possible to take a different approach - it could be theoretically possible to write a framework for the Wii which exposes all of the same functions as the Dreambox WASM host does, and then use maybe something like wabt to translate a Dreambox WASM game into C, and statically linking it with the aforementioned framework and compiling it for the Wii. Lots of extra steps & complications though.

I had at one point considered seeing if something like this was possible for the Dreamcast, but decided against it as none of the compressed texture formats would be supported so it'd be of limited utility. I also have made a grand total of $6 on Dreambox ever so it doesn't leave a whole lot of room for experimentation on niche things like this ;)

At the moment I don't believe any actual games have been released for it - thus far I've only made a handful of tech demos (an ROQ video player, a Quake BSP viewer, and a little character physics / skeletal animation demo), and I'm not aware of anything anyone else is working on.

Sadly I've been kept too busy at work & on other projects to really be able to focus on making full games for the thing myself 😔

That's a pretty broad question, so it's a little tough to answer, but I'll try and talk about what I did to make Dreambox.

The thing with Dreambox is that I started with a strong idea of what I wanted it to feel like, and what kind of capabilities it should have, and from there started trying to answer more specific questions (like, "how do people make Dreambox games?" -> "they should be able to use native languages like C++ or Rust to make games", "how should playing a Dreambox game work?" -> "games should be bundled into single files that users can drop onto the Window to play", "what 3D capabilities should Dreambox have?" -> "developers should be able to submit vertex-colored and textured geometry, but no shaders or render textures").

From there I guess I just tried to narrow down exactly how each of those worked. Like, I knew I wanted people to be able to use C++ or Rust, so I decided on using WASM because both of those are relatively easy to compile to WASM and there are ready-made runtimes I could use to execute WASM code so I wouldn't have to spend too much time on that aspect.

For Dreambox I also picked an environment I was very familiar with, so it's written on C# and FNA3D as I am very familiar with both. This reduced the amount of effort I was spending learning something new and made the development process go faster.

It's because we're outsourcing the costs of our dastardly agenda. Truly terrible stuff, really, ranging from "eating food" to "paying the bills"!