spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Wo liegt denn dieses volle Game Design Document? Ich habe im Wiki zwar ein paar Sachen gefunden, aber ganz ehrlich, dabei wüsste ich als Entwickler *nicht*, was ich umzusetzen hätte. Was ich bisher gefunden habe war nur eine schwächliche Liste von Gebäuden. Vielleicht kannst Du mir ja aber die richtige URL geben?
Ich wäre mit "ist nicht so schwer" auch ganz vorsichtig, denn so ein Dokument überfordert einen sehr schnell, speziell wenn man neu ist und es wirklich gut und detailliert sein soll. Deshalb habe ich da so meine gewissen Zweifel.
Außerdem sind das nicht die Details, die ich angesprochen hatte. Es geht um die Details der Implementierung. Je feiner nämlich das Spiel wird, desto mehr ist zu tun und das sind dann die Momente, wo Unity Euch dann rein gar nicht mehr hilft, sondern wo es wirklich nur um jede Menge Code geht.

Ein kleines Beispiel:
Eine Holzhütte, die aus Wald Holz herstellt, klingt nach einem simplen Prinzip. Nun soll da aber sicher nicht einfach alle paar Sekunden/Minuten ein Baum aus der Umgebung verschwinden und ein Holzbalken davor auftauchen (denn das wäre ja nicht besser als Anno, sondern deutlich schlechter), da gehört ja auch etwas Liebe dazu. Also muss da ein Holzfäller herum laufen. Er muss zu den richtigen Bäumen gehen (und bitte nicht wie ein Geist auf dem Weg dahin durch irgendwelche Bäume/Stämme/Hütten hindurch). Er muss den Baum umhacken. Er muss die Äste abhacken, er muss den Stamm klein hacken, er muss das Zeug in seine Hütte tragen, es dort mit Werkzeug bearbeiten und es dann vor die Hütte legen, bis jemand kommt und es abholt. Er darf nicht gehen, wenn keine Bäume mehr da sind. Er darf nicht losgehen, wenn sein Lager voll ist oder er kein Werkzeug hat. Die Bäume müssen natürlich auch immer kleiner gehackt aussehen und irgendwann als Äste rumliegen und verschwinden. Danach müssen sie nachwachsen oder spontan irgendwo wachsen.
All das bedarf natürlich passender Logik und vor allem Animationen der Bäume beim Wachsen und Umfallen, beim Zerhacken, beim Bearbeiten und Abholen. Natürlich mit passenden Sounds zu jeder Phase. Das war jetzt nur eine einzige Hütte. Jetzt stelle man sich vor in der Umgebung gäbe es drei. Dann müssen die Holzfäller auch noch so arbeiten, dass nicht plötzlich zwei denselben Baum umhacken, etc, etc. DAS sind Details. Und das dauert SEHR LANGE, bis das erledigt ist. Unity macht davon dann so gut wie gar nichts, denn das Erstellen der Animation und der Logik, das ist rein Euer Bier.

Ich behaupte, dass dieses ganze Pathfinding schon allein für den Holzfäller, die Schiffe oder die Transportkarren schon so komplex ist, dass ihr daran Wochen verbringen werdet, bis es alles richtig zusammenspielt. Speziell da die Transportkarren ja auch nach Prioritäten gescheduled werden sollten.

Zitat von »BlueCobold«

Am Anfang geht jedes Spiel unglaublich schnell. Der Teufel liegt in den Details. Gerade bei so einem Spiel wie ihr da vor habt, ist da einiges an Logik und tausende Kleinigkeiten versteckt, die man alle implementieren muss. Da hilft dann auch Unity nicht mehr.

Und wenn man sich um die ganzen Kleinigkeiten gekuemmert hat kommen noch ein paar tausende Bugfixes obendrauf die den Aufwand gut nochmal verdoppeln koennen.

Zitat von »BLOODWORK129«

[...]nun wirklich nicht allzu schwer.

Je erfahrener ein Entwickler ist, umso seltener wirst du diese Worte von ihm hoeren.

Die rund 60 Leute bei Related Designs haben nicht ein paar Jahre lang rumgesessen und daeumchen gedreht weil das doch alles so einfach und fix zu erledigen war.

Das war allerdings nicht ganz das, was ich unter der initialen Vorstellung des Projekts vor Augen hatte.

