Wer braucht denn Storywriter?

[KingPaddy]

muss er das Spiel ständig aus der Hand geben, macht er es doch, gibt der Autor die Geschichte wieder ein Stück weit aus der Hand. Im Endeffekt steigt dadurch nur das Risiko, dass das Spiel abgebrochen wird. Fazit: Ich glaube nicht, dass reine Autoren benötigt werden.

...

Trifft dann nicht eher zu, was csg dann sagt? Müsste der Storywriter dann nicht auch die Aufgabe haben als eine Art Produzent erstens die eigenen Ideen der anderen mit dem Plot in Deckung zu bringen und weil er dann den Gesamtzusammenhang der Story, der Abläufe der Orte, etc. im Blick hat die Koordination zum Beispiel beim Mapping, Charakterdesign etc. zu übernehmen? All diese Teile werden ja gerade über die Handlung erst zu einem Spiel verbunden, davor sind es Teile des Spiels, die erst einmal Ressourcen sind und in der Zusammenwirkung beim Präsentieren der Welt und der Handlung dann ein Ganzes ergeben. Wenn wir annehmen, dass es reine Storywriter gibt, dann wäre er prädestiniert dazu, auch noch die interne Projektkoordination zumindest zum Teil mitzuübernehmen, damit eben alles zusammengeht.

Aber verteilt auf mehrere Rechner, dafür ist der Maker einfach nicht gemacht.

...

Das schlösse jemanden, der sich primär um die Story kümmert ja erst einmal nicht aus, da der das Programm nicht unbedingt anfassen muss, aber für größere Projeke sind natürlich mehr Leute eigentlich besser und da ist das sicher eine Limitierung. Aber da muss man dann vielleicht wirklich das zugrundeliegende Programm ändern, je nach Bedürfnissen.

[Eddy131]

Das schlösse jemanden, der sich primär um die Story kümmert ja erst einmal nicht aus, da der das Programm nicht unbedingt anfassen muss, aber für größere Projeke sind natürlich mehr Leute eigentlich besser und da ist das sicher eine Limitierung. Aber da muss man dann vielleicht wirklich das zugrundeliegende Programm ändern, je nach Bedürfnissen.

...

Stimmt, an den Punkt hatte ich noch gedacht aber vergessen zu erwähnen.
Wenn man die Aufgaben mehr oder weniger strikt trennt, dann kann es schon klappen.
Wenn also die Ressourcen (Grafiken, Sounds) von verschiedenen Personen kommen, kann man auch in Gruppen arbeiten.
Am Maker selbst könnte höchtens abwechselnd arbeiten.
Etwa, das einer die Karten nach gewissen Vorgaben mapt, er das Projekt dann weitergibt, der nächste erstellt alle Events und ein Dritter fügt dann alle Dialoge mit ein.
Da braucht es aber viele Absprachen und das Problem das diejenigen, die das Projekt gerade nicht haben quasi arbeitslos sind, bleibt bestehen.
Könnte aber so klappen.

Um zum ursprünglichen Thema zurückzukehren: Ich würd's versuchen.
Mehr als ein Nein (bzw. Schweigen, was auf das Selbe hinausläuft) kannst du nicht bekommen.
Und vieeleicht findet sich ja jemand, der mehr Spaß am Erstellen hat bzw. einsieht, das seine Talente nicht beim Storytelling liegen

Da du größere Projekte angesprochen hast: Was sind den so die größten (im Sinne von der höchsten Anzahl an ständig mitarbeitenden Leuten (kleine Helfer zwischendurch zählen also nicht mit rein) ) Projekte im Hobby-Maker Bereich?
Ich würde SKS sagen, kenne aber längst nicht alle Gruppenwerke der letzten Jahre ^^

[csg]

Stimmt, an den Punkt hatte ich noch gedacht aber vergessen zu erwähnen.
Wenn man die Aufgaben mehr oder weniger strikt trennt, dann kann es schon klappen.
Wenn also die Ressourcen (Grafiken, Sounds) von verschiedenen Personen kommen, kann man auch in Gruppen arbeiten.
Am Maker selbst könnte höchtens abwechselnd arbeiten.

...

Ich kann euch mal grob skizzieren wie soetwas doch relativ einfach ablaufen kann:

Ihr erstellt eine Dropbox für alle Teilnehmer, in dem sich das Makerprojekt befindet. Zusätzlich schiebt ihr eine Textdatei hinzu ( zum Beispiel 'MASTER_KEY.txt' ). Wenn nun jemand anfängt, das Projekt zu bearbeiten, kopiert er sich diese Datei aus der Dropbox hinaus, zum Beispiel auf seinen Desktop. Nun sieht jeder, der auch etwas am Projekt machen will, dass die MASTER_KEY.txt nicht in der Dropbox ist - es ist also sofort klar, dass jemand gerade am Projekt arbeitet. Ist die Person mit ihrer Bearbeitung fertig, speichert die das Programm und schiebt die MASTER_KEY.txt wieder zurück in die Dropbox. Somit ist das Projekt wieder für die anderen freigegeben.
Natürlich kann so immer nur eine Person am Projekt selbst arbeiten, aber das dürfte in der Regel nicht so das große Problem sein. Damit spart man sich sowohl kompliziertes herumschicken und integrieren des Projektes, als auch ständige Absprachen.

[Kelven]

@KingPaddy
Eigentlich möchte aber doch derjenige, der die Idee zum Spiel hat, der Produzent sein, also alle Fäden in der Hand behalten. Warum macht er sonst ein Spiel? Das ist die erste Frage, die ich stellen würde. Jemand, der einen Dungeon Crawler machen möchte, braucht keinen Schreiber für die Handlung. Es muss daher ein Spiel sein, bei dem die Handlung wichtig ist. Er möchte also ein Spiel machen, bei dem die Handlung wichtig ist, hat aber selbst kein Interesse an der Handlung. Warum entscheidet er sich dann gerade für so ein Spiel? Wenn er nur eine tolle Gameplay-Idee hat, lässt sich für die bestimmt ein Spielkonzept finden, das auf eine Handlung weitgehend verzichten kann.

@csg

Natürlich kann so immer nur eine Person am Projekt selbst arbeiten, aber das dürfte in der Regel nicht so das große Problem sein.

...

Ist das nicht sogar das größte Problem? Man möchte ja eigentlich am Spiel arbeiten, wenn man Zeit und Lust hat, aber es könnte immer sein, dass gerade jemand anderes am Spiel arbeitet. Ich geh jetzt davon aus, dass der Entwickler, der am Spiel arbeitet, das Spiel nach "Feierabend" nicht sofort wieder auf die Dropbox schiebt. Das würde mir glaub ich schnell auf die Nerven gehen. Oder ich hab keine Ahnung, wie Dropbox funktioniert, die hat doch kein CVS-System, oder?

[KingPaddy]

Eigentlich möchte aber doch derjenige, der die Idee zum Spiel hat, der Produzent sein, also alle Fäden in der Hand behalten. Warum macht er sonst ein Spiel? Das ist die erste Frage, die ich stellen würde.

...

Ist wie gesagt das angesprochene Problem. Entweder man hat als Writer eine Idee und kann die anderen davon überzeugen und die bringen noch eigene Ideen ein, die damit in Einklang gebracht werden oder die leute, die die eigentlich Erstellarbeit machen, haben schon eine eigene Story-Idee wollen die lieber verwirklichen und haben dann auch nicht wirklich einen Bedarf für jemand anderen. Deswegen gehe ich auch nicht davon aus, dass das jemals was wird.

Unter der Bedingung, dass diejenigen mit dem technischen Know-How eben vor allem Techniker sind, dürfte es sicher gehen, aber wann findet man eben so eine idealtypische Konstellation? Die meisten fangen ja eben mit dem Makern an, weil sie, wie du sagst, eigene Ideen verwirklichen wollen.

Ist das nicht sogar das größte Problem? Man möchte ja eigentlich am Spiel arbeiten, wenn man Zeit und Lust hat, aber es könnte immer sein, dass gerade jemand anderes am Spiel arbeitet.

...

