Editor: support adding game plugin dependencies

[ivan-mogilko]

Problem

In theory the game plugin may have dependencies. Prior to 3.6.0 some plugins required SDL, but that's not a problem now when engine itself requires it. In practice at the moment there's only 1 popular plugin which has a non-standard dependency: the AGSteam plugin which needs "steam-api.dll". Problem is that the Editor is not aware of that, and does not copy this dll along with the plugin's dll when making the game. Users have to know about this and do it themselves every time.

Proposal

Find a way to make Editor copy plugin dependencies along with plugins automatically. Checking for dll dependency using winapi is probably possible, but is not reliable, as the list of deps may include system libraries. So there will still be a problem of distinguishing "custom" ones. Three possible methods that came to my mind so far are:

1. Add a function, roughly - "GetDependencies", - to the plugin interface, that plugin could implement. This function would return a list of custom dependencies as a list strings. Pros: reliable when available, as plugin's author may explicitly tell which dependencies they need. Cons: this method relies on plugin's author actually providing this.
2. Support reading dependency list from a text file, e.g. a file "plugin-name.deps.txt" placed along with plugins. Pros: simple, easy to add or fix by hand, anyone can add this file; we could even supply such files for popular plugins as a part of the AGS distribution. Cons: prone to mistakes (mismatching information).
3. Hardcode dependencies for the popular plugins. This is quick, but very nasty, not future compatible, and nobody else can add/fix this unless they recompile the editor.

[ericoporto]

Here's a different option:

Use a different folder structure, where each plugin has it's own directory.

• EnginePlugins
  • plugin1
  • Windows
    • x86
    • agsplugin1.dll
    • depplugin1.dll
    • Linux
    • ...

Pros: easy to update plugins separately, don't require additional plugin API, functionality is obvious Cons: lots of manual work to create the directories for the person releasing the plugin, no additional checking of dependencies - anything unintentionally placed in the directory gets copied.

Also possible for all of these is perhaps checking the dll for dependencies directly (through something like ldd).

Example from SciCompanion approach:

[Crystal-Shard]

Can game templates contain subdirectories? If so, then another approach is to make a game template, Blank Game With Steam, that includes the steam-api.dll in the Compiled\Windows folder. Building a game doesn't empty the folder, so once the DLL is there for a game, it's going to stay.

[ivan-mogilko]

Can game templates contain subdirectories? If so, then another approach is to make a game template, Blank Game With Steam, that includes the steam-api.dll in the Compiled\Windows folder. Building a game doesn't empty the folder, so once the DLL is there for a game, it's going to stay.

Templates can contain subdirectories, but

• What is the point of providing a plugin in 1 template, if somebody may be using any other template, including custom ones?
• Compiled folder is considered to be a project output and safe to delete anytime. They are also normally not added under the source control, like git or svn repositories.
• Plugins are not assumed to be present in game, instead they are copied from the Editor's program files when the game is built.
• Plugins don't only come for Windows, but for other platforms too.