Team-Projekte und ihre Tücken

Kann man Maker-Spiele im Team entwickeln? Natürlich, ist die kurze Antwort, denn es gibt ja Spiele, bei denen es funktioniert, aber die lange Antwort ist wie immer "Kommt darauf an". Den erfolgreichen Team-Projekten stehen ja x-mal so viele gescheiterte gegenüber, also muss die Schlussfolgerung, dass man sich im Team gut ergänzt und besser vorankommt, einen Haken haben. Dabei würde ich eigentlich gerne im Team arbeiten, nicht bei jedem Spiel, aber bei denen, die ich alleine nicht umgesetzt bekomme. Ich hab sogar erst darüber nachgedacht, einen Thread aufzumachen und zu fragen "Hat jemand Lust?", aber eine allgemeine Diskussion ist vielleicht besser. Ich selbst hab mit Team-Projekten nämlich keine guten Erfahrungen gemacht, weil aus allen nichts geworden ist. Ironischerweise war sogar mein erstes Maker-Projekt eines, das wir im Team machen wollten. Die meisten Projekte sind an der Lustlosigkeit der Teilnehmer gescheitert, ein Stück vielleicht auch daran, dass man gerade nicht schneller vorankam, sondern eher langsamer.

Man kann auf unterschiedliche Art zusammenarbeiten. Die Team-Mitglieder können alle "gleichberechtigt" sein. Über Handlung und Gameplay wird ausgiebig diskutiert, bis man auf einen Nenner kommt. Die Team-Mitglieder können aber auch nur einen Teil zum Spiel beitragen - Musik, bestimmte Grafiken usw. Die zweite Möglichkeit halte ich für viel erfolgversprechender, doch hier zeigt sich der angesprochene Haken. Die meisten aktiven Maker-Bastler aus unserer Community sehen sich nicht als Pixelgrafiker, Script-Schreiber oder Komponist, sondern als Spielentwickler - sie möchten natürlich die Fäden in der Hand behalten. Das Problem ist nur: Man kann nicht gleichzeitig am Maker arbeiten und wenn man zusammen eine Geschichte schreibt, dann klingt sie meistens auch so. Es ist also notwendig, die Aufgaben klar zu verteilen, ohne dass man damit gleich jeden zum Schweigen verdammt. Trotzdem sollte es immer nur die Aufgabe einer Person sein, das Spiel z. B. zu implementieren oder die Geschichte zu schreiben.

Obwohl es diese Schwierigkeiten gibt, finde ich den Gedanken aber nach wie vor interessant, ein Spiel zusammen zu entwickeln, weil man dadurch theoretisch mehr erreichen kann als alleine. Ich hätte z. B. Lust auf ein Tower-Defense-Spiel, bei dem ich mich aber nur mit pixelgenauen Bewegungen und Projektilen zufrieden geben würde. Auf ein Open-World-Spiel hätte ich auch immer noch Lust, nur ist dort der Aufwand selbst bei kleinen Dimensionen (man darf sich natürlich nicht übernehmen) gewaltig. Wobei ich nicht mal weiß, wie man bei so einem Spiel gut zusammenarbeiten könnte, ohne auf Hindernis Nr. 1 zu stoßen: Keine parallele Arbeit am Maker möglich.

Wie seht ihr das? Habt ihr Lust auf ein Team-Projekt? Habt ihr schon mal eines gemacht und ist etwas daraus geworden?

Ich schreibe dir atemlos lange und unglaublich geschwurbelte Dialoge für dein Tower-Defense-Spiel! :)

Zitat:

---

Zitat von Kelven

Wie seht ihr das? Habt ihr Lust auf ein Team-Projekt? Habt ihr schon mal eines gemacht und ist etwas daraus geworden?

---

Mein Spiel ist ein Team-Projekt. Die beiden Anderen sind auf Standby und helfen aus, wenn ich zB irgendeinen grafischen Effekt brauche, den ich alleine nicht hinbekomme, bzw. auch Hilfe bei den Animationen, Balancing, etc. Es sollte eine klare Struktur innerhalb geben, wer was und warum macht/nicht macht, dann dürfte die Arbeit generell gut klappen.

Langfristige Maker Teamprojekte halte ich für wenig sinnvoll.
Wenn alle an allem arbeiten wollen geht es kaum vernünftig, da man nur seriel arbeiten kann, spezialisiert man sich dagegen, so geht das Projekt unter, sobald ein Teammitglied abspringt.

Ein Pixelgenaues Towerdefense Spiel wäre auf XP oder VX eigentlich von den Grundmechanismen in wenigen Tagen umsetzbar, da wäre ein Teamprojekt vielleicht sogar machbar, must nur jemanden finden, der dir das Script schreibt, mit Platzhaltergrafiken, und die nötigen Grundlagen für eine Datenbank anlegt, so dass man Einheiten/Gebäude einfach hinzufügen kann.

Hm, mit den Teamprojekten ist das, wie du schon bemerkt hast, immer so ne Sache.
Natürlich sehen sich die meisten Makerer als Spieleentwickler, der am liebsten das ganze Projekt leiten würde (wie du es nennst, "alle Fäden in der Hand haben")
Das kann natürlich bei vielen Hobbygamedesignern nix werden, da es hier schnell zu Streit kommen kann. Das Beste ist, wenn man ein Team mit Leuten bildet, die man gut kennt und die über eine ausreichende Selbstrefelexion sowie Kompromiss- und Diskussionsbereitschaft
verfügen, im Forum über einen Thread willkürlich Leute zusammenzutrommeln halte ich persönlich demnach nicht für die beste Alternative, da du außerdem kein Bild von den Fähigkeiten deiner zukünftigen Teammitglieder hast.
Frag am besten mal bei einigen Leuten, bei denen du weißt, dass sie ihr Handwerk beherrschen, nach ob sie dir dies und das basteln/bereitstellen können, aber vorher solltest du dir im klaren sein, was du alles brauchst, damit du die Anfragen möglichst Zeitig abschicken kannst und deine Mitarbeiter auch "fristgerecht" liefern können. Das ist zumindest meine Auffassung von einer erfolgversprechenden Planung.

EDIT:
@Lihinel:
Genau wegen so Sachen vonwegen Abspringen sollte man sich zuverlässige Leute (also solche die man kennt und weiß, dass sie zuverlässig sind) suchen ;)
ine Gruppe voller Alleskönner halte ich jetzt nicht für das beste. Wenn einer ein- zwei Dinge gut kann, reicht das mMn

Zitat:

---

Zitat von Kelven

Wobei ich nicht mal weiß, wie man bei so einem Spiel gut zusammenarbeiten könnte, ohne auf Hindernis Nr. 1 zu stoßen: Keine parallele Arbeit am Maker möglich.

---

Nun hast du blöderweise die Antwort schon selbst gegeben: "Kommt drauf an" - also kann ich jetzt keinen gut abgehangenen Zeilenfüller anbringen, sondern muss etwas Konkretes schreiben.
Ich mache aktuell sehr gute Erfahrungen mit der Kooperation. The_Attidude komponiert die komplette Musik für "Wolfenhain" und sowohl das Ergebnis als auch die Art der Zusammenarbeit hat es mir sehr einfach gemacht, diesen Teil aus der Hand zu geben. Organisatorisch ist der musikalische Belang vermutlich noch mit am einfachsten zu handhaben, da man sich mit Platzhaltern behelfen kann und sich nicht gegenseitig mit Drängeleien nerven muss. Wenn man zusätzlich eine gemeinsame Wellenlänge findet und seine Aufgeschlossenheit gegenüber unerwarteten Ideen nicht bloß behauptet, kitzelt das noch zusätzliche Kreativität aus beiden Beteiligten.
Ich habe meine Wünsche möglichst aussagekräftig zu formulieren versucht (nicht ganz leicht bei Musik), meine ursprünglichen Vorstellungen jedoch oft wegen eines besseren Vorschlages fallen gelassen und die schließlich ausgearbeitete Version der Hintergrundmusik gab mir wiederholt neue Gedanken ein. Für mich hat diese Form gerade deswegen gut funktioniert, weil es keinen feststehenden Detailplan abzuarbeiten galt, wir vielmehr aufeinander eingehen und Einfälle selbst in späten Projektstadien willkommen blieben. Ob die Freude beiderseitig vorherrscht, müsste natürlich The_Attidude sagen. ;)
Für Kooperationen gerade in der Makertechnik wäre so ein Vorgehen natürlich ein Graus. Aber es gibt eben auch andere Bereiche, wie beispielsweise den hier genannten, in denen eine Zusammenarbeit lohnen kann.

Bei der Dimension meiner Ansprüche habe ich kaum eine andere Möglichkeit als ein Team-Projekt zu erstellen.
Ich könnte natürlich auch meine Ansprüche runter schrauben, aber man kann sich leicht vorstellen wie wahrscheinlich es ist soetwas langfristig durch zu ziehen.

