clowdr.dev
arrow_backZurück zum Logbook
Community

Discord-Server vs. Gamedev-Team: Warum das eine shippt und das andere nicht

Discord vs. Gamedev-Team: Ein Chatraum ist kein Team. Drei Dinge, die Discord nicht erzwingen kann, und der Migrationspfad, wenn du shippen willst statt chatten.

9 Min. Lesezeit
Discord-Server vs. Gamedev-Team: Warum das eine shippt und das andere nicht

Ein Discord-Server ist ein Chatraum mit Benachrichtigungen. Ein Gamedev-Team ist eine kleine Gruppe, in der jemand am Freitag auf deine Arbeit zählt. Das ist nicht dasselbe, und in der Lücke dazwischen sterben die meisten Indie-Projekte leise weg.

Du kannst ein Dev-Team innerhalb von Discord betreiben. Leute machen das jeden Tag. Aber Discord selbst kann dich so wenig zu einem Team machen, wie ein WhatsApp-Chat dich zu einem Ehepaar macht. Es ist ein Raum. Was in dem Raum passiert, hängt an dir, und die meisten über Discord organisierten Indie-Projekte packen nichts Tragendes in den Raum.

"Wir haben abgemacht zusammenzuarbeiten, und dann haben wir nie wieder miteinander geredet." Escapist Magazine, über Reddits Pick-up-Indie-Szene

Das ist die ganze Discord-Server-vs-Gamedev-Team-Frage in einem Satz. Also hier der direkte Vergleich:

Der Vergleich auf einen Blick

Was ein Team hatDiscord-ServerGamedev-Team
Benannte Verantwortung pro AufgabeNein (jeder kann alles aufnehmen, also macht es keiner)Ja (eine Person, namentlich, auf einer Karte)
Eine Deadline, die jemand anderes beobachtetNein (höchstens selbstgesetzt)Ja (wöchentliches Demo, Zweiwochen-Sprint, fremde Augen)
Kosten für plötzliches SchweigenNull (du schließt den Tab)Nicht null (du übergibst, du sagst warum)
Sichtbarer Fortschritt zwischen MeetingsVibes und ScreenshotsGepushte Builds, aktualisierte Karten, Stand-ups
Rollenklarheit"Ich helf irgendwie beim Code, glaub ich"Programmierer:in, Artist, Komponist:in, Lead, namentlich
Antworterwartung"Irgendwann bald"Innerhalb eines Tages bei Blockern
Kosten fürs AussteigenGhostGespräch
Wer ist warum dabeiUnausgesprochenAufgeschrieben

Wenn du dein aktuelles Projekt ehrlich gegen diese Tabelle gescort hast und die meisten Zeilen links landen, ist dieser Artikel für dich. Das Problem sind nicht deine Teammates. Dein Discord-Team ist nicht unzuverlässig. Es ist strukturlos.

Was ein Discord-Server wirklich ist (und wofür er gut ist)

Draufsicht auf eine graue Filz-Pinnwand voller verstreuter, leerer cremefarbener Notizzettel und dünner Fäden, die meisten Fäden enden an leeren Pins.

Zuerst ein fairer Blick auf Discord, ohne Strohmänner. Ein guter Server ist nützlich. Er ist der Ort, an dem du:

  • Leute findest, die die gleichen Spiele mögen wie du.
  • Samstags einen Build mit fünfzig Menschen playtestest.
  • Um Mitternacht eine blöde Engine-Frage stellst und eine Antwort bekommst.
  • Screenshots teilst und zwischen deinen eigenen Projekten sichtbar bleibst.
  • Den Menschen triffst, der irgendwann dein echter Teammate wird.

Das sind echte Jobs, und Discord erledigt sie gut. Das Problem beginnt, wenn Leute anfangen, diesen Raum zu behandeln, als wäre er ein Team.

"Viele Leute, aber die Reaktion ist niedrig." prybulets, über Discord-Server in Gamedev (Medium)

