proggen.org

Hey,

wenn ich ein Programm nach dem Model-View-Controller Design habe, ist es da sinnvoll das Model als eigenständigen Thread zu implementieren und über ein Eventsystem mit dem Controller arbeiten zu lassen? Beispielsweise wenn die View die Ausgabe eines 2D-Spiels erledigt und der Controller dabei die Benutzereingaben auswertet und vom Model Dinge berechnen lässt.

Also quasi so, dass Controller und View vom primären Thread behandelt werden und das Model eigenständig parallel läuft. Dann würde der Controller z.B. eine Bewegung (Pfeiltaste) erkennen, dem Model ein Event (dass sich der Spieler bewegen will) zuschieben. Irgendwann gibt das Model eine Antwort mit der neuen Position des Spielers. Die Antwort bekommt dann der Controller (über ein Event-System zurück) und kann der View die Veränderung mitteilen. Dabei könnte der Controller gucken: "Sind Events vom Model angekommen?". Wenn ja, gibt es die Events an die View (damit diese dann die Ausgabe modifiziert). Wenn er damit fertig ist (oder keine Events ankamen) lässt der Controller die View noch zeichnen und beginnt wieder von vorne.

Damit müsste der Controller nicht auf ggf. langwierige Pfadfindungen warten (imho würde das ja zu Lags führen). Andererseits sollte ich auch keine Probleme mit Race Conditions bekommen, wenn ich das Event-System bzgl. Senden und Empfangen von Events thread-safe mache, wenn für das Model genau ein Thread (und nicht mehrere) verantwortlich sind.

Was sagt ihr dazu? Ist das sinnvoll? Und auf was müsste ich konzeptionell noch achten?

LG Glocke

Glocke hat geschrieben:wenn ich ein Programm nach dem Model-View-Controller Design habe, ist es da sinnvoll das Model als eigenständigen Thread zu implementieren und über ein Eventsystem mit dem Controller arbeiten zu lassen? Beispielsweise wenn die View die Ausgabe eines 2D-Spiels erledigt und der Controller dabei die Benutzereingaben auswertet und vom Model Dinge berechnen lässt.

Klar, insbesondere wenn Du mehrere Views hast, die laufend den Controller nerven, ist es positiv, wenn dieser schnell wieder zuhören kann.

Glocke hat geschrieben:Also quasi so, dass Controller und View vom primären Thread behandelt werden und das Model eigenständig parallel läuft. Dann würde der Controller z.B. eine Bewegung (Pfeiltaste) erkennen, dem Model ein Event (dass sich der Spieler bewegen will) zuschieben. Irgendwann gibt das Model eine Antwort mit der neuen Position des Spielers. Die Antwort bekommt dann der Controller (über ein Event-System zurück) und kann der View die Veränderung mitteilen. Dabei könnte der Controller gucken: "Sind Events vom Model angekommen?". Wenn ja, gibt es die Events an die View (damit diese dann die Ausgabe modifiziert). Wenn er damit fertig ist (oder keine Events ankamen) lässt der Controller die View noch zeichnen und beginnt wieder von vorne.

Ich denke, hier stellt sich schnell die Frage, wer hier was macht und wie lange er dafür braucht.
Die View erkennt ja die Eingabe (z.B. einen Mausklick) und schickt das an Control. Control schaut im Model nach, was angeklickt wurde und entscheidet, was das bedeutet, ändert das Model entsprechend und gibt dem View den Hinweis, dass es nun was anderes darstellen soll.
Damit der Spieler weiterhin Action auf dem Bildschirm hat, sehe ich die View als ersten Kandidaten für einen eigenen Thread.

Glocke hat geschrieben:Was sagt ihr dazu? Ist das sinnvoll? Und auf was müsste ich konzeptionell noch achten?

