spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Mein Eindruck, den ich jetzt von dieser Vorstellung erhalten habe, lässt sich am ehesten zusammenfassen, mit "Ihr habt wahrscheinlich schon viele Strategiespiele gesehen, seid aber keine Spieleentwickler".
Der Grund dafür ist nicht der Umfang, den das Projekt mit sich bringt (wobei ich diesen noch nicht mal richtig einschätzen kann, da fast gar nichts zu den Spielmechaniken geschrieben wurde). Viel eher liegt es daran, dass ihr scheinbar _jeden_ Vorschlag für das Spiel umsetzen wollt. Daraus resultiert zwar auch ein gewisser Aufwand, abhängig von den ganzen Dingen, die zusammenkommen, es könnte aber durchaus passieren, dass das Spiel am Ende keine runde Sache wird, dass der Spieler vom Umfang erschlagen wird oder dass die ganzen Mechaniken sich nicht in ein Gleichgewicht bringen lassen (Balancing).
Ein ganz einfaches Beispiel für entsprechende Widersprüche wäre das Setting. Mittelalter oder futuristisch? Realistisch oder Fantasy?
Daraus resultierend könnten wieder widersprüche in der Mechanik aufkommen, so dass für das Mittelalter vorgeschlagen werden könnte, dass Schwertkämpfer gegen Lanzenträger, Lanzenträger gegen Bogenschützen und Bogenschützen gegen Schwertkämpfer gut sind (oder andersrum), während es für das futuristische Setting 5 Elemente gibt, die in vergleichbarer Beziehung stehen. Auch wenn man mehrere Epochen und ein Aufstieg von der einen zur nächsten einbaut (Empire Earth ist da ein beispiel, wo es von Steinzeit bis futuristisch ging), hat man dann das Problem, dass man das System mit den 3 Elementen und das mit den 5 Elementen irgendwie unter einen Hut bringen muss.
Ein vielleicht sogar noch besseres Beispiel wäre die Steuerung von Einheiten oder das Ressourcenmanagement. Der eine würde eine direkte Steuerung aller Einheiten wollen, während der andere ein System wie in die Siedler besser findet. Der eine würde es wohl einfacher handhaben wollen, sodass abgebaute Ressourcen nur in ein Lager gebracht werden müssen, damit diese dann überall zur Verfügung stehen, ein anderer würde eine realistischere Herangehensweisebevorzugen, wo man alle abgebauten Ressourcen irgendwo unterbringen muss, um sie bei Bedarf von dort auch wieder zu holen.
Nur am Rande: es kann auch zu einem gewissen Mehraufwand kommen, wenn der Code an die neuen Anforderungen angepasst werden muss. (Wir sind in der Steinzeit, also können sich Einheiten nur am Land und im Wasser bewegen. Jetzt kann der Spieler weiter voranschreiten und Luftfahrzeuge bauen und somit auch fliegen. Und nund gibt es U-Boote, also soll auch eine Bewegung unter Wasser möglich sein. Jetzt soll der Spieler in eine seiner Einheiten schlüpfen können. Nun gibt es auf dem Wasser landende Flugzeuge und Hovercrafts. Und nun kann der spieler unterirdische Wege schaffen und mit Landeinheiten diese benutzen. Und jetzt ...)
Und es könnten sich Ideen einfinden, die euch vielleicht scheinbar vom Genre des Strategiespiels abbringen, die aber auch für das gewisse Etwas sorgen könnten. Einfache Beispiele wären, dass man in die Haut einer Einheit schlüpfen kann (siehe "Dungeon Keeper", in diesem Spiel sinnvoll, um feindliche Fallen auszuläsen, die Umgebung zu erkunden oder um im 2. Teil Minispiele spielen zu können) bzw. permanent eine Einheit kontrollieren muss (siehe "The I of the Dragon", auch wenn der Ausbau der Dörfer dort eher am Rande stattfand).
Ich bezweifle zwar, dass euer Spiel so gut wird, wie es hier beschrieben wird, aber ihr dürft mich gerne vom Gegenteil überzeugen.

Heißt, dass die 55 Seiten mit detailierter Beschreibung in Schriftform verfasst wurden? Ich hoffe nicht, dass das so ist und bspw. ausreichend Grafiken und Auflistungen/Stichpunktlisten verwendet wurden. (Andernfalls: wer sollte das lesen?)

