spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

- Setz dir ein realistiches Ziel. In meinem Fall war das bis Ende des Jahres einen eigenen Model- und Landschaftseditor zu erschaffen, mit dem man später die Spiele-Welt erschaffen kann. Beim Scrum würde man das nun die Vision nennen ;-), aber halt wirklich ein Satz.
- PowerPoint, PowerPoint, PowerPoint und nochmal PowerPoint. Ich weiß gar nicht wie viele Folien ich vor der ersten Code-Zeile vom aktuellen Projekt erstellt habe, aber es waren eine Menge und nach einem Spaziergang mit dem Hund wurde dann immer wieder geschoben und die Abläufe, Strukturen etc. pp. neu verschoben, bis ich nach 2 Monaten dann endlich sagen konnte "Ok, so kanns funktionieren."
Selbst verständlich tut es das dann nicht, da einem im Laufe der Entwicklung und um so tiefer man in das Thema hinein kommt, die Dinge bewusster werden und einem plötzlich dann doch Fälle/Situationen einfallen, wo das Konzept nochmal angepasst werden muss.
- bzgl. der Sequenzdiagramme:
Ich denke man sollte sich schon einen groben Überblick verschaffen, wie gewisse Abläufe zusammenspielen, vor allen Dingen auch wie die Thread-Kommunikation zusammenspielt und man auch 8- und 16-Core-Systeme, mit denen man bei Projekten, die heute starten, durchaus rechnen muss, auch sinnvoll nutzen kann, hier eine Gedankestütze, die ich damals mal gebaut hatte:
http://docs.google.com/present/view?id=dg6jwrfq_8d5xqp2fx
Allerdings sollte man denke ich nicht bis auf Funktionslevel herunter gehen, da das eh fiktiv wäre, sondern eher auf Task-Basis arbeiten, schauen wie die Tasks zusammenhängen, sprich welche Abhängigkeiten bzw. ggf. Konflikte diese aufweisen können, wo man sie parallelisieren kann, welche Kettenreaktionen bestimmte möglicherweise erzeugen könnten und so weiter und sofort.
Für sich selbst auf Funktionsebene zu planen wäre fiktiv, das kann man dann eher im Nachhinein auf der Basis wohl dokumentieren, wenn sich etwas in der Praxis etabliert hat und anderes das verlangen.
- Dateistruktur: Wenn du damit den Quelltext meinst, versuche ich so gut zu "komponentisieren" wie es nur irgendwie geht. Aphereon braucht jetzt auf einem 3 GHz QuadCore schon Minuten für einen kompletten Recompile, trotz flacher Hierarchien. Man sollte es der Übersicht halber natürlich nicht übertreiben, aber wie gesagt schon darauf achten bei bestimmten Projekt-Teilen die nicht soooo eng miteinander verdrahtet sein müssen, dass diese sich dynamisch verbinden können, sprich keine DLL-Abhängigkeit geben ist, so dass sie entsprechend auch parallel compiliert werden können.
- Tools: Visual Studio 2005 + Visual Assist X, X-Code (Mac OS X/iPhone), Eclipse (Linux/Android), Total Commander, SubVersion, PowerPoint, Google Docs, Adobe Photoshop
- bzw. Testen/Entwicklung: Klar, schrittweise drauf hinarbeiten. War am Anfang extrem monoton erst einmal 4 Monate quasi nur Dinge wie Speichermanagement, die ganzen Multithreading-, String, Array, Table, Variant bla bla bla ... Klassen etc. pp. ausarbeiten zu müssen, bevor man dann überhaupt mal eine optische Belohnung auf den Bildschirm bekommt, aber wenn man es anders herum angeht... und es ist z. Bsp. überhaupt kein Problem einen simplen Landschaftsengine in 2 Wochen zusammen zu schustern, um was "tolles" zu sehen, dann ist es eigentlich nur eine Frage der Zeit, bis man die Quittung dafür bekommt und die Zeit eigentlich verbrannt ist. Von daher lieber Baustelle für Baustelle drumrumarbeiten, in seperaten Test-Gebieten rumexperimentieren und dann schrittweise voran arbeiten.
- Grafiken & Co.: Verschieden. Grafiken & Co. mache ich meistens dann, wenn mir beim Programmieren gerade nichts mehr einfällt oder mich der Dummy nach einer gewissen Zeit so stört, dass der Hammer her muss :-).
- Klassen: Kann man so in 2 Minuten nicht beantworten.

