Es lohnt sich, unserem Spiel 'futuristische' Funktionen hinzuzufügen, oder sollten wir uns woanders konzentrieren?

Ich bin leitender Programmierer in einem mittelgroßen Indie-Game-Studio. Dies ist unser erstes Spiel als Team. Wir arbeiten an einem futuristischen FPS-Spiel mit einem Gewinnbeteiligungsplan.

Wie auch immer, wir haben einige sehr gute Programmierer, die in der Lage sind, noch nie dagewesene Features zu erstellen (echte realistische Flüssigkeiten, Zerstörung von prozeduralen Netzen, prozedurale Skyboxes usw.). Sie brauchen viel Zeit, sehen aber gut aus. Wir streben einen 12-monatigen Entwicklungszyklus an. Also sollten wir das machen oder einfach ein Standardspiel machen.

Versuchen Sie es nicht, weil Sie wissen, dass Sie es können.

Das Gameplay sollte an erster Stelle stehen, alle Dinge (sogar Grafiken) sind zweitrangig. Wenn das Spiel Spaß macht und Spaß macht, aber schlechte (oder nicht so neue) Grafiken hat, wird es trotzdem Spaß machen und Spaß machen und die Leute werden es spielen, und auch Ihre Metakritik wird gut sein. Andernfalls, wenn das Spiel großartige Grafiken und Funktionen hat (realistische Flüssigkeiten, Zerstörung des prozeduralen Netzes usw.), aber nicht unterhaltsam oder schwierig zu spielen ist (schlechte Steuerung usw.), werden die Leute es nicht spielen. Keine Spieler = kein Geld und auch schlechte Metakritik.

Planen Sie also zuerst das Spiel, das Sie spielen möchten, und überlegen Sie sich die Spielfunktionen und die spielbaren Situationen. Versuchen Sie nicht, das Feature X in das Spiel zu integrieren, nur weil es cool aussieht. Wenn es keinen Sinn ergibt oder keinen wichtigen Teil des Spiels ausmacht, lassen Sie es einfach fallen.

Vermeiden Sie es auch, das Gameplay um eine dieser fantastischen Funktionen herum aufzubauen, wenn es keinen Sinn ergibt oder Sie der Meinung sind, dass es keinen Spaß machen wird. Zum Beispiel: Sie könnten denken, "Ich habe eine prozedurale Netzzerstörung, also zwingen wir den Spieler, alles zu zerstören, bevor er im Spiel weiterkommt (damit er sehen kann, dass Netze prozedural zerstört werden)".

Fazit: Denken Sie zuerst über Ihr Spiel und seine Bedürfnisse nach. Planen Sie von dieser Basis aus Ihre Entwicklungsphase, und Sie werden sehen, ob genügend Platz für eine oder mehrere dieser fantastischen Funktionen vorhanden ist (und ob es sinnvoll ist, sie zu Ihrer speziellen Art von Spiel hinzuzufügen).

Wenn man bedenkt, dass ein 12-monatiger Zyklus nicht bedeutet, dass man in Woche 52 mit dem Codieren aufhört und es aus der Tür schiebt, stehe ich auf der Seite mit den bereits gegebenen Antworten, dass das Spielen an erster Stelle stehen muss und nur dann ordentliche Funktionen hinzugefügt werden, wenn sie dem Spiel helfen abspielen.

Im Idealfall haben Sie Zeit für einen Beta-Test mit Release-Kandidaten, sodass die meisten Arbeiten mit Ausnahme von Fehlerbehebungen und Optimierungsstopps in Woche 50 ausgeführt werden.

Die vollständigen Funktionen sollten lange vor der Betaphase verfügbar sein, sodass Sie möglicherweise interne Tests durchführen können, um alles vor dem Polieren in der Betaphase zu stabilisieren. Das sind also nur 46 Wochen Arbeit, bevor Sie das Spiel für den Versand vorbereiten.

Der Schlüsselgedanke ist zu entscheiden, ob es sich lohnt, Ihren heißen Ingenieur an einem System arbeiten zu lassen, wenn dieser Ingenieur nicht bereits an Ihrem nächsten Titel arbeitet. "Was könnte er sonst noch tun?" Sind die versteckten Kosten für jede Entscheidung.

Übrigens, simulierte Flüssigkeitsmengen, prozedurale Zerstörung, dynamische Sky-Boxen usw. wurden alle in kommerziellen Spielen durchgeführt und der Grund, warum Sie nicht so viel über sie hören, ist, dass das Spiel selbst immer wichtiger war.

Viel Glück, alles, was Sie tun, wird spannend!

Wenn Ihre Programmierer so gut sind, dann nutzen Sie diese Fähigkeiten, um pünktlich und unter dem Budget zu liefern. Und überlegen Sie bis zum Start Ihres nächsten großen Projekts, wie Sie die Fähigkeiten Ihres Teams besser nutzen können, wenn Sie über ein größeres Budget verfügen, das eine gute Erfolgsbilanz aufweist.

Aber wenn Sie Dinge auf diese Weise tun müssen, dann wählen Sie eine coole Sache. Nicht alle, nicht einmal zwei - Führen Sie niemals zu viele Risikofaktoren gleichzeitig ein. Und die, die du auswählst, MUSS in gewisser Weise im Mittelpunkt des Gameplays stehen, denn der Rest ist nur Flusen. Wenn Sie Blizzard sind, können Sie es sich leisten, herumzusitzen und nette Funktionen hinzuzufügen - obwohl ihre Entscheidungen IMHO immer geschäftsorientiert sind.

Aber wenn Sie versuchen, alle oder nur einige der Dinge zu implementieren, die Ihre Programmierer können, weil es cool zu sein scheint und Sie denken, dass Sie das können, werden Sie einen großen Sturz erleben.

Auch hier lautet der Schlüssel NICHT etwas hinzufügen, das nicht mit Sicherheit zur Dynamik des Kernspiels beiträgt - was auch immer das ist (es klingt so, als ob das noch TBD hat).

"Wir haben einige sehr gute Programmierer, die die Fähigkeit haben, noch nie dagewesene Funktionen zu erstellen."

Nichts persönliches, aber ich muss sagen, ich bezweifle es. Valve (um nur einen auszuwählen) hat einige der besten Programmierer der Branche, wenn nicht der Welt. Havoc hat auch einige ziemlich kluge Leute - es gibt Dutzende anderer Beispiele. Sie haben alle mehr Programmierer als Sie, mehr Zeit und höhere Budgets.

Vielleicht haben Sie es irgendwie geschafft, eine Gruppe von absoluten Genies zusammenzubringen. Aber ich würde vorsichtig sein, was die Unterschiede zwischen dem, was Programmierer für möglich halten, und dem, was wir in einer begrenzten Zeit und zu einem veröffentlichbaren Standard tatsächlich können. Wie andere gesagt haben, können Sie (wenn Sie sehr zuversichtlich sind) eine auswählen. Ich persönlich würde den Prozess, ein Spiel auf den Markt zu bringen, mindestens einmal durchlaufen wollen, bevor ich versuchte, nach dem Mond zu schießen.