Zu den eigentlichen Elementen des Spiels:
Strategiespiele beinhalten meiner Meinung nach grundsätzlich einen gewissen Simulationsfaktor, weshalb die explizite Erwähnung eigentlich nicht notwendig sein sollte. Aus dem "Schlachtfeld" lese ich heraus, dass für euch diese taktische Übersicht, die man ansonsten in "Rome Total War" hat, der standard ist. Für mich wäre wohl eher dieses Schlachtfeld das, was ein Strategiespiel besitzen sollte, aber das liegt wohl eher daran, dass ich bisher auch weit mehr solche Spiele gespielt habe.
Wie die RPG-Elemente umgesetzt werden sollen, wäre interessant zu wissen. Soll jede einzelne Einheit für sich Kampferfahrung sammeln können (Dungeon Keeper), besondere Einheiten, eine Gruppe von Einheiten, der "Held" (siehe "Warcraft 3") des Spielers oder doch eher der Spieler selbst? Es gibt so viele Möglichkeiten, wie man entsprechende Elemente einfließen lassen könnte, weshalb ich es als relativ bedeutungslos erachten muss.
Da ansonsten wohl nichts konkretes beschrieben wurde, kann ich auch nichts weiter zum Spiel sagen.


Und als Programmierer würdem ich interessieren: Warum C++? Welche Entscheidungen wurden in der Hinsicht bereits getroffen? (Wobei es eher so scheint, als sei nocht nichts konkret entschieden, aber dann sollte auch nicht geschreiben werden, dass C++ geplant sei.)

Es gibt in der Theorie des Game Designs verschiedene Spielertypen: den Farmer, den Sieger, den Gelegenheitsspieler, etc. Ich weiß gerade nicht die aktuellen Namen, aber in einem Buch auf meinem Nachttisch stehen sie drin. Der Punkt ist: ein Spiel kann immer nur eine begrenzte Zahl von Spielertypen ansprechen. Es wird immer Spieler geben, die sich von einem Spiel nicht angesprochen fühlen. Ein "perfektes" Spiel halte ich für nahezu unmöglich und es macht auch meiner Meinung nach keinen Sinn, aus den Meinungen aller ein allmächtiges Spiel zu erstellen.

Ich bin mir gerade nicht sicher, welche Typen dort genannt werden (ich habe auch dir englische Version "The Art of Game Design" gelesen), allerdings erinnert mich das spopntan an Mechanics, Dynamics, Aesthetics (kurz MDA, wurde auch in einem Artikel auf gamedev.net beschrieben, das sich wiederum auf ein Video von Extra Credits zu diesem Thema bezieht). grundsätzlich sollte man sich 2-4 der genannten Ästhetiken als Ziel setzen. Im Video wurde Minecraft als ein Beispiel genannt, welches sehr viele davon bedienen kann.
In "Designing Virtual Worlds" werden ebenfalls Spielertypen genannt, allerdings gibt es dort 2 Diagramme. Im ersten dürften "Griefer", "Achiever", "Sozializer" und ein weiterer Typ stehen, da ich das Buch gerade nicht da habe, kann ich leider auch nicht nachgucken. In diesem Buch beziehen sich diese Typen und deren weitere Verwendung sehr auf virtuelle Welten (im Sinne des Buchs). Es dürfte zwar übertragbar sein, allerdings auch nur in einem gewissen Maße.

Zitat von »StragegeTobi«

Das Projekt startet erst wenn das Technische Konzept fertig ist, welches wir mit dem gesamten Team machen möchten, um euch möglichst viel mit einzubinden und spätere Korrekturen möglichst zu vermeiden.

Das klappt sowieso nicht. Lass Dir das aus jahrelanger Erfahrung sagen Ich sehe es immer wieder. So gut man auch ist, man vergisst immer Dinge, die am Ende viele Änderungen notwendig machen. Macht lieber nur einen groben Plan und nähert Euch Schritt für Schritt an die Details an.

Ich bin mittlerweile dazu übergegangen kaum etwas zu planen in weiter Zukunft zu planen und das Schriftlich fest zu halten. Wenn man das System dynamisch genug gestaltet sind Änderungen an Details bis zur letzten Minute möglich. Manchmal ist es sogar notwendig, weil etwas nicht so umsetzbar ist wie du es dir gedacht hast oder dir eine bessere Lösung eingefallen ist. Hat man da zu viel geplant kann man ne ganze Menge löschen oder umschreiben. Das Designdokument sollte wirklich sehr allgemein gehalten sein, also kaum Details enthalten.

Wenn man allein Arbeitet ist nur eine sehr kurzfristige Planung notwendig. Je mehr Mitarbeiter, desto mehr Zeit musst du in die Planung der Aufgaben und die Bereitstellung der notwendigen Mittel(z.B. UML Diagramme, Interfaces etc.) investieren. Falls du noch mehr über die Projektplanung und -durchführung lesen möchtest würde ich dir Die Kraft von Scrum oder gleich das ausführlichere Scrum - Agiles Projektmanagement erfolgreich einsetzen empfehlen(mit Sicherheit auch bei deinem örtlichen Buchhändler erhältlich ).

Na ja... das Designdokument sehr wohl sehr detailliert sein, wenn man schon eins macht. Aber das Ding enthält dann die Usecases. Also das "was kann man machen und wie funktioniert das", aber kein "wie ist das technisch umgesetzt".
Dem zweiten Absatz stimme ich zu.