spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zur Dokumentierung kann/sollte die UML(http://de.wikipedia.org/wiki/Unified_Modeling_Language) als Hilfe genutzt werden.

Ansonsten gibt es Pattern, die viele Probleme bzw. deren Lösung schon einmal beschreiben. Hier kann man sich ganz gute Anregungen holen.

Hab ich die Frage so richtig verstanden/beantwortet?

Lg

Zitat von »Techie«

Bei der GameEngine habe ich keine Ahnung wie ich die Architektur designen/festlegen soll.

Das ist genau der Grund warum idR empfohlen wird ein Spiel, keine Game Engine zu entwickeln. Wenn du ein Spiel entwickelst wirst du schnell sehen wie die Architektur sein muss damit es funktioniert... und vermutlich einige male refactorings durchfuehren bis das Spiel fertig wird.
Aus dem Spiel kannst du dann eine Game Engine extrahieren um weitere Spiele zu bauen.

Refactorings sind denke ich ein gutes Stichwort. Im Laufe der Entwicklung wird sich eine elegantere Struktur heraus kristallisieren und du kannst sie umsetzen. Mit wenig Erfahrung hinsetzen und davon auszugehen, dass man die Architektur vorher einmal plant und dann so durchziehen kann ist utopisch.

Zu dem Thema sind mir ein paar Dinge eingefallen die ich eben in meinem Blog niedergeschrieben habe: http://hetzge.de/index.php/architektur-u…ieleentwicklung . Alzuviel Erfahrung in der Spieleentwicklung habe ich nicht wirklich, trotzdem hoffe ich, dass es dem ein oder anderen hilft.

xardias hats ja schon gesagt, aber der Vollständigkeit halber, hier der obligatorische Link: http://scientificninja.com/blog/write-games-not-engines

@hetzge:
Ich habe den Artikel nur sehr grob durchgelesen und keine Fehlinformationen erkennen können (was aber nichts heißen muss, ich habe ihn ja nicht genau unter die Lupe genommen). Abgesehen von ein paar Fehlern in Sachen Zeichensetzung (häufig fehlen Kommas) ist mir aufgefallen, dass ich sehr viele der beschriebenen dinge auch in meiner Ausbildung hatte.


Engine:
Wichtige Schlagworte wären da "Objektorientierte Entwicklung", worunter dann auch "Objektorientes Design" und "Objektorientierte Analyse" fallen. Letzteres dürfte dich wohl gerade sehr interessieren. Beachte dabei aber bitte immer, dass so ziemlich jede Lektüre dazu auf der Annahme basieren dürfte, dass für ein zu realsierendes Softwaresystem alle Anforderungen bereits vorhanden sind. In der normalen Softwareentwicklung wird man diesen Fall wohl fast nie antreffen und in der Spieleentwicklung noch seltener.

Ich möchte außerdem noch Test-Driven development (Testgetriebene Entwicklung) in den Raum werfen.

Test-driven development finde ich für Spiele sehr hinderlich, weil sich die grafischen Elemente meist nicht so einfach testen lassen.

Ich stimme BlueCobold zu (ich will dich ständig mit "t" schreiben grrr!). Design Pattern und UML sind meiner Meinung nach die besten Hilfsmittel. Der Rest ist eh meistens recht spezifisch. Man muss dann schauen, was in dem Fall am bestern funktioniert.

Zitat von »BlueCobold«

Test-driven development finde ich für Spiele sehr hinderlich, weil sich die grafischen Elemente meist nicht so einfach testen lassen.

Deswegen habe ich es nur in den Raum geworfen und nicht einfach jeden versklavt und zur Benutzung gezwungen.
Aber auch bei normaler Anwendungssoftware hat man i. d. R. Probleme beim automatisierten Test der Oberfläche. Dafür gibt es zwar auch wieder Tools, allerdings stellen diese wieder eine andere Art des Testens dar.
Diesem Problem entgegnet man grundsätzlich damit, indem man die Aktionen, die durch Eingaben an der Benutzeroberfläche ausgelöst werden, von der Oberfläche separiert. Auch wenn man jetzt meinen könnte, dass dies doch Gang und Gebe sein und von jedem so eingesetzt werden sollte, könnte es dennnoch (gerade unerfahrene) Entwickler geben, die sich darüber noch keine großartigen Gedanken gemacht haben.

Einmal ein Beispiel, wo man in einem Spiel TDD gut einsetzen kann:
Ich musste für mein Spiel (schon eine Weile her) einen "VariablenManager" schreiben, der die Spielinternen Variablen (hat nichts mit den C#-Variablen zu tun) verwalten soll. Man muss ihm sagen können, dass er eine neue Variable aufnehmen soll (Eigenschaften: Name, Typ, Standardwert, konstant, automatisch zurücksetzend), man muss Werte abrufen können (teilweise auch ohne den eindeutigen/"vollqualifizierten" Namen zu kennen), man muss Werte setzen können, man muss Werte zurücksetzen können, man muss das automatische zurücksetzen auslösen können und noch ein paar andere kleinere Dinge.
Meine Herangehensweise hatte einige Gemeinsamkeiten mit Unit-Tests: ich hatte ein Konsolenprogramm, welches die neu implementierte Klasse mit einigen Testdaten aufgerufen hat und immer darauf hingewiesen hat, wenn das tatsächliche Verhalten nicht dem erwarteten entsprach. Beispielsweise wenn ein Wert nicht gesetzt werden kann oder wenn ein Wert für eine Konstante gesetzt wurde oder wenn ein Wert nicht zurückgesetzt wurde oder...
Oder allgemeiner formuliert: überall da, wo man eine Klasse vollkommen losgelöst von allen anderen bereits vorhandenen Klassen implementieren kann.

Allerdings sollte man, eben aufgrund des bereits beschriebenen Nachteils, TDD nicht so konsequent einsetzen, wie bei der normalen Anwendungsentwicklung.

Derzeit habe ich damit angefangen, dieses automatisierte Testen in form von Unit-Tests wieder einzubauen, da ich es nach der Fertigstellung verworfen hatte, da die Funktionalität doch fertig implementiert war. Leider nur hatte ich den Code danach auch ein wenig refactort, das hat auch fast immer funktioniert, nur leider hatte das auch schonmal die Funktionstüchtigkeit der Klasse zerstört und ich durfte erstmal debuggen (wobei ich da nicht davon ausgegangen bin, dass es an dieser Klasse liegt).

Zitat von »TrommlBomml«

Ich stimme BlueCobold zu (ich will dich ständig mit "t" schreiben grrr!). Design Pattern und UML sind meiner Meinung nach die besten Hilfsmittel.

Das habe ich nicht gesagt und der Meinung bin ich auch ganz und gar nicht. UML halte ich in der Praxis meist nur für Dokumentation brauchbar und Patterns sind eine schöne Sache, aber man sollte sie nicht verwenden, nur damit man sie verwendet hat. Und denke ich sollte man nicht unbedingt mit der Überlegung: "Welches Pattern würde sich hier eignen" heran gehen, sondern maximal mit: "Hier würde Pattern X sich prima eignen".