Team-Projekte die bei 0 Anfangen und dann mit einem brainstorming beginnen, halte ich nur unter einer bedingung für lebensfähig: Die Teammitglieder sind (eng!) befreundet und kennen sich allesamt schon lange persönlich.

Die typischen Web-Aufrufe "Hey, ich will ein Spiel entwickeln und suche dafür noch Drehbuchschreiber, Mapper und Komponisten!!!222212" sind hingegen meistens einfach nur virtuelle Sammelbecken für leute, die zwar viele Ideen haben die sie umsetzen wollen, denen es aber an Engagement mangelt, die Umsetzung auch tatsächlich durchzuziehen. Also erhoffen sich 99% der Mitglieder von Internet-Teams von einer Projektarbeit letztlich - wenn auch oft unbewust - den Rest der Teilnehmer irgendwie von der Überlegenheit ihrer Ideen überzeugen zu können und so zu realisieren, dass ein vollständiges Team schlussendlich ihr Spiel entwickelt. Sobald sie merken, das der Hase anders läuft, und die anderen teammitglieder die Überlegenheit ihrer ideen einfach nicht anerkennen wollen, gibt es dann Probleme mit der Motivation, die schließlich dazu führt, dass nach und nach alle Teilnehmer das Interesse verlieren.

Ich suche ja im Augenblick selber Leute, die mich bei Three moons unterstützen. Das finden von Hilfe ist in diesem Fall - fortgeschrittenes projekt - natürlich schwerer, weil nur die leute als Unterstützer in Frage kommen, die Makern können und denen Three moons gefällt. Alle leute, die zwar makern können, die Three moons jedoch nicht mögen, scheiden von vornherein aus, weil sie nicht helfen wollen. Sollte eine zusammenarbeit unter diesen bedingungen allerdings zustande kommen, schätze ich die Chance auf eine erfolgreiche kooperation bedeutend höher ein, weil die Erwartungen der Teilnehmer dichter beieinander liegen, als bei einem projekt, das bei Null anfängt, und wo es oft schon erste Streitigkeiten darüber gibt, ob es nun ein Sci-Fi oder ein fantasy Setting werden soll.

Zitat:

---

Zitat von Kelven

Die meisten Projekte sind an der Lustlosigkeit der Teilnehmer gescheitert, ein Stück vielleicht auch daran, dass man gerade nicht schneller vorankam, sondern eher langsamer.

---

This. Lustlosigkeit ist schon bei den ganzen Einmann Projekten ein großes Problem. Wenn dann einer im Team die Lust verliert fällt im schlimmste Falle halt mal eben der Mapper komplett weg. Oder der Grafiker. Oder der Techniker. Ja, was dann? Neuen Suchen? Einfach pausieren und auf Besserungen hoffen? Hat Person X wieder Lust, wie siehts denn dann mit dem Rest aus? Wollen die überhaupt noch?

Ich selber hab bereits an einigen Teamprojekten gearbeitet. Mehrere zusammen mit Phno (aus denen wohlgemerkt nie was wurde - sei es wegen besagtem Motivationsmangel oder weil die Projekte schlichtweg nicht mehr exisiteren (Söldner! ;______; )) und dann eines, das man durchaus als Erfolg verbuchen kann:

Phoenix Wright - Hidden Traces

Bei den Spielen mit Phno hat jeder so für sich irgendwas gemacht. Klar, wir hatten ne Aufgabenverteilung (sind z.B. gemeinsam die Story durchgegangen und haben gesagt, einer mappt die Stadt, wer anders mappt in der Zeit nen Dungeon etc), verglichen mit Hidden Traces, wo es eine ganz klare Aufgabentrennung gab (Story = Ich, wobei sich das nur auf die genauen Dialoge bezieht, die Canas aber nach belieben noch erweitern und abändern konnte; Grafik und Technik und das spätere Umsetzen der Story im Maker hat dann Canas selber gemacht; später kam noch MagicMaker für einige Grafiken dazu, aber das war afair erst nachdem unser zweiter und bis dato letzter Fall released war), war das aber nicht sonderlich strikt.

Teamprojekte können funktionieren, wenn man weiß, was man will und sich auf die Personen verlassen kann. Und besagte Lustlosigkeit nicht eintritt. Und das ist wohl das größte Problem an der Sache.

@Daen
Dann bestehe ich aber auf gesprochene Dialoge. ;)

@real Troll
Ja, die Musik ist einer der Spielbestandteile, die sich jederzeit einfügen lassen und damit wirklich parallel gemacht werden können. Schwieriger wird es schon bei der Grafik, denn man kann ja nicht alles durch Platzhalter ersetzen. Die Implementierung würde erst recht im Chaos enden, wenn zwei oder mehr Personen gleichzeitig an den Karten arbeiten.

@caesa_andy
Neben den genannten Anforderungen müsste ein Helfer bei dir auch Spaß an den - ich sage mal - unliebsamen Aufgaben haben. Das stelle ich mir wirklich sehr schwierig vor jemanden zu finden, der dazu Lust hat. Aber vielleicht sehe das nur ich so, dass die Aufgaben unliebsam sind.

Zitat:

---

Zitat von Kelven

@caesa_andy
Neben den genannten Anforderungen müsste ein Helfer bei dir auch Spaß an den - ich sage mal - unliebsamen Aufgaben haben. Das stelle ich mir wirklich sehr schwierig vor jemanden zu finden, der dazu Lust hat. Aber vielleicht sehe das nur ich so, dass die Aufgaben unliebsam sind.

---

Was genau fällt bei dir denn da drunter?

Auf jeden Fall nicht alles, aber Testen und Balancing zum Beispiel. Das sind für mich eher Pflichtaufgaben.

Balancing finde ich persönlich nicht weiter tragisch und das testen kann man sich durch ein paar Tricks auch stark vereinfachen. Aber ja, es stimmt natürlich, dass auch diese Aufgaben gemacht werden müssen und grade bei einem umfangreicheren Spiel auch sehr zeitaufwändig sein können. Aber wenn jemand ein eigenes Spiel für sich selbst erstellt, müsste er das ganze auch selber machen, oder?

"Ich suche mir einen partner, damit der das macht, das ich nicht machen will" erscheint mir jedenfalls keine optimale basis für eine teamarbeit zu sein. ;)

Ich kann mich als Entwickler schlichtweg nicht auf Externe tester verlassen. Ich kann einen beta-test aus der Traufe heben, nachdem das Spiel lauffähig ist. Aber ich kann keinen extra tester einstellen, der mir jede halbe stunde mailt, das eine Cutczene nicht funktioniert, weil ein NPC gegen eine mauer läuft. Wenn ich meine eigenen Cutszenes teste, kriege ich schon schüttelkrämpfe, was für Mist-Bugs ich da manchmal einbaue. Irgend ein armer Tester würde da vermutlich Schreikrämpfe kriegen ... ne, durch die Alpha muss ich als Entwickler schon selber durch. ;)

Gleiches gilt natürlich auch für das balancing. Ich kann niemanden für das balancing einteilen, der den Boss anschließend so balanced, das er zu leicht ist, weil er selber nicht verstanden hat, wie die taktik des bosses eigentlich funktioniert. Solche Dinge weiß nur ich. Und erst wenn ICH weiß, das etwas funktioniert, DANN kann ich andere daran setzen. Und das ist auch bei teamarbeiten nicht anders. Wenn einer von zwei Kumpanen einen bosskampf designed, muss er den selber balancen und kann das nicht den anderen machen lassen.

Ich dachte du suchst jemanden, der sich auch ums Testen und Ausbalancieren kümmert (natürlich nicht alleine). Dein Posting klingt aber wiederum so, als ob du es doch nicht aus der Hand geben möchtest. Aber mal unabhängig davon gibt es beim Entwickeln Tätigkeiten, die macht man lieber als andere. Das was man gerne macht, würde man vielleicht auch für fremde Spiele machen, das andere aber eher weniger und es ist sicher schwieriger, jemanden für die "unbeliebten" Aufgaben zu finden.

Zitat:

---

Zitat von Kelven

Wobei ich nicht mal weiß, wie man bei so einem Spiel gut zusammenarbeiten könnte, ohne auf Hindernis Nr. 1 zu stoßen: Keine parallele Arbeit am Maker möglich.

---

Nun, das Datenformat moderner Maker ist relativ simpel. Es wäre sicher kein größeres Problem eine externe Versionsverwaltung zu schreiben welche zumindest grundlegendes mergen ermöglicht. Der Aufwand lohnt sich aber eher weniger weil eben kein Bedarf dran besteht.

-------------------------------------------------------------

Ich würde fast behaupten für Teamprojekte unterschätzen viele Leute worauf sie sich da eigentlich einlassen. Ein Top-Spiel benötigt mehrere Jahre Entwicklung und ist nicht eben in 2 - 3 Monaten gebaut. Wer aber keine Erfahrung mit Spieleentwicklung, Programmierung oder ähnlich gelagerten Themenfeldern hat wird sich da mit Sicherheit ordentlich verschätzen.

