For the games you could first create a symlink tree to the engine parts.

INFO: main.cpp:478 : Anura engine version 1.4
INFO: main.cpp:517 : Default Tile Size: 16
INFO: main.cpp:518 : Default Tile Scale: 2
INFO: main.cpp:520 : Build Options:
INFO: main.cpp:522 :     isomap
INFO: main.cpp:522 :     lua
INFO: main.cpp:522 :     save_png
INFO: main.cpp:522 :     sdl2
INFO: main.cpp:522 :     svg
INFO: module.cpp:334 : LOOKING IN 'modules/frogatto/module.cfg': 0
INFO: module.cpp:334 : LOOKING IN '/home/chronos/.frogatto//dlc/frogatto/module.cfg': 0
INFO: main.cpp:596 : FAILED TO LOAD MODULE: frogatto

How would I run this game with e.g. argentumage? Or is the module still called frogatto? bin/anura seems to ignore arguments.

UPD: nevermind, it has --module=<name> argument for that: https://github.com/davewx7/citadel/wiki/Building-from-Source

For the games you could first create a symlink tree to the engine parts.

is using stow fine for that ? or do you have sthg else in mind ?

@yegortimoshenko sorry my first post was not clear enough. This is only the engine but I do wish to add argentum age to the PR. Frogatto would be a nice addition but I didn't know the data was non free. Maybe it's still available though.

@teto I was wrong, Frogatto's data is under CC-BY 3.0: https://github.com/frogatto/frogatto/blob/master/LICENSE

There are two problems with adding game data into the derivation:

1. Anura can't be used for game development, or even helping developers test the game (new version of Frogatto is still in development), if game data is linked into read-only Nix store. It also means that we have to keep up with game updates (and both games are updated on daily basis).

2. I'd argue it's not the right place for game data to be. No one would distribute an audio player with complete set of all albums one might want to listen to. I don't see why this should be the case with game data.

There will probably be more games that use this engine in the future, and we shouldn't have to tweak the derivation when every new game comes out.

It's unfortunate that the engine itself doesn't do this already, but this could be solved by writing a wrapper that makes deeply symlinked (to the effect union mounted-like) temporary directory that stacks game engine on top of current working directory, which should be the game data folder.

At current form there is no sense in having this derivation at top-level.

well I fully agree with you, it seems like a stupid limitation to have the game in a submodule. While creating such a wrapper should be easy/ok (especially with stow), I will try to ping upstream if they can't solve it there.

@yegortimoshenko just to confirm you could play argentumage ? even if it was hackish that would be already good news :)

@teto I could! I fetched https://github.com/anura-engine/anura, fetched Argentum Age repo into modules/ subdirectory, and then I could play it.

I'm only peripherally involved in Frogatto these days, so I'm somewhat posting in ignorance here. Could a simple soft link, like ln -s /somewhere/else modules, suffice? You wouldn't need to do any other linking, and nothing in the Anura package would need to change when a module is updated – as long as the module doesn't need a newer version of the engine. (As @teto said, a module is a just folder in the modules folder in Anura.)

Considerations:
I think Anura has some sort of auto-updater for the engine as well as the game files, but I don't know how it would work for NixOS. Or even if you'd want it to work. (Argentum Age often needs an engine no older than itself, while Frogatto is a lot more forgiving.)

If you would like to package the stable frogatto release, version 1.3, it will need an older version of the engine. The current version of Anura is not backwards-compatible that far.

I'm not sure if the current development version of Frogatto is 100% playable at the moment. It might not load some levels.

Thanks for taking the time to package Anura! ❤️

@DDR0

Could a simple soft link, like ln -s /somewhere/else modules, suffice? You wouldn't need to do any other linking, and nothing in the Anura package would need to change when a module is updated – as long as the module doesn't need a newer version of the engine. (As @teto said, a module is a just folder in the modules folder in Anura.)

Nix store is read-only, so that is not possible. We can't make any changes to modules/ after Anura has been built. The are really only two viable solutions to the problem on our side besides patching Anura source code: either deeply symlinking (or copying) the engine and game module into a temporary directory on each run, or running Anura in a Linux user namespace chroot, overlaying game data on top of engine via UnionFS. Both take some time on startup and would require a substantial amount of time and work.

On the other hand, if modules/ was not hard-coded and there was a --modules-directory switch to specify a custom modules directory, that would solve this issue. Or, better yet, --module-path flag, so that one could play Argentum Age just by fetching game data from GitHub and running anura --module-path ~/Downloads/citadel.

I think Anura has some sort of auto-updater for the engine as well as the game files, but I don't know how it would work for NixOS. Or even if you'd want it to work.

As long as Anura is backwards compatible, that should not be an issue: if the game stops working, the Nix package can be updated or an older version of game data can be used. The auto-updater won't work of course, neither would we want it to.

I don't think I understand. Couldn't you change the modules link before Anura is built? Or can you not change anything the link links to, even though the link links outside the store?

eg, "${store}/anura/modules" would be a link to "${writable-user-data}/anura/modules" or something, so nothing in the store would have to change. Then, a user could link "${writable-user-data}/anura/modules/citadel" to "~/Downloads/citadel" if they wanted to. (There are a few people who do the last link already.)

Upstream doesn't seem to want to fix this, so closing. Feel free to reopen if proper workaround is implemented, but mind that Anura doesn't seem to be particularly vigilant about not breaking reverse compatibility, meaning it's not a game interpreter and perhaps should not be treated as such.