So I was pretty impressed with how Godot stored its assets in a
.pck file and serves them in a sort of virtual file system at runtime, rather than just shipping a
resources folder. It is cleaner, prevents easy tampering and hides the game's resources. I searched for a similar crate in Rust, I found
mlar and nothing else. If you know of any other crate, please ping me about it.
So a friend and I got to work designing the spec of vach, a custom archiving format. We discussed a lot, read several articles and wrote some code. We wanted it to be easy to use, memory efficient, tamper-conscious and low-overhead.
Extra emphasis on:
- Cutting dependency costs.
- The loader never loading all the data into memory at once.
- General advice.
- This part
So here I am kindly asking for y'all to review the code and give me your harshest criticisms. Here is the latest development repo and latest (incomplete) documentation. For sample usage, please refer to the tests' code, I haven't written any
examples yet. I will gladly answer any questions asked. Thx in advance.
If you know of any other crate, please ping me about it.
Searching crates.io for
filesystem game I found the following:
assets_manager, distill, gvfs, hpk (there's more under the #assets keyword)
- the swear words in your README might be a bit off-putting for some users
- Judging from your README it's unclear if encryption will be mandatory or optional.
- Consider renaming your repo to
vach, naming it sth different (
vile) is a bit confusing. On a related note naming your CLI crate
vach-cli is probably clearer than just
- you'll want a README for your crate (
vach/README.md so that it shows up on crates.io)
- you'll want module documentation for the crate so that it shows up on docs.rs (should include an example how to get started ... also comes with the advantage that the examples are tested by
- Your documentation speaks of
archive source several times but never explains what that is.
- You have some typos e.g.
can be accesses ->
can be accessed, ...
homepage in your
Cargo.toml should be
- I'd also refine your tags
#filesystem, #assets, #game, #compression seem more descriptive than
#storage, #vach, #format, #secure.
I don't see the appeal of putting all crate logic in a
prelude submodule. I'd probably instead group the structs by purpose e.g. I'd put
SecretKey in one submodule for the crypto stuff. If the other structs are essential to your library I'd put them in the top level. If you want a prelude for importing you could still have one and just re-export everything.
This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.