Dazu kommt die generelle menschliche Eigenschaft der "Teamfähigkeit". Wird in fast jedem Beruf gefordert und ich behaupte stumpf das nicht mal die Hälfte aller Leute die sich als "teamfähig" bezeichnen dies auch wirklich sind. Denn dazu gehört in erster Linie Kompromissbereitschaft oder die Fähigkeit mit "echten" Argumenten überzeugen zu können (z.B. mathematischen bei Streitigkeiten um das Balancing) und eben auch Nachgeben wenn man überstimmt wird oder nachgewiesen im Unrecht ist.

Diese Probleme gibt es aber in jeder Branche, das ist keineswegs RPG Maker spezifisch.

Vielleicht tritt es hier nur deutlicher auf weil die Community einfach kleiner ist, oder der Maker eben für "nicht Programmierer" gebaut wurde. Es ist für den einzelnen einfach leichter sich vom Team wieder abzukapseln weil die praxisbezogenen Abhängigkeiten nicht so deutlich sind wie in anderen Bereichen. Anders herum wird es für ein Team schwieriger Ersatz zu finden, nicht weil schon viele Dinge festgeschrieben sind (siehe die Suche von caesa_andy), sondern viel mehr weil ein technisch überzeugendes Spiel auch mit Durchschnittsgrafik ankommen kann, oder ein grafisch sehr hochwertiges Spiel keine absolut ausgefeilte Technik braucht und somit keine Teamabhängigkeit besteht. Im Gegenteil: Gute Ressourcen gibt es zu Hauf im Netz, genau so wie gute Scripte. Wozu brauch ich einen Programmierer wenn ich mir diverse KS/Menü Modifikationen aus dem Netz laden, per Plug&Play installieren, und nur noch konfigurieren kann? Wozu brauch ich einen Grafiker wenn ich mir, ggf. auch kostenpflichtig, Tonnen an Chipsets/Charsets besorgen kann? Die Fähigkeit zum Zusammenschnippeln und Umfärben genügt.

Das sind dann zwar Spiele maximal am oberen Durchschnitt, aber es ist möglich, und das reicht vielen schon. Die Perlen enstehen dann wenn es jemand schafft ein funktionierendes Team aufzubauen, oder eben die verschiedenen Fähigkeiten alle in sich selbst vereinen kann (Mal ehrlich, wie viele Leute hier können alleine zeichnen, programmieren und komponieren auf höherem Niveau?).

Lange Rede kurzer Sinn: Selbstüberschätzung, Aufwandsunterschätzung und fehlende Notwendigkeit zur Teambildung um akzeptable Resultate zu erzielen sind für mich persönlich die Hauptgründe warum so viele Teamprojekte scheitern.

Zitat:

---

Zitat von Kelven

Kann man Maker-Spiele im Team entwickeln?

---

Die Frage beschäftigt mich gerade ganz konkret. Mein eigenes Projekt (das ich hier auch mal vorstellen muss...) läuft jetzt schon seit 6 Jahren (ich entwickle bisher allein). Und trotzdem hab ich grade mal die Hälfte vom ersten Kapitel fertig (von geplanten 8 ). Da stellt sich für mich die Frage - geht es überhaupt ohne Teamarbeit, wenn ich mal zu einem Ergebnis kommen will?

Das Problem ist, dass meine Erfahrungen mit Maker und Teamarbeit nicht so toll sind. Wir haben mal zu sechst ein Projekt angefangen. Jeder hatte einen Charakter erfunden und sollte erst mal den ersten Teil makern, wo der Charakter vorkommt. Und beim mergen fangen dann die großen Probleme an. Man darf ja zum Beispiel nicht dieselben Switches verwenden, sonst wird das mergen zur Qual. Selbe Dateinamen von Ressourcen sollten auch nicht vorkommen etc. Ich hab keine Ahnung, wie man das in den Griff kriegen soll. Vielleicht war's ja auch der falsche Ansatz, dass alle alles machen können. Das Projekt ist jedenfalls nicht über die Planungsphase hinausgekommen.

Ne andere Möglichkeit - wie schon einige erwähnten - ist Arbeitsteilung nach Grafiken, Musik, Story etc. die ja offenbar bei einigen funktioniert. Andererseits ist es den Kommentaren oben nach wohl nicht damit getan, einfach nen Thread zu erstellen, wo man jemanden für den entsprechenden Teil der Arbeit sucht. Wie baut man denn ein funktionierendes Team auf? Habt ihr damit Erfahrungen?

Grüße, StorMeye

Zitat:

---

Zitat von Kelven

Ich dachte du suchst jemanden, der sich auch ums Testen und Ausbalancieren kümmert (natürlich nicht alleine). Dein Posting klingt aber wiederum so, als ob du es doch nicht aus der Hand geben möchtest. Aber mal unabhängig davon gibt es beim Entwickeln Tätigkeiten, die macht man lieber als andere. Das was man gerne macht, würde man vielleicht auch für fremde Spiele machen, das andere aber eher weniger und es ist sicher schwieriger, jemanden für die "unbeliebten" Aufgaben zu finden.

---

Ach so meinst du das. Da sag ich mal "Sowohl als auch". Für mich ist es natürlich klar, das ich meine erstellten Inhalte selber auf beta-Status teste und Balance. Ich erwarte allerdings auch, dass mein hypothetischer kumpane das ebendso macht. D.H. ich werde bei ihm nicht den Rotstifft ansetzen, und er bei mir nicht. Erst nachdem die einzelnen Projektbestandteile Beta-Status haben, wird getauscht und gegenkontrolliert. Dafür findet im Vorfeld eine Absprache statt, wie etwas auszusehen hat.

Zitat:

---

Zitat von Caine Luveno

Nun, das Datenformat moderner Maker ist relativ simpel. Es wäre sicher kein größeres Problem eine externe Versionsverwaltung zu schreiben welche zumindest grundlegendes mergen ermöglicht. Der Aufwand lohnt sich aber eher weniger weil eben kein Bedarf dran besteht.

---

Ich sehe das problem nicht. Bei allen maker-Versionen ist es möglich Maps und alle Datenbankeinträge einfach per Copy&Paste von einer Instanz des makers in eine andere zu kopieren. Ich öffne einfach beide Projekte simultan, markiere den eintrag den ich übertragen will, drücke STRG + C, gehe in das zielprojekt, suche dort die Zielstelle und drücke STRG+V. ich glaube sogar, das der "Multi Copy" befehl aus dem Maker für Items oder Armors funktioniert.
Dafür brauche ich kein Script und der Maker passt dabei dann sogar die jeweiligen ID's automatisch korrekt an. Das einzige, was nach einer zusammenführung manuell überarbeitet werden müsste, sind event-Zugriffe auf andere Maps (z.B. ein Player Transfer zu einer anderen map.).

-------------------------------------------------------------

Zitat:

---

Ich würde fast behaupten für Teamprojekte unterschätzen viele Leute worauf sie sich da eigentlich einlassen. Ein Top-Spiel benötigt mehrere Jahre Entwicklung und ist nicht eben in 2 - 3 Monaten gebaut. Wer aber keine Erfahrung mit Spieleentwicklung, Programmierung oder ähnlich gelagerten Themenfeldern hat wird sich da mit Sicherheit ordentlich verschätzen.

---

Das Problem ist aber nicht makertypisch, sondern "Menschentypisch" und tritt überall im leben auf. Das man leute, die von etwas keine Ahnung haben, immer mit Vorsicht genießen sollte, weil sie dazu neigen, sich zu übernehmen, ist schon immer so gewesen. Und beim makern kann man gottlob oft schon an der Art und weise, wie ein Gruppengesuch oder eine Projektvorstellung geschrieben ist, erkennen, wie erfahren der andere ist.

Zitat:

---

Dazu kommt die generelle menschliche Eigenschaft der "Teamfähigkeit". Wird in fast jedem Beruf gefordert und ich behaupte stumpf das nicht mal die Hälfte aller Leute die sich als "teamfähig" bezeichnen dies auch wirklich sind. Denn dazu gehört in erster Linie Kompromissbereitschaft oder die Fähigkeit mit "echten" Argumenten überzeugen zu können (z.B. mathematischen bei Streitigkeiten um das Balancing) und eben auch Nachgeben wenn man überstimmt wird oder nachgewiesen im Unrecht ist.

---