Ich kenne das von anderen Projektarbeiten. Mir ist das persönlich ganz, ganz selten passiert, dass die Leute wirklich zum selben Zeitpunkt an etwas arbeiten wollten. Also gerade wenn man Zeit oder Lust abhängig arbeitet sind die Abstände ggf. immer sehr groß und die Disparitäten sowieso, dass man sich eher selten in die Quere kommt. Das ist nur in der Anfangszeit wo die Motivation noch groß ist und jeder was machen will, ein Problem. Später verläuft sich das stärker.

[Pinguin mit Brille]

Ich spreche mal aus der Sicht von jemand, die sich vorrangig als Autorin sieht ~
Jedes Spiel hat seine Schwächen und Stärken, aber grundsätzlich brauchen Spiele ja keine Story, nur einen "Rahmen", einen Kontext, in dem der Spieler motiviert wird, zu agieren. Wenn man sich aber für ein bestimmtes Spiel-Genre entscheidet, welches storylastig ist und nicht alleine durch Gameplay getragen werden kann (wie ein RPG), dann muss man auch eine ziemlich gute Story abliefern. Ich kenne einige Spiele, die versuchten sich auf ihre Story zu stützen, aber wegen besagter dann versagen. Sich da Hilfe von jemand anderes zu suchen ist da sinnvoll und meiner Meinung nach auch der beste Weg, eine halbwegs anständige Story auf die Beine zu stellen, selbst wenn man selber nicht gerade ein Märchenonkel ist.
Außerdem, nur weil man sich Hilfe von einem Autor holt, heißt das ja nicht, dass das Projekt komplett von diesem übernommen wird. Als Co-Autorin eines Webcomics sehe ich darin sogar eher eine Stärke - wenn man sich regelmäßig mit jemanden über sein Projekt austauscht, kann das einem neue Denkanstöße geben. Ich persönlich brauche das sogar, weil ich sonst in Muster abrutsche, die ich in meinen Geschichten vermeiden will.

tl;dr: Ja, man sollte sich Autoren suchen, wenn man sich seiner Sache nicht sicher sind, aber sich dann nicht wundern, wenn das dann nicht tut und jemand die Story, Dialoge, World-Building ect. kritisiert.

Ich habe auch mal eine alte Extra-Credits-Folge dazu rausgekramt, die vielleicht ganz interessant zu dem Thema ist...

[Eddy131]

@Pinguin: Grundsätzlich gebe ich dir recht.
Sich Hilfe zu holen - auch wenn man meint es zu können - ist nie verkehrt.
Dadurch bekommt man andere Meinungen und Wissen zur Verfügung, das man selber nicht hat, was immer ein Vorteil ist.
Die Grundfrage von KingPaddy war ja aber, dass er schon eine fertige Story hat und ob es sinn macht, diese jemand anderem zu "überlassen" damit derjenige daraus ein Spiel entwickelt.

Aber abseits davon wäre eine Gute Möglichkeit noch die, das man die Grundidee von dem Macher nimmt und dann ein talentierter Storyteller nach den groben Vorgaben eine gute Story entwickelt.
Quasi Hand in Hand arbeitet.
Die Frage, was der Autor dann davon hat erübrigt sich meiner Meinung nach - was hat den irgendwer davon, das er hier Spiele entwickelt?
Mal ausgenommen die, die sie später kommerzialisieren, was sich im Aufwand/Gewinn-Verhältnis auch nicht wirklich rechnet.

[Whiz-zarD]

Es soll wohl irgendwie möglich sein, das mehrere Personen jeweils eine Map machen und die dann später in einem Projekt zusammengefasst werden.
Es artet aber meist eher in einem Flickenteppich aus.
Und es muss vorher immer genau definiert werden, wer welche Ressourcen benutzt hat, wer welche Variablen belegt etc.
Wenn man an einem Rechner arbeitet und gemeinsam alles durchplant, dann mag das noch funktionieren.
Aber verteilt auf mehrere Rechner, dafür ist der Maker einfach nicht gemacht.

...