Wie übliche: das Modell darf keine Antworten geben, wenn es gerade im Umbau ist. Sonst fragt Deine View, ob sie auf Feld 1/1 einen Panzer malen muss und erhält ein ja; das Model schiebt den Panzer auf Feld 1/2 und wenn das Model bei Feld 1/2 angekommen ist steht da auch ein Panzer...

Also gleich eine aktuelles Karte schicken (der Panzer ist auf 1/1 oder auf 1/2, aber er ist genau einmal da und nicht verschwunden oder doppelt) oder dem View auf Halde stellen, bis das Model wieder konsistent ist.

Vorneweg: die MVC-Idee habe ich in meinem Kopf etwas verändert:
http://img13.myimg.de/mymvcc920a.png

Dabei habe ich wie gesagt überlegt das Model als eigenständigen, parallelen Prozess zu verwalten, der mittels Eventsystem mit dem Controller interagiert.

Xin hat geschrieben:Die View erkennt ja die Eingabe (z.B. einen Mausklick) und schickt das an Control. Control schaut im Model nach, was angeklickt wurde und entscheidet, was das bedeutet, ändert das Model entsprechend und gibt dem View den Hinweis, dass es nun was anderes darstellen soll.

Also das was ich "Controller" nenne beinhaltet z.B. das prüfen, welche Taste gedrückt wurde (z.B. mit SDL-Funktionen). Mein Model gibt der View indirekt den Hinweis, was sich verändert hat, indem es dem Server irgendwann "antwortet". Damit meine ich keine direkt "Antwort" im üblichen Sinne, sondern vielmehr ein Update "das ist jetzt dort". Und dieses Update gibt der Controller dann an die View weiter. Sicherlich könnte man dieses Update direkt vom Model an die View geben.

Xin hat geschrieben:Damit der Spieler weiterhin Action auf dem Bildschirm hat, sehe ich die View als ersten Kandidaten für einen eigenen Thread.

Naja mein "Game Loop" besteht quasi aus dem Wechselspiel User-Controller-View. Bei jedem Durchlauf geschieht folgendes:

• Die Eingaben werden mit SDL-Funktionen erkannt und in einer separaten Struktur abgespeichert.
• Aus der Struktur erkennt der Controller welches Ereignis der Spieler ausgelöst hat (z.B. seine Figur zu bewegen).
• Dieses Ereignis gibt der Controller an den Model-Thread. Damit ist für ihn die Sache gegessen.
• Danach schaut er, ob vom Model Aktualisierungen vorliegen. Wenn ja gibt er die an die View.
• Dazu liest er die Event-Daten und manipuliert die View über ihre entsprechende Methoden.
• Anschließend sagt er der View: "Malen". Diese löscht den Bildschirm, zeichnet alles und zeigt es an.
• Schließlich berechnet der Controller die Framerate und wartet ggf. ein paar ms, um das Programm zu bremsen.

Als mögliche Verzögerungsquelle sehe ich da erstmal die Verarbeitung der an die View weitergeleiteten Updates. Allerdings weiß ich nicht genau was da ein View-Thread bringen würde. Gehen wir davon aus, dass das Model seine Updates direkt an die View leitet, würde die View dann eben die Aktualisierungen genauso anwenden und die Framerate entsprechend sinken. (Abgesehen davon müsste dann die View selbständig die Framerate steuern - aber das wäre kein Problem). Für den Controller bliebe dann schließlich nur das "Eingabe erfassn und dem Model mitteilen".

