Lohnt es sich zu planen, bevor Sie in den Code springen?

Ich habe immer gedacht, dass Planung für ein Spiel wichtig ist. Aber ich weiß nicht an welchem ​​Punkt. Einige sagen mir, ich solle programmieren anstatt zu planen, aber ich glaube, es ist immer noch wichtig, denn wenn Sie sich im Code befinden, wissen Sie, was Sie als nächstes leichter tun können. Ich arbeite derzeit an einem Spiel, das viele Inhalte haben wird, also habe ich beschlossen, ein Designdokument zu erstellen, in dem diese Inhalte vorgestellt werden, und auf einer Nebenebene mache ich Proofs of Concept, um zu überprüfen, ob dies möglich ist. Teile jedes Proofs des Konzepts könnten dann später im realen Spiel verwendet werden.

EDIT: Ich arbeite alleine an diesem Projekt.

Meine Frage lautet also: Lohnt es sich zu planen, bevor Sie in den Code springen? Ich bin immer noch interessiert zu wissen, was andere dazu sagen. Weil ich immer noch ein paar Leute höre, die sagen, ich solle codieren, anstatt zu überlegen. Also, was ist deine Meinung dazu?

Sie sagten zwei kluge Dinge in Ihrer Frage:

1. "Code statt Denken" - das beschreibt eine ganze Philosophie: http://gettingreal.37signals.com/toc.php
2. "Proofs of Concept, um zu prüfen, ob es möglich ist" - Ich habe viele Ideen gesehen und hatte sie, die sich als unmöglich oder äußerst schwierig erwiesen, als sie fast fertig waren. Manchmal kann man es einfach nicht vorhersagen, weil es Ihre Programmierumgebung (Sprache, Bibliotheken, Hardwareleistung) ist, die Sie einschränkt.

Deshalb sage ich:

• Entwerfen Sie, aber machen Sie kein großes Design-Dokument, wenn Sie nicht nach Mitarbeitern oder Investoren suchen, es sei denn, es macht Ihnen Spaß und Sie machen eine Pause von der Programmierung.
• Denken Sie immer daran, was Sie erreichen möchten. Jedes Modul sollte einen gestalteten Ein- und Ausgang haben. Auf diese Weise können Sie das Modul problemlos testen und haben kein Gefühl, im Nebel zu wandern.
• Denken Sie daran, dass Sie sowieso die meiste Zeit entwerfen, da das Eingeben von Code nur etwa 5% Ihrer Zeit in Anspruch nimmt (zumindest das Eingeben des endgültigen Codes).
• Programmieren ist keine theoretische Wissenschaft. Anstatt zu prüfen, ob etwas auf einem Blatt Papier funktioniert, können Sie es einfach codieren und versuchen. Bei dem Endprodukt geht es hauptsächlich darum, Benutzereingaben kinderleicht zu machen, die Benutzeroberfläche gut auszusehen und sich mit Sonderfällen zu befassen - ein schmutziger Test einer Idee kann sofort durchgeführt werden.
• Erstellen Sie eine Aufgabenliste, wenn Sie Angst haben, Ihre Ideen zu vergessen
• Sprechen Sie mit Ihren Freunden über Ihre Ideen, da diese weniger begeistert sind und möglicherweise mehr Erfahrung auf einem Gebiet haben. Einmal hatte ich die Idee, Einheitenparameter (in einem strategischen Spiel) geheim zu halten, aber mein Freund sagte mir, es sei eine schlechte Idee, da er ein Spiel wie dieses gespielt habe und es eine schreckliche Benutzererfahrung gewesen sei.

Ja, aber nur ein bisschen .

Für das Programmieren von Spielen, insbesondere für das Programmieren von Spielen, ist es wichtig, einen guten Anwendungsfall zu haben, bevor Sie Code schreiben. ZB was soll der Spieler tun, wohin soll er gehen und wie, wie interagiert er mit der Welt usw. Dies kann ein auf Papier skizziertes Storyboard sein oder aus einer Diskussion mit einem Kollegen hervorgehen ... Dies ist Teil des Spieldesigns , und es wäre dumm, mit dem Codieren zu beginnen, ohne auch nur eine ungefähre Vorstellung davon zu haben, wie das Spiel gespielt werden soll.

Spiele müssen jedoch iterativ erstellt werden . Sie können keine große Spezifikation für Ihr Spiel erstellen und hoffen, dass das Spielen Spaß macht. Sie müssen regelmäßig spielen, um herauszufinden, was funktioniert und was nicht, und müssen immer wieder iterieren. Je schneller die ausführbare Datei ausgeführt wird, je schneller das Spieldesign getestet werden kann, desto besser wird das Spiel am Ende. Es ist also immer besser, so schnell wie möglich mit dem Codieren zu beginnen, von einem sehr unformalen Spieldesign aus, zu sehen, was rauskommt, und weiterzumachen.

Eine Sache ist sicher, da Sie alleine programmieren, brauchen Sie kein ausgefallenes Software-Designdokument oder eine Methodik, der Quellcode ist das Design.

Einige sagen, Sie sollten codieren, anstatt zu denken? Nun, um Code zu erstellen, müssen Sie wissen, was Sie erstellen möchten. Um zu wissen, was Sie erstellen möchten, müssen Sie zuerst überlegen, was Sie haben möchten. Sie müssen also überlegen, bevor Sie Code erstellen.