Klar. Aber es ist nicht nur wichtig auf die Wünsche zu hören, sondern auch manche davon umzusetzen Im Gegensatz sollte man sogar nicht alle Wünsche umsetzen, weil die Wünsche von Usern meist widersprüchlich sind oder das Balancing negativ beeinflussen können. Verschiedene Spieler haben eben verschiedene Ansprüche.
Ich z.B. bin ein sehr visueller Mensch und wenn jemand etwas (paraphrasiert) sagt wie: "Wie Anno, nur besser", dann stelle ich mir natürlich vor, wie die doch sehr gelungene Grafik oder Gameplay wohl verbessert werden, ohne dass andere Dinge gegenüber den Details des Originals vernachlässigt oder gar entfernt werden. Wenn ihr also eine visuell abgespeckte Variante bauen wollt, ist das durchaus legitim. Ich denke nur, dass Ihr das auch gleich klar machen solltet. Dadurch wirkt Ihr dann nämlich deutlich realistischer und ehrlicher, sowohl zu den Interessenten, als auch zu Euch selbst und den Leuten, die Ihr hofft anzuwerben und für Euer Projekt zu gewinnen. Selbstüberschätzung ist eine sehr gefährliche Sache (viele von uns werden das eine oder andere Projekt eben deswegen schon zu Grabe getragen haben) und wird von erfahrenen Leuten schnell gewittert oder vermutet, was Euch sicherlich die Suche nur erschweren kann.

Ich erzähle dir jetzt mal eine kleine Geschichte von mir, und dann kannst du dir überlegen, ob du wirklich noch Leute suchst. Übrigens finde ich es gut, dass du mit Kritik umgehen kannst und nicht beleidigt verschwindest, das ist schon ein sehr guter Anfang.

Vor ungefähr 10 Jahren oder so wollte ich ein 2D Rollenspiel entwickeln. Isometrische Grafik, mit rumlaufen und Gegner anklicken und all das. Von der Programmierseite aus lief alles recht ordentlich, aber ich brauchte Grafiken. Alles bisher hatte ich mit Paint gepixelt, aber bei isometrischen Figuren hörte es wirklich auf.
Also habe ich in diversen Foren nach Grafikern gesucht. Und weil jeder gerne Rollenspiele entwickelt, habe ich auch einige gefunden. Insgesamt haben an dem Projekt glaube ich 7 Grafiker mitgearbeitet. Wir hatten dann auch schön ein eigenes Forum, in dem wir diskutiert haben, ich habe die Grafiken von den Grafikern bekommen und regelmäßig in neue Versionen gepackt und die dann an alle verteilt, so weit, so gut.
Das Problem war der enorme Verwaltungsaufwand. Mit 7 Leuten über Internet ein Spiel planen ist echt nicht einfach, man chattet und schreibt unglaublich viel und muss sich mit zig Leuten absprechen. Und dann gehen viele eben so schnell, wie sie gekommen sind. Einer hat nur einen einzigen Gegner mit 2 Animationen gemacht und sich dann nie wieder gemeldet. Und dann fangen die an, eigene Ideen einzubringen, einer wollte unbedingt seinen Roboter, den er gerade modellierte, in unser Fantasy-RPG einbauen. Letztendlich wurde also schrecklich viel diskutiert, aber herausgekommen ist relativ wenig. Ganz zu schweigen davon, dass jeder natürlich seinen eigenen Grafikstil hatte, was man teilweise wirklich gemerkt hat.

Heute habe ich genau einen Kollegen. Und ich empfinde diese Größe als nahezu ideal. Ein Programmierer, ein Grafiker, jeder kümmert sich um seinen Teil und niemand pfuscht dem anderen irgendwie ins Handwerk. Ich habe nur noch einen, mit dem ich Ideen absprechen muss und wir können uns eigentlich immer schnell einigen, und wirklich eine Menge machen.

Du musst die Sache so sehen: Hast du mehr Teammitglieder steigt die Arbeitsleistung im Idealfall linear, aber der Kommunikations- und Entscheidungsaufwand quadratisch (wenn jeder mit jedem streitet). Offensichtlich sind wenige, aber gute Leute also sehr viel besser, als viele Anfänger bzw. nicht so begabte. Die einzige Lösung ist, wenn von oben einfach nur Befehle kommen und alle Teammitglieder diese abarbeiten müssen und selber nichts zu sagen haben. Aber damit sich jemand auf so etwas einlässt, muss das Projekt schon eine ganze Menge zu bieten haben. Und das hat beinahe kein Hobbyprojekt.

Solange du also alleine nichts schaffst, wirst du auch im Team nichts erreichen. Erst wenn ein kleines Team richtig gut läuft, kann man sich Gedanken über mehr Mitglieder machen, IMHO.