Discord läuft auf schwachen Bindungen. Schwache Bindungen sind super für Entdeckung und katastrophal fürs Shippen. Eine schwache Bindung ist jemand, der auf deine Nachricht antwortet, wenn sie interessant ist, und sie ignoriert, wenn nicht, ohne Kosten in beide Richtungen. Ein Spiel zu shippen verlangt das Gegenteil: jemand, der auch antwortet, wenn es langweilig ist, weil er es zugesagt hat.

Ein Server voller schwacher Bindungen sieht in Woche eins aus wie ein Team, weil alle begeistert sind. In Woche sechs sieht er aus wie ein Friedhof aus "noch interessiert?"-Pings, die keiner beantwortet.

Was ein Gamedev-Team wirklich ist

Vertikal gestapelte Illustration von drei kleinen Schreibtisch-Arbeitsplätzen, jeder mit einer namentlich beschrifteten Owner-Karte, einem Aufgaben-Requisit und einer Uhr, die dieselbe Uhrzeit anzeigt.

Hier sind drei Dinge, die ein echtes Dev-Team hat und die ein Discord-Server allein nicht erzwingen kann. Du kannst alle drei auf Discord draufbauen. Die meisten tun es nicht.

1. Benannte Verantwortung pro Aufgabe

Im Team hat jedes Stück Arbeit einen Namen dran. Keine Rolle, eine Person.

"Wenn zwei Leute für etwas verantwortlich sind, ist niemand dafür verantwortlich, und es ist viel besser, einen klaren Owner für diese Sache zu haben." IndieGameClinic, über Trello für kleine Teams

Wenn das Inventar-UI "irgendwie das Ding von der Programmierung" ist, wird das Inventar-UI nicht gebaut. Wenn das Inventar-UI Saras Karte ist, bis es fertig ist, bringt Sara es zu Ende oder sagt laut, dass sie geblockt ist. Beide Ergebnisse bewegen das Projekt. Die Variante mit geteiltem Credit produziert keins von beiden.

Discord-Server defaulten auf die geteilte Variante. Ein Team defaultet auf benannte Verantwortung.

2. Eine Deadline, die jemand anderes beobachtet

Willenskraft ist der schlechteste Projektmanager, der je eingestellt wurde. Deadlines funktionieren, weil jemand anderes erwartet, ein Ding zu einem bestimmten Datum zu sehen, und diese Erwartung übernimmt den Teil der Arbeit, den deine eigene Motivation nicht schafft.

"Wir alle wissen aus Schule und Arbeit, dass wir Deadlines brauchen, um Dinge rechtzeitig fertigzubekommen. Und eine Sache, mit der Indie-Devs oft kämpfen, ist, diese Logik auf die eigenen Projekte anzuwenden." IndieGameClinic

Die günstigste Variante ist ein wöchentliches Demo. Freitag um 17 Uhr pusht das Team einen Build, spielt ihn an, schreibt auf, was kaputt ist. Auf einem Discord-Server sind Demos optional und verschwinden bis Monat zwei wieder leise. In einem Team sind Demos das Rückgrat der Woche, und man spürt es, wenn eins ausfällt.

3. Kosten, die nicht null sind, wenn du aussteigst

Auf Discord kostet es nichts, ein Projekt zu verlassen. Du stummschaltest den Kanal. Du antwortest nicht mehr. Vier Wochen später pingt dich jemand und du siehst es nicht. Das Projekt stirbt eine Stille nach der anderen.

Aus einem Team auszusteigen ist unangenehmer, und genau das ist der Punkt. Du sagst es den Leuten. Du sagst, warum. Du übergibst deine Karten oder gibst deine Zugänge zurück. Die Unannehmlichkeit ist tragend: sie zwingt dich zu bleiben oder sauber auszusteigen, statt sechs Monate lang als toter Knoten herumzuhängen.

Das ist nicht theoretisch. Das Ghostbox-Postmortem auf Game Developer nennt Design-ohne-Owner als einen der Gründe, an denen das Studio gescheitert ist, und empfiehlt, Gründerzahlen auf zwei bis vier zu begrenzen, genau aus diesem Grund. (Game Developer, Dom Drysdale) Alistair Doulins Artikel auf derselben Seite benennt denselben Fehlermodus auf Indie-Ebene: "Persönlichkeit schlägt Fähigkeit", wenn du keine Rituale hast, die sie abstützen. (Game Developer, Alistair Doulin)

