Modular Objects with conflicting implementations

Question

I am working on a game framework that would allow users to use multiple mods/plugins to add additional features to the game.

For the remainder of the post, I'll use the following definitions:

mod: code that requires changes to both the client and the server. For example, adding a new packet to the protocol.

plugin: code that changes existing functionality without requiring a change on the other side. For example, adding a remote management interface to the server, or allows the client more fine-grained controls over sound and audio quality.

This question relates to both of these aspects, however I'll be focusing on mods as they seem to be giving me the biggest trouble.

Let's say I provide a default player class called Player that models a Player's character. Let's say, for this particular server, the server operator wants to include 2 mods, Foo and Bar, both of which are written by different people.

Both Foo and Bar need to add additional functionality to the Player class. Foo needs a method doFoo, and Bar needs a method doBar. Both actual implementations are included somehow by the mod developers (probably in a different class).

One solution I've considered is using Reflection, and modifying the class at runtime, extending specific mod interfaces. Something like

public interface FooPlayer {
    void doFoo();
}

public interface BarPlayer {
    void doBar();
}

public class FooPlayerImplementation implements FooPlayer {
    public void doFoo() {
        // ...
    }
}

public class BarPlayerImplementation implements BarPlayer {
    public void doBar() {
        // ...
    }
}

public class FooLoader {

    public void onLoad() {
        SomeManager.findPlayerClass()
                   .implementInterface(FooPlayer.class, FooPlayerImplementation.class);
    }
}

public class BarLoader {
    public void onLoad() {
        SomeManager.findPlayerClass()
                   .implementInterface(BarPlayer.class, BarPlayerImplementation.class);
    }
}

