Mods handling with multiple games, mods, and user permissions

[clintbellanger]

There are complex scenarios that come up when we consider all the typical ways we want flare-engine to be used.

See this discussion for history: https://github.com/clintbellanger/flare-game/issues/297

Here let's list "test cases" that detail examples of how we expect players and modders to use flare-engine. Then we can compare proposed solutions against these cases.

[dorkster]

Right now, one of our goals is to reduce redundant copies of the "default" mod. In other words, we want to share the mods directory with multiple games. The issue here is that we want to group mods by game, filtering out the ones that aren't used for the current game. Be careful of forward referencing here. We don't want to say "The fantasycore mod is part of the wandercall game", because we want fantasycore to be part of many different mods.

The next problem deals with where we find mods. Currently, we determine a single path, either a system-wide folder or the current directory. We can also optionally replace this path with the --game_data flag. I think we ultimately want to flesh this out to 3 paths that are checked in this order:

• a custom path given via command line. This would mainly be for devs
• a local folder (for *nix systems, this would be somewhere in the $HOME directory). Users who can't or don't want to install mods system-wide can use this
• a system-wide folder (current directory also falls here). Installers and packages managers would put mods here

[dorkster]

Time for another idea. And let's assume we're running ./flare --game=flare.

First we load mods/flare_mods.txt. This files contents are:

fantasycore
alpha_demo

So, we add these two mods to the list of available mods. Also at this time, search other mods/$GAME_mods.txt files and add any non-used mods to a blacklist.

For each $MOD that's not in either list, open mods/$MOD/settings.txt and look for a game= line (game=flare in this example). If we have a match, add that mod to the available mods list.

Note that multi-purpose mods like fantasycore would not have a game= line. This creates a minor inconvenience for these types of mods. Say the user wants to use a multipurpose mod and sticks it in their ~/.local/share/flare/mods/ folder. They would then have to add that mod to ~/.local/share/flare/$GAME_mods.txt.

For example, if we add damage_mod to ~/.local/share/flare/flare_mods.txt, the cumulative list of enabled mods would be:

fantasycore
alpha_demo
damage_mod

It's worth noting that having more than one multi-purpose mod per-game seems very uncommon. Typically, it's a single mod of common art assets (e.g. fantasycore or lpc_core).

[clintbellanger]

An option we can consider: in the config menu we can try only displaying the relevant mods, but have a checkbox that says "show ALL mods".

Someone might do this to add a generic mod, it gets into their local mods.txt, then they can uncheck "show ALL mods".

Combine this with mods specifying which game they belong to (if they are specific mods unlike fantasycore), and which mods they depend on.

Or, generic mods could mark themselves as generic? Or we assume generic if no game= is specified. Such a checkbox could be used to display game-neutral mods, but not mods that are specifically for another game.

[clintbellanger]

This is tough. Even besides the technical considerations, there are just design choices that make this tricky.

I may prefer that a total conversion mod gets to have their own install folder, with all their necessary mods included. The flare-engine would still be a standalone install.

So when it comes time to get Wandercall ready, perhaps it will install to a Wandercall folder. With its own copy of fantasycore and default. And I expect most modders who use fantasycore will do so in a Wandercall-compatible universe. I think of Neverwinter Nights -- it had basically a core set of assets that was always available, but people could easily load other adventure modules. I'd like that to be the case for Wandercall.

Perhaps we can just live with having a duplicate of e.g. fantasycore or LPC assets, when someone makes an entirely different universe that is fundamentally incompatible with the existing games?

Maybe we start this way for Flare 1.0? You launch flare by specifying a base data folder, and that's all the trickery needed really?

[dorkster]

This is tough. Even besides the technical considerations, there are just design choices that make this tricky.

I'm starting to agree. My method mentioned above works pretty well, but I kind of hit a wall when I came to deciding what to do with minicore. I think no matter which way we go trying to implement this, we'll hit something like that.

I think the libre nature of the Flare engine is good for redistribution with total conversions. Let's look at ioquake3. There are many games using this engine (OpenArena, UrbanTerror, etc). Each comes with its own copy of the engine. This is good because some games need their own source level changes. Not to mention it prevents version conflicts. What if Flare 2.0 is installed by a package manager, but a mod only works with Flare 1.0?

[dorkster]

