[Best Practices]Spielerstellung - Von Anfang bis Ende

Jetzt mach doch erst einmal ein paar Spiele-Erstellungen fertig, und berichte danach -wenn du Erfahrung hast- von den best practices dazu.

Es ist immer gut, einen detaillierten plan zu haben. Viel Erfolg!

Zitat von Paranoya

Dieser Beitrag soll jedem, vom Anfänger bis zum Senior die Chance bieten und dazu dienen, seine Erfahrungen zu teilen und von den Fehlern, Erfahrungen, Best Practices der anderen zu lernen.

Ich kann von 2 ganz gravierenden Erfahrungen berichten.
1. Die eine Erfahrung, die ich erlebt habe in einem UE4 Projekt war, dass wir uns zu Tode verwaltet haben.
Wir wollten alles ordentlich machen und hatten von dem Projekt nur ne grobe Story und ein Konzept niedergeschrieben. Das meiste war noch in unseren Köpfen.
Dann haben wir ein Projektmanagementsystem benutzt wo man Aufgaben erstellen und zuweisen kann und haben dort (aus meiner Sicht) viel zu detailliert/kleinlich Aufgaben erstellt.
Dazu kam dann noch, dass wir uns nicht an die vorgegebenen Bedienregeln gehalten haben, die wir uns selber ausgedacht haben. Diese haben den zeitlichen Aufwand der eigentlichen Aufgabe oft um einiges vergrößert als die Aufgabe selber gedauert hat.

Also mein Tip an der Stelle. Lieber erstmal klein anfangen und seine Gedanken in Excel oder Word /Libreoffice festhalten und alles aufschreiben damit sich das Team damit befassen kann als am Anfang direkt komplexe System einzusetzen wenn man mit solchen kaum oder keine Praxiserfahrung hat und selber noch im Lernprozess steckt.

2. Die zweite Erfahrung erklärt ein Sprichwort ganz gut.
"Lieber ein Ende mit Schrecken als ein Schrecken ohne Ende."
Ich beziehe das jetzt mal auf die Mitglieder in einem Team. Damit meine ich, dass man Leute, die dem Projekt nichts beitragen (aus welchen Gründen auch immer), eher wieder aus dem Team entfernen sollte als sie ewig mitzuschleifen und sich damit nur rumärgert. Während man selber stetig am Projekt arbeitet und seine Zeit aufbringt, entpuppen sich andere dann vielleicht nur als Nutznießer und im schlimmsten Fall meckern sie nur rum und tragen nichts produktiv zum Projekt bei. Bestes Beispiel auch aus Berufserfahrung, Teammitglieder, die zu kaum einem Meeting erscheinen, sich keine Entwürfe durchlesen und dadurch den aktuellen Stand nicht kennen, aber wenn sie dann mal da sind, nur rum meckern und alles besser wissen. Solche leute halten einen nur auf - glaubt mir.

So hier nochmal meine 5 Cent.

Erst mal - sehr löblich wenn man zumindest einen groben Plan hat.

Wie detailliert ein Plan sein soll hängt meiner Meinung nach sehr vom "Ernst" ab. Wenn man Leute angestellt hat und auch bezahlt damit diese im Projekt arbeiten dann sollte der Plan sehr detailliert sein. Wenn alle nur für Umme und aus Spaß mitarbeiten dann ist ein zu detaillierter Plan eher hinderlich - bei Amateuren bildet es sich oft erst während der Programmierung heraus was "machbar" ist. Ein schlechtes Spiel kann man jeden Tag ein wenig besser machen. Es gibt nix gutes ausser man tut es.

Meiner Erfahrung nach ist bei Hobby Projekten der Killer Nummer Eins einfach zu hohe Anforderungen. Sprich ich will ein RPG machen und verwurste so viel Zeit und Ressourcen in das Inventory System daß am Ende keiner mehr Lust hat und einfach nix bei rumkommt. Wichtig ist es schon ganz am Anfang einen Prototypen zu machen - auch wenn der gar nix mit dem späteren Spiel zu tun haben wird. Ist ein task momentan nicht realistisch und zügig mit Fortschritten zu bereichern einfach mit was anderem weitermachen, Fortschritt ist wichtig, besser machen kann man später.

Killer nummer zwei ist es wenn die Leute den Spaß verlieren. Spaß hat man hauptsächlich wenn man Dinge tut die einem liegen und die man gerne macht. Wenn einer gerne modelliert dann sollte er sich darauf konzentrieren. Wichtig ist es auch daß die Früchte der Arbeit verwendung finden - sprich ich bastel die Modelle auch zügig ins Spiel und zeige meinem Modeller die Ergebnisse im Spiel, so daß er was zum anfassen und sehen hat und stolz ist. Lasse ich ihn modellieren und die Modelle verstauben auf meiner Festplatte dann wird er demotiviert und verliert die Lust.