Wann ein Discord-Server die richtige Wahl ist

Nimm den Server, wenn der Job ein Server-Job ist:

  • Du hast ein veröffentlichtes oder fast veröffentlichtes Spiel und willst einen Ort, an dem Spieler abhängen, Clips teilen und Bugs melden.
  • Du brauchst Playtester, keine Builder. Fünfzig Leute, die bereit sind, eine Stunde lang dein Demo zu zerlegen, sind ein Discord-Gewinn.
  • Du scoutest Teammates und willst einen Monat lang beobachten, wie jemand redet, bevor du ihn um Commitment bittest.
  • Du bist zwischen Projekten und willst ein Netzwerk schwacher Bindungen, das dich ohne Verpflichtung warmhält.
  • Du machst einen Jam mit einem harten Drei-Tage-Fenster, in dem die Struktur die Deadline selbst ist.

Nichts davon braucht benannte Verantwortung, wöchentliche Demos oder Übergaberituale. Ein Kanal und eine gepinnte Nachricht reichen.

Wann ein Discord-Server aufhört zu funktionieren

Reihe von fünf an die Wand montierten Karton-Tafeln, die vom satten Bernstein zu blassem Grau verblassen, die letzte Tafel hängt schief an einem einzigen Pin.

Der Server hört in dem Moment auf zu funktionieren, in dem du brauchst, dass jemand etwas Bestimmtes bis zu einem bestimmten Datum erledigt. Fünf Symptome, dass du diese Linie schon überschritten hast:

  • Der "Anderthalb-Monats"-Einbruch. Traffic halbiert sich. Dann halbiert er sich wieder. Ein Thread auf gamedev.net bringt es genau auf den Punkt: "Der Einsatz hat nach etwa anderthalb Monaten nachgelassen." Das ist kein Pech, das ist die Halbwertszeit von Schwach-Bindungs-Motivation.
  • "Das Leben kam dazwischen." Eine spezifisch nicht überprüfbare Ausrede, die nur in strukturlosen Teams auftaucht. In Teams wird aus "das Leben kam dazwischen" ein "ich schaff den Freitag nicht, können wir das Demo auf Montag verschieben?" mit Grund. Auf Servern ist es ein Abschied.
  • Der Ideen-Typ verdrängt den Build-Typ. Wenn niemand baut, dehnt sich das Reden darüber, was gebaut werden soll, in die Stille aus. Du merkst es daran, dass der #ideen-Kanal aktiv ist und der #builds-Kanal eine Geisterstadt.
  • Das 3.000-zu-5-Verhältnis. Lost Relic Games hat über dreitausend Mitglieder in seinem Discord. Er hat im Stream gesagt, dass eine Handvoll vertrauter Leute den Laden tatsächlich "am Laufen halten". Jeder Server hat dieses Verhältnis. Wenn du nicht bei den fünf bist, bist du bei den dreitausend.
  • Niemand ist für den aktuellen Blocker zuständig. Frag in den Raum: "wer repariert den Save-Load-Bug?" Wenn die Antwort lautet "jemand sollte sich das mal anschauen", ist der Raum kein Team.

"Internetbasierte Indie-Projekte mit Remote-Teams und jungen, ambitionierten Leuten scheitern fast alle." Slayemin, Your Indie Game Dev Team Will Fail (Medium)

Das ist seit Jahren das top-rankende Ergebnis für "indie game dev team will fail", und es bleibt top, weil es stimmt. Die Struktur, auf die Leute defaulten (Discord plus Trello plus Vibes), schließt die Lücke zum Shippen nicht.

Wie du merkst, in welchem du eigentlich bist

Makro-Nahaufnahme einer cremefarbenen Karteikarte auf dunklem Walnussholz, mit einer Spalte aus sechs kleinen Checkboxen, von denen zwei mit roten Tinten-Häkchen markiert sind.