Leute, auf die das zutrifft, sollten - grade im Fortgeschrittenen (Berufs-)Alter - dringend eine Psychotherapeuten aufsuchen. Das ist nicht beleidigend gemeint, aber das das massive Festhalten an eigenen Ideen und die Unfähigkeit, Ideen anderer als gut anzuerkennen, sind Symptome die auf ein sehr, sehr schwaches Selbstwertgefühl hinweisen. Solche leute suchen im regelfall eine bestätigung ihrer person durch ihre leistung.
Bleibt diese bestätigung jedoch aus, reagieren sie, indem sie die leistung ander herrabsetzen und sich selbst damit trotzdem übder diese stellen. Menschen mit einem sauber ausgeprägten Selbstwert, die genau wissen, was sie können und wohin sie gehören sind in der Überzahl sehr gut teamfähig, da sie auch in der lage sind, anzuerkennen, wenn jemand anderes einfach eine bessere Arbeit liefert als sie.
"Der mensch" ist per definitionsehr gut teamfähig, da wir herden oder Rudeltiere sind.

Wobei ich dir allerdings zustimmen muss, ist die Sache mit den Kompromissen. Mich erschreckt es immer wieder zu sehen, wie Leute dazu neigen, faule Kompromisse zu schließen, bei denen keiner irgendwas bekommt, als dem gegenüber auch mal was zu gönnen. Ich persönlich neige dazu, kompromisse auf Basis eines Gleichgewichts zu schließen (Du hast Arbeit A vorgeschlagen, ich Arbeit B, also machen wir heute A und nächste Woche B). Die meisten anderen leute, die ich kenne, versuchen kompromisse zu schließen, indem beide auf ihre Perspektive verzichten (Du willst Arbeit A machen, ich Arbeit B, also machen wir heute Arbeit C.)
Ich finde so etwas fürchterlich, aber auch das hängt mit dem auf-sich-selbst projezierten Wert ab.

Zitat:

---

Das sind dann zwar Spiele maximal am oberen Durchschnitt, aber es ist möglich, und das reicht vielen schon. Die Perlen enstehen dann wenn es jemand schafft ein funktionierendes Team aufzubauen, oder eben die verschiedenen Fähigkeiten alle in sich selbst vereinen kann (Mal ehrlich, wie viele Leute hier können alleine zeichnen, programmieren und komponieren auf höherem Niveau?).

---

Nichts für ungut, aber hier muss ich klar wiedersprechen.
Der maker ist weder graphisch noch technisch eine Hochleistungs-Engine. Das nieveau auf dem wir uns bewegen, konkuriert bestenfalls mit dem des Supernintendo vor 20 Jahren. Graphisch ist damit kein Blumentopf zu holen. Noch dazu wo es ohnehin kaum Pixler gibt, deren Fähigkeiten auch nur annähernd mit dem RTP mithalten können.
Die Aussage, das ein Spiel, das nur auf frei verfügbare Ressourcen setzt, bestenfalls oberer durchschnitt werden wird, ist unter diesen gesichtspunkten Blödsinn. Zum einen sehen die ressourcen von Enterbrain und Co. erheblich besser aus, als das, was viele leute selber zustande bringen, und zum anderen werden wir mit unserer 2D-Pixelmatsche sowie so keine Begeisterungsstürme auslösen. Das beste, auf was wir hoffen können, ist, dass das Spiel dem Spieler Spaß macht. Und das kann es mit M&B genau so, wie mit eigenen grafiken.

@StorMeye
Du solltest zunächst Werbung für dein Spiel machen, am besten durch eine Demo. Vielleicht melden sich dann schon ein paar Interessenten. Am geeignesten sind aber denke ich gute Bekannte und Freunde, weil man sich auf die am meisten verlassen kann.

@caesa_andy
Man kann Maps kopieren, aber dazu müssten alle, die an ihnen arbeiten, den gleichen Maptree benutzen. Legen Person A und Person B neue Maps an, können ja zwei Maps die gleiche ID besitzen. Man kann zwar auch das im Voraus planen, aber es gibt immer mal Situationen, in denen doch noch eine weitere Map benötigt wird usw. Wenn nur einer das Spiel implementiert, sinkt denke ich der Verwaltungsaufwand. Die Konzeption von Dungeons kann man aber wohl schon auslagern.

Zitat:

---

Das ist nicht beleidigend gemeint, aber das das massive Festhalten an eigenen Ideen und die Unfähigkeit, Ideen anderer als gut anzuerkennen, sind Symptome die auf ein sehr, sehr schwaches Selbstwertgefühl hinweisen.

---

Das siehst du glaube ich zu eng. Die meisten Menschen sind nur eingeschränkt dazu bereit, ihre eigenen Ideen und Vorstellungen zurückzuschieben oder andere Ideen ohne Murren zu akzeptieren. Natürlich kann ich nur von dem ausgehen, was ich bisher im Leben erlebt hab, sei es außerhalb und innerhalb des Internets, aber für eine erste Studie reicht mir das schon aus. ;) Du solltest also nicht zu hart mit den anderen ins Gericht gehen, wobei eine physische Störung auch kein Persönlichkeitsmakel, sondern eine Krankheit ist.

Zitat:

---

Das nieveau auf dem wir uns bewegen, konkuriert bestenfalls mit dem des Supernintendo vor 20 Jahren. Graphisch ist damit kein Blumentopf zu holen. Noch dazu wo es ohnehin kaum Pixler gibt, deren Fähigkeiten auch nur annähernd mit dem RTP mithalten können.

---

Verglichen mit kommerziellen 2D-Spielen sind die Grafiken der Maker-Spiele sehr einfach gehalten, das stimmt. Innerhalb der Maker-Szene gibt es aber schon einen großen grafischen Wettkampf. Tendenziell machen Spiele, die "besser" aussehen, auch einen "besseren" Eindruck. Ob sie dann spielerisch oder erzählerisch überzeugen ist wieder eine andere Frage, aber zunächst zählt der optische Eindruck.

Das kommt darauf an, welches RTP du meinst. Die von 2K und 2K3 kann ein versierter Pixelkünstler sicher übertreffen und das vom XP wird von einigen Pixlern wegen handwerklicher Mängel kritisiert. Die RTPs von VX und Ace sind wiederum gar nicht gepixelt, soweit ich als Laie das beurteilen kann. Ich hab eher den Eindruck, dass die Grafiken so wie z. B. auch die Theodore-Sets "gezeichnet" wurden. Deswegen kann man die RTP-Grafiken nicht direkt mit Pixel-Grafik vergleichen. Man kann sie natürlich schöner finden, aber handwerklich gibt es da schon Unterschiede. Viele Pixler wollen gar nicht so zeichnen.

Zitat:

---

Zitat von StorMeye

Und beim mergen fangen dann die großen Probleme an. Man darf ja zum Beispiel nicht dieselben Switches verwenden, sonst wird das mergen zur Qual. Selbe Dateinamen von Ressourcen sollten auch nicht vorkommen etc. Ich hab keine Ahnung, wie man das in den Griff kriegen soll.

---

Vor einiger Zeit bauten diverse Mitglieder des Ateliers ein Forumprojekt und lösten das Problem durch Vorbereitung und Planung. Teilnehmer meldeten sich an und erhielten noch vor dem Startschuss ihre Variablen und Switches zugeteilt (so in der Art: Nr. 1-200 an Hinz, Nr. 201-400 an Kunz) , mit denen sie ihre jeweiligen Abschnitte ganz nach Laune verwirklichen konnten. Das reduzierte die technischen Schwierigkeiten beim finalen Zusammenbau.

Für mich gibt es da eine ganz einfache Formel zu. Alle Teammitglieder, bzw. die meisten, müssen gleichermaßen am Projekt interessiert sein UND es muss einen Teamleiter geben, der alles koordiniert. Das trifft auch nicht nur auf Makerprojekte zu, sondern generell auf Teamarbeit.
Ich hatte jetzt schon mehrere Makerteams und da konnte man das sehr gut beobachten. Bei den RPG-Freakz funktionierte es lange Zeit sehr gut, weil alle motiviert und gleichermaßen daran interessiert waren, die Projekte voranzubringen. Grund dafür war, dass alle von Anfang an befreundet waren. Ging dann leider mit dem steigenden Alter auseinander, da wir alle nicht mehr soviel Kontakt zueinander haben.
Ein anderes Projekt von mir ging in die Hose, weil der Projektleiter und Initiator des Ganzen scheinbar kein Interesse mehr daran hat. Schade, wie ich finde, weil ich mir bereits eine komplett eigene Welt ausgedacht habe und die Story schon sehr weit ausgearbeitet ist. Wird wohl nie eine Umsetzung finden das Projekt. :(

Zitat:

---

Zitat von Kelven

Das siehst du glaube ich zu eng. Die meisten Menschen sind nur eingeschränkt dazu bereit, ihre eigenen Ideen und Vorstellungen zurückzuschieben oder andere Ideen ohne Murren zu akzeptieren. Natürlich kann ich nur von dem ausgehen, was ich bisher im Leben erlebt hab, sei es außerhalb und innerhalb des Internets, aber für eine erste Studie reicht mir das schon aus. ;) Du solltest also nicht zu hart mit den anderen ins Gericht gehen, wobei eine physische Störung auch kein Persönlichkeitsmakel, sondern eine Krankheit ist.

