Game Start Library

[AnakinRaW]

I want to extract a library for my launcher which was responsible for

• finding the games
• finding the mods
• starting the game with a mod
• starting the game with "linked mods" (as specified by the modinfo spec)

Where do we want to have that project? Here, or in a new repo.
@gruenwaldlk

[gruenwaldlk]

Having a library/utility that can find the game (and mods based on that) based on registry paths, Steam, etc. would be a nice addition.
Maybe even having a way to determine the game type.

There could be some difficulty if multiple instances are installed.

Actually starting the game should probably be up to the tool using the library.

[AnakinRaW]

I can make this two staged, so game starting logic and the rest are separated.
I already have a game type detection included.

Having multiple game installations is indeed tricky if not even impossible to solve without having a trustful user config. Best I can offer is, that the detector searched on a given path (which default to the current execution directory) or registry. Method.

One reason i have game starting code included, is becuase a game can be in some sort of intermediate state if the game is installed but not 1st time started yet (or steam integrity check). Currently i can await steam to configure the game (by starting it and closing immediatly). I could add an callback so an external tool can listen to that situation, though

[gruenwaldlk]

My expectation for a library in this case would be a single service/utility that can be used:
Something like this:

public interface IGameLocatorService : IService{
  public bool TryLocateGame([NotNull] IGameDefinition gameDefinition, [CanBeNull] out IGameLocation gameLocation);
}

IGameDefinition would be something like the IAlamoLanguageDefintion that contains the game type (EaW or FoC) and desired platform (Steam, disk, Gold Pack, ...) and maybe some additional info.

IGameLocation would return either a location, or an error state with the details on what went wrong.

Should probably be part of the PG.StarWarsGame project.

[AnakinRaW]

lgtm

[AnakinRaW]

#130

[gruenwaldlk]

I've looked over #130 but haven't seen it (I might have missed it, I'm way too tired at the moment): Is there some convenient way to end up with a final structure of hierarchically sorted mods including the absolute paths to their data directories in such a way that either file lookup calls could be implemented in such a way that the overwriting logic between dependent mods is retained, or alternatively/additionally a way to flatten a mod consisting of a bunch of submods into a single structure?

[AnakinRaW]

That layout in the issue aged i little. the plan is to call explicitly a ResolveDepdendencies function on the mod you want. You can let it resolve it recursively with an option though. After that call the Dependencies contains a sorted and flattened list of all dependencies. You can get the file path of a mod by casting it to an IPhsysicalPlayableObject which has the Directory property. This is required because we also have the concept of virtual mods, which don't have a concrete location on disk (which would be something like combined mod of two submods. See the diagram below)

The reason why i made the resolving explicit has complexity reasons.

1. When calling the resolve function, all mods, MUST already been registed to the IGame. In other words: It won't create a new IMod instance when resolving. If the IGame does not have the mod the operation will fail. Reason for that is, we otherwhise risk ending up creating multiple instances of the same mod. It also make the whole operation kind-of thread safe, meaning we can resolve multiple mod dependencies simultaneously.
2. Finding Mods on disk is a very complex and heuristic task. The resolver simply shall not be responsible for searching mods on the filesystem.
3. Supporting 2. Tool developers using this library might want to perform any kind of complex work between the instanceiation of a mod, adding it to the game and eventually resolving depdencies. If we would resolve at the moment the mod instance gets created we risk resolving on a "dirty" or unstable application state
4. This makes the mod instance as much lazy as possible. I'm not arguing with performance, because that's probably not a risk unless you have 1k of mods all chained up in odd ways. But the laziness gives you all the advantages i described in 1-3.

Same applies when an IGame instance is created. It shall NOT automatically search for mods. The developer must explicitly call this instruction.
I added events for each step to inform callbacks when such an event happened.

Diagram of a totally non-physical mod:

V ::= The virtual mod you want to play

      Physical 
     SubMod1 
   /         \
 V            + --> Physical BaseMod
   \         /
      Virtual  
    SubMod2

Expected Resolve Order: 
V, SubMod1, SubMod2, BaseMod

Note: The order below woudn't make much sense because it would create potential conflicts with SubMod1 and BaseMod, so Developers have to be very careful. 
V, SubMod2, SubMod1, BaseMod