Open RPG. Alle machen mit?

[Ascare]

@makenshi & Kelven
Das KS ist natürlich ein Grundgerüst des Spiels (falls das RPG überhaupt eins haben soll, es geht ja auch ohne). Es müsste natürlich schon technisch vorgemakert sein, so das Mitarbeiter Verbesserungen oder neue Features (Skills, Animationen etc.) hinzufügen können.
Und was technische Kram angeht ist natürlich klar das es pingelig genau dokumentiert bzw. kommentiert werden muss.

@Kelven
Zur Regie: Das wäre natürlich Aufgabe des Kernteams, wobei es wahrscheinlich nötig wäre das mit einer Person zu besetzen, was widerum den Nachteil hat das man vollends auf diese Person angewiesen ist und das wiederspricht dem Open RPG Konzept wo eigentlich jeder austauschbar bleiben soll um möglichst große Flexibilität und zugleich Produktivität zu haben.
Was natürlich vorstellbar ist das man nur für einen bestimmten Bereich einen Regisseur sucht. Mal angenommen es gibt eine Unterhaltung in einem Dorf. Der Regisseur bekommt schon das fertig gemappte Dorf, die NPCs stehen, die Dialoge stehen und er muss quasi mit dem gegebenen Material der Szene Leben einhauchen. D.h. Move Events der Charaktere machen, Pan Screens festlegen, Text Messages verwenden etc.
Sicherlich gibt es viele "Szenen" die einer Regie benötigen und da kann man immer wieder jemand neuen besetzen. Stichwort Produktivität. Und das Kernteam achtet dabei das alles miteinander auch harmoniert. Es könnte also daraus hinauslaufen das am Ende das Spiel von ka...20 Regisseuren bearbeitet wurde. So wie es bei Serien auch standard ist.

@Sgt.Pepper
Das geht dann doch zu sehr in Richtung MetroP. Man wäre auch bei dem Modell viel zu abhängig von den einzelnen Mitarbeitern und diese hätten auch zu sehr Entscheidungsfreiheit über das Projekt, am Ende kommt da ein spielerisch, erzählerisch völlig unterschiedlicher Brei dabei raus.

[Kelven]

MAn kann ja auch ein vorgefertigtes KS Script nehmen. Gibt da fast alles was man braucht. Side View,Front View, FF10 KS, STar Ocean KS etc.

...

Vorgefertigte Kampfsysteme sind was für Pussies. \o

@Ascare
Serien sind aber meistens episodisch, da stört es nicht so, wenn die Regisseure wechseln. Falls das Spiel aber zusammenhängend sein soll, wirkt es schon etwas komisch, wenn die eine Szene mit den tollsten Animationen glänzt und gut inszeniert wurde und die andere aus Standposen besteht. Wenn mehrere Leute direkt am Maker arbeiten, gibt es auch das Problem, dass man immer warten muss, bis der Vorgänger etwas abgeliefert hat (um sich daran zu orientieren). Es gibt halt kein CVS für den Maker.

[CapSeb]

Ich habe noch mal drüber nachgedacht.

Man sollte alle Chainelemente, also jede Form der episodischen Fortführung, komplett von vornherein ausschließen. So wäre es zB. denkbar diese Herangehensweise als Grundregel aufzunehmen.

Man könnte darüber hinaus allgemein Grundregeln festlegen, die ab einer bestimmten Reife des Spiels nicht geändert werden dürfen. Das jetzt schon zu 100% festzulegen, wäre zu hypotetisch.

- Kettenregel:

(1) Weist ein Spielelement, egal welches Gebiet es betrifft, ob Grafik, Story, Scripting, Feature oder Sound, eine kettenartige Entwicklung auf (dem Chaingame entsprechend) oder würde eine solche auslösen, das heißt notwendig machen, darf es nicht verwendet werden.

- Beitragsregel:

(1) Ein Teilnehmer, der einen abgeschlossenen Beitrag zum Spiel geliefert hat (siehe Kettenregel), ist nicht verpflichtet weitere Beiträge zu leisten.
(2) Jeder Beitrag wird gesondert und unabhängig vom Entwickler betrachtet und durchläuft erneut einer Qualitätsprüfung.