LG
Alyx

Ich sitz grad an was kleinem im Stil von Jump and Run, nur dass das ziemlich groß geworden ist, weil man den Aufwand am Anfang unterschätzt.
Die Dokumentation (damit meine ich alles, von der Idee über Konzepte bis zum Readme) mach ich mit OpenOffice Write und Notepad++ für TXT-Dateien.
Mein Anwendungsdesign mach ich mit UML. Ich finde das sehr praktisch wenn mann seine Applikations über Zustandsdiagramme modelliert, die Zustände dann mit Sequenz- und Klassendiagrammen modelliert und so eine relativ gute "Anleitung" zum Implementieren hat. Viele Initialgedanken erfasse ich aber immer noch ganz rückständig mit Papier und Stift.
Tools: Kann man auf meiner Webseite sehen. Als Repository verwende ich SVN. Zusätzlich versuche ich mir eine Tool-Chain für den Content aufzubauen, teils mit fertigen Tools (z.B. Blender) teils mit Editoren, die ich noch anpassen muss.
Zum Lernen/Testen von Techniken hab ich ein zweites Projekt, das ich als Spielwiese verwende. Erst mal wird dort alles ausprobiert und wenns dann tut, portiere ich es in meine Spiel-Bibliothek. Das geht dann mit relativ geringem Aufwand.

Thoran

- Konzepierung ... Achtung es folgt eine kleine ausschweifende Lebensgeschichte :lol:
Früher hab ich bzw. wir (Golden Vertices, 2-Mann-Team) noch sehr viel aus dem Kopf heraus geplant und uns nur ein paar Notizen dazu gemacht. Natürlich reicht das auf Dauer nicht und man arbeitet mehr und mehr Dokumente aus, in denen der Rahmen und wichtige Entscheidungen (vorallem zu Fragen die untereinander nicht sofort klar waren) festgelegt sind. Mit jedem Projekt wurde der Planungsteil größer, weil wir schnell gemerkt haben dass sich das einfach enorm auszahl und Missverständnisse vermeidet.
Beim Programmieren hab ich schon früh immer wieder Kritzeleien für wichtige Grundkonzepte gemacht. Korrektes UML behersche ich leider (noch) nicht - außerdem war ich bisher immer der einzige Programmierer bei mir. Diese Zeichnungen heb ich mir länger auf um meine Gedankengänge vom letzten mal besser vor Augen zu haben und um in einem Detailproblem den "großen Plan" nicht unnötig zu gefährden. Zudem liegt immer gern eine TODO-Liste vor dem PC .
Bei dem letzten Golden Vertices Projekt Xrodon hatten wir in der Dropbox Dokumente mit Story, Dialogen, Attribut/Objekt-Eigenschaften, Bug-Lists, Todo-List, Anleitung. Die Vorgehensweise hat sich sehr bewährt, aber im Lauf der Zeit hat sich gezeigt, dass mehr vorausplanen bei den wirklich wichtigen Punkten sicher nicht geschadet hat (ich denke man muss je nach Team-Größe und Ziel nicht alles von Anfang an akkurat planen, aber man sollte einen Überblick haben und alles auf Machbarkeit geprüft haben und wichtige Streitpunkte bereits besprochen und niedergeschrieben haben -- wichtige Punkte wollen gefunden sein)
Bei meinem aktuellen Projekt CuBrush (erstmals wieder alleine) bin ich bereits dazu übergegangen vor Beginn eine Art Designdokument auszuarbeiten. Mittlerweile hab ich allerdings schon wieder kleine Änderungen vorgenommen, die darin nicht mehr erwähnt werden. Prinzipiel hab ich mich allerdings daran gehalten. Da ich allein arbeite kann ich es mir durchaus leisten viel aus dem Kopf heraus zu machen. Aber das muss jeder für sich selbst entscheiden. Was mir enorm geholfen hat ist, dass ich dieses mal den Code selbst mehr geplant hab als bisher - nicht im Detail, aber das Grobkonzept welche Klassen das Spiel ausmacht und wie diese untereinander kommunizieren hab ich mir von anfang an überlegt. Davon bin ich zwar in Details abgewichen, aber so konnte ich auf bisherigen Erfahrungen aufbauend eine Lösung erarbeiten die sich soweit sehr bewährt hat.
Mittlerweile führe ich einen Changelog für Cubrush - das hab ich bisher nie gemacht - und ich kann dir sagen sowas ist echt Klasse! Ich kann jedem empfehlen auch wenn man allein arbeitet möglichst früh (von Anfang an gestaltet sich etwas schwer) sich alles genau zu notieren was man gemacht hat. Das motiviert und verschafft Überblick über das was sich wirklich getan hat.