Killer Nummer 3 ist die Demokratie. Frage ich 10 Leute wie sie das Inventar in einem RPG haben wollen bekomme ich 10 verschiedene Antworten. Ist gut von jedem die Meinung zu hören aber einer muß den Hut aufhaben und Entscheiden. Man braucht einen Diktator der am Ende sagt das Grass wird hellgrün, punkt aus so ist es. Nicht unbedingt gegen die Mehrheit aber irgendwas muß entschieden werden, sonst gehts nie vorwärts. Im Zweifel Fakten schaffen, etwas durchsetzen und es als "Platzhalter" erklären wenn einer dumm fragt. Kommt keiner mit etwas besserem rüber bleibt es halt.

Hallo zusammen,

ich bin kein Entwickler, aber ich habe eine Weile lang ein Entwicklerteam als (hobbymäßiger) Betatester unterstützt und hier und da die Community betreut. Ich musste im Prinzip dabei zusehen, wie sich die Truppe verrannt hat. Schön war das nicht, denn es hatte was von einem verendenden Reh, das man mit dem Auto angefahren hat. Das Spiel wurde übrigens auf der Source Engine gebaut.

Die größten Fehler waren m.E. die mangelhafte Kommunikation, das "machen lassen" von einzelnen Entwicklern und die Unklarheit unter den Entwicklern wie das finale Produkt in etwa aussehen soll, was in der Vermischung von grundverschiedenen Konzepten resultierte.

Die mangelhafte Kommunikation hatte in erster Linie zur Folge, dass nicht alle an einem Strang zogen, weil jeder im Prinzip seine eigene Version des Spiels vor Augen hatte. Der Eine wollte es langsam und anspruchsvoll, der andere schnell und mit vielen tollen Effekten und der Nächste hatte wieder etwas ganz anderes im Sinn. Im Endeffekt wurden so mehrere Konzepte miteinander vermischt, bis dann überhaupt nichts mehr funktionierte. Es ist wie wenn man in einem Kreis steht, jeder ein Seil in der Hand hat und die in der Mitte verknotet sind. Jeder zieht an seinem Seil, der Knoten wandert hierhin und dorthin, aber er bleibt im Grunde wo er ist. Es geht einfach nicht weiter und man hat dann oft vorhandenen Content mit hübscherem Content ersetzt obwohl sich kein Spieler entsprechend beschwert hatte.

Ebenfalls schlecht war der allgemeine Informationsfluss von oben nach unten. Man (Tester und Moderatoren) wusste nie so genau, wie eigentlich gerade der Stand war und wie es weitergeht. So lief man immer mal wieder beim Versuch die Community bei der Stange zu halten in eine Wand. Das sieht erstens saumäßig dumm aus und es verärgert auch die Mods, weil es einfach nicht sein müsste. Auch kam es immer wieder vor, dass verschiedenste Dinge auf den allerletzten Drücker gemacht werden mussten (obwohl man sie ordentlich hätte vorbereiten können), weil ein Entwickler es nicht für nötig hielt die Supportebene rechtzeitig oder überhaupt zu informieren. Tester hatten wir einige, die waren aber über den ganzen Globus verstreut und da braucht es nunmal einige Tage Vorbereitungszeit, wenn man da vernünftig testen will. Falls ihr Tester um euch scharen könnt, bindet die gut ein, damit die wissen was gerade läuft und wie der Zeitplan ist. Die sollen auch nicht die Lust verlieren, denn es dauert auch immer eine Weile, bis die wissen wie was gemacht wird und wie sie das Feedback aufbereiten müssen, damit es für einen Entwickler wirklich brauchbar ist.

Ein weiterer großer Punkt war das "machen lassen" eines neuen, fleißigen Entwicklers in dem kleinen Team. Nachdem dieser sich eingearbeitet hatte, sollte er eigentlich erst einmal die eine oder andere Map Clippen. Damit hat er auch angefangen, aber plötzlich hat er die halbe Map umgebaut. Er wurde zwar angehalten so etwas nicht zu machen, die Änderungen blieben jedoch. Das Resultat war aus Sicht der Tester (waren alles Spieler!), dass die Änderungen keinen Mehrwert für den Spielspass und die taktischen Möglichkeiten bedeuteten. Im Endeffekt hat der Entwickler viele Stunden seiner Zeit und der Tester verballert. Das hat erhebliche Spannungen gegeben, denn die (unbezahlten) Tester sind Spieler. Die laufen genau einmal über die Map und wissen sofort, dass die Umbauten völlig unnötig waren. Dass man etwas umsonst macht kann schon mal vorkommen, aber das muss die Ausnahme sein! Die Devise der Tester ist: "Wir sind Spieler, wir wissen was uns Spass macht, wir sind erreichbar und ihr hättet einfach mal fragen können, dann hätten wir euch gleich gesagt, dass dieser Umbau Quark ist."