Btw habe ich mit Absicht das so gedacht, dass das Model den Controller benachrichtigt, weil:
Wenn ein Spieler das Spiel verlassen will (und wir befinden uns in einem Netzwerkspiel), dann sollten die anderen Spieler ja darüber benachrichtigt werden, die Daten des Spielers entfernt werden usw. Somit würde dieser Logout auch ein Ereignis sein, der ans Model muss. Geht das Update "User X ist raus" aber direkt an die View (die dann dessen Sprites entfernt), würde der Controller das nicht wissen. Indem er vom Model benachrichtigt wird mit "So, der ist raus. Bin fertig mit ihm." weiß er, dass der Logout "geklappt" hat (von der Absicht des Spielers wusste er ja durch die Eingabe bereits, nur nicht vom "Erfolg" dessen). Okay, schlechtes Beispiel von einem "erfolgreichen Logout" zu sprechen. Aber ich denke ihr wisst was ich meine
Der Controller soll - wenn es sich z.B. um den eigenen Spieler handelt - dann nicht das Programm beenden sondern z.B. ins Menü zurückkehren. Dazu sollte aber das Model (wenn er Server runtergefahren wird) mit beendet werden... ich fände es da falsch den Controller nicht über den "Erfolg" zu informieren. Aber vielleicht lässt sich das besser lösen

Xin hat geschrieben:Wie übliche: das Modell darf keine Antworten geben, wenn es gerade im Umbau ist. Sonst fragt Deine View, ob sie auf Feld 1/1 einen Panzer malen muss und erhält ein ja; das Model schiebt den Panzer auf Feld 1/2 und wenn das Model bei Feld 1/2 angekommen ist steht da auch ein Panzer...

Okay das sollte sich dann mit meiner Erklärung erübrigt haben

LG Glocke

Poste die Bilder bitte ins Forum. Externe Links verschwinden.
Wir haben noch über 100G ungenutzten Speicherplatz, den möchte ich nicht damit verschwenden, dass Posts darüber geschrieben werden, dass Bilder unauffindbar - oder in dem Fall - forbidden sind.

Glocke hat geschrieben:

Xin hat geschrieben:Die View erkennt ja die Eingabe (z.B. einen Mausklick) und schickt das an Control. Control schaut im Model nach, was angeklickt wurde und entscheidet, was das bedeutet, ändert das Model entsprechend und gibt dem View den Hinweis, dass es nun was anderes darstellen soll.

Also das was ich "Controller" nenne beinhaltet z.B. das prüfen, welche Taste gedrückt wurde (z.B. mit SDL-Funktionen). Mein Model gibt der View indirekt den Hinweis, was sich verändert hat, indem es dem Server irgendwann "antwortet". Damit meine ich keine direkt "Antwort" im üblichen Sinne, sondern vielmehr ein Update "das ist jetzt dort". Und dieses Update gibt der Controller dann an die View weiter. Sicherlich könnte man dieses Update direkt vom Model an die View geben.

Der Controller trifft üblicherweise die Entscheidung, wie auf ein Event zu reagieren ist. Das Event wird aber doch im View ausgelöst, schließlich klickst Du mit der Maus auf die View und die View sagt - je nach eigener Intelligenz dem Controller, dass Panzer 15 geklickt wurde. Der Controller entscheidet dann, ob dieser Panzer jetzt markiert wurde oder ob dieser Panzer jetzt angegriffen wird, weil Du vorher auf Panzer 10 geklickt und dann auf "angreifen" geklickt hast.

Jede Aktion ist quasi ein "Tool". Am Anfang ist das Tool "Markieren" aktiv. Du klickst Panzer 10, das Tool entscheidet, den Panzer zu markieren und ein Menü bereit zu stellen. Du klickst auf "Angreifen", das Menü wird ausgeblendet und Du packst Du das Tool "Attacke!" auf den Toolstack. Die View bekommt ein neues Klick, diesmal auf Panzer 15, sendet das an den Controller. Der Controller leitet das Event an das aktive Tool "Attake!" weiter. Das Tool weiß, dass Panzer 10 jetzt Panzer 15 attackieren soll und gibt dem Model den Auftrag, an Panzer 10 die Handlung "verfolgte und attackiere Panzer 15" zu übergeben.
View fordert in der Zwischenzeit mal ein Update der Karte und stellt dieses da. Dabei steht Panzer 10 jetzt anders da, weil er sich Richtung Panzer 10 ausrichtet... Im Controller hat das Tool "Attacke!" seine Aufgabe erledigt, beendet sich und entfernt sich vom Stack. Das oberste Tool ist jetzt wieder "Markieren" und Du kannst den nächsten Panzer markieren, um Befehle zu geben.