- Dokumentationsregel:

(1) Es muss ersichtlich sein, wie mit einem Beitrag umgegangen werden kann. Eine Dokumentation ist im Sinne der Aufwandminimierung nur in eingeschränkter Form nötig.
(2) Bei komplizierteren Fällen sind ausführlichere Dokumentationen erforderlich.
(3) Treten Komplikationen auf, wird der Beitrag nicht verwendet.
(4) Der Teilnehmer hat daraufhin die Möglichkeit den Beitrag zu überarbeiten, muss dies jedoch ausführlich dokumentieren, sodass an Hand der Dokumentation die zuvor vorhandenen Komplikationen vom Kernteam ausgeschlossen werden können.

- Füllregel:

(1) Zu jeder im Spiel vorhandenen Lücke wird ein bestimmter Qualitätsrichtwert vom Kernteam aufgestellt. Dieser bildet die untere Grenze. Aus allen, diese Grenze überschreitenden Beiträgen, wird der geeignetste vom Kernteam ausgewählt und implementiert.
(2) Im Sinne der Aufwandminimierung wird ein Beitrag nur ersetzt, wenn sich ein neuer Beitrag für diese Lücke eindeutig vom bisherigen abhebt und belegbare Verbesserungen aufweist.
(3) Das Füllen einer neuen Lücke hat Vorrang vor dem Ersetzen eines bereits geleisteten Beitrages.

...

Diese ersten Ideen sollten am besten nochmal überarbeitet werden. Vielleicht sollte man sich auch erst einmal fragen, ob solche Regeln notwendig sind. Zumindest weiß man dabei wo man dran ist.
Aber bisher haben wir ja noch kein Kernteam...


CapSeb

[Ascare]

@Kelven
Ich bin mir sicher das du den Wechsel eines Regisseurs nicht wahrnimmst. Warum? Weil alle Regisseure auf einem hohen Qualitätsniveau arbeiten bei der eben nicht auffällt wer nun gerade die Regie macht (gilt natürlich in erster Linie für Serien). Und die Qualität wird durch die Produktionsfirma gesichert aka Kernteam.^^
Und das mit dem Warten: Naja, es wartet niemand. Wer wartet denn worauf? Es gibt halt offene Arbeitsaufträge und der der sie als erstes mit einer entsprechenden Qualität abliefert kommt dann ins Projekt rein. Es kann sein das es dauert oder aber auch es geht so schnell das das Kernteam mit der Überprüfung gar nicht mehr nachkommt.

@CapSeb
Die Regeln klingen soweit in Ordnung, aber es gibt einfach das Problem das wir kein Modell haben an dem wir uns orientieren könnten. Hier gilt wohl die Devise: Probieren geht über studieren. D.h. eigentlich müssten man sich an so eine Art "Test RPG" als Massive Team Work überhaupt einmal ausprobieren. Ein kurzes, typisches Standardspiel ohne große Besonderheiten. Hier kann man erstmal Erfahrung sammeln, Probleme feststellen etc. und erst dann, wenn überhaupt, kann man sich an ein größeres Projekt ranwagen.

[lucien3]

Eine einfachere Variante eines solchen Projektes wäre einfach, wenn einer was anfängt, also die ersten spielminuten macht, der nächste macht weiter und übergibt es wieder dem nächsten usw. Dann wird auch die Story für alle ne Überraschung und das organisieren ist wesentlich einfacher.

[CapSeb]

@lucien3: Damit wären wir wieder bei Chaingames. Aber eines der Zieles ist es, genau das zu verhindern. Ein einheitliches Projekt statt vieler Schnipsel.

@Ascare: Ich finde die Idee eines kurzen Standardspiels doch schon einmal eine guten Anfang. Damit wäre auch die Hürde genommen, aus Angst vor der Größe garnichts zu machen.

Vielleicht wäre es als nächstes sinnvoll sich Gedanken zum Kernteam zu machen. Größe, Struktur, Grad der Festlegung und Anderes müssten geklärt oder zumindest Ideen dafür gesammelt werden.
Denn umso mehr hier geschrieben wird, desto deutlicher wird, was man sich unter dem Projekt vorstellen kann und sollte. Auch für die, die nur lesen. Der Post von Lucien zeigt z.B., dass der Non-Chaingame-Gedanke weiter verdeutlicht werden muss.


CapSeb

[lucien3]

Denn umso mehr hier geschrieben wird, desto deutlicher wird, was man sich unter dem Projekt vorstellen kann und sollte. Auch für die, die nur lesen. Der Post von Lucien zeigt z.B., dass der Non-Chaingame-Gedanke weiter verdeutlicht werden muss.

...

Wobei ich jetzt nicht alles durchgelesen hab, was in den letzten Tagen geschrieben wurde. Wollte nur den Gedanken loswerden und bin erst jetzt dazu gekommen.

Damit wären wir wieder bei Chaingames. Aber eines der Zieles ist es, genau das zu verhindern. Ein einheitliches Projekt statt vieler Schnipsel.

...

Gut, man könnte dennoch eine genauere Story planen und dann jedem einen Abschnitt zuweisen. Es könnten halt nicht alle gleichzeitig arbeiten.

Das Problem beim Non-Chaingame sehe ich einfach, dass es dann doch kein einheitliches Projekt wird, weil die einzelnen Teile nicht wirklich zusammenpassen. Wenn man jedoch das Spiel immer weiter bearbeitet, dann sieht man durch die Arbeit des Vorgängers, wie weitergemacht werden soll. Man kann es dann anpassen.
Ein Problem bei dieser Variante ist meiner meinung dann jedoch wieder, dass solch ein Projekt schnell ins lächerliche gezogen wird (s. unendliche Geschichte) und zu nem trashgame wird.

[Ascare]

@lucien3
Das Hauptproblem bei so einem Chaingame sehe ich eher in der Wartezeit. Jeder muss auf den anderen warten bis er fertig ist. Und wenn man der letzte in der Schlange war kann es sein das man über 1 Jahr gewartet hat bis man endlich zum Zug kommt und wer weiß vielleicht hat man bis dann kein Bock, keine Zeit.
Zudem muss man immer die Fehler geradebiegen die der/die letzen immer gerade hinterlassen haben. Keine Kontrolle, kein gar nichts, das wird nicht gut oder aufgrund der Warterei auch nicht produktiv.

@CapSeb
Meine Idee für das Kernteam wäre so das sie eher wie eine Art Jury besteht. Fachmännische Augen sozusagen. Sie wären bspw. 5 Personen die sich ein Grundgerüst ausdenken und evtl. dieses auch schon fertig makern, aber nur den Anfang. Das Projekt müsste dann so aufgebaut sein das theoretisch von jedem ein neuer Beitrag kommen kann der das Projekt zum wachsen bringt.
Natürlich müsste man je nach Projekt gewisse Ziele festlegen und je nachdem Stellen ausschreiben. Oder es gibt Leute die sich bewerben und etwas bestimmtes dem Projekt zufügen möchten und wenn es passt wirds vom Kernteam genehmigt.
Das Kernteam könnte wie eine Art Filter funktionieren. Der erste aus dem Kernteam erhält den neuen Beitrag zum Projekt, gibt nach der Überprüfung & Korrektur sein ok und sendet es an den zweiten. Der macht dasselbe und sendet es an den dritten usw. Wenn zB 4 von 5 dem neuen Beitrag zum Open RPG zustimmen wird es beim nächsten offiziellen Release erscheinen.
Oder Variante B, das Kernteam überprüft gleichzeitig den neuen Beitrag. Falls es in Ordnung ist gibt es wieder ein demokratisches ok, falls noch fehlerhaft, aber gut, dann wird es zum Autor zur Bearbeitung zurückgeschickt. Falls schlecht einfach abgelehnt. Vielleicht kommt man mit der Variante sogar schneller zum Ergebnis.

