Observer vermeiden?

[StefanBo]

Was wenn zwei Städte kollidieren?

Die Städte in meinem Spiel haben keine Reifen.

[kollidieren]

StefanBo schrieb:

Was wenn zwei Städte kollidieren?

Die Städte in meinem Spiel haben keine Reifen.

Hat die Erde oder ein Meteor auch nicht und trotzdem kann es zu einer Kollision kommen!

[StefanBo]

kollidieren schrieb:

StefanBo schrieb:

Was wenn zwei Städte kollidieren?

Die Städte in meinem Spiel haben keine Reifen.

Hat die Erde oder ein Meteor auch nicht und trotzdem kann es zu einer Kollision kommen!

Fliegende/schwebende Städte habe ich aber auch nicht.

So, back to topic. Anyone?

[StefanBo]

So, habe mir mal einen Account gemacht und probiert, die Problematik mit zwei Beispielen und einem kleinen Diagramm deutlicher zu machen. Sorry schon einmal für's Doppelposten, aber ich kann die anonymen Beiträge ja nicht editieren.

Klick mich. Ich hoffe das Englische stört nicht.

[pumuckl]

Okay, so gesehen find ich das Design eher mäßig. Das Lua-Script sollte mit dem interagieren, der die Kontrolle über die "Welt" hat, nicht mit der ganzen Welt. In deinem Fall wäre das der server selbst, oder eine Ebene, die zwischen Modifier und Server gesteckt wird. Dann behälst du auch die Kontrolle darüber, was getan wird und wirst vom Script nicht überascht.

[StefanBo]

Okay. Die Sache ist nur, dass ich es ziemlich angenehm gefunden hätte, die Objekte von überall modifizieren zu können, ohne mir über Seiteneffekte Gedanken machen zu müssen.

Momentan nutze ich Luabind, um die C++-Klassen nach Lua zu exportieren, und das funktioniert sehr leicht und komfortabel. Wenn ich dann das Modifizieren der Daten direkt verbiete, müsste ich ein Interface nach Lua exportieren, das die Kontrolle hat, richtig?

Weiterhin wäre es auch irgendwie ärgerlich, für jede Operation, die ein Entity betrifft, in einem Interface Methoden bereitzustellen. Bspw.:

class Interface {
	public:
		bool MoveEntity( Entity& entity, const Vector3& new_position );
		// ...
};

Aber wie es aussieht, braucht's eine zentrale Instanz, die Herr der Lage ist. Danke pumuckl. Falls sonst noch jemand eine Idee hat: Immer her damit.

[ipsec]

Mal Lua-Script hin oder her, wenn die Position eines Autos verändert wird, muss es seiner Stadt melden "ich habe mich bewegt". Und die Stadt muss es dann irgendwie an dan Netzwerkserver weiterreichen (da könnte man vielleicht mit Observer arbeiten, da kenne ich jetzt das Gesamtdesign zu wenig). Und ob jetzt das Auto.SetPos(...) im Lua-Script oder im Quelltext aufgerufen wird, spielt ja eigentlich keine Rolle.

[Eisflamme]

Deswegen ja pumuckls Vorschlag ne Zwischenschicht zu basteln, über die die Veränderungen erfolgen...

Man kann auch für jede zu verändernde Klasse eine Proxy-Klasse basteln, die Änderungen weiterreicht, aber zusätzlich dem Server Meldung tut.

[pumuckl]

StefanBo schrieb:

die Objekte von überall modifizieren zu können, ohne mir über Seiteneffekte Gedanken machen zu müssen.

Grade wenn du die Objekt von überall modifizieren lässt, hast keine Kontrolle mehr über die Modifikationen und die Seiteneffekte. Vor allem, wenn die Autos relativ "dumme" Objekte sein sollen, muss es irgendjemanden geben, der auf sie aufpasst

[StefanBo]

Eisflamme schrieb:

Man kann auch für jede zu verändernde Klasse eine Proxy-Klasse basteln, die Änderungen weiterreicht, aber zusätzlich dem Server Meldung tut.

Das wäre eine Mischung aus Proxy und Observer, wenn ich das richtig sehe. Die Idee finde ich ziemlich genial.

In diesem Falle dann z.B. "EntityProxy", der die Position eines "Entity"-Objekts modifiziert und zusätzlich einen Observer benachrichtigt. Ich finde das sehr elegant, weil man so einerseits die Daten (Entity) von den Operationen (EntityProxy) trennt und abhängige, zusätzliche Operationen möglich macht (Senden der aktualisierten Daten über's Netz).

Edit: Wie sieht denn das implementationstechnisch aus? Ich dachte da jetzt an Klassenmethoden, die auf die Daten wirken. Oder ist das für solche Fälle eher untypisch? (möglich ist auch, dass EntityProxy eine Referenz auf Entity hält)

pumuckl schrieb:

Grade wenn du die Objekt von überall modifizieren lässt, hast keine Kontrolle mehr über die Modifikationen und die Seiteneffekte. Vor allem, wenn die Autos relativ "dumme" Objekte sein sollen, muss es irgendjemanden geben, der auf sie aufpasst

Da hast du völlig recht. Einen Proxy davor zu schalten scheint mir wirklich die (bzw. eine) sinnvolle Lösung zu sein.

Danke an alle!

[pumuckl]

Ich weiß nicht, ob du wirklich für jede Entität einen Proxy brauchst. Wenn das Ganze übers Netzwerk läuft, brauchst du ja so oder so ein Handle oder eine ID für deine Entities. Wenn du einen einzelnen Entity-Manager hast, kannst du ihm mitteilen, dass du eine Entität bewegen willst und die ID/das Handle mitgeben. Der Manager kümmert sich dann um die Validierung (ist es möglich/erlaubt?) und Weiterleitung des Befehls an das Entity-Objekt, und darum, die Observer zu benachrichtigen, die sich bei ihm für die ID angemeldet haben.

[StefanBo]

Ich hatte auch zunächst überlegt, diese Funktionalität in "Universe" unterzubringen, wo die Entities aufgehoben werden. Mir gefällt aber der Gedanke, dass die Funktionsweise davon abgekapselt ist.

Weiterhin fällt mir das Exportieren nach Lua um ein Vielfaches einfacher, weil ich den ganzen Proxy-Kram sehr gut verstecken kann. In einem Lua-Skript sieht es weiterhin so aus, als würde man direkt mit dem Objekt zu tun haben. Sonst müsste ich quasi den Entity-Manager exportieren, was dann nicht mehr so schön nach OOP aussieht.