Ergebnis 1 bis 20 von 43

Thema: Team-Projekte und ihre Tücken

Hybrid-Darstellung

Vorheriger Beitrag Vorheriger Beitrag   Nächster Beitrag Nächster Beitrag
  1. #1
    @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 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 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.

  2. #2
    Zitat Zitat von Kelven Beitrag anzeigen
    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.

  3. #3
    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.

  4. #4
    @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.

  5. #5
    Zitat Zitat von Kelven Beitrag anzeigen
    @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 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 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.

  6. #6
    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.

  7. #7
    Zitat Zitat von Kelven Beitrag anzeigen
    @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 Beitrag anzeigen
    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.

  8. #8
    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.

  9. #9
    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.

  10. #10
    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.

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •