Doku?

Morgen. Gibt es eigentlich eine "gute" (bzw umfangreiche) Dokumentation über den Prozess zur Herstellung von Spielen aus softwaretechnischer Sicht? Ein Video, einen umfangreichen Blog, so irgendwas. Die Industrie selbst macht ja sogut wie immer ein Geheimnis aus ihrer Arbeit - aber irgendwo muss man ja auch mal "über die Schulter schauen können" (ich rede jetzt nicht von einem tollen Making Of. Sondern über etwas informativeres)

rapso

es gibt da nicht wirklich ein 08/15 schema wie es zu machen ist, jeder macht es anders. wenn entwickler mit publishern verhandeln, legen die im vertrag mit fest, wann was wie gemacht wird, weshalb es manchmal streitereien gibt, da dinge nicht aufgenommen wurden in den vertrag bzw anders ausgelegt werden.

ich denke es macht niemand ein geheimnis draus, es ist schlicht du wandelbar und unterschiedlich wie es die einzelen machen, als das es dokumentierbar waere.

falls du konkrete fragen hast, kann vielleicht der ein oder andere hier im forum sie beantworten.

Konkrete Fragen hatte ich eigentlich nicht, ich wollte es eher so "schön kompakt und zusammengefasst" sehen. Aber gut, so schnell überlegt:

1. Ausgehend davon, ein beliebiges Spiel dauert von Beginn bis zur Fertigstellung sagen wir mal 5 Jahre. Sound, Grafik, Leveldesign, etc. ist mal Nebensache; aber wie sieht es mit der Programmierung aus? Sitzen die Programmierer da mal gut 1 - 2 Jahre und programmieren "einfach munter vor sich hin" bis sie das Teil dann vielleicht mal kompilieren können? Der Programmierer, der für beispielsweise die Physik verantwortlich ist, kann ja erst dann seine Arbeit wirklich sehen, wenn die restliche Engine mal im Groben steht; zwar ändert sich die Physik selbst nicht, aber ich stelle es mir schwierig vor, Monate lang zu programmieren ohne je zu sehen, wie sein Werk eigentlich wirklich aussieht.

2. Wie wird hier eigentlich kompiliert? Ausgehend von einem Entwicklerstudio von 30 Mann und 5 Teams; jedes Team schreibt einen bestimmten Teil (Engine, Grafik, ...). Aber wie wird das im Endeffekt kompiliert? Gibt es da einen allmächtigen und übercoolen Computer der nur zum Kompilieren im Studio steht - so richtig mit großem, rotem Knopf und lauten Alarm-Geräuschen wenn der gedrückt wird? Kompiliert sich das jeder selbst wenn er Lust dazu hat? Zweiteres halte ich aufgrund der Existenz von Buildnummern eher unwahrscheinlich.

3. Nochmal zu den Teams: ich schätze mal, die meisten Spiele werden nach Scrum-Prinzip entworfen, oder? Wenn ja, wie können die Teams untereinander ihre Schnittstellen definieren, ohne das etwas dabei schief geht?

4. Viele Spiele werden ja mit eigenen Editoren (etwas im Stile der CryEngine) entworfen. Das heißt: die Programmieren verbringen zuerst den Großteil ihrer Arbeit an der Arbeit an diesen Editoren?
Und: wie genau eigentlich kommen solche Editoren zu ihren Ergebnissen? Wie wird das Resultat gespeichert, wie wird es wieder ausgegeben? Das exportierte Spiel ist eine fertige .exe-Datei mit hübscher Welt und allen Funktionen; wie aber funktioniert das? Ich denke mal nicht, dass der Editor heimlich ein Compiler ist und Maschinencode ausspuckt - eher dass sämtliche Dinge (Position, Eigenschaften,... der gesamten Welt und Objekte) irgendwie gespeichert werden und die .exe nur noch eine Art "Umgebung zur Verarbeitung" darstellt? (ähnlich wie ein C#-Quellcode und das .NET-Framework) Und dennoch bleibt: wie aber wird dann gespeichert? Das ist doch eine riesige Menge an Daten?

Mehr fällt mir spontan nicht ein.

Xebov

Ein Spiel ist Grundlegend erstmal nichts anderes als jede andere Software auch. Die Vorstellung das da viele Programmierer im stillen Kämmerlein vor sich hinprogrammieren ist falsch. Bei solchen großen Projekten würde man damit auch nicht sehr weit kommen.

Wie rapso schon gesagt hat gibt es bei solchen Projekten kein einheitliches Vorgehen, jeder macht das ganze anders. Es gab mal von Microsoft zur Entwicklung von Windows 7 einen Einblick wie das Projekt dort gehandhabt wurde, leider hab ich den nicht zur Hand. Deren Grundprinzip bestand darin das mehrere Teams gebildet wurden, jedes Team hat nach außen Schnittstellen festgelegt die andere Teams nutzen konnten, die interne Umsetzung hat das Team dann unter sich ausgemacht, dafür gibt es dann natürlich Arbeitsrichtlinien und detalierte Aufträge.

Für den Code werden Versionskontrollsysteme eingesetzt. Diese Software kann mehrere Versionen der selben Datei in Zweigen verwalten, auserdem können sie zB Dateien mergen usw. Jeder hat dort seinen festgelegten Zweig in dem er arbeitet, er zieht sich Updates und schiebt eigenen Code hoch. Dabei compiliert auch jeder mal nur für sich um seinen Code zu testen. So würde das Team das die Physik in deinem Beispiel baut sich zB eigene Testsoftware schreiben die nicht zwingend Grafisch sein muß, man kann recht viel auch in Konsolenprogrammen testen. Von Zeit zu Zeit werden auch alle Stabilen Versionen der Komponenten eingesammelt um komplette Builds durchzuführen die dann als Grundlage für weitere Arbeiten dienen. Das ist aber auch nur eine Möglichkeit es zu tun.

Die Editoren generieren Dateien. Dort sind dann Modelle, Physik, Landschaften, Level usw drin die dann geladen werden. Viele Spiele nutzen dort dann auch Scriptsprachen wie zB LUA für dynamisches. Die exe macht nichts anderes als diese Dateien zu öffnen und zu laden.

Grundsätzlich ist die Entwicklung von Software ein recht weites Feld mit unzähligen Möglichkeiten ein Ziel zu erreichen.

cooky451

Noch mal zu dem Physik-Ding: Da hast du eine falsche Vorstellung. Ein Programm zu basteln dass dir ein paar Models anzeigt um die Physik zu testen, dauert vielleicht 16 Stunden für einen erfahrenen Programmierer, und das wenn er auf API (OpenGL/DirectX) Ebene anfängt. Es ist allgemein nicht so, dass man da ewig programmieren würde ohne etwas testen zu können. Denn auch wenn das gesamte Artwork noch nicht zur Verfügung steht, keine Story existiert etc., kleine Test zusammen frickeln geht immer. Ich denke du hast da auch eine falsche Vorstellung was den Arbeitsaufwand angeht. Der Weg "nix"->"ich kann ein bisschen rumspielen" ist nichts (reiner Planungsteil mal weggelassen) im Gegensatz zu "ich kann ein bisschen rumspielen"->"das Spiel ist fertig".

rapso

1. das wichtigste an einer teamarbeit ist, dass jeder im team arbeiten kann. entsprechend ist es anfangs relativ egal wie, hauptsaeche es laeuft moeglichst viel. zudem ist niemand gezwungen auf etwas zu warten, jeder kann sein teil anfangen zu programmieren, es ist ja nicht so dass ein physik programmierer in seinem studium nie etwas von seiner physic simulation gesehen hat, weil er kein team von artist hatte, er wird schon wissen wie er mit ein paar linien boxen zeichnet und wie er sich einfache .m models laden kann.
zudem ist es sehr sehr seeeehr selten dass man bei 0 anfaengt, irgendwo hat man immer schon genug code um eine basis engine zu erstellen.
schau dir z.b. http://www.ludumdare.com/ an, dort erstellen viele einzelne leute spiele, in 48h. so in etwa ist das am anfang eines projektes.

2. jeder compiliert fuer sich, ist ja nicht die welt, gerade am anfang. spaeter kann man module aufspalten und jeder baut seines, hat dann feste interfaces zu den anderen modulen und kann alle zeitlang eine neue version bekommen und auch selbst verteilen.
die build nummer ist keine die sagt wieviele builds es insgesammt gab, sondern wieviel der naechtliche buildserver erstellt hatte, den nutzt man um taeglich eine neue version vom spiel zu haben fuer leute die nicht selbst compilieren (sprich, alle ausser programmierer).

3. es geht immer etwas schief, darauf beruht scrum doch eigentlich. du kannst nicht wirklich planen, du hast bei scrum taegliche meetings wo jeder sagt 'ich habe daran gearbeitet, dabei ist x y z unerwarteterweise aufgetaucht, hey steve, koenntest du dir das mit mir mal ansehen? und danach schaut man halt wie es passend gemacht wird.

4. editoren werden seltener gemacht, meistens nutzt man schon existierende tools. sie werden meistens parallel zum spiel entwickelt. das spiel bekommt feature fuer feature und wenn man moechte dass es jemand nutzt, muss man dieses feature erstellbar/manipulierbar machen. entweder integriert man das in eines der export plugins fuer andere tools (z.b. 3dsmax), oder baut es in den editor ein.
editoren halten sich halt pro objekt seine eigenschaften im speicher, z.b.

float PositionX;
float PositionY;
float PositionZ;
float RotationX;
float RotationY;
float RotationZ;
float Gewicht;
int Farbe;
int AnzahlVerwandte;
...

wenn man den editor erweitert, fuegt man oft neue eigenschaften ein und/oder funktionalitaet um diese zu manipulieren.

5.(auch wenn du es nicht gefragt hast:P), bedenke, ein spiel kann man aus vielen gruenden nicht planen.
-niemand weiss was 'spass' machen wird. manchmal machen teams version 2 oder 3 von demselben spiel, und waehrend version 1 ein totaller erfolg war, ist 2 und 3 langweilig/schlechter. das was spass macht erfaehrt man erst beim spielen, durch ausprobieren, durch reden mit freunden. es wird also niemand wissen was zu tun ist, sogar wenn er ein spiel 1:1 klauen will (also die idee).
-niemand weiss was es fuer schwierigkeiten geben wird, gerade wenn ein projekt 5jahre dauert. schau dir an was vor 5jahren war, jeder glaubte spiele wie WOW werden bald alle spieler an sich ziehen, es gab keinen riesen markt an mobile games, kaum free2play, kein minecraft. man weiss nicht was in 5jahren sein wird, vielleicht cloud gaming, vielleicht user-created-content, vielleicht crowd gaming oder was man noch nichtmal ahnt, darauf muss ein spiel angepasst werden. du kannst heute nicht ein spiel rausbringen was exklusive fuer psp oder fuer netbooks sind, damit waerst du garantiert pleite. vor 5jahren haette das vielleicht noch eine gute idee sein koennen.
-es sind sehr individuelle menschen dabei, manche machen alles was man sich wuenscht, manche haben ihre sturen koepfe, anderen ist alles egal und sie machen ihren dienst etc. das aendert sich im laufe der zeit auch und es gibt neue leute usw.

du bist quasi am strand und baust deine sandburg, hoffst dass niemand drauftritt, vielleicht macht jemand mit, ihr seit euch einig es wird die coolste sandburg der welt, aber auch wenn es was wird, ihr haettet vorher nicht wissen koennen wie es wird und wenn ihr nochmal eine basteln wuerdet, waere es eine genau so coole, aber ganz anders.