Zum Test RPG:
Ich stelle mir da wirklich was einfach vor, den hier steht das ausprobieren des Massive Team Works im Vordergrund. Grafisch/akkustisch/technisch wirklich reines RTP, einfach Story: Held geht in den Wald um Pilze für das Abendessen zu sammeln. Als er zurückkehrt liegt das Dorf in Schutt und Asche, Familie tot, Held schwört Rache. Bis hierhin stellt das Kernteam alles fertig und ab hier können die Mitarbeiter weitermachen. D.h. es können neue Dörfer, Dungeons, Quests usw. entstehen. Aber natürlich sollte auch das Ende schon festgelegt sein dies könnte evtl. wieder das Kernteam machen. Also wenn man so will Intro & Outro Kernteam und kompletter Mittelteil nur von Mitarbeitern.

[Kelven]

@Ascare
Dein Vorschlag zum Test-RPG ist aber nicht gerade motivationsfördernd. ^^" Gerade weil man theoretisch aus dem Vollen schöpfen könnte, sollte man doch lieber auf all die talentieren Grafiker, Komponisten, Scripter und Geschichtenerzähler zurückgreifen und kein 08/15-Spiel machen. Ich z.B. hätte nur dann Interesse mich in irgendeiner Weise zu beteiligen, wenn das Spiel etwas besonderes wäre.

(Und so eine Geschichte sollte man nicht mal zu Testzwecken benutzen.)

[makenshi]

@Ascare
Dein Vorschlag zum Test-RPG ist aber nicht gerade motivationsfördernd. ^^" Gerade weil man theoretisch aus dem Vollen schöpfen könnte, sollte man doch lieber auf all die talentieren Grafiker, Komponisten, Scripter und Geschichtenerzähler zurückgreifen und kein 08/15-Spiel machen. Ich z.B. hätte nur dann Interesse mich in irgendeiner Weise zu beteiligen, wenn das Spiel etwas besonderes wäre.

(Und so eine Geschichte sollte man nicht mal zu Testzwecken benutzen.)

...

Dito Kelven. Auch wenn ich sonst neben dem aktuellen Projekt nie auch nur einen Finger für etwas anderes rühre, wäre hierbei ein gewisser Anreiz da.

Allerdings nur bei entsprechendem Projekt. Sonst ist es irgendwo vergeudete Zeit.

[Ascare]

Verabscheut ihr das RTP und die Story so sehr, das ihr nicht mal zu Testzwecken, zum Ausprobieren des Massive Team Works, eigentlich nur um zu sehen ob das klappt und ob man sich an etwas größeres, aufwendigeres ranwagen kann, mitmachen würdet?

EDIT: Weil man muss es ja so sehen: Wenn man merkt das diese Teamarbeit nicht mal bei einem kleinen Projekt klappt, dann wird es bei einem größeren erst recht scheitern und das wäre dann vergeudete Zeit.

[Kelven]

Ja, ich verabscheue diese degenerierte Ansammlung von Grafikverbrechen zutiefst. Aber mal aus einer anderen Sicht gesehen: Was sollte man denn zum Projekt beitragen, wenn Grafik, Musik und Gameplay sowieso schon vorgegeben sind? Außerdem könnte man sich selbst bei so einem kleinen Projekt eine interessantere Geschichte einfallen lassen.

Aber egal, ich hätte schon Lust etwas zur Geschichte beizutragen (Grafik erübrigt sich ja), jedoch nicht als Mitglied des Kernteams, sondern als jemand, der dann auf der Vorgabe aufbaut.

[swordman]

Wäre es nicht auch gleichzeitig angebracht, dass sich ebenfalls eine Story mit mehrer Personen überlegt wird? Ich denke genau zu testen ob alles sich so einfach zusammenfügen lässt, sollte dieses "Test - Game" ausmachen (Story, Storytelling/Plot, Technik, etc.)

Im übrigen wäre ich auch dabei, ich finde die Idee ziemlich interessant, wollte mich aber etwas im Hintergrund halten. Was bis jetzt noch nicht genannt wurde ist der Vorteil, das Leute die anderen auch über gewisse Durststrecken "mitziehen". Nehmen wir an einer aus dem Kernteam hat persönlichen Stress (was wirklich immer vorkommen kann), so mit können seine Teamkollegen für kurze Zeit seinen Part übernehmen.