- Dateiformat
Auch wenn ich noch nicht solche Erfahrungen gemacht hab wie Alyx kann ich ihm da sehr zustimmen. Kompilierzeiten sind nervig und Scriptartige Dateien bringen viele Vorteile. Bisher hab ich fast nur mit binären Daten-Formaten und textbasierten "Anweisungslisten" gearbeitet (auch mal gern ini). Aber neuerdings nutze ich XML und das ist durchaus sehr angenehm für verschiedenste Zwecke. Über Sinn und Unsinn je nach Fall kann man da sicher sehr lang streiten.

- Tools:
Visual C++ Express 2010 und bei Bedarf Blender, Gimp, Audacity. Achja "CppCheck" hab ich neuerdings entdeckt, das ist ganz fein manchmal

- Testen/Entwicklung:
Ich versuch möglichst Durststrecken in dennen man nichts testen kann zu vermeiden. Testen schafft Sicherheit und motiviert. Klar ists manchmal Designtechnisch nicht möglich und auch dumm sich eine Vorrichtung zum testen hinzudrücken - dann versuch ich die folgenden Schritte umso besser zu planen.

- Grafiken und Modelle
Das arbeiten mit Platzhaltern war in Golden Vertices Zeit an der Tagesordnung, da nicht immer die richtigen Sachen zur richtigen Zeit fertig wurden. Außerdem ists für Benutzeroberfläche für meinen Kumpel auch viel leichter gewesen den Dummie dann zu überarbeiten als es für mich gewesen wäre seine Grafiken einzupassen. Da spielt natürlich Absprache eine große Rolle. Prinzipiel ist mir natürlich lieber, wenn man gleich richtige Sachen einsetzt. Aber oft muss man sich eben erst auf die Funktionalität konzentrieren bevor man sich mit der Optik beschäftigen kann. Ist aber durchaus Fall abhängig.

- Klassen
Hm ja das ergibt sich aus der Planung. Ist natürlich auch oft geschmackssache. Zuviele Klassen blähen auf und können unter Umständen Performance einschränken. Zu wenige machen unübersichtlich und fehleranfällig. Bei deinem Bespiel Shooter Gegnertypen würd ich schaun, ob ich nicht die Gegnertypen zusammenfassen kann und dann ggf. eine gemeinsame Parentklasse oder gar eine einzige Klasse mit einem Typspezifier machen.

Zu "Wie macht ihr das wenn ihr eine Physikengine einbaut?" will mir nicht recht was einfallen. Hab aber auch noch nie eine Physikengine eingebaut xD


So das war jetzt wohl soviel Text das es eh keiner mehr liest.
Würde mich freuen wenn noch mehr davon schreiben. Einige Dinge würden mich bei anderen auch durchaus interessieren.

Zitat

So das war jetzt wohl soviel Text das es eh keiner mehr liest.

Hehe der Konzipierungspart war mir echt zu lang.

Zitat

- Grafiken und Modelle
Das arbeiten mit Platzhaltern war in Golden Vertices Zeit an der Tagesordnung, da nicht immer die richtigen Sachen zur richtigen Zeit fertig wurden. Außerdem ists für Benutzeroberfläche für meinen Kumpel auch viel leichter gewesen den Dummie dann zu überarbeiten als es für mich gewesen wäre seine Grafiken einzupassen. Da spielt natürlich Absprache eine große Rolle. Prinzipiel ist mir natürlich lieber, wenn man gleich richtige Sachen einsetzt. Aber oft muss man sich eben erst auf die Funktionalität konzentrieren bevor man sich mit der Optik beschäftigen kann. Ist aber durchaus Fall abhängig.

Oh ja das kenne ich, mir geht das aber ordentlich auf den Zeiger. Vor allem wenn Grafiker vorhanden sind, aber monatelang nichts kommt und selbst wenn man dann neue sucht, kommt immer noch nichts. Das ist wirklich frustierend.