Where at runtime, it would inject the Player class with the implementations from Foo and Bar, and make it implement FooPlayer and BarPlayer. But then we have issues where two different mods add the same method signature in their own interface (which could be resolved by prepending the class name to the method, but then we're going down a very dark rabbit hole).

Another thing that I had thought about briefly was just going event-driven to an insane degree, so that developers didn't need to do something like this, but that opens an equally hair can of worms, as well as not providing the amount of control a developer might need.

But I'd REALLY like to avoid reflection if at all possible.

I've seen AspectJ and aspect-oriented programming, and it looks like it may work, but I don't have any experience to tell.

The questions I have are:

1. Is there a way to get this sort of functionality in an OOP way?
2. Is there a way to do this with the standard Java SE library?
3. Could AOP accomplish this?

Considerations: If any of these are wrong or misguided, please let me know.

1. I don't think that inheritance will work because there could be multiple mods that want to extend the functionality of Player, and all Players would be subject to all of the mods. There couldn't be a FooPlayer and a FooBarPlayer at the same time. If n mods extend the Player functionality, than the Player must have n components.
2. The decorator pattern won't really work I think because manual intervention would be required by the operator (who may or may not know anything about programming) to weave the implementations together.

Something like

public class FooBarStaminaMagickaPlayer implements Player, Foo, Bar, Stamina, Magicka

3. If possible, I would like to avoid having each mod developer have a mapping within their code to keep track of things.

For example, something like

public class StaminaMapper {
    private final Map<Player, Stamina> playerStaminaMap;
}

Answer 1

There is one other solution. It may slow down code (not as bad as reflection though) .

Everything has an interface. The classes will only do function composition: pipe returns to parameters to returns, etc. All prameters and instance variables are interfaces.

A mod or plugin is just a package of implementions for interfaces. Make one mod called defaults. Put this in its own package. That way, the rest is API code.

Mod loading has to be done. Now a container can inject classes in, and look for mod folders.

There can be a list of all mods in a file, in priority order. With a conflict, the first mod listed will be the one used in the container.

I recomand a dependency injection framework for this. I would also recomand using gaurd clauses. with messages in the exeptions for parameter valid ranges. Just because glitches, and exploits would be made.

Answer 2

You are most likely feeling like all of your options will take you down a "very dark rabbit hole" because you are already in a rabbit hole, and the proper solution is to step back out of the hole and consider a new direction.

Here is a link on how many games are developed which might address your concerns indirectly but more fundamentally.

https://en.wikipedia.org/wiki/Entity_component_system

This quote I think addresses your exact roadblock:

An ECS follows the Composition over inheritance principle that allows greater flexibility in defining entities where every object in a game's scene is an entity (e.g. enemies, bullets, vehicles, etc.). Every Entity consists of one or more components which add additional behavior or functionality. Therefore the behavior of an entity can be changed at runtime by adding or removing components. This eliminates the ambiguity problems of deep and wide inheritance hierarchies that are difficult to understand, maintain and extend.

and

http://www.gamedev.net/page/resources/_/technical/game-programming/understanding-component-entity-systems-r3013

---

Ok this is my attempt to give you an example of how to solve the problem using ECS. This can be greatly improved upon. The purpose is to show off the design, not the details of how to make it work optimally.

abstract class Component
{
    public string ComponentType { get; } // implements some identifier which modders can generate/register for new components
}

class Position : Component { }
class Velocity : Component { }
class Health : Component { }

abstract class Entity
{
    public List<Component> Components;
    public abstract T GetComponentOfType<T>();
    public abstract Component GetComponentById(string Id);
}

class MovementSystem
{
    public static void Execute(Position p, Velocity v)
    {
        // do stuff with p and v
    }
}


// When it comes time to add new components, all you do is add the modder's new component, system, registration, and any other mechanism for incrementing the game loop.

class Stamina : Component { }

class StaminaSystem
{
    void Execute(Position p, Velocity v, Stamina s)
    {
        // do stuff with p and v and s
    }
}

class StaminaSystemLoop
{
    bool IsEntityEquipedWithCorrectComponentsForThisSystem(Entity e);

    void Increment(Entity e)
    {
         StaminaSystem.Execute(e.GetComponentOfType<Position>(), e.GetComponentOfType<Velocity>(), e.GetComponentOfType<Stamina>());
    }
}



class GameLoop
{
    void Increment(List<Entity> gameEntities)
    {
        foreach(var e in gameEntities)
        {
             // Detect if entity is a match for any given system.
             // Execute the system with the components using GetComponentOfType.
             //
             // The installation process for the mod will need to add the detection logic and the execution logic.
             // So this is where you have to get creative about it. E.g.:
             if(StaminaSystemLoop.IsEntityEquipedWithCorrectComponentsForThisSystem(e))
                  StaminaSystemLoop.Increment(e);
        }
    }
}

Answer 3

I will only respond to your first question since I don't have enough experience to pronounce myself on AOP.

My favourite way to extend a complete (understand non-abstract) existing piece of code is to use the decorator pattern.

Let's say this is what you defined as a minimal working player for your framework. The most important point is that every public method in PlayerImpl must be inherited from Player (see below why):

public interface Player {
    void doAction();
}

public final class PlayerImpl implements Player {
    @Override
    public void doAction() {
        //do action
    }
}

It is then possible for mods developers to safely (without altering the existing) add behaviour to a player using the decorator pattern:

public interface Foo {
    void foo();
}

public final class FooPlayer implements Player, Foo {
    private final Player origin;

    public FooPlayer(Player origin) {
        this.origin = origin;
    }

    @Override
    public void doAction() {
        origin.doAction(); //or define totally new behaviour when needed (typically for a plugin)
    }

    @Override
    public void foo() {
        // put special mod behaviour
    }
}

And then in usage, instances of FooPlayer are always usable by your framework (because they inherit from Player) and the mod developer can also use the specific behaviour in its code when needed:

public static void main(String[] args) {
    FooPlayer p1 = new FooPlayer(MyGame.provideNewPlayer());
    MyGame.registerNewPlayer(p1); //still compatible with what you provide altough holding a reference of FooPlayer
    p1.doAction();
    p1.foo();
}

Answer 4

I don't think any form of inheritance is going to work reliably with this. As you've identified, you're going to have conflicts, and you'll be creating a brittle/fragile set of classes. If you change your base class (for whatever reason) then all your clients will have to change too.

AOP may work for you, but I think it'll be non-intuitive, and I don't think it'll be particularly resilient in the face of code changes.

My preferred solution in this sort of scenario is to follow your observer idea. Clients A and B can both register listeners and then run code upon changes registered by your server class. You'll probably find that you have to issue events for most (all?) state changes, and perhaps make other entities in your system available (via a supported API) for your clients. As it stands, it sounds like your requirements are pretty vague, and I would do something simple for the moment and see what transpires.

Answer 5

For blending, make a class called FooBlender. Where Foo is the interface. It will have a list off Foo. For each method call, get the list of what the other classes return. Then return the average or blend of that list.