Spielen zwei Personen (also zwei Views), kommen auch Eingaben aus unterschiedlichen Bereichen. Entsprechend kann ein Controller das nicht abfragen.

Der Controller hat in der Regel überhaupt keine Verbindung zum Anwender, sondern enthält die Programmlogik. View ist die Anwenderseite, das Model die Datenhaltung. Das Model verwaltet aber nicht die Aktualisierungen für eine einzelne View. Man will Userinteraktion (View), Programmlogik (Controller) und Daten (Model) ja vollkommen voneinander trennen, damit man View oder Model austauschen kann. Eine View für Textdisplays oder Drucker. Oder man nimmt das Model mit und baut einen Leveleditor damit - für einen Leveleditor kann man vermutlich auch die View wiederverwenden, aber die Programmlogik (Attacke!) ist eine andere.

Glocke hat geschrieben:[*] Schließlich berechnet der Controller die Framerate und wartet ggf. ein paar ms, um das Programm zu bremsen.

Nicht warten... oder nur konstant und kurz. (max. 20 Millisekunden)

Frag das Model, wie die aktuelle Karte ist, zeichne sie, stell sie dar. Und das in einem Endlosloop, höchstens unterbrochen durch das Senden von "Klick" an den Controller.

Glocke hat geschrieben:Für den Controller bliebe dann schließlich nur das "Eingabe erfassn und dem Model mitteilen".

Das Model hat keine Programmlogik, sondern nur eine Schnittstelle, die Daten zu bearbeiten, Fragen zu stellen (Wo ist der Panzer mit der ID...).

Glocke hat geschrieben: Btw habe ich mit Absicht das so gedacht, dass das Model den Controller benachrichtigt, weil:
Wenn ein Spieler das Spiel verlassen will (und wir befinden uns in einem Netzwerkspiel), dann sollten die anderen Spieler ja darüber benachrichtigt werden, die Daten des Spielers entfernt werden usw. Somit würde dieser Logout auch ein Ereignis sein, der ans Model muss. Geht das Update "User X ist raus" aber direkt an die View (die dann dessen Sprites entfernt), würde der Controller das nicht wissen. Indem er vom Model benachrichtigt wird mit "So, der ist raus. Bin fertig mit ihm." weiß er, dass der Logout "geklappt" hat (von der Absicht des Spielers wusste er ja durch die Eingabe bereits, nur nicht vom "Erfolg" dessen). Okay, schlechtes Beispiel von einem "erfolgreichen Logout" zu sprechen. Aber ich denke ihr wisst was ich meine

Wenn Du Programmlogik und zusammenpackst, dann hat der Controller wirklich nichts zu tun. Dann ist es aber auch nur ein (MC)-V-Aufbau.

Die Abmeldung sollte der Viewer machen. Er verbindet sich mit dem Netzwerkservice (dem Spiel-Controller). Spielt man nicht im Netzwerk startet er einen eigenen Spielcontroller.

Hier ist MVC vielliecht was klein gedacht. Du brauchst quasi MS-VC. View und Controller, der lokal läuft und Model und Service, der das Spiel steuert. Der Controller steuert die Verbindungen zum Service, startet lokal einen Service wenn man alleine spielt. Aber das Model schickt Meldungen. Die View darf höchstens über Controller und Service fragen, wie denn gerade so die Weltlage ist. Du hast also gewissermaßen zwei Controller-Hierarchien: Spielcontroller (Service) und Teilnehmer-Programmlogik (Controller) je Teilnehmer.