mfg swordman

[Suraki]

Ein solches Projekt eignet sich imo nicht, um eine gradlinige Story à la Velsarbor zu erzählen. Wenn mehrere Leute eine Story kreieren, dann brauchen sie auch die entsprechenden kreativen Freiheiten. Damals wäre das mein Vorschlag: Das Team einigt sich auf ein Setting (z.B. auf ein Königreich mit der gemeinsamen Hintergrundgeschichte etc.) und dann kann jeder Storywriter selber eine kleine Geschichte erfinden, die in den Gesamtkontext des Settings passt. Das hört sich jetzt im ersten Moment ziemlich wirr und unübersichtlich an, doch ich denke, es wäre eine gute Idee das Setting möglichst gut zu verbrauchen und von verschiedenen Aspekten zu beleuchten (z.B. wenn die Grundgeschichte um Alchemie geht, kann jeder Storywriter die Sache aus einer anderen Perspektive erleuchten). Schliesslich werden die einzelnen Fragmente zusammengesetzt und in eine Geschichte verwoben. Die einzelnen Geschichten werden auf unterschiedlichen Stationen der Heldenreise erlebt z.B. kann der Held nach einer Anfangsphase wie in VD sich frei in der Welt bewegen, wo er in den verschiedenen Orten die einzelnen kleinen Geschichten erleben kann (z.B wie geht ein bestimmtes Dorf mit dem Thema Tod und Alchemie um). Natürlich gibt es eine zusammenhängende Geschichte die die einzelnen Teile verbindet, aber wie es so in RPGs ist, muss nicht alles erforscht worden sein um den Obermotz herausfordern zu können.

Zusammenfassung: Es gibt ein gemeinsam entworfenes Setting zu dem jeder seine Interpretation hinzufügen kann in Form von Reiseettapen (Dörfer, Höhlen, Städte), die zu einer zusammenhängenden Geschichte verwoben werden.

[Lachsen]

Hm... Im Prinzip ist das wirklich mal nen interessante idee, aber man muss wirklich aufpassen, wie man das genau angeht.

Dem Ansatz von Suraki würde ich so weitgehend zustimmen.

Es ist wirklich keine gute Idee, etwas Großes und Zusammenhängendes im massiven Team zu entwickeln. Eine wirklich wichtige Eigenschaft von einem wirklich guten Spiel ist vor allem die Einheitlichkeit. Nichts ist schlimmer, als wenn das Spiel in sich selber widersprüchlich ist, aber genau das kann sehr schnell passieren wenn das Spiel durch eine Sammlung von Ideen duzender Leute entsteht.

Um ein wirklich erstklassiges RPG-Maker Spiel zu erstellen, muss alles durchgeplant und abgesprochen sein. Alle Aspekte von Hintergrundgeschichte über Charaktere bis hin zum Szenario müssen zusammenpassen. Der Grafikstil muss einheitlich sein, das Interface einheitlich, das Gameplay abgestimmt und feingeschliffen.

Es ist schwer, so etwas mit großen Teams zu organisieren, vor allem wenn es keine klare Rangordnung gibt. Sich demokratisch auf einen konkreten Inhalt zu einigen, halte ich persönlich schon fast für unmöglich.

Genau deshalb bin ich auch der Meinung, das ein vorgegebenes Grundszenario und Gameplaykonzept, zu dem die Leute in kleinen Teamprojekten abgekapselte Beiträge zu leisten können, die bessere Vorgehensweise ist.

Dennoch: Wenn man es komplett abgekapselt, wird das Ergebnis wieder mehr an ein Metropolis erinnern als sonst was. (nebenbei: Nichts gegen Metropolis, mir hat das Projekt wirklich gefallen)

Von daher würde ich vorschlagen, dass es neben den kleineren Team Projekten von Leute gibt, die sich um die übergreifende Qualitätskontrolle kümmern.
Qualitätskontrolle würde bedeuten:

• Starke Unstimmigkeiten zum Grundszenario finden und beheben (keine DBZ-artigen Übermenschen im realistisch angehauchten Mittelalter Szenario)
• Schwierigkeitsgrad ausbalancieren.
• Beta-Testen, Fehler melden, beheben etc.

Darüber hinaus wäre ich für eine weitgehend strikte Unterteilung, zwischen den einzelnen Teams und der Qualitätskontrollen Gruppe. Wenn jeder überall etwas machen kann, gerät das Projekt wahrscheinlich schnell durcheinander (nach dem Motto "Zuviele Köche verderben den Brei").

In dem Sinne ist es nämlich nicht nötig, dass jedes Team weiß, was jedes andere Team macht. Jedes Team kümmert sich um sein Projekt. Lediglich die Qualitätskontrolle Gruppe muss einen allgemeinen Überblickt behalten.

Und ganz wichtig für den Anfang: Plant das Szenario bitte nicht im weiten Rahmen mit allen Leuten, sondern mit einer begrenzten Auswahl an (sehr interessierten) Personen. Macht einen erste weitgehende vollständige Version vom Szenario und Hintergrundgeschichte fertig und stellt sie vor. Wenn es zu viele Beschwerden über die Grundlage gibt, überdenkt das ganze nochmal allerdings nicht im direkten Austausch mit der breiten Masse. Sammelt alle Kritikpunkte, zieht euch damit wieder zurück, macht ein neues Konzept und stellt es wieder vor.
Sobald dann etwas gefunden wurde, was weitgehend akzeptiert wird, NAGELT ES FEST und macht es zur Bedingung, dass die Leute, die an dem Projekt mitwirken, mit der Grundlage einverstanden sind, diese einhalten werden und nicht dazu drängen werden, sie zu überarbeiten oder sonst wie zu verbessern für die gesamte Laufzeit des Projektes.

Okay, das ist eventuell etwas extrem, aber ja: die Grundlage muss meiner Ansicht nach bombenfest sein, damit das Projekt etwas wird.

Ansonsten: Wenn mir die Grundlage gefällt, werde ich vielleicht die eine oder andere Sache beitragen.

Soviel von meiner Seite

C ya

Lachsen

EDIT: Ich glaube ich hätte mir erstmal den Thread richtig durchlesen sollen. Ich glaube die Idee am Anfang von einem Team, dass die Grundlage festlegt und der Rest, der durch Aufträge verteilt wird, hat an sich schon irgendwie etwas...

[Ascare]

@Suraki
Und da sind sie wieder! Die unersetzbaren Teammitglieder die sich auf einen bestimmten Bereich kümmern und die Kernkomponenten zusammenfassen. Ohne die gar nichts läuft und ohne die es nicht voran geht. Genau das wollte ich vermeiden. Ziel ist völlige Unabhängigkeit von Mitarbeitern, auch im Kernteam. Was man braucht sind mehr oder weniger fähige Leute, aber ersetzbar sollte jeder bleiben.

@Lachsen
Bezüglich Demokratie: Unterschätze nicht die Macht der Abstimmung! Das ist überhaupt der Grund warum wir eine Regierung haben.

Und zweitens ist vieles an Vorschlägen schon innerhalb des Threads gefallen, ja, aber ich möchte dennoch was dazu sagen. Eben damit es später keinen Brei gibt, sollten im Grunde nur Aufträge erteilt werden. Quasi kann sich jeder daran beteiligen und mitmachen. Alles Beiträge werden von dem Kernteam kontrolliert (vielleicht ist auch hier eine Aufteilung: Die die sich besser mit Scripting auskennen überprüfen die technischen Sachen und die Grafiker eher die optischen z.B.).

Aber mir ist noch was anderes eingefallen als ich dein Posting las:

Ich weiß gar nicht wie ich das erklären soll...uhh...ich nehm mal als Beispiel Velsarbor:
Stellt euch vor Velsarbor wäre eine VV und reines RTP. Wirklich alles, das ganze Spiel in einem Standardlook und -system (ok, schwer vorzustellen).
Und dieses Projekt dient dann als Open RPG Projekt und Ziel ist es nun dieses Projekt dermaßen aufzupolieren und zwar so wie es heute aussieht und sich spielen lässt. Also aus Alex wird Kento. Aus Brian Cibon. Aus SKS, das Sideview KS, aus dem Standardmenü, das jetzige Custom Menü, aus RTP Wald, der Terranigma Wald usw.
Es wäre sozusagen eine Art "Pimp my Game".

