4Players.de Das Spielemagazin. Kritisch. Ehrlich. Aktuell.
 
von Julian Dasgupta,

"Kickstarter-Zusatzziele sind Bullshit"

Spielkultur (Sonstiges) von 4Players
Spielkultur (Sonstiges) von 4Players - Bildquelle: 4Players
Es ist ein eingespieltes Ritual bei Kickstarter-Projekten: Kurz vor oder nach dem Erreichen des Mindestziels werden Zusatzziele ausgelobt. Über die so genannten Stretch-Goals wollen die Entwickler noch mal die Spendierfreudigkeit der bereits vorhandenen Unterstützer erhöhen und  natürlich noch weitere Leute dazu animieren, den Geldbeutel zu zücken.

Andy Schatz ist hingegen kein großer Fan des Konzepts und weiß, dass er mit seiner Meinung nicht unbedingt Beliebtheitspreise gewinnen wird bei den Kollegen: "Es freut mich wirklich, dass die Leute da wirklich erfolgreich waren auf Kickstarter, und versteht mich nicht falsch, ich finde die Idee ja wirklich gut, dass man einfach so an Geld kommen kann. Ich bin aber der Meinung, dass es sehr furchtbar ist, ein Spiel um ein variables Budget herum zu designen. Ehrlich gesagt glaub ich, dass Stretch-Goals totaler Bullshit sind."

Das sei vielleicht seine eigene, idealistische Weltsicht, aber sollte eben darüber nachdenken, was in das Spiel soll, und was man dafür benötigt. Das Erweitern über Zusatzziele sei weniger organisch.

Der Mann, der endlich Monaco fertiggestellt hat, merkt an, er berücksichtige den Input der Spieler in Beta-Tests. Wenn man das Design hingegen an bestimmte Budgetoptionen koppele, um noch mehr Zusagen zu bekommen, sei dies der "perfekte Weg zu einem Spiel, das entweder unvollständig oder überladen ist."

"Ich finde, du solltest entscheiden, ob das Spiel unvollständig ohne jene Features ist. Wenn dem Spiel ein Finger fehlt, dann füge einen hinzu. Wenn ihm keiner fehlt, dann füge keinen hinzu."

Es sei durchaus möglich, dass er eines Tages selbst Kickstarter bemühen wird. Er betrachte die Implikationen für das Spieldesign aber skeptisch.


Kommentare