Und im Ernst, Sie brauchen wahrscheinlich nicht gleich zu Beginn einen detaillierten Plan, aber eine Übersicht und / oder Meilensteine ​​zu haben ist immer von Vorteil - auch für Ihre Einstellung, wenn Sie die Dinge wie getan streichen, werden Sie mehr ermutigt, mehr zu tun Arbeit.

Sowohl Codierung als auch Planung sind erforderlich. Zuerst planen, dann programmieren, aber nicht alles auf einmal planen. Planen Sie einen Kern, programmieren Sie ihn, und aktualisieren Sie Ihren Plan nach Bedarf. Planen Sie dann Funktionen, die sich zu Spielbarkeit, Grafiken, Sounds, Sprites usw. usw. addieren. Auf diese Weise wird das von Ihnen erstellte Spiel besser aussehen und sich insgesamt besser anfühlen. Natürlich können Sie einen solchen Zyklus mehrmals ausführen, und ich rate Ihnen, Entscheidungen zu treffen, die die Hochskalierung unterstützen, falls dies erforderlich sein sollte.

Sie müssen wissen, wohin Sie gehen, bevor Sie Code schreiben, und Schreiben / Zeichnen kann eine gute Möglichkeit sein, das zu verwirklichen, was Sie erreichen möchten. Ich sage Zeichnen, weil das Zeichnen von Diagrammen, Skizzen usw. auch sehr hilfreich sein kann. Sie müssen kein wunderbares Dokument erstellen, das mit Word oder etwas anderem erstellt wurde. Nehmen Sie einfach einen Bleistift und ein Stück Papier (viel Papier?) Und zeichnen Sie, schreiben Sie alles, woran Sie vielleicht denken.

Für mich ist es eine gute Praxis, Bleistift und Papier zu verwenden, es hilft, Ihre Ideen zu verwirklichen und auch festzulegen, wohin Sie gehen möchten, um zu verhindern, dass Sie irgendwohin gehen und Ihr Ziel festlegen. Es funktioniert für alles, was Reflexion braucht. Und in vielen Bereichen ist es naheliegend, Dinge aufzuschreiben, bevor man die eigentliche Arbeit erledigt.

Tun Sie, was auch immer für Sie funktioniert. Persönlich plane ich Dinge in geringem Umfang, aber keine Designdokumente sind extrem detaillierte Pläne, bevor ich anfange, irgendetwas zu programmieren. Tun Sie, was für Sie am produktivsten ist, vor allem, weil Sie alleine arbeiten.

(Ich gehe davon aus, dass die Frage aus der Sicht des Code-Designs / der Architektur gestellt wird, nicht aus der Sicht des Game-Designs, obwohl die Antwort zumindest teilweise für beide gilt.)

Wie bereits gesagt, brauchen Sie beides und müssen es ausbalancieren. Sowohl das Über- als auch das Unterdesign Ihres Codeflusses / Ihrer Codestruktur kann Probleme verursachen. Es ist schwer zu sagen, wie das richtige Gleichgewicht aussieht, aber im Allgemeinen muss ich zumindest eine vage Vorstellung davon haben, wie der Rest des Codes mit dem übereinstimmt, was ich gerade programmiere, und über mögliche Probleme nachdenken. Ansonsten neige ich dazu, "mich selbst in eine Sackgasse zu verschlüsseln" - in eine Situation zu geraten, in der mir klar wird, dass "okay". Dank der Lösung dieses Problems habe ich ein neues Problem erstellt, das meine gesamte vorherige Lösung (oder im schlimmsten Fall sogar noch mehr) wiedergibt vergeblich ".

Generell können Sie meiner Meinung nach grob beurteilen, ob Sie das richtige Gleichgewicht haben, indem Sie über "Was-wäre-wenn" -Szenarien nachdenken, wie in "Was-wäre-wenn", wenn ich es später (wenn alles in dem ähnlichen Paradigma, wie ich es jetzt verwende, vollständig implementiert habe) herausfinde dass Teil A etwas anders arbeiten muss, was bedeutet, dass ich Teil B, der sich damit verbindet, komplett überarbeiten muss, um die Änderungen aufzunehmen? " Wenn Änderungen an der Architektur eines Teils nicht erfordern, dass Sie mehr als ein oder zwei andere Teile ändern, und die Änderungen nicht kaskadieren (was bedeutet, dass Sie wiederum auch die nächsten Teile ändern müssen, die mit Teil B verbunden sind, und dann die Teile, die mit Teil B verbunden sind ihnen usw.) ist der Code in relativ guter Weise unterteilt.

Aber das ist wirklich etwas, für das Sie ein Gefühl bekommen, nachdem Sie etwas Erfahrung gesammelt haben. Dies ist zum Teil der Grund, warum jeder Spielanfänger den Rat gibt, zuerst etwas Bekanntes und Einfaches zu codieren (Breakout / Tetris / Snake) und es vollständig zu machen, mit allen Menüs, Sounds, Effekten, alles, um das Spiel zu einem vollständigen Ende zu machen - es ist besser Wenn Sie ein kleineres Projekt vermasseln und es (ob auf gute oder schlechte Weise) tun, können Sie genau ein Gefühl dafür bekommen, wie weit die Auswirkungen verschiedener Architekturentscheidungen reichen.