Meine Projekte laufen so ab:

Konzipierung: Ich schreibe ein extrem ausführliches Design Dokument, welches ich in mehrere Teile gliedere, wie z.B. Grundlegende Informationen, 2D Grafiken, 3D Grafiken, Spielinhalte/Features, Programmierung, usw. Diese Teile werden dann nochmal in mehrere Unterkategorien unterteilt. Bei Programmierung kommen z.B. alle programmiertechnischen Details rein, wie Klassen, Funktionen, Algorithmen, usw. Erst wenn ich der Meinung bin, dass wirklich alles bis ins kleinste Detail durchgeplant ist, beginne ich mit der eigentlichen Arbeit.

Tools: Visual Studio 2010, Code::Blocks, Intel C++ Compiler für Geschwindigkeitsoptimierungen, Visual Assist X,
Visual Leak Detector, (Gimp, Blender, aber meist nur um Platzhalter zu erstellen, da ich kein sonderlich guter Grafiker bin), Reason, Audacity

Testen/Entwicklung: Strikt nach Design Dokument, es sei denn ich habe eine neue gute Idee, dann passe ich erst das Design Dokument an und arbeite dann danach. Alles was ich code, wird sofort getestet, selbst die Fehlerabfragen manchmal. Trotzdem lassen sich einige logische Fehler nicht vermeiden und deshalb wird bei Projektende alles nochmal akribisch getestet, bevor es veröffentlicht oder beim Kunden abgegeben wird.

Klassen: Alles was sich zusammenfassen lässt, bekommt ein Interface. Ich code komplett Objektorientiert, es sei denn es gibt keine andere Möglichkeit oder es ist völlig sinnlos. Die Klassen versuche ich durchschnittlich groß zu halten, wenn es nicht anders geht, wird eine Klasse auch mal länger, wie z.B. eine Device Klasse einer Engine. Wenn ich mehrere kleine Klassen habe (Beispiel: Vertex) und diese zueinander passen (Beispiel: Face oder Polygon), kommen sie zusammen in ein Modul.

Zitat von »Wümpftlbrümpftl«

So das war jetzt wohl soviel Text das es eh keiner mehr liest.

Doch, sehr wohl, weil es bei dir meistens lohnt ;-).

Bzgl. der Klassen nochmal kurz: Wie Wümpftl schon schrieb ist es sehr wichtig hier sinnvolle Strukturen zu bauen. So ist es zum Beispiel sehr sinnvoll für alle Objekte, bei denen es auf 1 Byte mehr oder weniger nicht ankommt, bestimmt Funktionen zu garantieren... wie einen virtuellen Destruktor oder Funktionen wie DerivedOf, GetClassName oder z. Bsp. bei vielen meiner Klassen ein Assign und LoadFromStream bzw. SaveToStream, um dann so etwas zu ermöglichen:




Dein Beispiel mit den Gegner ist ein etwas unpraktisches, da dies in einem 3D-Spiel z. Bsp. gleich 2 verschiedene Klassen wären und im Fall eines Online-Spiels z. Bsp. folgende Verwandschaft haben könnten:

AObject -> ADBObject -> ADBPlayer
AObject -> AWorldObject -> APhysicalObject -> APlayer

Wobei Player dann als zusätzliches Flag hätte, was für ein Typ Player es ist, in dem Beispiel dann ein feindlicher.

LG
Alyx

