Mapping non-transient disposable dependencies of the same type with different keys?

[JesseTG]

My game has support for local multiplayer. Each player is assigned their own IInputService whose implementation reads input from their assigned controller.

However, things get more complicated in my test suite. Among other things, my tests include:

• Constructing a map from a given grid, running for some length of time, then ensuring the grid is in the expected state
• Simulating the player's input from a pre-designed sequence
• Making a scripted sequence of changes to the test game state (like spawning enemies)
• Doing all of the above for one player (not necessarily Player 1)
• Doing all of the above for all players at the same time
• Doing all of the above for all players at the same time with each getting their own grid state, input sequence, and maybe other things

These resources are not transient because they're loaded as assets, or they contain state that needs to be known by multiple dependency recipients.

If they were transient, I could inject a factory function. However, that's not the case.

Also, these dependencies are generally disposable; they're assets that I loaded from Addressables that need to be cleaned up when the test ends. I've wrapped them in objects that implement IDisposable, but I still have to guarantee that they're disposed of.

What would you suggest?

[hadashiA]

In my opinion, you should not directly Inject an object like "Player".
The object graph between "Player" and other services will be many-to-many, and it will be very complicated to manage.

I prefer the DDD style, i.e.,

• Create a "collection of Players" (=referred to as Repository) and hide the Players from other services.
  • Through collections, many dependencies become 1:1.
  • Dispose one Player Repository and all Players will be safely disposed.
• Separate objects like "Player" and "Grid" from the control flow.
  • Create an event handler, such as the one called Controller / Presenter. This will send commands to the Player and Grid to control the timing.
  • The Controller / Presenter uses the Player. The reverse is not true.
• In addition, I prefer to separate Player Actor and Player Data, but this depends on the situation.

This is a general statement. Not sure if it will fit your case perfectly.
However, I think a design that requires less DI is preferable, and I think it is important to fix the relationship to 1:1 for layered architecture, etc.

[hadashiA]

Hmm. So, what exactly are "resourcess loaded as assets" ?
( I thought this was a player representation displayed on the screen. ..

[JesseTG]

I think I need to go into more details, then. Here is (a very old build of) my game that can provide useful context. Also, here's a blog post that describes my test suite some more; it's very old but it does have some pictures that show what I'm trying to accomplish.

When I say "Player" I am referring to the general concept of someone playing the game, not to a particular object or data structure.

Most entities in the game are associated with Player 1 or Player 2. In single-player modes, there are no entities associated with Player 2.

Each player has their own state, but they mostly share the same configuration and services (i.e. they use the same prefabs, same config objects, same audio service, etc.). They do, however, have their own input services.

And in my automated test suite, they may also have their own test initializers (because I might want both simulated players to move in different ways, or to start each test case with different grids).

Hmm. So, what exactly are "resourcess loaded as assets" ?

Pieces of test cases, mostly. Here's a screenshot:

You're looking at a test case that contains an initial grid state, and expected grid state, and the player's simulated actions (in this case to move right a few times). Each item is represented as an asset (see the little object selectors?).

Not only do I need to ensure that Player 1 can't pass through blocks, but I also need to ensure that Player 2 can't pass through blocks. This is to verify that the relevant code is sufficiently player-agnostic.

These test cases are used to generated parameterized tests, so they're mostly specific to individual test methods. Sometimes I'm testing something that doesn't fit this structure, so I load the individual assets via Addressables.

---

Here's another example that will involve both players at once. Suppose that clearing blocks will send more blocks to the other player's grid. I would want to test the following scenarios, all of which will require both players to have different final grid states and input sequences:

• When one player clears blocks, the other player's grid should have more garbage blocks
• When one player clears blocks and the other player's grid is almost full, the other player's grid should fill up
• One player's movement does not affect the other player's simultaneous movement

( I thought this was a player representation displayed on the screen. ..

No. For the actual player entities, I use an ECS library (not Unity ECS). Interactions between entities is not the issue; the issue is the occasional dependency that is mapped to a logical player. Remember, there is no one object that represents an entire player's state; there are lots of objects that are indexed with the aforementioned Player enum, though.

[hadashiA]

Ok, I think I know what you want to create, but I need to sort out the problem. What is the problem?

These resources are not transient because they're loaded as assets, or they contain a state that needs to be known by multiple dependency recipients.

What is a resource ? the blocks?
Are you having trouble finding a way to dispose of the blocks in each Integration Test case?
( If that is the case, my initial advice may not make much difference. (Just change Player to Block...)

[JesseTG]

These things. (Note the red circles.)

Although I think I might have figured something out anyway; factory functions. But it doesn't have to be a plain Func; I can make the factory stateful (and therefore disposable) and register one of its methods as a factory function.

I sometimes overthink things.

[hadashiA]

It's okay to implement Factory manually, but it's more flexible to inject a single-function Facotry into the repository. Also, the dependencies are simplified by using an object that represents a collection.

class BlockRepository : IDisposable
{
    readonly List<Block> blocks = new List<Block>();
    readonly Func<FooParam, Block> factory;

    public BlockRepository(Func<FooParam, Block> factory)
    {
        this.factory = factory;
    }

    public void Spawn(GridCoord coord, ....)
    {
        var newBlock = ...
        blocks.Add(newBlock);
    }

   // Destroying and clearing blocks, and so on...

    // Dispose all blocks...    
    public void Dispose()
    {
        // ...
    }
}

EDIT:

Yeah, I think I figured out the problem. You want to ReleaseAsset a prefab that was loaded asynchronously by Addressable, I guess.

Typically, in games, asynchronous loading is not done at every runtime, but rather in some bulk at scene transitions. (Especially if it's through a server).

Therefore, I prefer to create a dedicated class for loading/unloading Addressables as well.

class FooAssetCollection : IDisposable
{
    readonly IDictionary<FooType, GameObject> prefabs;
    // Various other resources...

    public FooAssetCollection(IDictionary<FooType, Object> prefabs)
    {
        this.prefabs = prefabs;
    }

    public void Dispose()
    {
        // Release all prefabs...
    }
}

var assets = await ...
var collection = new FooAssetCollection(...);

using (LifetimeScope.Enqueue(builder =>
{
    builder.RegisterInstance(collection)
}))
{
    await ...
}

These are my thoughts. I think you can make the Factory Disposeable as you think.