Es liegt nicht an der IDE, sondern am Team selbst.
Ein nützliches Hilfsmittel ist eine gescheite Quellcode-Verwaltung. Ich kenne mich aber nicht mit dem RPG Maker aus und daher weiß ich nicht, in welchem Format die Dateien vorliegen. Also entweder als Textdatei, die vergleichbar sind, oder ein proprietäreres Binärformat. Wer mit Leuten zusammenarbeitet, die in unterschiedlichen Orten leben, könnte man auch per Skype oder TeamSpeak in definierten Abständen eine Art Stand-Up-Meeting einberufen, damit alle auf den gleichen Stand sind und jeder weiß, was der andere macht. Auch Code-Reviews könnten z.B. per TeamViewer gehalten werden. Es liegt also nicht am RPG Maker, wenn zwei Entwickler sich auf den Füßen stehen, sondern an den Entwicklern selbst, da sie sich nicht koordinieren können.

Habe ich da einen falschen Eindruck oder wie seht ihr das? Gibt es da überhaupt einen Bedarf für reine Storywriter?

...

Das verlinkte Video von Pinguin mit Brille erklärt es schon ganz gut, was das eigentliche Problem ist.
Die Frage ist also eher: Kann das Team das umsetzen, damit das Produkt stimmig wird?
Ein gutes Spiel braucht keine gute Story. Die meisten Spiele, die sich wie blöde verkaufen haben eine strunzdumme Geschichte. Auch die Geschichten aktueller hochgelobten Indie-Spiele sind schnell erzählt. Es ist also mehr das Drumherum, was ein gutes Spiel ausmacht. Ein "Jungfrau in Nöten"-Rollenspiel mit Stereotypen würde sich sogar auch noch heute sehr gut verkaufen, wenn das Spiel dem "State of the Art" entspricht. Es ist also mehr die Präsentation der Geschichte, die das Spiel spielenswert macht und nicht die Geschichte selbst. Das ist auch der Grund, warum ich viele aktuelle Click'n'Point-Adventures eher nur mittelmäßig finde, obwohl sie von allen gefeiert werden. z.B. wirken Dialoge vielfach abgehackt, als hätten die Synchronsprecher nur Satz für Satz vorgelesen und jeder Satz wäre in einer separaten Audiodatei gespeichert, die der Entwickler diese dann hintereinander abspielt. Es ist oftmals kein flüssiges Reden und das macht die Stimmung kaputt. Als Positiv-Beispiel kann man sich ja mal die damalige iMuse-Engine von LucasArts anschauen (die hatten das führende i 16 Jahre vor dem iPhone eingeführt ), mit welchen liebevollen Details der Sound wiedergegeben wurde, so wird z.B. der Übergang von einem Musikstück zum nächsten dynamisch berechnet, sodass es sich wie ein kontinuierlicher Soundtrack anhört. Bei Monkey Island 2 wurde z.B. die Musik dramatischer, je näher man zum Grab von Largo's Großvater geht.

[Linkey]

Ist das nicht sogar das größte Problem? Man möchte ja eigentlich am Spiel arbeiten, wenn man Zeit und Lust hat, aber es könnte immer sein, dass gerade jemand anderes am Spiel arbeitet. Ich geh jetzt davon aus, dass der Entwickler, der am Spiel arbeitet, das Spiel nach "Feierabend" nicht sofort wieder auf die Dropbox schiebt. Das würde mir glaub ich schnell auf die Nerven gehen. Oder ich hab keine Ahnung, wie Dropbox funktioniert, die hat doch kein CVS-System, oder?

...

Das Projekt kann direkt aus dem DropBox-Ordner heraus geöffnet werden. Sobald du speicherst, sind die Daten aktualisiert und werden automatisch hochgeladen.
So arbeite ich - da ich mehrere Rechner benutze - auch immer ohne Probleme mit dem Maker.

Im Falle, dass man am unbedingt Projekt arbeiten möchte, während es einer verwendet, kann man dies auch machen. Einfach das Projekt als lokale Kopie auf den Rechner ziehen, dort arbeiten (wenn man bspw. Maps, Gegner, etc. erstellen möchte) und später, wenn das Projekt wieder auf der DropBox freigegeben ist, per Copy Paste die Änderungen einfügen (du kannst Maps, Datenbankeinträge wie Items, Gegner, etc. per Copy&Paste von einem Projekt ins andere einfügen).