Sieh das MVC nicht sooo eng. Das Pattern löst Probleme die für MVC passen. Pass Dein Problem nicht dem Pattern an, sondern überlege Dir ein für Dein Problem passendes Pattern. Hier eben die Trennung zwischen Userinteraktion (Viewer, der die Darstellung und Eingaben annimmt), dem Viewer-Controller, der Deinen Eingaben eine Semantik verleiht (Klick, Move, Klick, klick => Aha! Panzer 10 greift 15 an), dem Service-Controller (Spieler A:Panzer 10 greift 15 an, das trage ich ins Model ein) und eben dem einen Model (Landschaft + Handlung) oder den zwei Models (Landschaft / Handlung).
Sieh MVC als Inspiration, nicht als Dogma.

Wow schönes Post Ich fasse mal zusammen

• Bilder als Anhang... Geht klar
• Die View erzeugt UserEvents (Unit Movement etc.)
• Der Controller führt die Logik (Pathfinding usw.) aus (Hoffe ich hab das so richtig verstanden^^)
• Das Model enthält die Units

Xin hat geschrieben:Sieh das MVC nicht sooo eng. Das Pattern löst Probleme die für MVC passen. Pass Dein Problem nicht dem Pattern an, sondern überlege Dir ein für Dein Problem passendes Pattern. Hier eben die Trennung zwischen Userinteraktion (Viewer, der die Darstellung und Eingaben annimmt), dem Viewer-Controller, der Deinen Eingaben eine Semantik verleiht (Klick, Move, Klick, klick => Aha! Panzer 10 greift 15 an), dem Service-Controller (Spieler A:Panzer 10 greift 15 an, das trage ich ins Model ein) und eben dem einen Model (Landschaft + Handlung) oder den zwei Models (Landschaft / Handlung).
Sieh MVC als Inspiration, nicht als Dogma.

Ich glaube ich werde vom MVC-Konzept erstmal bissel abkommen. Hier mal das Konzept was ich bisher so verwenden würde:

Jeder Client enthält View und Client-Controller. Der Server enthält Server-Controller und Model. Meine View erzeugt User-Events, wie MoveUnit(UnitID, Destination) und gibt diese über ein Event-System an den Controller. Der Main-Thread verwaltet die View. Der Client-Controller ist ein separater Prozess und interagiert mit dem Server. Dazu schickt er alle Events via TCP an den Server-Controller. Der gibt das Event schließlich ans Model. Mein Model beeinhaltet die Logik. Ich sehe in diesem Kontext die beiden Controller eher als Client und Server eines Server-Client-Systems. Mit der Netzwerkkommunikation haben die wahrscheinlich genug Arbeit. Auf dem Server läuft wie gesagt der Server-Controller und gibt die Events via Event-System an das Model, indem eine Model-Methode moveUnit(PlayerID, UnitID, Destination) aufgerufen wird. Dabei haben wir einen eigenständigen Server.
Wenn ein Spiel gehostet wird, soll einer der Spieler als Server fungieren. Dazu müsste der Server um die Client-View erweitert werden, die dann ihre Events direkt ans Model gibt.
Für jede Änderung erzeugt das Model ein Update - z.B. UnitPosition(UnitID, Position) - das der Server via UDP an den Client schickt. Die View des Clients führt die Änderung dann durch.

Somit wäre ich dann effektiv bei einem View-Service-Model-System (bzw. lokal für den Server mit Clientfunktionalität) bei einem View-Model-System.

Könnte meine Rechnung so aufgehen? Das ganze ist jetzt eher ein Konzept als das davor

LG Glocke

/EDIT: Daten und datenbezogene Logik zusammenzufassen erscheint mir sinnvoll, da Ausgabe und ausgabebezogene Logik (in der View) auch zusammengefasst sind

Glocke hat geschrieben:Für jede Änderung erzeugt das Model ein Update - z.B. UnitPosition(UnitID, Position) - das der Server via UDP an den Client schickt. Die View des Clients führt die Änderung dann durch.

Somit wäre ich dann effektiv bei einem View-Service-Model-System (bzw. lokal für den Server mit Clientfunktionalität) bei einem View-Model-System.

Könnte meine Rechnung so aufgehen? Das ganze ist jetzt eher ein Konzept als das davor

