spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »BlueCobold«

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".

Das Stimme zu war nur auf das Test-Driven bezogen. Alles danach war meine Meinung. UML vielleicht unbedingt als das Mittel, aber zumindest, um sich einen überblick zu verschaffen durchaus hilfreich. Pattern sollen ja auch nur ein Hilfsmittel und keine Implementierungsvorgabe sein . Das Spielspezifische kann ein Pattern eh nicht abdecken...

Zitat von »BlueCobold«

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".

Das ist eben der Knackpunkt, damit das funktioniert, braucht man eine gewisse Erfahrung. Damit sieht man dann bei bestimmten Problemstellungen automatisch, dass sich ein Pattern gut anwenden lässt oder eben nicht.

Zitat von »Techie«

Bei dem dem Spiel "Master of Orbs" auch Designprobleme bzw. keine Ahnung wie ich ein 'Design Dokument' erstellen soll.

Dazu gibt es verschiedene Meinungen, was in ein Gamedesign-Dokument gehört. Es kann teilweise schon techniklastig sein, oder nur reine Spielekonzepte beinhalten. Eventuell ist es eine gute Idee, wenn du dein Spiel erstmal grob als Brettspiel gestaltest und damit die Spielemechaniken testest. Evtl. hilft dir das hierweiter. Eine "Vorlage" findet sich bei Gamasutra, wobei du solche Vorlagen immer an deine Bedürfnisse und Wünsche anpassen musst.
Zum Abschluss noch eine ganze Latte von GameDesign Dokumentenvorlagen auf Google.

Als Vergleich nur mal wie lange ich schon an meine Engine sitze. Bis jetzt dürfte ich etwa 3 Jahre an meiner Engine arbeiten und im Gegensatz zu dir setze ich wo ich nur kann auf 3rd-Party Bibliotheken (Renderer, Audio, Input, Szenendateiformat, Scripting, GUI, Partikelsystem, Skysystem, Physik, etc.) und trotzdem ist es ein riesen Berg Arbeit, den ich am Anfang total unterschätzt habe. Dazu kommt noch die Toolchain, die mMn wirklich essentiell (man kann es nicht oft genug und fett genug schreiben) ist, um den Aufwand beim Erstellen der Assets/Inhalte des Spiels gering zu halten. Und gerade bei der Toolchain wird es schwieriger sich auf 3rd-Party-Tools zu verlassen, weil man in diesem Bereich dann doch recht schnell auf Rahmenbedingungen stößt, die durch die eigene Engine vorgegeben sind, durch welche es sinnvoll werden kann, seine Tools selber zu schreiben ( was ich nun zwischenzeitlich mache, was den Szeneneditor angeht).
Wenn man dann schlußendlich dazu kommt ein Spiel (bzw. in meinem Fall einen Editor zuschreiben) welches die Engine verwendet, wird einem ersteinmal klar wo die eigene Engine Fehlentscheidungen im Design aufweist, die das Programmieren eines Spiels nicht möglich oder total unpraktikabel machen. Da gibts dann nur die Möglichkeit "zurück ans Reißbrett" und das Enginedesign ändern. Wohl dem der schon ein Enginedesign hat, welches im nachhinein noch solche Änderungen ohne zu viel Arbeitsaufwand zu lässt.

In diesem Sinne: Denke gut darüber nach wie du deine eigene Engine schreibst, was du wirklich selber machen willst und wo du vielleicht besser auf die bereits existierenden "Räder" anderer zurückgreifst.

Thoran

Zitat von »BlueCobold«

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.

Ich hielt UML früher auch mal für sinnvoll und hab wirklich ernsthaft versucht, es zu verwenden. Aber am Ende des Tages kann ich dazu nur sagen, dass die Erfahrung mich lehrt, dass UML sich für kaum mehr eignet, als Pattern aufzumalen. Und die Idee, Software erstmal in UML zu entwerfen und dann einfach nurmehr aus den Diagrammen den Code zu generieren, halte ich für bestenfalls völlig fehlgeleitet. Wie jemand mal so schön gesagt hat: "UML is drawing pictures of what it would look like, if work had actually been done"...

Jo, UML ist gut geeignet, um Grobübersichten über bestehende Architektur oder Statemachines zu machen. Um damit etwas zu spezifizieren, was mal umgesetzt werden soll, ist es eigentlich wie jeder Wasserfallansatz in der Praxis reichlich untauglich.

Wenn du Probleme damit hast deine Software zu designen, dann solltest du noch lange die Finger von eigenen Engines lassen. Der Link zu make games not engines wurde ja schon gepostet. Lies dir das sehr gut durch und versuch es zu verstehen. Dieser Weg ist sinnvoll.

Gerade für den Anfang würde ich "emergentes Design" empfehlen. Also einfach loslegen, Stück für Stück deine Spielfunktionen einbauen und dabei merken was du noch so brauchst. Bei Spieleentwicklung braucht man es dabei mit dem Unit-Testing wohl nicht so eng sehen. Eine dedizierte generelle Engine solltest Du weglassen.

Zitat von »Techie«

P.S.: TrommlBomml Wie kommst du auf T ?! xD

Keine Ahnung woher die Macke kommt. Wahrscheinlich weil ich es wie ein T am Ende spreche