- Konzepierung
Nun da ich fast bisher nur aleine gearbeitet habe hatte ich bisher nur eine ToDo Liste und ein Changelog Den Rest hab ich aus dem Kopf gemacht. Bei dem neusten Projekt wo ich tätig bin haben wir eigendlich das Konzept in einem Forum (Story, Spielziel, ausgearbeitet eine Roadmap erstellt und führen eine ToDo Liste (kann durchaus sein das mein Projektleiter noch mehr hat )

- Dateiformat
Da kann ich meinen Vorrednern nur zu stimmen Wird das Projekt erst mal größer sind Kompilierzeiten wirklich sehr nervig, Scripte oder Scriptartige Files sind somit ein Segen . Sonst verwende ich einfache INI Files oder das NBT (sowas wie ein Binäres XML) Datei Format.

- Tools:
Ich selber verwende Visual C++/C# Express 2010, Gimp, Google Sketchup 7 und Mercurial für die Klassische Spiele Entwicklung

- Testen/Entwicklung:
Ich bin eigendlich richtig Test süchtig Ich bau irgend ein kleines neues Detail ein und muss es sofort Testen. Damit vergewissere ich mich das 100%tig so Funktioniert und ich mich an das nächste Stück machen kann.

- Grafiken und Modelle
Ich verwende eigendlich immer kleine Dummy Modelle die ich in Sketchup erstellt habe bis ich die richtigen hab weil sonst würd ich nur schleppend vorran kommen

- Klassen
Ich versuche eigendlich immer fast alles als Klasse zu machen was ein System ist und was ein Objekt in Spiel wieder gibt. Deshalb verwende ich auch Singleton Klassen

- "Wie macht ihr das wenn ihr eine Physikengine einbaut?"
Ich intigriere oft Objekt Klasse und Physik in einem da die Physik aleine schon aus Kollisions Gründen immer im Spiel sein sollte. Geupdatet wird dann immer beim Draw Vorgang. Ob das die beste Lösung is weiß ich net aber sie hat mal bis jetzt Funktioniert

- Konzept
Also da denke ich eigentlich zu vielen Zeiten drüber nach, schriftlich oder in Dateien halte ich aber im Grunde nichts fest.
Das brauche ich eigentlich nur wenn ich 'ne wirklich komplexe stelle hab und ohne nicht weiterkomme. Dann notiere ich mir den aktuellen Ablauf. Ansonnsten hab ich mir am Anfang ein Ziel gesetzt und versuche das zu erreichen.

- Dateiformat
Dazu muss ich sagen, verwende ich eigentlich immer was neues. D.h. ich denke mir was aus und geb' der Sache auch direkt 'nen Namen. Der ist dann meist aus dem Spielnamen und der Dateifunktion zusammengesetzt. Mein aktuelle Projekt (Running 3D) hat so zb. .r3d-Files für die Recorde je map

- Klassen und "Wie macht ihr das wenn ihr eine Physikengine einbaut?"
mache ich im grunde so wie Jeason, wobei ich zb für die Kollision eine extra Klasse gebaut hab die nur dafür zusändig ist.

Zitat von »Philip Rosenthal«

Wer zu spät an die Kosten denkt, ruiniert sein Unternehmen. Wer immer zu früh an die Kosten denkt, tötet die Kreativität

Ich finde den Satz kann man so in etwa auch gut auf Projekte übertragen.
Man kann vor der erste Zeile Quellcode natürlich das komplette Spiel bis hin ins Detail planen, so dass man nur noch von den Diagrammen den Code abtippen muss und beim erstellen einer Grafiken eine 2 A4 Seiten Planung neben dran hält. Aber das nagt bei vielen einfach zu sehr an der Motivation, weil man halt so viel geplant hat aber noch nichts produktives sieht. Umgekehrt kann es aber auch sein dass man einfach mal anfängt und einem später klar wird, dass das so gar nicht geht. Das kann dann schon mal unweigerlich zum Neuanfang des Projektes führen, was ja auch nicht so toll ist.

Wenn du das Ziel deines Projektes vor Augen hast, und Bescheid weisst was du alles brauchst um dort hin zu kommen, kannst du dich ruhig schon einmal daran setzen und anfangen. Wenn dir einmal nicht klar ist wie es weiter geht, dann machst du ganz einfach eine kleine Planungs Session.

Ich denke dass es sicher wichtig ist, mit welcher Technologie (Sprache, Engine) man das Projekt umsetzen möchte bevor man anfängt. Nicht alles muss in C++ geschrieben werden, für Interface lastigere Spiele könnte ja zum Beispiel auch C# hinhalten. Du solltest dir auch überlegen ob das Spiel Plattformunabhängig laufen sollte. Eine unkomplizierte Variante dafür wäre es zum Beispiel eine Flash oder Silverlight Anwendung zu machen, was den Vorteil mit sich bringt dass man es im Webbrowser spielen kann. Das hängt aber auch davon ab wie viel Leistung das Spiel benötigt.

Jedes "grössere" Projekt bedeutet mehr Aufwand als dass man es sich erwartet, es führt auch kein Weg daran vorbei. Also wenn du das Projekt umsetzen willst, dann mach's einfach!

Befolgung dieses Rats auf eigene Gefahr, da ich noch nie ein richtiges Projekt umsetzen konnte