Multiton? (Singleton Variante)

Coolcat

wie es jeder machen würde

Und wie würde es jeder machen?

Coolcat

Also eine Factory ist was anderes....

...aber ich merke schon an eueren Reaktionen, dass meine Idee wohl ziemlicher Müll sein muss Ich denke ich werd es dann auf die konventionelle Art machen.

miller_m

Coolcat schrieb:

Also eine Factory ist was anderes....

wieso du brauchst halt eine basisklasse.
halten könntest du zb: in einer map<enum, basisklasse*> bei einem zugriff wird das objekt erstellt und zurückgegeben falls schon eine instanz vorhanden ist wird diese zurückgegeben. bin ich jetzt so annährend richtig was du dir vorstellst?
du könntest mir allerdings noch dein universell erklären.

Coolcat

@miller_m:
Also ja du bist nah dran... Thx das du dir mühe gibst mich zu verstehen...

Ich verstehe ich dich jetzt so, das du ein extra Menu und ein Game von Engine ableitest.
Also da alle Instanzen (also für GAME, MENU, usw.) identisch sind brauch ich ja nicht von einer Basisklasse "Engine" ableiten.
Mit universell meine ich eben genau dies. Also die Klasse ist so universell, dass man damit sowohl das Spiel selbst als auch das Menü machen kann.

Es wäre dann eine Factory, die nur Objekte vom Typ Engine erzeugt. (was dann keine Factory in dem Sinne mehr ist, vorallem, weil die Factory in die Klasse Engine eingebaut wäre)

Coolcat

miller_m

Coolcat schrieb:

Ich verstehe ich dich jetzt so, das du ein extra Menu und ein Game von Engine ableitest.

irgendwie so etwas, sprich von einer schnittstelle die vernünftig ist. blos nicht von engine halt.

class EngineObj; // virtuelle basisklasse
class Menu : public EngineObj;
// usw
class Engine
{
    map<enum, EngineObj*> objlst;

    public:
        EngineObj *get(enum) { }
};

Coolcat schrieb:

Also da alle Instanzen (also für GAME, MENU, usw.) identisch sind brauch ich ja nicht von einer Basisklasse "Engine" ableiten.

aber könntest du sie in einem container speichern.
game hat nichts mit der engine zu tun. zwischen game und engine sollte eine klare trennung sein.

[edit]
tags

Coolcat

game hat nichts mit der engine zu tun.

Hä?
Warum kann GAME (bzw. genauso MENU) nicht einfach eine Instanz von Engine sein die für das Spiel zuständig ist?

Ich meine das ungefähr so:

class Multiton {
public:
    Multiton& getMultiton(int typ) {
        Multiton* mt = mtMap[typ];
        if (mt) { return *mt; }
        mt = new Multiton();
        mtMap[typ] = mt; 
        return *mt;
    }

private:
    static map<int,Multiton*> mtMap;

    //! Konstruktor
    Multiton() { }

    //! Destruktor
    ~Multiton() { }

    //! alles freigeben, was in mtMap ist...
    static void destruct() { /*...*/ } 
};

Edit: ^^ Tippfehler im Quellcode

miller_m

Coolcat schrieb:

Warum kann GAME (bzw. genauso MENU) nicht einfach eine Instanz von Engine sein die für das Spiel zuständig ist?

ist vermutlich eine streit frage, aber für ist es so das game die engine als schnittstelle benutzt.

Coolcat

ok, mag sein

also ich sag erstmal thx@all, ich werde nochmal etwas über dem Design grübeln....

Coolcat

Machs wie alle Engines und implementier nen Szenenmanager, dann kannste im Spiel verschiedene Szenenmanager verwenden je nach Status deines Spiels.

und wo genau ist der vorteil von dem hier:

//hier tolle globale enums:

[...]

  getSingleton(GAME);
  getSingleton(MENU);

gegenüber dem hier:

//tolle, globale variablen
engine game,menu;

[...]

  game;
  menu;

ist imho beides nicht so prall.

Coolcat

@gueststar:
Saug dir hier (legal) das erste Kapitel von "Game Programming Gems 1"
http://www.edv-buchversand.de/mitp/chapter.php?cnt=chapter&id=itp-0923&lng=
(ca. 600 kb)

Und schau dir dann mal Seite 10ff und 32ff an.
Das Buch ist auch sonst sicher interesant...

Coolcat