Nightfire123456 schrieb am
dx1 hat geschrieben:
4utzz hat geschrieben:Ich versteh zum Beispiel nicht, wie man erklären kann, dass man mit 100.000 ? mehr ?
Und ich erinnere mich gerade in der Abteilung Spiele nicht an ein Stretch Goal, das 100.000 Euro (gibt's doch gar nicht bei KS)|USD|GBP über dem vorherigen Stretch Goal, bzw. als erstes Stretch Goal über dem Kampagnenziel liegt oder lag. Hilfst Du mir da bitte auf die Sprünge, damit ich interessantere Fragen als "Wie kommst Du von "to pledge" auf "Kunde sein"?" stellen kann?
Doch das gab es schon öfters, gerade wenn es um das porten auf anderen Plattformen geht. Allerdings normalerweise in $ was ja doch deutlich wenige als ? sind. Sind aber meist Strechtgoals die recht weit hinten angesiedelt sind, kann mich nicht errinern schon mal gesehen zu haben das es so ein hohen sprung schon mal genau nach dem Kampagnen Ziel gab.
Ob man jetzt spender oder Kunde ist kommt doch bei Kickstarter auf das gleiche raus, ob man jetzt ein Spiel als Kunde vorbestellt und die Ware dann zum release bekommt oder Geld im vorraus spendet um zum release das Game zu bekommen kommt ja am Ende auf das gleiche raus... :wink:
Zu erklären warum man 100.000$ braucht um statt einer Plattform 2,3,4 oder noch mehr zu bedienen ist doch ganz einfach: Es kostet Zeit und Zeit = Geld. Ausserdem denke ich darf man das alles nicht so eng sehen da die meisten Stretch Goals nur belangloses Zeugs bieten. Ist wie mit den minderwertigen Day One oder vorbesteller Dlc´s von EA. Da bekommt man meist auch nur kleinmist dazu aber es regt anscheinend viele Leute dazu an sich diesen Mist sofort zu besorgen.
Ich finde den vergleich mit Addons ganz passend. Früher haben die Entwickler auch nur das primär wichtige ins Spiel gepackt und Ideen die das Budget gesprengt hätten dann gesammelt in ein Addon gebracht. So seh ich das mit den Stretchgoals nur das hier halt schon im vorraus so abläuft
dx1 schrieb am
4utzz hat geschrieben:Ich versteh zum Beispiel nicht, wie man erklären kann, dass man mit 100.000 ? mehr ?
Und ich erinnere mich gerade in der Abteilung Spiele nicht an ein Stretch Goal, das 100.000 Euro (gibt's doch gar nicht bei KS)|USD|GBP über dem vorherigen Stretch Goal, bzw. als erstes Stretch Goal über dem Kampagnenziel liegt oder lag. Hilfst Du mir da bitte auf die Sprünge, damit ich interessantere Fragen als "Wie kommst Du von "to pledge" auf "Kunde sein"?" stellen kann?
muselgrusel schrieb am
v3to hat geschrieben:das kann man sicher nicht verallgemeinern. schon alleine, weil es auch immer vom projektstatus und der art der erweiterung abhängt. und vor allem vom vorhandenen personal (spreche da aus eigener erfahrung)...
Mhh, ich habe mich vielleicht etwas ungenau ausgedrückt. Generell schrieb ich von den Stretch-Goals als eine Art Zusatzoption während der Entwurfs- bzw. Implementierungsphase. Allerdings bin ich wie du auch auf den Projektstatus und die unterschiedlichen Arten der Erweiterung eingegangen, den Faktor Personal habe ich jedoch übersprungen, da gebe ich dir recht ;)
Diablokiller999 hat geschrieben:Oder um es kurz zu fassen, alles eine Frage des Software Engineerings
Kurz zusammengefasst, ja :D
FightingFurball hat geschrieben:Naja
KS ist normalerweise nicht mitten im Projekt verankert sondern in der Verhandlungs- und Vergabephase am Anfang. Es stimmt schon dass spätere Implementierung teurer ist als alles am Anfang festzulegen aber das ist nicht das Ziel von KS.
KS ist mehr oder weniger der Verhandlungstisch von Auftragnehmer und Auftragnehmer obwohl es so genau nicht zutrifft, da der Auftraggeber hier nicht mit einem spezifischen Projekt auftaucht, sondern als Investor agiert.
Normalerweise würde die AN-Seite eine Ausgestaltung vorstellen, welche sich an den Vorgaben der AG erfüllt in hinblick auf Budget- und Zeitvorgaben. Dagegen stellt sich die AG-Seite die vielleicht (meistens...) andere Vorstellung in Bezug auf Features und/oder Zeit hat...
Bei KS ist der Entwickler der Auftragnehmer und der Pledger der AG in abgewandelter Form. Hierbei erteilt nicht der AG den Auftrag sondern der AN schlägt einen Auftrag vor. Das Basisziel ist dabei der Erstvorschlag und die Stretchgoals sind Zusatzoptionen welche gelinde gesagt mehr Budget brauchen.

Wie schon an v3to geschrieben, bezog ich mich eher auf die Stretch-Goals als eine Art Zusatzoption während der Entwurfs- oder Implementierungsphase. Wenn man die Stretch-Goals während der Analyse- und/oder...
FightingFurball schrieb am
muselgrusel hat geschrieben:Ich bin ein wenig in der Materie drin, und weiß ungefähr wie die Planung für ein Softwareprojekt aussieht, welche Phasen es durchläuft etc. pp..
Vor diesem Hintergrund muss ich schon sehr lächeln, über welche Sachen hier diskutiert wird, oder wie sich teilweise Leute anscheinend den Entwicklungsprozess vorstellen ;)
Meiner Meinung nach fördern Stretch-Goals sicherlich nicht den Entwicklungsprozess und sind wohl relativ schwer in diesen zu implementieren. Ganz abgesehen vom "moralisch Korrekten" (DLC etc.pp.), oder künstlerischem Anspruch beim entwickeln des Entwurfs kann es die Entwicklung sicherlich negativ beeinflussen. Dabei kommt es natürlich auf die Art des Stretch-Goals an, denn ein Linux-Support ist relativ spät in der Entwicklungsphase schwer zu implementieren, währenddessen z.B. eine weitere Klasse auch noch später mit erheblich geringeren Kosten (in jeglichen Arten) hinzugefügt werden kann. Beachten sollte man auch, dass bei einem "klugen" Entwurf schon im Vorhinein Überlegungen getroffen wurden, die die Realisierung weiterer Features erleichtert. In solch einem Fall müssten die "technischen" Kritikpunkte natürlich geringer bewertet werden ;)
Bei weiteren Klassen, im Gegensatz zu z.B. einem Linux-Support, sind wir jedoch auf einer anderen Ebene, die z.B. das Spieldesign umfasst, und so auch weniger Einfluss auf die technische, als auf die "inhaltliche" Qualität hat. Ob ein zusätzliches "inhaltliches Features" die Qualität schmälert? Das kommt wohl auf den Grad der Einarbeitung in das Design und damit zusammenhängend den Zeitpunkt der Implementation (umso später umso schwerer wird wohl die Einarbeitung in das Gesamtkonzept) an. Natürlich kann hier der Entwurf schon weitere Features vorgesehen haben, die solch eine spätere Implementation erleichtern würden ;)
Alles in allem stimme ich dieser "einseitigen Sicht" nicht zu. Es kommt auf den Zeitpunkt der Implementation, die Voraussicht der Entwickler und vor allem das spezifische Feature...
Diablokiller999 schrieb am
muselgrusel hat geschrieben:Das kommt wohl auf den Grad der Einarbeitung in das Design und damit zusammenhängend den Zeitpunkt der Implementation (umso später umso schwerer wird wohl die Einarbeitung in das Gesamtkonzept) an. Natürlich kann hier der Entwurf schon weitere Features vorgesehen haben, die solch eine spätere Implementation erleichtern würden ;)
Oder um es kurz zu fassen, alles eine Frage des Software Engineerings :Hüpf:
schrieb am