Make encrusted a library independent of the frontend

[petoknm]

I have been working on an Android port of encrusted and I forked the project to make it behave more like a library crate(removing all UI implementations, JS...). I then created my own crate that depends on it and implements the UI in a way that I want. I think it's always best to keep the core emulation code in a separate crate to be more reusable (like for example https://github.com/mikebenfield/euphrates).

Are there any plans to make encrusted a more developer-friendly library? As I said, I have a fork that Im working on that removes some parts of, but there are more parts I would like to revisit like the UI trait (I dont like the fact that the trait needs to care about the specific implementations), maybe a more generic Read/Write-like traits would be more suitable. In upcoming weeks, when I feel its something worth a PR, I will push the repo and we can discuss this further.

I think Z-machine emulator is something worth having as a library, because its pretty hard to implement well. And because of the size of the code I would much rather tweak this, than rewrite it from scratch.

[swolchok]

(Disclaimer: I've contributed recently but don't expect to have nearly as much time going forward.) IMO this would be nice too. There are some features that seem to be Zork-specific, like the stuff to draw a map automatically that assumes things about where the player's location is held in memory, that would be nice to split out as well. There are also some structural issues with supporting Z-machine version 5; it asks a lot more of the user interface that encrusted isn't really set up to incrementally support right now.

[petoknm]

I think a lot of the stuff could be removed if we just went with v3 support only... I really dont want to deal with sound and graphics in the UI either... v3 seems to have most games anyways AFAIK

[DeMille]

Hey! sorry I haven't had the time to respond to this til now, but this a sweet idea. The code base is all a bit tangled up right now since the web UI part got wedged in there, but I don't think it would be hard to split up the core zmachine and presentation layers. I think I'll start doing that next actually.

The jump from v3 to v5 support is indeed pretty steep. I would need to assume a whole different UI model which is a lot more complicated than I anticipated. I'm probably going to shelve those ambitions for a while anyway.

[petoknm]

I did quite a lot of work on the fork over at https://gitlab.com/petoknm/encrusted One of the first ones was to make the zmachine IO independent on the UI... I made a choice to go with input being passed as an argument(Option<String>) and output being a trait like this:

pub enum Output {
    Text(String),
    Object(String),
    StatusBar(String, String),
    SaveData(Vec<u8>),
}

pub trait Out {
    fn output(&mut self, output: Output);
}

That allowed me to also have tests in Rust because I can just render the output into a String just by implementing that trait for Strings, for example like so (Out implements Display):

impl Out for String {
    fn output(&mut self, output: Output) {
        write!(self, "{}", output).unwrap();
    }
}

You can check out my fork and I'll be more than happy to merge some changes upstream :)