Deine Rechnung kann aufgehen. Ich kann mich weiterhin nicht damit anfreunden, dass die View Änderungsmitteilungen verschickt, aber weder muss ich es programmieren, noch freunde ich mich mit jedem Softwaredesign an, was trotzdem funktioniert.

Xin hat geschrieben:Ich kann mich weiterhin nicht damit anfreunden, dass die View Änderungsmitteilungen verschickt

Naja das Model schickt die Mitteilungen an die View. Die View sendet effektiv "Aktualisierungsaufforderungen" in Form der Events.

Btw. entspräche das doch auch MVC (wenn man Wiki glauben schenken mag ^^) :
http://de.wikipedia.org/wiki/Model_View ... 28model.29

Die Bekanntgabe von Änderungen an relevanten Daten im Modell geschieht nach dem Entwurfsmuster „Beobachter“

Wie man den Beobachter dann implementiert ist ja eine andere Sache.

Xin hat geschrieben:Deine Rechnung kann aufgehen.

Siehst du eventuell Punkte auf die ich dabei achten müssten - bzw. was ich derzeit noch nicht berücksichtigt habe? Du hast mit Software-Entwicklung mehr Erfahrung als ich

LG Glocke

Glocke hat geschrieben:

Xin hat geschrieben:Ich kann mich weiterhin nicht damit anfreunden, dass die View Änderungsmitteilungen verschickt

Naja das Model schickt die Mitteilungen an die View. Die View sendet effektiv "Aktualisierungsaufforderungen" in Form der Events.

Btw. entspräche das doch auch MVC (wenn man Wiki glauben schenken mag ^^) :
http://de.wikipedia.org/wiki/Model_View ... 28model.29

Die Bekanntgabe von Änderungen an relevanten Daten im Modell geschieht nach dem Entwurfsmuster „Beobachter“

Ich sagte ja auch nicht, dass das falsch ist, ich sagte lediglich, dass ich als View vermeiden würde, ein zweites Model zu pflegen, in das dann Änderungen aus dem Server-Model übertragen werden müssen.
Das kann notwendig sein, um die Netzwerklast zu senken. Aber wenn's nicht nötig ist, würde ich darauf verzichten.

Glocke hat geschrieben:

Xin hat geschrieben:Deine Rechnung kann aufgehen.

Siehst du eventuell Punkte auf die ich dabei achten müssten - bzw. was ich derzeit noch nicht berücksichtigt habe? Du hast mit Software-Entwicklung mehr Erfahrung als ich

Ich bin nicht im Planungskomitee Deiner Software, ich weiß nichtmals, was Du für ein Spiel planst. ^^

Eine qualifizierte Aussage ist entsprechend ... "Keine Ahnung" ^^
Vielleicht orientierst Du Deine Planung ein wenig an meiner Softwaretechnik für den Hausgebrauch Sie hilft in jedem Fall Punkte zu finden, auf die man achten sollte.

Xin hat geschrieben:Ich sagte ja auch nicht, dass das falsch ist, ich sagte lediglich, dass ich als View vermeiden würde, ein zweites Model zu pflegen, in das dann Änderungen aus dem Server-Model übertragen werden müssen.
Das kann notwendig sein, um die Netzwerklast zu senken. Aber wenn's nicht nötig ist, würde ich darauf verzichten.

Ach jetzt hab ich gerafft was du meinst xD Du gehst davon aus, dass die View jeden Zyklus neu erfragt wo alles ist, und alte Daten quasi "vergisst" nachdem es alles gemalt hat, richtig?
Unabhängig von der Netzwerklast glaube ich, dass - wenn sich die View die Objekte merkt und alle bewegten Objekte aktualisiert werden - das den Datenaustausch zwischen Model und View wesentlich verkleinert.... imho ^^

Xin hat geschrieben:Ich bin nicht im Planungskomitee Deiner Software, ich weiß nichtmals, was Du für ein Spiel planst. ^^
Eine qualifizierte Aussage ist entsprechend ... "Keine Ahnung" ^^