If we are in fact going to forget about this, we'll need to revert the code removal in flare-game.

[stefanbeller]

I agree it would be easiest to have even all the source files included for a game as well as having the default mod and such. However then we should talk about how we can help the packagers to not end up in conflicts when packaging. Initially polymorphable had changes in the cmake files to have it installed at other locations.

Also do we need to care about having some files there multiple times, which are exactly the same? (Or can we tell the packagers to come up with a solution?) This would address the opening post of https://github.com/clintbellanger/flare-game/issues/292

[clintbellanger]

Could projects still share an unmodded flare-engine? If we treat flare-engine as a stand-alone application, as engines should be, then games shouldn't usually need to compile their own versions of the engine.

What about this setup.

Flare is engine-only and by default gets installed to

/usr/local/share/flare

If someone runs flare without any params, flare-engine with the default mod is run. Maybe we add some basic instructions to the default mod title screen

Wandercall is data-only and by default gets installed to

/usr/local/share/wandercall

Someone could launch wandercall with this command:

flare wandercall

Then the engine uses wandercall as the "folder" name instead of flare, instead of having that set at compile time.

/usr/local/share/wandercall/mods/[mods]
~/.config/wandercall/[settings]
~/.local/share/wandercall/[saves]

The above wandercall folder contains all the mods it needs to run, including a copy of default and fantasycore. Anyone adding to the wandercall world would want their data in the /usr/local/share/wandercall/mods folder.

Then wandercall wouldn't need to include a copy of the source, just possibly a launch shortcut/command.'

Someone could still set a base_dir if wandercall isn't installed to one of the default locations.

We could still implement local mods in ~./local/share/wandercall/mods

This means: no install conflicts, no duplicate code, but yes on duplicate mods. But I think we could live with duplicate mods existing in different game worlds.

Games could still opt to release with a local copy of the engine, especially if they make code changes. Or if they don't want to update their data to stay in sync with engine changes?

[clintbellanger]

I think I'm trying to accommodate linux-land users without knowing a ton about how games and engines are usually handled there. If games basically always come along with their engine, even if the engine is reusable and precompiled, then we should just do that.

What game engines are comparable to what we want to do with Flare? How are those handled in repos?

[dorkster]

It's common for games to be packaged as $GAME and $GAME-data. However, the engine for those games is typically not reused for other game data packages.

I'd be okay with a command line switch that set the engine folder. Total conversions should have their own *.desktop files anyway, so modders can add the switch to the Exec line there.

[clintbellanger]

We talked to mafm and Ablu who do packaging for Flare and other projects.

It sounds like something along these lines is best. Note here I'll use the folder "/usr/share/games/" but this is easily changed depending on OS.

The engine is installed here:

/usr/share/games/flare/

Each "game" that uses the unforked flare engine has its data installed in its own folder. engine_folder (e.g. "wandercall" or "polymorphable") is set at runtime.

/usr/share/games/flare/wandercall/mods
/usr/share/games/flare/polymorphable/mods

For now these each contain the default mod, which could be customized per game if desired.

Later down the road if many separate game worlds are created reusing the same core assets (e.g. fantasycore or lpccore) we could consider supporting shared mods to deduplicate data. I think we don't worry about that until it looks like it will be a real issue.

[dorkster]

574 is in place now, so let me do some explaining.

When running flare now, we use a GAME_FOLDER variable to decide where our folders are. The default value for this is default, so the game will create and use these directories (the base parts of these may vary):

# settings/keybindings
~/.config/flare/default/

# save files
~/.local/share/flare/default/

# local mods
~/.local/share/flare/default/mods/

# system-wide mods (this isn't created for obvious reasons)
/usr/share/games/flare/default/mods/

So in in practice, we'll override default by doing something like:

flare --game=flare-game

If flare-game isn't installed system wide, we can now plop mods into the local mods folder. Personally, I made my local flare-game/mods directory a symlink to the mods folder in my flare-game repo, which is handy.

For the sake of packagers, I suggest we create a CMake file for flare-game / polymorphable to install to the correct folder and generate a *.desktop file.

[stefanbeller]

Thanks for the instructions how to proceed. Protip: If you link the default mods to flare-game, you can even start flare without any command line arguments.

[dorkster]

Is there anything remaining in regards to this issue?