Es ist halt die Frage für wen man das Spiel baut. Wenn man das für sich selbst baut braucht man kein Feedback von außen. Baut man es aber um es z.B. zu verkaufen, sollte man schon ein offenes Ohr für die haben, die es mal kaufen sollen.

Mit dem "machen lassen" kann gut gehen - aber der Chef (DIktator sag ich immer) mß ab und zu mal reinschauen (wenigstens einmal die Woche) und feedback geben oder auf die Finger hauen.

Hier spielt auch wieder das "zu viele Köche verderben den Brei" Prinzip rein - wenn 2 Leute mit unterschiedlichen Vorstellungen an maps basteln dann kommt meist Mist raus.

Ich hab aber auch schon modeler erlebt die haben bei so Communit Projekten Gas gegeben und immer das Gespür gehabt was richtig war - die konnte man machen lassen und sich darauf verlassen daß praktisch täglich neue brauchbare Models und Animationen wie am Fließband produziert wurden. SO macht das natürlich Spaß, aber ich glaube es ist auch selten.

Tester sind immer leicht zu bekommen und meist auswechselbar. Gute Tester die brauchbares Feedback geben sind aber selten - die sollte man zumindest ernst nehmen.

Mit Prototypen sollte man sich nicht verrennen - jeden tag nen neuen Releasen ist zu viel Aufwand und nervig für Leute mit geringer Bandbreite. AM besten "Meilensteine" definieren und so etwa alle 2 Wochen was releasen wenn genug Material drin ist oder Bedarf zu Testen besteht.

Wenn man sich mit dem feedback und Anregungen der Community verrennt bietet sich sowas wie Trello an, da kann man gut Ideen, Bugs und Features verwalten ohne dauernd was zu vergessen.

Kommunikation ist immer so ein zweischneidiges Schwert - sie sollte knapp und bündig seinund zielgerichtet. Sprich die Leute nicht mit dummen Monologen zulabern und sich zehnmal wiederholen. Lieber jeden einzelenen persönlich einmal die Woche anschreiben und ihm gezielt feedback geben was gut war, was nicht und was ansteht. Man kann auch nen whatsapp chat oder so machen, aber ich bin dagegen, eist klautes viel Zeit, jeder labert was für ne Biersorte er gerade trinkt oder wie das Wetter in Buxtehude ist. Of lenkt es ab. Macht man sowas dann sollte man es etwas moderieren. Ich bin aber kein großer Freund davon. lieber ein Forum oder so, daß sich keiner genötigt fühlt dauernd in Echtzeit ein Schwätzchen zu halten.

Wenn man auf die Kommunikation der Community geht um zb Tester zu betreuen und das Feedback zu bekommen sollte man 1 vllt 2 Personen (Moderatoren) extra dafür einsetzen die das Spiel kennen und regelmäßigen Kontakt untereinander und zu den devs halten.

Ob das jetzt über ein Forum oder sonstiges geht ist erstmal egall.

Wichtig ist das es erstens nicht zu viele Moderatoren sind, damit nicht alles doppelt und dreifache an die devs herangetragen wird und die Tester sozusagen ein Verhältnis aufbauen können.

Der 2 wichtige Punkt ist das die Mods vertrauenswürdig sind und auch Ahnung haben, da die abschätzen müssen was wichtig ist und an die devs weitergegeben werden muss und was erstmal auf die Warteliste kommt. Es bringt nichts wen der dev 100 Sachen am Tag bekommt wo irgendwelche Pixel bugs sind ec. Und er sich vor Arbeit nicht um neue Inhalte kümmern kann oder schlimme Bugs zb. ein dupen durch Logout vergisst.

Der 3. Wichtige Punkt wurde schon angesprochen. Die Mods müssen auch auf dem aktuellen Stand sein um eventuelle Fragen der Tester zu beantworten oder Rückmeldung zu geben. Kein Tester macht es lange mit wen er regelmäßig Feedback gibt aber keine Infos oder Rückmeldungen gibt. Da verliert man die Tester nach einer Weile.