Ein Rollenspiel mit isometrischer Darstellung und Mehrspielerfunktionalität. Das ist sehr, sehr, sehr, sehr, sehr viel Arbeit. Aber als Hobby und ohne Zeitdruck ...
Zur Zeit bin ich noch am Unterbau des Ganzen. Ein paar Tests, bzgl. Zeichnen einer Map mit Tiles und Objekten inkl. Bewegung sowie etwas Netzwerkkommunikation, habe ich schon erfolgreich "absolviert". Und zur Zeit versuche ich das ganze so zu strukturieren, dass dabei ein System rauskommt, das mir gefällt ^^ (wobei "gefällt" definitionsabhängig ist... )

Xin hat geschrieben:Vielleicht orientierst Du Deine Planung ein wenig an meiner Softwaretechnik für den Hausgebrauch Sie hilft in jedem Fall Punkte zu finden, auf die man achten sollte.

Ich schau es mir mal an Danke für den Tipp.

Glocke hat geschrieben:Ach jetzt hab ich gerafft was du meinst xD Du gehst davon aus, dass die View jeden Zyklus neu erfragt wo alles ist, und alte Daten quasi "vergisst" nachdem es alles gemalt hat, richtig?
Unabhängig von der Netzwerklast glaube ich, dass - wenn sich die View die Objekte merkt und alle bewegten Objekte aktualisiert werden - das den Datenaustausch zwischen Model und View wesentlich verkleinert.... imho ^^

Sie muss ja nicht alles vergessen. Es reicht ja auch nur relevante Daten vermittelt werden, zum Beispiel die Positionen der Objekte.

Wichtig ist, dass bei der Abfrage Daten nicht nachgearbeitet werden müssen oder sich das Spielfeld im Viewer auflöst, wenn Daten verloren gehen. Im schlimmsten Fall stockt es kurz, dann geht es aber mit dem nächsten Bild korrekt weiter. Das eine muss auffallen und nachgearbeitet werden, das andere kannst Du per UDP verschicken und wenn's nicht ankommt, dann kommt vielleicht das nächste an...

Glocke hat geschrieben:

Xin hat geschrieben:Ich bin nicht im Planungskomitee Deiner Software, ich weiß nichtmals, was Du für ein Spiel planst. ^^
Eine qualifizierte Aussage ist entsprechend ... "Keine Ahnung" ^^

Ein Rollenspiel mit isometrischer Darstellung und Mehrspielerfunktionalität. Das ist sehr, sehr, sehr, sehr, sehr viel Arbeit. Aber als Hobby und ohne Zeitdruck ...
Zur Zeit bin ich noch am Unterbau des Ganzen. Ein paar Tests, bzgl. Zeichnen einer Map mit Tiles und Objekten inkl. Bewegung sowie etwas Netzwerkkommunikation, habe ich schon erfolgreich "absolviert". Und zur Zeit versuche ich das ganze so zu strukturieren, dass dabei ein System rauskommt, das mir gefällt ^^ (wobei "gefällt" definitionsabhängig ist... )

Joah. Das ist ungefähr so aussagekräftig wie "ich schreib ein Spiel".

Es macht zum Beispiel einen Unterschied, ob bei Dir einzelne Panzer unterwegs sind und ein paar Dutzend nicht im Spielfeld oder Armeen mit hunderten Bogenschützen auf dem Bildschirm kämpfen und Kavalerie rumrennt etc.
Die Details sind oftmals ausschlaggebend.

Glocke hat geschrieben:

Xin hat geschrieben:Vielleicht orientierst Du Deine Planung ein wenig an meiner Softwaretechnik für den Hausgebrauch Sie hilft in jedem Fall Punkte zu finden, auf die man achten sollte.

Ich schau es mir mal an Danke für den Tipp.

Dafür wurde es geschrieben. ^^