---

Wenn du unter nem Miyamoto Shigeru arbeitest musst du dich auch an seine Ideen richten und bist eingeschränkt. Nur mal als Vergleich.

Kommt drauf an, ob man dafür bezahlt wird, oder ob man etwas freiwillig macht(und dann noch ob man dazu "genötigt" wurde oder ob man richtig Lust hatte weil man das Projekt interessant findet - was sich natürlich im Laufe der Zeit ändern kann wenn das Projekt eine andere Richtung einschlägt, weil der "Chef" es irgendwie vorgibt). Wer bezahlt wird macht es ja wegen dem Geld. Da kann der Rest ja egal sein.

Außerdem kommts drauf an, ob in nem Büro gearbeitet wird oder irgendwie kleine RPG-Maker-Leute sich übers Internet Sachen zuschicken. Büro alle zusammen ist wohl leichter, wenn man sich direkt mal zu nem Gespräch treffen kann ohne irgendwelche Hardware dazwischen. Nicht umsonst haben alle riesigen MMORPG-Betreiber auch Anforderungen, dass sogar irgendwelche Community-Manager die nur in Foren was posten auch bei denen irgendwo in die USA hingehen und dort im Büro mit denen hocken - statt es irgendwie von zu Hause zu machen.

@Zakkie
Ja, die Mitglieder eines Teams haben nicht immer das gleiche Mitspracherecht uns wahrscheinlich wird jemand in einem professionellen Team auch nicht aufmucken, weil er sonst seinen Job riskiert. Man wird sich oft arrangieren, doch das muss noch lange keine gute Teamarbeit sein. Es macht ja schon einen Unterschied, ob jemand seine eigene Idee verwirft, weil er Konflikte vermeiden möchte oder weil er die andere Idee überzeugender findet. Der erste Fall kann der Harmonie im Team schaden, auch wenn man nicht gleich dem anderen zähneknirschend seine Sturheit übel nimmt.

Zitat:

---

Zitat von Kelven

@caesa_andy
Man kann Maps kopieren, aber dazu müssten alle, die an ihnen arbeiten, den gleichen Maptree benutzen. Legen Person A und Person B neue Maps an, können ja zwei Maps die gleiche ID besitzen. Man kann zwar auch das im Voraus planen, aber es gibt immer mal Situationen, in denen doch noch eine weitere Map benötigt wird usw. Wenn nur einer das Spiel implementiert, sinkt denke ich der Verwaltungsaufwand. Die Konzeption von Dungeons kann man aber wohl schon auslagern.

---

Wenn ich per Copy und paste eine Map aus einem ACE Projekt kopiere und in ein anderes einfüge, dann fügt der Zielmaker die map automatisch in die nächste freie Map-ID ein, und versucht nicht, eine eventuell bereits vorhandene map zu überschreiben. Mag sein, das das bei den alten makern anders war, aber zumindest im ACE ist das zusammenkopieren des map-Tress absolut möglich, man muss nur im hinterkopf behalten, dass sich die Map-IDs dabei ändern und Map-Übergänge deshalb nach dem zusammenfügen nicht mehr funktionieren werden.

Zitat:

---

Das siehst du glaube ich zu eng. Die meisten Menschen sind nur eingeschränkt dazu bereit, ihre eigenen Ideen und Vorstellungen zurückzuschieben oder andere Ideen ohne Murren zu akzeptieren. Natürlich kann ich nur von dem ausgehen, was ich bisher im Leben erlebt hab, sei es außerhalb und innerhalb des Internets, aber für eine erste Studie reicht mir das schon aus. ;) Du solltest also nicht zu hart mit den anderen ins Gericht gehen, wobei eine physische Störung auch kein Persönlichkeitsmakel, sondern eine Krankheit ist.

---

Von "Ohne murren" war ja auch gar nicht die Rede ;)

Es muss mir natürlich nicht gefallen, wenn ich überstimmt werde, aber ich muss es respektieren und die Qualität der Arbeit von anderen anerkennen können. Menschen sind Rudel und Familientiere. Uns nach einem hierarchich höher stehenden Alpha-Tier zu richten, liegt in unseren Genen begründet. Deswegen darf ich zwar mit einer Entscheidung nicht einverstanden sein, aber auch Dinge, mit denen ich nicht einverstanden bin, muss ich trotzdem akzeptieren und respektieren können.
Sobald ich anfange, passiv-aggressiven Widerstand gegen eine Entscheidung zu leisten mit der ich nicht einverstanden bin, etwa, indem ich meine mitarbeit einstelle, oder nur noch meckere und damit auch andere an der ausübung ihrer Aufgaben hindere, dann liegt eine Persönlichkeitsstörung aufgrund eines zu geringen selbstwertes vor, weil ich dann nicht in der Lage bin, zu akzeptieren, dass die mehrheit eine Andere lösung nunmal besser findet.
Die allermeisten maker-Projekte scheitern doch daran, dass das Team über kurz oder lang auseinander fällt, weil die Teilnehmer alle um jeden preis ihre eigenen ideen durchdrücken wollen, und bei Ideen von anderen in einen passiven Widerstand verfallen. Und dieses verhalten ist eben nicht "normal". Normal ist es tatsächlich, den "besten" Weg zu einem ziel zu suchen, und diesen auch zu gehen. unabhängig davon, wer diesen Weg vorgeschlagen hat.
So lange ich argumentativ gegen eine Entscheidung vorgehen kann, aber trotzdem meine Bereitschaft signalisiere, mich der Mehrheit zu fügen, ist alles in ordnung. Wenn ich aber anfange, zu sperren und zu blocken, weil ich keine rationalen Argumente mehr habe, und deshalb regelmäßig in den "ich will nicht!"-Modus verfalle, sollte ich mich untersuchen lassen.

Zitat:

---

Verglichen mit kommerziellen 2D-Spielen sind die Grafiken der Maker-Spiele sehr einfach gehalten, das stimmt. Innerhalb der Maker-Szene gibt es aber schon einen großen grafischen Wettkampf. Tendenziell machen Spiele, die "besser" aussehen, auch einen "besseren" Eindruck. Ob sie dann spielerisch oder erzählerisch überzeugen ist wieder eine andere Frage, aber zunächst zählt der optische Eindruck.

---

Richtig. Dieser ist aber nicht zwingend vom verwendeten Tileset abhängig. Es gibt leute, die Mappen mit dem 2k RTP besser, als andere leute mit Mack oder theodore. Und es gibt leute, die pixeln alles selbst, kriegen dabei aber trotzdem nichts auf die Reihe, das orgendlich aussieht, weil sie wahlweise ebend nicht pixeln, oder nicht mappen können.
Ich kann auch eine "spielerische Perle" mit dem 2k RTP erstellen, da spricht absolut nichts gegen. Anders als Caine Luveno das behauptet sind selbsterstellte ressourcen keine zwingende vorraussetzung für ein "Gutes Spiel". Denn gute Optik ist auch mit freien Ressourcen machbar. und letztlich kommt es sowieso nur auf den Spielspaß an.

Ich glaube, der Grund für das Scheitern vieler Teamprojekte liegt noch ein bisschen tiefer, als nur in den unterschiedlichen Ansichten der Teammitglieder, ihrer Unterschätzung des Aufwands oder ihrer Unzuverlässigkeit.

Schon das Wort „Zusammenarbeit“ beinhaltet einen Hinweis darauf, warum es mit selbiger beim Spielemachen meiner Meinung nach so selten klappt: Wenn das Projekt in Einzelaufgaben zerlegt wird (die dann abgesprochen, verteilt, koordiniert, terminiert, implementiert... werden müssen), dann wird aus dem ursprünglichen Freizeitvergnügen sehr schnell etwas ganz anderes, nämlich Arbeit. Und ich fürchte, das ist der eigentliche Killer von Teamprojekten und der Grund, warum die Lust und die Motivation letztendlich verloren gehen und die Teammitglieder wieder abspringen.

Nachgewiesenermaßen sind Spaß, Lust und Motivation am höchsten, je selbstbestimmter eine Tätigkeit ist und am kleinsten, je fremdbestimmter diese ist. Deshalb haben wahrscheinlich die Arten von Kooperation die größte Chance auf Erfolg, die dem Einzelnen so viel Freiheit wie möglich lassen oder, anders gesagt, bei „Gewerken“, die sich so wenig wie möglich ins Gehege kommen (siehe real Trolls Beispiel mit dem Musiker).