Sechs-Fragen-Diagnose. Beantworte ehrlich. Keine Punkte für das, was du nächsten Monat vorhast.

  1. Wer besitzt den nächsten lieferbaren Meilenstein, namentlich? (Keine Rolle. Eine Person.)
  2. Wann ist das nächste Demo, und wer schaut zu? (Ein Datum und mindestens ein Paar Augen, die nicht deine sind.)
  3. Was passiert, wenn jemand eine Woche nicht antwortet? (Merkt das Team es innerhalb von 48 Stunden, oder erst wenn jemand in Woche drei zufällig in den Kanal pingt?)
  4. Kannst du sagen, was jede Person letzte Woche gebaut hat? (Konkret. Commits. Dateien. Nicht "sie haben an Sachen gearbeitet".)
  5. Gibt es eine schriftliche Vereinbarung, auch nur ein One-Pager? (Was jede Person zusagt, was sie bekommt, was passiert, wenn sie geht.)
  6. Würdest du 50 € darauf wetten, dass das in den nächsten 12 Monaten shippt? (Nicht "vielleicht." Würdest.)

Zähl aus:

  • 0 bis 2 Ja: Du hast einen Discord-Server. Hör auf, es ein Team zu nennen. Du erleichterst dich damit von einer Menge Schuldgefühl, das du gerade fehlleitest als "warum bin ich so undiszipliniert".
  • 3 bis 5 Ja: Du hast etwas Team-Artiges. Such die fehlenden Teile raus und installiere sie in den nächsten zwei Wochen, sonst hält die Struktur die nächste harte Woche nicht aus.
  • 6 Ja: Du hast ein Team. Mach weiter so. Außerdem: du bist selten.

Wenn diese Frage härter landet als erwartet, lies "Du bist nicht faul. Du bist ohne Struktur.". Der Reframe ist das ganze Ding.

Wie du einen Discord-Server in ein Team verwandelst (oder sauber aussteigst)

First-Person-Blick durch einen dunklen Korridor, der sich in zwei Wege gabelt: einer mit der Aufschrift UPGRADE führt zu einem warm beleuchteten Studio, der andere mit der Aufschrift LEAVE zu einer offenen Ausgangstür.

Du hast zwei ehrliche Wege. Entscheide dich für einen.

Weg A: Den Server vor Ort upgraden

Du magst diese Leute und willst mit ihnen shippen. Mach diese fünf Dinge in den nächsten zwei Wochen und lass keins davon weg:

  1. Wähl einen Vertical Slice, der in sechs bis zehn Wochen machbar ist, nicht das ganze Spiel. (Siehe Das Vertical-Slice-Protokoll.)
  2. Benenne drei Owner, namentlich, für die drei größten Teile des Slice. Jeder einen. Keine geteilten Karten.
  3. Setz ein wöchentliches Demo. Gleicher Tag, gleiche Uhrzeit, alle pushen einen Build, alle spielen zwanzig Minuten, alle schreiben auf, was kaputt ist. Freitag 17 Uhr funktioniert für die meisten Zeitzonen. (Siehe Das Ship-It-Friday-Ritual.)
  4. Schreib einen One-Pager. Was jede Person zusagt, was sie bekommt, wenn das Spiel Geld einspielt, was passiert, wenn sie geht. Das braucht keinen Anwalt. Es muss nur existieren.
  5. Einigt euch auf eine Antworterwartung. Achtundvierzig Stunden bei Blockern, fünf Tage bei Nicht-Blockern. Stille darüber hinaus ist ein Signal, kein Rätsel.

Das ist alles. Das Trello-und-eine-Karte-in-Doing-Muster von IndieGameClinic ist die günstigste Variante und sie funktioniert. Vier Spalten, eine Karte pro Person in Doing, für alle sichtbar.

Weg B: Sauber aussteigen

Du willst Weg A mit diesen Leuten nicht gehen, und das ist okay. Manche Discord-Projekte werden keine Teams, egal was du installierst, und die längste Lüge in Indie-Dev ist, sich das sechs Monate lang weiter einzureden.

Wie du gehst, ohne die schwachen Bindungen zu verbrennen, die du später brauchst:

  1. Sag es laut im Kanal. Ein Absatz. "Ich steige aus diesem Projekt aus. Danke für die Zeit, hier bin ich stehen geblieben, hier ist die Datei, die ihr braucht." Kurz. Kein Drama.
  2. Übergib, was du gebaut hast. Auch wenn es keiner aufnimmt. Ohne Übergabe zu gehen ist genau der Schritt, der die schwache Bindung für das nächste Mal vergiftet.
  3. Warte nicht darauf, gefragt zu werden. Je länger du schweigst, desto mehr wirst du Teil des Grundes, aus dem das Projekt stirbt.