Warum diese Methode? Nun man hat eine Vollversion die an sich gut ist, jedoch durch den ganzen standardkram eben hätte besser sein können. Als Mitarbeiter kennt man das Spiel, man mag es. Es ist quasi wie eine alte Karre die man richtig aufmotzen könnte die dann viel besser wäre. Daher pimpen.

Es wäre eine Alternative zum Open RPG, aber ähnlich. Ich weiß nicht ob es ein schlechteres Konzept ist...die Idee ist noch zu Frisch im Hirn als das ich es wirklich beurteilen kann. Ich muss nochmal drüber schlafen.

[Kelven]

Das Problem ist nur, dass niemand von der Leitung austauschbar ist, denn diese Leute sind ja sozusagen die Motivationsstütze des ganzen Projektes. Ohne sie würde niemand was machen, Menschen sind von Natur aus faul. Und wenn die Leitung nun ständig durchwechselt, sind die Verantwortlichen ja anscheinend selber nicht motiviert. Ähnliches gilt für die Leute, die Ressourcen abliefern oder an der Story schreiben, denn man kann gute Leute nur durch gute Leute austauschen. Sonst hat man eine zu stark schwankende Qualität.

[swordman]

@Suraki & Lachsen: Finde ich an sich gut, so eine Idee. Allerdings sollte man sie
noch durch einige wirkliche Story - vorranbringende Spielorte ergänzen, die von
dem "Kernteam" fertig gestellt werden.

@Ascare: Hört sich gut an, aber ich denke in der Praxis würden die Mitarbeiter
verzweifeln.^^
Es gibt eigentlich nichts schlimmeres, als irgendwelche Dinge doppelt zu machen beim Maker, jedenfalls für mich. Wenn ich ein Spiel fertiggestellt hab, will ich es auch gern veröffentlichen. Obwohl mir der Aspekt des vorgefertigten Konzepts gefällt ...


mfg swordman

[Ascare]

Das Problem ist nur, dass niemand von der Leitung austauschbar ist, denn diese Leute sind ja sozusagen die Motivationsstütze des ganzen Projektes. Ohne sie würde niemand was machen, Menschen sind von Natur aus faul. Und wenn die Leitung nun ständig durchwechselt, sind die Verantwortlichen ja anscheinend selber nicht motiviert. Ähnliches gilt für die Leute, die Ressourcen abliefern oder an der Story schreiben, denn man kann gute Leute nur durch gute Leute austauschen. Sonst hat man eine zu stark schwankende Qualität.

...

Na was heißt ständig durchwechselt. Das Kernteam ist wie eine Art Jury. Nachdem das Grundgerüst steht haben sie eigentlich nur noch die Aufgabe der Kontrolle und Freigabe. Wenn bei einem Contest ein Jurymitglied durch jemand anderen ersetzt wird, lindert das doch trotzdem nicht deinen Spaß am Contest mitzumachen oder? Insbesondere wenn du weißt das Wechsel normal sind.
Und klares Ziel ist natürlich das nur gute Leute was zum Projekt beitragen, schlechte Leute werden aussortiert bzw. gar nicht erst angenommen. Und das sollte alles demokratisch funktionieren, damit das Projekt nicht unter der Hand eines fehlgeleiteten Teamleaders leidet.

[niR-kun]

ich würde nicht den RMXP benutzen, da er
KEINE FREEWARE oder OPENSOURCE ist.

Open - für mich sind das Programme oder Spiele die völlig
offen bzw. frei sind. Ich persönlich würde ein RM nehmen,
der unter GPL, LGPL oder eienr BSD-artigen Lizenz steht.

PS: Ich hab kein RMXP, und möchte ihn auch nicht nutzen ...
Gute alternativen sind rar oder noch in Entwicklungsphase.

PPS: Cool der PowerPatcher ...