Je kleinteiliger die Arbeit aufgespalten wird (Schreiber, Mapper, Zeichner/Pixler...) und je abhängiger jeder von der Arbeit des anderen ist, desto weniger freie Entfaltungsmöglichkeiten bleiben dem Einzelnen und desto geringer wird seine intrinsische Motivation. Dann braucht es Motivation von außen (z.B. Bezahlung) um die Leute im Team zu halten und genau die kann ein nicht kommerzielles Projekt ja nicht bieten. Gleichzeitig ist aber grade Arbeitsteilung / Spezialisierung der Weg zu einem Endprodukt höherer Qualität. Das scheint mir das wahre Dilemma zu sein.

Man müsste also so zusammenarbeiten, dass man sich gegenseitig nicht derart einschränkt, dass aus Freizeitvergnügen Arbeit wird und dazu eignen sich manche Aufgabengebiete besser als andere: Dem Musiker muss zwar das Spiel, für das er die Musik macht, allgemein zusagen, aber er wird nicht unbedingt über Details im Storyverlauf, Gameplay oder der Entwicklung der Charaktere diskutieren wollen. Dasselbe bei einem Zeichner, der Artworks / Faces der Charaktere oder Bilder für bestimmte Schlüsselszenen zeichnet. Solange der Auftraggeber offen für den persönlichen Stil seiner Mitarbeiter (die er sich ja selbst ausgesucht hat) bei der Umsetzung seiner Vorgaben bleibt und nicht seinerseits jedes Detail vorschreiben will, kann das mit Zusammenarbeit schon funktionieren.

Zitat:

---

Zitat von Kelven

@Zakkie
Ja, die Mitglieder eines Teams haben nicht immer das gleiche Mitspracherecht uns wahrscheinlich wird jemand in einem professionellen Team auch nicht aufmucken, weil er sonst seinen Job riskiert. Man wird sich oft arrangieren, doch das muss noch lange keine gute Teamarbeit sein. Es macht ja schon einen Unterschied, ob jemand seine eigene Idee verwirft, weil er Konflikte vermeiden möchte oder weil er die andere Idee überzeugender findet. Der erste Fall kann der Harmonie im Team schaden, auch wenn man nicht gleich dem anderen zähneknirschend seine Sturheit übel nimmt.

---

Das ist leider so ein Problem des Internets.
In meiner Firma mucke ich sogar recht häufig auf, wenn mir was programmiertechnisch nicht passt, oder man meint, man müsse für ein hoch komplexes Thema ein Hotfix rausschmeißen, was so dermaßen in die Hose gehen wird, weil keiner den Überblick über die gesamten Auswirkungen hat. Auch stichel ich gerne meine Vorgesetzten mit meinen Forderungen für ein Refactoring, weil ich der Meinung bin, dass wir so was in einigen Stellen schon bitter nötig haben, aber das bezahlt kein Kunde, und deswegen wird es nicht gemacht. (Die Software ist 13 Jahre alt und ist historisch gewachsen). So etwas lässt sich aber besser persönlich unter vier Augen klären bzw. sagen, als über das Internet. Per Chat starrt man lediglich nur Buchstaben an, und man weiß gar nicht, wie der Gesprächspartner überhaupt reagiert. Es fehlt einfach die Mimik und die Gestik, die in einem Gespräch sehr bedeutsam sind. Wenn man den Gesprächspartner gegenüberstehen hat, reagiert man schon automatisch ruhiger, weil man den Partner ansehen kann, ob er die Problematik überhaupt verstanden hat, oder nicht.

Zitat:

---

Zitat von Carnys

Nachgewiesenermaßen sind Spaß, Lust und Motivation am höchsten, je selbstbestimmter eine Tätigkeit ist und am kleinsten, je fremdbestimmter diese ist. Deshalb haben wahrscheinlich die Arten von Kooperation die größte Chance auf Erfolg, die dem Einzelnen so viel Freiheit wie möglich lassen oder, anders gesagt, bei „Gewerken“, die sich so wenig wie möglich ins Gehege kommen (siehe real Trolls Beispiel mit dem Musiker).

---

Wenn man ein Projekt richtig plant, dann kommt so was auch nur sehr selten vor.
Aber ich kenn es von meiner Kindheit/Jugend selber: Man zäumt oft das Pferd oft von hinten auf. Man plant und entwickelt gleichzeitig das Spiel. Das wäre so, als ob man das Drehbuch zu einem Film schreibt, während man den Film dreht, und das kann nur in die Hose gehen. Ein weiteres Problem ist halt, dass hier noch viele recht jung und unerfahren sind, was die Teamarbeit und die Entwicklung angeht. Es kann nicht funktionieren, wenn das gesamte Team am Design, an den Grafiken und am Scripting rumfummeln. Selbst in der professionellen Spieleentwicklung gibt es nur ein sehr kleines Designer-Team, das nichts anderes tut, als sich wirklich um das Design zu kümmern, und um nichts anderes. Auch braucht man jemanden, der das gesamte Projekt koordiniert. Die Programmierung und das Scripting ist eigentlich nur ein sehr kleiner Teil, wenn die Werkzeuge bereitstehen. Soundeffekte werden eigentlich immer nur mal sporadisch eingebaut, wenn man meint, dass das jetzt mal eine gute Gelegenheit wäre. Auch Grafiken müssen nicht immer gleich verfügbar sein. Wenn es keine gibt, dann bastelt man sich halt schnell ein paar Dummy-Grafiken und arbeitet erstmal damit. Einfarbige Rechtecke reichen meist schon aus.

Das Problem, was ich aber sehe, ist die Kommunikation. Das Internet ist keine tolle Kommunikationsplattform, für die Koordination eines Teams. Das erfordert schon sehr viel Disziplin, und regelmäßige Meetings, damit jeder auf den neuesten Stand ist. In einer Anime-Fansub-Gruppe, wo ich mal aktiv war, haben wir dafür sogar ein Benachrichtigungssystem gebastelt, wo wir mitteilen können, wie weit wir unsere Arbeit erledigt haben, und was noch fehlt. Wenn jemand dann mit seiner Arbeit fertig war, bekam der nächste in der Kette dann Bescheid, dass er loslegen kann und wo er dann die erforderlichen Daten finden kann. Also eine Art Product-Lifecycle-Management. In der Softwareentwicklung nennt man das Application-Lifecycle-Management (ALM). Ich nehme auch mal an, dass die wenigsten hier mit einer Softwareverwaltung ala SVN oder Git arbeiten. Solche Hilfsmittel erleichtern das Leben ungemein, wenn es einen gemeinsamen Ort gibt, wo die Daten verwaltet werden, und man auch den Werdegang der Daten beobachten kann. So kann man auch wieder ein paar Schritte zurückgehen, wenn die Entwicklung doch nicht so wird, wie man es sich vorgestellt hat.

Ich möchte mal eine Teilthematik anreißen,mal sehen wie ihr das seht:

Teamleiter als Tätigkeit
Teamleiter wird oft als Amt angenommen, d.h. z.B. der Storytyp macht auch den Chef.
Was haltet ihr von Teamleiter als Tätigkeit, d.h. einem, der sich um Kommunikation, Planung, Abstimmung kümmert, aber selber keine Fachbereiche bearbeitet.
Ich will die Knackpunkte und mögliche Polemik nicht vorwegnehmen, daher lass ich das mal einfach so stehen.

Halte ich für weniger praktikabel, Corti, denn meiner Auffassung nach muss im Sinne ehrenamtlicher Arbeit der Teamleader mit größtmöglichst bestem Vorbild vorangehen um die Motivation langfristig hoch zu halten.
Wenn das Team also nicht aus 150 Leuten besteht, ist es meiner Meinung nach ratsam das ein "Chef" sich einbringt und auch oder gerade mit die unangenehmsten Aufgaben (z.B. Bugfixing) erfüllt.

Ein reiner Teamleiter wirft bei Projekten so einige Probleme auf. Bei kleinen Gruppen hätte er nichts ... oder nicht viel ... zu tun und währe daher der "gammeljob", der einfach zuschaut, wie sich das Spiel selber entwickelt. Bei größeren, strukturierteren teams müsste ein teamleiter hingegen über gewisse Kompetenzen verfügen, die Erfahrung vorraussetzen. Er müsste die mitarbeiter Motivieren, Arbeiten koordinieren, Arbeitsschritte und Arbeitszeiten aufeinander abstimmen.
Ein Teamleiter macht nur dann sinn, wenn er sicherstellen kann, dass die Arbeiten an dem projekt Just-in-Time fortgeführtund fortgesetz werden. Arbeitsschritte müssten also so verteilt werden, das der Grafiker just in dem Moment mit dem Berg-Tileset fertig ist, in dem der mapper mit den Wüsten-maps fertig ist, und die Berglandschaften beginnt. Ein Teamleiter, der dazu nicht in der lage ist, so das der Workflow einzelner Mitarbeiter zwangsweise und unfreiwillig unterbrochen wird, macht seinen Job nicht gut, und ist daher überflüssig. So einen Job kann deshalb kein 15 Jähriger Hobby-Entwickler machen...dazu gehören Grundkentnisse in betriebsorganisation.

Dasd mag jetzt hochgestochen klingen, wegen Hobby und so, aber genau so ist es. Ein Teamleiter als separates teammitglied macht nur dann Sinn, wenn auch professionelle Arbeitsabläufe angestrebt werden. Ist das nicht der fall, und die einzelnen teammitglieder betrachten das Makern sowieso nur als Hobby, dann kann auch der mapper den "Teamleiter-Job" problemlos mit machen, denn hier und da mal eine E-Mail-Schreiben, das ist nun wirklich keine Arbeit.

Zitat:

---

Zitat von caesa_andy

Dafür brauche ich kein Script und der Maker passt dabei dann sogar die jeweiligen ID's automatisch korrekt an. Das einzige, was nach einer zusammenführung manuell überarbeitet werden müsste, sind event-Zugriffe auf andere Maps (z.B. ein Player Transfer zu einer anderen map.).

---

Wenn du in einem Event Held ID 4 der Party hinzufügst, bleibt der Befehl nach der Kopie in ein anderes Projekt unverändert, auch wenn der Held dort die ID 7 hat. Die einzige Option welche es da für eine Autokorrektur seitens des Makers gäbe wäre eine Referenzierung über den Namen, was zu ganz anderen Kollisionsproblemen führt.

Zitat:

---

Zitat von caesa_andy

Das Problem ist aber nicht makertypisch, sondern "Menschentypisch" und tritt überall im leben auf. Das man leute, die von etwas keine Ahnung haben, immer mit Vorsicht genießen sollte, weil sie dazu neigen, sich zu übernehmen, ist schon immer so gewesen. Und beim makern kann man gottlob oft schon an der Art und weise, wie ein Gruppengesuch oder eine Projektvorstellung geschrieben ist, erkennen, wie erfahren der andere ist.

Leute, auf die das zutrifft, sollten - grade im Fortgeschrittenen (Berufs-)Alter - dringend eine Psychotherapeuten aufsuchen. Das ist nicht beleidigend gemeint, aber das das massive Festhalten an eigenen Ideen und die Unfähigkeit, Ideen anderer als gut anzuerkennen, sind Symptome die auf ein sehr, sehr schwaches Selbstwertgefühl hinweisen. Solche leute suchen im regelfall eine bestätigung ihrer person durch ihre leistung.
Bleibt diese bestätigung jedoch aus, reagieren sie, indem sie die leistung ander herrabsetzen und sich selbst damit trotzdem übder diese stellen. Menschen mit einem sauber ausgeprägten Selbstwert, die genau wissen, was sie können und wohin sie gehören sind in der Überzahl sehr gut teamfähig, da sie auch in der lage sind, anzuerkennen, wenn jemand anderes einfach eine bessere Arbeit liefert als sie.
"Der mensch" ist per definitionsehr gut teamfähig, da wir herden oder Rudeltiere sind.

---

"Fortgeschrittenes Berufsalter" siehst du hier in der Community aber eher selten, ausgenommen beim härteren Kern (so zumindest meine Einschätzung der letzten 8 Jahre). Zum Therapeuten würde ich nicht jeden schicken der nicht gut im Team arbeiten kann. Ich erlebe täglich wie schwer sich manche Leute damit tun, und wäre dies so eine Selbstverständlichkeit wie du sagst, würde es gerade im Berufsleben nicht immer wieder explizit gefordert werden bzw. bei Einstellungstests im kleinen Rahmen sogar erprobt.

Zitat:

---

Zitat von caesa_andy

Wobei ich dir allerdings zustimmen muss, ist die Sache mit den Kompromissen. Mich erschreckt es immer wieder zu sehen, wie Leute dazu neigen, faule Kompromisse zu schließen, bei denen keiner irgendwas bekommt, als dem gegenüber auch mal was zu gönnen. Ich persönlich neige dazu, kompromisse auf Basis eines Gleichgewichts zu schließen (Du hast Arbeit A vorgeschlagen, ich Arbeit B, also machen wir heute A und nächste Woche B). Die meisten anderen leute, die ich kenne, versuchen kompromisse zu schließen, indem beide auf ihre Perspektive verzichten (Du willst Arbeit A machen, ich Arbeit B, also machen wir heute Arbeit C.)
Ich finde so etwas fürchterlich, aber auch das hängt mit dem auf-sich-selbst projezierten Wert ab.

---

im Bezug auf die Spieleentwicklung ist sowas schwierig. Wenn A nun ein Fantasy Szenario ist und B ein Scifi Szenario kannst du nicht beides umsetzen. Wenn mehr Variablen hinzu kommen wird es umso komplexer. Um beim Beispiel zu bleiben entsteht entweder ein Spiel mit Zeitreisen, oder einer "muss" sich der Mehrheit des Teams beugen (wenn wir mal von mehr als zwei Personen und nur zwei Settings ausgehen).

Zitat:

---

Zitat von caesa_andy

Der maker ist weder graphisch noch technisch eine Hochleistungs-Engine. Das nieveau auf dem wir uns bewegen, konkuriert bestenfalls mit dem des Supernintendo vor 20 Jahren. Graphisch ist damit kein Blumentopf zu holen. Noch dazu wo es ohnehin kaum Pixler gibt, deren Fähigkeiten auch nur annähernd mit dem RTP mithalten können.

---

Natürlich bezieht sich diese Aussage speziell auf eine Betrachtung innerhalb der Community. Wenn wir anfangen diesen Rahmen zu verlassen, und uns z.B. mit modernen Kassenschlagern wie GTA V vergleichen würden, wäre jedwede getane Arbeit oder Spielvorstellung von vorn herein absolut sinnlos.

Bzgl. dem SNES Vergleich muss ich auch widersprechen. Das mag für den RM2k/2k3 gelten, aber die modernen Maker sind dem SNES deutlich überlegen. Nur weil beides 2D Grafik verwendet ist es nicht automatisch "gleich schlecht" was die technischen Möglichkeiten angeht.

Zitat:

---

Zitat von caesa_andy

Die Aussage, das ein Spiel, das nur auf frei verfügbare Ressourcen setzt, bestenfalls oberer durchschnitt werden wird, ist unter diesen gesichtspunkten Blödsinn. Zum einen sehen die ressourcen von Enterbrain und Co. erheblich besser aus, als das, was viele leute selber zustande bringen, und zum anderen werden wir mit unserer 2D-Pixelmatsche sowie so keine Begeisterungsstürme auslösen. Das beste, auf was wir hoffen können, ist, dass das Spiel dem Spieler Spaß macht. Und das kann es mit M&B genau so, wie mit eigenen grafiken.

---

Der Spielspaß ist mit Nichten von den verwendeten Grafiken abhängig. Das habe ich auch nie behauptet. Meine Behauptung war das eben die Möglichkeit mit schlechteren Grafiken ein brauchbares Spiel zu erschaffen besteht und somit eine Teamfindung nicht nötig ist. Das ändert nichts an der Tatsache dass z.B. ein Vampires Dawn, sowohl grafisch als auch technisch, nicht mit einem Velsarbor mithalten kann und ist nirgendwo eine Bewertung des Spielspaßes, womit die Aussage "oberer Durchschnitt" zum Thema "wozu brauche ich ein Team im Bezug auf Grafik/Technik etc?" gerechtfertigt ist. Alleine schon der Mangel an Individualität wertet das Spiel im Bereich "Grafik" ab.

Zitat:

---

Anders als Caine Luveno das behauptet sind selbsterstellte ressourcen keine zwingende vorraussetzung für ein "Gutes Spiel".

---

"Oberer Durchschnitt im Bereich Grafik und Technik" ist für dich also gleichbedeutend mit "schlechtes Spiel"? Ggf. war der Zusammenhang zwischen dem letzten und vorherigem Absatz nicht so deutlich wie ich es gerne gewollt hätte, aber das war schon im Zusammenhang zu sehen.

@caesa_andy
Die alten Maker legen beim Copypasta auch neue Maps an, aber trotzdem haben die Maps in den jeweiligen Projekten ja unterschiedliche IDs. Das kann man nur mit einem gewissen Verwaltungsaufwand verhindern.

Passiv-aggressiv sind doch alle Menschen und das täglich. ;) Ich glaube nicht, dass man da gleich von einer psychischen Störung sprechen kann. Beim Alphatier könnte man anbringen, dass ein Rudelführer von den anderen Tieren weitgehend als Anführer akzeptiert wird. Wenn jemand den Projektleiter nicht für kompotent hält, dann sieht er dort auch kein Alphatier und er kann den Projektleiter ja sogar zurecht für inkompetent halten. Ein aufmüpfiges Verhalten ist also nicht immer falsch. Im Tierreich ist es soweit ich weiß außerdem so, dass die Alphatiere schnell ihren Platz verlieren, wenn die anderen sie nicht mehr akzeptieren.