Aussteigen ist kein Scheitern. In einem strukturlosen Projekt zu bleiben, weil du dich schuldig fühlst, schon. Wenn das Projekt dir auf Rev-Share verkauft wurde und die Zahlen nicht aufgehen, zeigen dir diese Red Flags, was du in Woche eins hättest sehen sollen. Wenn du immer wieder in Projekten landest, die dich ghosten, hat dieser Leitfaden zu r/INAT die Filter fürs nächste Mal.

Die Empfehlung

Draufsicht auf einen kleinen runden Holztisch mit einem Wochenkalender in der Mitte, ein Freitag-Demo-Block ist bernsteinfarben hervorgehoben, vier Plätze sind je mit einer namentlichen Karte und einer Tasse markiert.

Discord ist der Ort, an dem du Teammates findest. Es ist nicht der Ort, an dem du Spiele shippst.

Wenn dein Projekt über Woche drei hinaus ist und niemand am Freitag auf deine Arbeit zählt, ist das Problem nicht, wer im Raum ist. Es ist der Raum. Installiere die drei Nicht-Verhandelbaren, oder wechsel in eine Struktur, in der sie schon installiert sind.

Clowdr ist dieses zweite Ding. Gebaut um benannte Verantwortung, wöchentliche Demos, schriftliche Vereinbarungen und Übergaben statt Ghosts. Mitwirkende behalten ihre Rechte. Niemand ist in irgendeiner "Familie". Projekte shippen, weil jemand am Freitag auf die Arbeit zählt, jeden Freitag.

Bei Clowdr anmelden →

Wenn du mehr von der strukturellen Lösung willst, bevor du dich festlegst, fang mit Accountability Circles für das Kleinteam-Ritual an oder mit Wie du zuverlässige Teammates für dein Indie-Game findest für den Vetting-Teil. Beide nehmen dieselbe Position ein wie dieser Post: deine Disziplin ist in Ordnung. Deine Struktur nicht.

FAQ

Ist Discord schlecht für die Spieleentwicklung? Nein. Discord ist ein hervorragendes Chat-Tool und ein guter Community-Hub. Es ist ein schlechtes Projektmanagement-System, weil es kein Konzept von benannter Verantwortung, Deadlines oder Übergaben kennt. Nutze es für Community, nicht für Koordination.

Können kleine Indie-Teams ausschließlich mit Discord shippen? Ein Zweierteam mit starkem Vertrauen kommt oft mit Discord und Willenskraft durch. Ab drei Personen kippt die Rechnung und du brauchst explizite Struktur (Karten mit Ownern, ein wöchentliches Demo, eine schriftliche Vereinbarung). Die Schwelle ist klein.

Was ist der Unterschied zwischen einer Gamedev-Community und einem Gamedev-Team? Eine Community ist eine Gruppe mit einem gemeinsamen Interesse und ohne gemeinsames Lieferversprechen. Ein Team ist eine kleine Gruppe mit einem gemeinsamen Lieferversprechen und benannter Verantwortung für die einzelnen Teile. Die meisten "Teams" auf Discord sind in Wirklichkeit Communitys.

Woran erkenne ich, dass mein Discord-Projekt scheitern wird? Geh die sechs Diagnosefragen oben durch. Null bis zwei Ja ist ein starkes Scheitersignal. Der Einbruch nach anderthalb Monaten, nicht überprüfbare "Real-Life"-Abgänge und kein sichtbarer Output pro Person zwischen den Meetings sind die drei lautesten Spätsymptome.

Datenschutz-Auswahl

Cookies und Messung

Wir nutzen notwendige Speicherung, um deine Auswahl zu merken. Analytics- und Marketing-Speicherung bleiben aus, bis du sie erlaubst. Tracking-Tools sind noch nicht eingebaut, aber diese Auswahl ist bereits fuer Google Consent Mode v2 vorbereitet.