Alternative all'ereditarietà multipla per la mia architettura (NPC in un gioco di strategia in tempo reale)?

La composizione e l'ereditarietà dell'interfaccia sono le solite alternative all'eredità multipla classica.

Tutto ciò che hai descritto sopra che inizia con la parola "can" è una capacità che può essere rappresentata con un'interfaccia, come in ICanBuild o ICanFarm . Puoi ereditare tante di quelle interfacce come credi di aver bisogno.

public class Worker: ICanBuild, ICanFarm
{
    #region ICanBuild Implementation
    // Build
    #endregion

    #region ICanFarm Implementation
    // Farm
    #endregion
}

Puoi passare in edifici "generici" e coltivare oggetti attraverso il costruttore della tua classe. Ecco dove arriva la composizione.

Come altri posters hanno menzionato, l'architettura di un componente potrebbe essere la soluzione a questo problema.

class component // Some generic base component structure
{
  void update() {} // With an empty update function
} 

In questo caso estendi la funzione di aggiornamento per implementare qualsiasi funzionalità che l'NPC dovrebbe avere.

class build : component
{
  override void update()
  { 
    // Check if the right object is selected, resources, etc
  }
}

L'iterazione di un contenitore di componenti e l'aggiornamento di ciascun componente consentono di applicare la funzionalità specifica di ciascun componente.

class npc
{
  void update()
  {
    foreach(component c in components)
      c.update();
  }

  list<component> components;
}

Poiché ogni tipo di oggetto è ricercato, puoi utilizzare una qualche forma del modello di fabbrica per costruire i singoli tipi che desideri.

npc worker;
worker.add_component<build>();
worker.add_component<walk>();
worker.add_component<attack>();

Ho sempre avuto problemi mentre i componenti diventano sempre più complessi. Mantenere bassa la complessità dei componenti (una sola responsabilità) può aiutare ad alleviare questo problema.

Se definisci interfacce come ICanBuild , il tuo sistema di gioco deve ispezionare ogni NPC per tipo, che in genere è disapprovato in OOP. Ad esempio: if (npc is ICanBuild) .

Stai meglio con:

interface INPC
{
    bool CanBuild { get; }
    void Build(...);
    bool CanFarm { get; }
    void Farm(...);
    ... etc.
}

Quindi:

class Worker : INPC
{
    private readonly IBuildStrategy buildStrategy;
    public Worker(IBuildStrategy buildStrategy)
    {
        this.buildStrategy = buildStrategy;
    }

    public bool CanBuild { get { return true; } }
    public void Build(...)
    {
        this.buildStrategy.Build(...);
    }
}

... o ovviamente potresti usare un certo numero di architetture diverse, come un qualche tipo di linguaggio specifico del dominio sotto forma di un'interfaccia fluente per definire diversi tipi di NPC, ecc., dove si costruiscono tipi di NPC combinando diversi comportamenti:

var workerType = NPC.Builder
    .Builds(new WorkerBuildBehavior())
    .Farms(new WorkerFarmBehavior())
    .Build();

var workerFactory = new NPCFactory(workerType);

var worker = workerFactory.Build();

Il generatore NPC potrebbe implementare un DefaultWalkBehavior che potrebbe essere sovrascritto nel caso di un NPC che vola ma non può camminare, ecc.

Metteremo tutte le abilità in classi separate che ereditano dall'Abilità. Poi nella classe tipo unità hai una lista di abilità e altre cose come attacco, difesa, salute massima ecc. Inoltre hai una classe di unità che ha salute, posizione, ecc. E ha tipo unità come variabile membro.

Definisci tutti i tipi di unità in un file di configurazione o in un database, invece di codificarlo con precisione.

Quindi il level designer può facilmente regolare le abilità e le statistiche dei tipi di unità senza ricompilare il gioco, e anche le persone possono scrivere mod per il gioco.