@Carnys
Das ist ein wichtiger Punkt. Der Spaß beim z. B. Pixeln kommt ja nicht unbedingt daher, dass man nach genauen Vorgaben pixelt, sondern daher, dass man seine Kreativität auslebt. Ich würde versuchen, in einem Teamprojekt keine all zu starren Vorgaben zu machen.

@Corti
Ist der Teamleiter denn nicht meistens derjenige, der das Spiel ursprünglich machen wollte? Der hat dann ja konkrete Vorstellungen von Handlung und Gameplay, die er auch so umgesetzt sehen möchte. Das gibt man nicht so gerne aus der Hand.

Das A und O für Teamarbeit ist Motivation, Respekt und Kommunikation. Wenns an einem dieser drei Sachen hapert fährt man sich leider sehr schnell in eine Zwickmühle.

Wer im Beruf schon viel mit Teamarbeit zu tun hat kennt das sicher, dass es gern mal an einem oder mehreren dieser drei Dinge krankt. Das muss nicht auch noch in einem Hobbyprojekt sein, finde ich - Also lieber von Anfang an klar darüber sein, was man will und was die Teammitglieder wollen.

Jemand der "Chef" ist und koordiniert muss sein, sonst verliert sich einfach irgendwann der Überblick. Das geht sehr wohl ohne Alphatierverhalten und Starallüren - Jeder hat einfach seine Talente, und während der eine gut pixelt und der andere gut komponiert kann der dritte gut organisieren und lenken. Solange Vertrauen und Respekt im Team vorherrschen muss das auch gar nicht zu Machtkämpfen führen. Idealerweise hat die Rolle des Koordinators nichts mit Macht, sondern schlicht mit guten Koordinierungsfähigkeiten zu tun.

Darum würde ich ein Teamprojekt niemals mit Leuten in Angriff nehmen, bei denen ich mir nicht sicher sein kann dass ich mit ihnen auf einen Nenner komme. Das heißt nicht dass ich nur Leute in ein Team lasse, die zu allem was ich tue Ja und Amen sagen - Mitarbeiter ohne eigene Meinung und Ideen reinzuholen ist ein sicherer Weg, ein Projekt an die Wand zu fahren oder zumindest was ziemlich halbgares abzuliefern. Nein, verschiedene Meinungen sind gut und wichtig, und sei es nur damit man seine eigenen nochmal überdenkt und herausfordert. Aber die Grundeinstellung und die Lust muss eben übereinstimmen. Wenn ich weiß, dass ich großes mit meinem Projekt vorhabe, für meinen Kumpel ist es aber nur ein Zeitvertreib, dann wird es früher oder später krachen.

Viel und vernünftig miteinander reden, gerade bei Meinungsverschiedenheiten, viel Respekt füreinander zeigen und vorallem viel Spaß haben! Dann kann eine Teamarbeit richtig klasse werden. Ich bin eigentlich eher der introvertierte Typ, aber ich habe sehr viel darüber gelernt, wie bereichernd eine klasse Gruppe sein kann. Der Versuch lohnt sich, wenn man weiß dass man an einem Strang für ein tolles Spiel ziehen kann.

Aber mal in die Runde gefragt: Hätte denn jemand Lust zusammen mit mir den Beweis anzutreten, dass Teamprojekte funktionieren können bzw. genauer dass Spiele von der Zusammenarbeit profitieren? ;) Ich finde den Gedanken schon interessant - was passiert, wenn die kreative Energie von mehreren kombiniert wird? Natürlich sollten wir das an einem kleinen Projekt ausprobieren, ein Rollenspiel-Epos bindet zu lange.

Theoretisch gerne, aber wenn ich nicht sowieso schon zuviel zu tun und zu wenig Zeit hätte, würde ich wohl am ehesten Andy bei seinem Spiel helfen.

@Kelven
Also ich hätte schon Lust dazu. Ich finde es auch spannend, zu sehen, ob es funktionieren kann, das Pferd sozusagen von hinten aufzuzäumen: Nach Leuten zu suchen, deren Motivation es ist, das mit der Zusammenarbeit mal ausprobieren zu wollen. Da ergibt sich die Art des Projekts, das entstehen kann, ja erst daraus, was für Fähigkeiten die Leute, die sich melden mitbringen. Für kreative Experimente bin ich immer zu haben.:D

Ich habe immer Interesse daran mit anderen zusammen zu Arbeiten. Ich finde es sehr viel schöner in einem Team zu arbeiten denn als alleine an soetwas zu sitzen.
Selbst wenn am Ende eben nicht etwas dabei heraus kommt, so hat man zumindest eine gute Zeit verbracht und ein wenig soziale Kontakte gepflegt.
Außerdem erhält man immer schnell Feedback, und lernt gegebenenfalls auch noch etwas dabei.

Hm, prinzipiell bin ich interessiert. Ich denke aber es kommt auf die Dauer der Entwicklungszeit an und wie episch das ganze ausfallen soll.
Ich weiß, dass ich das eigentlich lieber nicht tun sollte, aber ich sage einfach mal ich habe Interesse an einem Teamprojekt.

@Corti
Du ziehst Andy mir vor? Das bedeutet Scheidung!

@Carnys, Cornix und Maister-Räbbit
Ich mache mal einen Thread im Entwickler-Forum auf, da können wir alles weitere besprechen.

So, hier ist der Thread.

Zitat:

---

Zitat von Kelven

Aber mal in die Runde gefragt: Hätte denn jemand Lust zusammen mit mir den Beweis anzutreten, dass Teamprojekte funktionieren können bzw. genauer dass Spiele von der Zusammenarbeit profitieren? ;) Ich finde den Gedanken schon interessant - was passiert, wenn die kreative Energie von mehreren kombiniert wird? Natürlich sollten wir das an einem kleinen Projekt ausprobieren, ein Rollenspiel-Epos bindet zu lange.

---

Naja, lieber ein richtiges RPG oder gar nichts. No offense Calvin. :/

Zitat:

---

Zitat von Caine Luveno

Wenn du in einem Event Held ID 4 der Party hinzufügst, bleibt der Befehl nach der Kopie in ein anderes Projekt unverändert, auch wenn der Held dort die ID 7 hat. Die einzige Option welche es da für eine Autokorrektur seitens des Makers gäbe wäre eine Referenzierung über den Namen, was zu ganz anderen Kollisionsproblemen führt.

---

Wenn eine Gruppe nicht einmal dazu imstande ist, sicherzustellen, dass alle Teilnehmer mit der selben Datenbank arbeiten, dann liegen da ganz andere Dinge im Argen, als "nur" eine technische Unzulänglichkeit des Makers, denn dann hat da offenbar niemand auch nur die geringste Ahnung von koordinierter Arbeit. Das ein Teammitglied die Datenbank verwaltet und aktuell hällt, sollte selbstverständlich sein. Wenn es Teams gibt, die sogar dabei Probleme haben, sowas zu organisieren, dann ist das eher ein "Wir wurschteln alle drauf los" als ein "Wir arbeiten im Team".
Und darüber zu diskutieren, ob eine Teamarbeit unter solchen Vorraussetzungen möglich ist, ist unnötig.

Zitat:

---

Zitat von Kelven

Aber mal in die Runde gefragt: Hätte denn jemand Lust zusammen mit mir den Beweis anzutreten, dass Teamprojekte funktionieren können bzw. genauer dass Spiele von der Zusammenarbeit profitieren? ;) Ich finde den Gedanken schon interessant - was passiert, wenn die kreative Energie von mehreren kombiniert wird? Natürlich sollten wir das an einem kleinen Projekt ausprobieren, ein Rollenspiel-Epos bindet zu lange.

---

Ich halte das wie Corti. Wenn ich noch Kapazitäten frei hätte, würde ich mir selbst helfen :D

Abgesehen davon, arbeite ich eh nur noch mit dem ACE, was das ganze natürlich schwerer macht, weil den ja längst nicht jeder hat. Das einzige, was mich vllt wirklich noch reizen würde, wäre ein kleines Horror-Adventure ... aber ich arbeite wie gesagt nur noch mit dem ACE.

Zitat:

---

Zitat von caesa_andy

Ich halte das wie Corti. Wenn ich noch Kapazitäten frei hätte, würde ich mir selbst helfen :D

---

Same here - aber Kelven, wir stellen für SKS IMMER ein... :D

Ihr könntet mir lieber noch ein paar Pixel-Sklaven abgeben. ;)

@caesa_andy

Zitat:

---

Das einzige, was mich vllt wirklich noch reizen würde, wäre ein kleines Horror-Adventure ... aber ich arbeite wie gesagt nur noch mit dem ACE.

---

Das fände ich auch interessant, aber der ACE ist mir im Moment zu teuer.

Die Steam Weihnachtsangebote kommen ja bald, also mal die Augen offen halten. Während des Herbstverkaufs war der Ace für 15 Euro zu haben.