Dies hier ist ein vorläufiges Quasi - Anforderungsdokument (sowohl Was als auch Wie), das vorerst nur für angemeldete Nutzer sichtbar sein soll und später in den PneumaticMan Artikel umgebaut werden kann. Es kann von den GDW - Teilnehmern ergänzt werden, auf Bedarf.

=Spielidee=

Das Spiel "Pneumatic Man" ist ein Jump´n Run mit Höhlensetting im Sci-Fi-Design. Der Spieler, welcher sich auf einem springenden Superbohrer befindet, hat die Aufgabe seine verschütteten Kameraden zu befreien und den Levelausgang zu erreichen. Dabei wird er mit unterschiedlichen Fallen und Gegner konfrontiert, die ihm diese Aufgabe erschweren. Der Held befindet sich auf einem Superbohrer der gleichzeitig als Sprungmaschine genutzt wird. Dieser bohrt permanent und zerstört den Boden. Aus diesem Grund muss der Spieler sich schnell durch das Level bewegen, damit er nicht in Sackgassen oder Fallen fällt.

==Welt==

* Höhlensetting / Sci-Fi-Design: Der Aufbau der Welt ist in Blöcken
* fixer Start-/ Endpunkt für jede Map
* Im Level verstreut sind eingesperrte Kameraden. Eine bestimmte Anzahl an Kameraden ist essenziell für den erfolgreichen Levelabschluss, weitere gerettete Kameraden verbesern die Qualität des Levelabschlusses.
* Die Anzahl der im Level verstreuten Kameraden ist Variabel.
* Es ist möglich, das ein Level keine Kameraden zu retten enthält.
* Wird der Endpunkt ohne die geforderte Anzahl an befreiten Kameraden erreicht, wird eine entsprechende Meldung ausgegeben. (Die geforderte Anzahl kann auch 0 sein)
* Die Blöcke haben Haltbarkeiten, die bei jeder Berührung mit dem Bohrer sinkt bis er zerstört wird.
* Es gibt Blöcke mit verschiedener Haltbarkeit, u.A. auch unzerstörbare.
* Es gibt Blockarten die 1, 2, 3 (später: Typ 1, 2, 3) oder unendlich viele Bounces aushalten, bis sie zerstört werden.
* Der Zerstörungsradius der Bombenblöcke beträgt 2 Blöcke.
* Es gibt Bomben mit unterschiedlichen Explosionsradien (Optional)
* Springt der Charakter, entfernt er von Typ 1, 2 und 3 Blöcken jegliche Haltbarkeit des Blockes von dem er Abspringt und des Blockes wo er landet.
* Wenn der Spieler in der Mitte von zwei Blöcken bohrt, werden beide abgebaut mit der Hälfte des Einzelabbaus.
* Es gibt unzerstörbare Blöcke und Bombenblöcke die zeitverzögert explodieren und angrenzende Blöcke zerstören.
* Es gibt horizontal-bewegende Plattformen, die unzerstörbar sind.
* Es gibt keinen Fallschaden.
* Wird der Level erfolgreich beendet, erscheint ein WinScreen (es existiert bereits eine Teil-Graphik hierfür: transparentes Tablet).
* Der WinScreen enthält eine Checkliste an geretteten Kameraden.
* Stirbt der Charakter, wird das Level reseted.

===Fragen===

#Wie groß sollen die Level ungefähr ausfallen?
#Sitzen die zu befreienden Charakter IM Stein oder in Lücken in diesem?

==Fallen==

* Lavafontänen die in zeitlichen Abständen eine bestimmte Höhe nach oben schießen, und den Spieler töten.
* Herabfallende Steine, die durch einen Trigger ausgelöst werden, zerstören Blöcke / Spieler.
* Ein Stein kann auch beliebig vielen Blöcken bestehen (= komplexer Stein).
* Fällt dieser komplexe Stein herunter, werden alle kollidierenden Blöcke zerstört. Dies geschieht so lange, bis alle Schichten des komplexen Steins vernichtet wurden.
* Stacheln am Boden, Decke und Seiten.
* Stacheln hängen an Blöcken.
* Zerstört man den Block, an dem Stacheln hängen, fallen sie hinunter.
* Fallen Stacheln in Lava, werden sie zerstört.

===Fragen===
#Fallen Stacheln auf einen festen Block, bleiben sie dort liegen und fungieren weiterhin in ihrer Funktion als Stacheln? (Anmerkung: LevelDesigner und Designer wollten sich absprechen)
#Der Spieler stirbt sofort bei Berührung mit Stacheln in allen Lagen? Oder bei der flachen Seite nicht?
===Anmerkungen===
#Wenn riesige, herunterfallende Steine realisiert werden sollten, müsste man evtl. separat darüber nachdenken, wieviele Steine diese bei Berührung zerstören. Es existiert eine Überlegung das jede Reihe eines Riesensteins eine weitere Reihe neutralisiert. (Evtl. so bereits umsetzbar)

==Spieler==

* Der Spieler springt dauerhaft und kann nicht nicht-springen (bouncen). Bzw.: Der Spielercharakter kann auf einem Punkt springen, aber nicht still stehen.
* Jede hoch-runter Bewegung entfernt auf dem darunter liegenden Block 1 Haltbarkeit.
* Der Charakter springt nicht in festen Rastern.
* Landet ein Charakter zwischen zwei Blöcken, zerstört er bei beiden die hälfte der Haltbarkeit, die er normalerweise bei nur einem Block zerstören würde.
* Begriffsäquivalenz: "Gehen", Bouncen, Bohren.
* Der Spieler kann springen mittels Tastendruck.
* Wärend dem Sprung kann man die Richtung des Sprungs ändern.
* Die maximale Sprungdistanz beträgt in der Breite 2 Tiles.
* Sind alle Blöcke unter dem Charakter zerstört und er berührt die Lava darunter, stirbt er.
* Stirbt der Charakter ist er sofort tot, es gibt keine Lebensanzeige.
* Der Charakter hat nur ein Leben, es gibt also auch keine Anzahl an Leben ungleich 1.
* Stirbt der Charakter, muss es möglich sein, sich in den Highscore einzutragen.
* Größe der Spielfigur: 1,5 Blöcke
* Standardbewegung des Helden beträgt in der Höhe 0,5 Block (in der Animation, nicht Physikalisch)
* Sprunghöhe beträgt 3 Blöcke
* Die Bewegungsweite, egal ob Sprung oder Bounce beträgt bei Maximalbeweung 2 Blöcke.
* Der Spieler soll eine Art Supersprung / Doppelbounce bekommen (Optional)
* Der Spieler kann nicht rutschen, nur springen.

===Fragen===

#Wie würde der Doppelbounce funktionieren? (doppelter Tastendruck?)
#Die Bewegungsweite, egal ob Sprung oder Bounce beträgt bei Maximalbeweung 2 Blöcke: müsste es nicht Entfernung je Zeiteinheit sein?

==Gegner==
* Eine Gegnerart die sich auf festen Pfaden bewegt. Bei Berührung stirbt der Spieler.
* Der Gegner Lavafontäne schiesst in regelmässigen Abständen aus der Lava hervor und tötet den Spieler auf berührung.
* Der Gegner Gesteinsbrocken fällt von oben herrunter, zerstört den ersten Block auf den er fällt und tötet den Spieler, wenn er ihn von oben trifft.
* Der Gesteinsbrocken zerstört KEINE unzerstörbaren Blöcke, der Gesteinsbrocken wird jedoch an dieser Stelle zerstört.
* Der Gegner Bombe befindet sich in Blöcken und zündet, sobald der Spieler darauf landet. (Siehe Fragen)
* Befindet sich eine Bombe innerhalb des Umkreises einer Explosion (z.B. von einer Bombe), so explodiert diese auch.
* Der Zerstörungsradius der Bombenblöcke beträgt 2 Blöcke.
* Der Gegner glücklicher, dicker Hund springt auf den Spielercharakter zu und zerstört dabei nach den selben Regeln wie der Spielercharakter Blöcke.
* Der glückliche, dicke Hund lässt sich töten, indem man ihn von oben bespringt.
* Der glückliche, dicke Hund stirbt, wie der Spieler bei allen Fallenarten die tödlich sind, triggert aber keine Events.
* Erreicht der glückliche, dicke Hund den Spieler, stirbt der Spieler.
===Fragen===
#Es gibt auch schräge Blöcke: problematisch wegen Bombe?
#Gibt es einen Countdown bis die Bombe explodiert? Wenn ja wie lang?

#Wie funktionieren die Stacheln?

==Items (optional) ==
* Es gibt einen Power Up Helm, das ein Sterben durch ein Ereignis, das von oben kommt, ein mal verhindert. (optional)
* Es gibt Item-Blöcke, aus denen Power Up's spawnen (optional).
* Es gibt Sprungfeder-Blöcke, die den Spieler höher springen lassen, wenn man darauf springt. Diese gehen nicht kaputt. (optional)
* Es gibt Gegner, die Projektile verschiessen in geraden linien. Dre Spieler kann auf diese Projektile springen um sie als Plattform zu benutzen (optional)
* Analog zu Wurfparabel-Projektilen (optional)

==Menü / HUD==

* Es gibt eine Levelauswahl.
* Bei der Levelauswahl ist auf jeden Fall das erste Level auswählbar.
* Hat man ein Level oder eine Reihe von Leveln erfolgreich beendet, wird, bei Aufruf des Menü's, dort auch das nächste Level zur Auswahl angezeigt.
* Hat man ein Level erfolgreich beendet, kommt der WinScreen.
* Auf dem WinScreen wird sowohl separat gerettete Arbeiter, Anzahl vollständig zerstörter Blöcke und benötigte Zeit, als auch der errechnete Highscore in Form einer Zahl angezeigt.
* Wärend dem eigendlichen Spiel wird die Anzahl der zerstörten Blöcke angezeigt, eventuell auch die Anzahl der geretteten Arbeiter.

==Umsetzungsdetails==
Hier kommen Umsetzungsdetails hinein, die auch implementarische Details beinhalten können.

===Details zur Steuerung===
* Die Bewegungsgeschwindigkeit ist bei der Gamepad-Steuerung abhängig von der Anschlagsweite des Analogsticks.
* Schlägt man den Analogstick des Gamepads voll in eine Richtung an, soll die Maximalgeschwindigkeit ausgelöst werden. Je weniger der Stick in eine Richtung gedrückt wird, desto weniger Geschwindigkeit soll die Figur haben.
====Fragen====
#Bei einem Tastendruck wird eine Startgeschwindigkeit von x%, je länger der Tastendruck ist, desto mehr Geschwindigkeit soll addiert werden. Nach 1s (startwert! muss getestet werden) soll die Maximalgeschwindigkeit erreicht werden?

===Details zur Tilemap===
(unvollständig)

* alles englisch (Name, Eigenschaften usw.)
* Camelcase
* Ein Layer mit allen Objekten mit denen man kollidieren kann
* Tile properties: Invulnerable (true/false), Hitpoint (int), Type (Lava, Floor, Spike/Stacheln, )
* Eigenschaften für Objekte:
** Name: Player,
** Name: LavaFountain, Intervall: float, Height: float(in Kacheln), IntervallOffset: float, length: float
** Name: RockTrigger, Id: (int) passend zur id der Steine,
** Name: Rock, TriggerId: (int) ref auf Id vom Trigger,

Pneumatic Man

2015-03-17T13:06:24Z

Cypria: Die Seite wurde neu angelegt: „Dies hier ist ein vorläufiges Quasi - Anforderungsdokument (sowohl Was als auch Wie), das vorerst nur für angemeldete Nutzer sichtbar sein soll und später i…“

GameDevWeek/Trello

2015-03-16T12:09:08Z

Cypria:

Trello ist ein web-basierte Projektmanagement Tool und wird zur GDW verwendet. In der GDW SS 2014/15 wird es zusammen mit einer angepassten Variante von Kanban verwendet. Im Gegensatz zu vorherigen GDW's ist es vonnöten, das ''jeder'' Trello nutzt. Es enthält einige Funktionalitäten mit denen man einen Kanban-Prozess abbilden kann, jedoch nicht alle. Die Limitierung für bestimmte Spalten werden beispielsweise nicht unterstützt, daher werden diese Manuell erwähnt und festgehalten.

=Listen=
Es gibt einige Listen die einen Kanban-Prozess unterstützen sollen.
==Todo==
Wird von der Orga mit Karten von der Liste Potentielle Features befüllt. Alle anderen beteiligten ''nehmen'' sich durch drag and drop Karten, die sie bearbeiten möchten und ziehen sie in die Liste In Progress. Die Liste Todo ist hierbei nicht durch eine maximalkartenanzahl beschränkt.
Wenn eine Karte mit einem Bug-Label bestückt ist, hat diese für die Gruppen, die sie bearbeiten können, Vorrang.

===Checkliste===
Das kanbanartige Vorgehen hat den Vorteil, das man auch recht schwammig Anforderungen einpflegen kann. Solche Karten haben dann Markierungen für mehrere mögliche Gruppen, die sie bearbeiten können. Die detaillierteren Schritte können dann in Checklisten innerhalb dieser Karten angegeben werden.

Entschliesst sich ein Mitglied einer dieser Gruppen dazu einen Punkt der Checkliste zu bearbeiten, konvertiert er diesen Punkt zu einer Karte, markiert die neu entstandene Karte mit dem Gruppenlabel, zieht die Karte entsprechend in die Liste In Progress und setzt sich in die Zuständigkeit.

Das die Karte aus einer Checkliste einer anderen Karte entstanden ist lässt sich unter Activity nachlesen, und somit zu seinem Ursprung verfolgen.

Karten mit Checklisten sollten nur in Todo stehen, jedoch lässt es sich nicht ausschliessen, das es auch Sinn machen kann welche in Ready for testing zu erstellen.

Gibt es eine Karte mit einer Checkliste, die aber mehrere Beteiligte durcharbeiten müssen, muss der Teamleader dafür sorgen, das das Häkchen der Checkbox erst dann gesetzt wird, wenn jeder diesen Punkt durchgearbeitet hat. Diese Mehrarbeit für den Teamleader lässt sich leider nicht umgehen.

==In Progress==
Wird eine Karte bearbeitet, sei es von Designern, Programmierern, Töne-machern oder sonstigen, landet die Karte in In Progress. Die Person, die diese Karte bearbeitet, setzt seinen Trello-namen darunter, damit man sieht wer es bearbeitet.
Es ist gar möglich, das mehrere Leute an einer Karte arbeiten, dann setzen diese ihre Namen darunter.

Ist eine Karte erfolgreich abgearbeitet, landet sie in der Liste Ready for testing.
Gibt es ein Problem, wird die Karte in die Liste Blocked verschoben, im Idealfall mít einem kurzen Kommentar, wo das Problem liegt.

Es sollte nicht vergessen werden das, wenn die Karte fertig bearbeitet ist, die personelle Zuständigkeit des Bearbeiters von der Karte wieder gelöscht wird, sonst kann man später nicht mehr feststellen wer aktuell die Karte am bearbeiten ist. Sollte es notwendig sein, vorherige zuständige zu identifizieren, ist dies immer noch möglich, da man beim hinzufügen eines Members und beim löschen der Zuständigkeit Activitys auf der Karte hinterlässt, die weiterhin lesbar sind.

==Blocked==
Hier landen Karten die aus unterschiedlichen Gründen nicht weiterbearbeitet werden können. Sei es, das ein Designer Abhängigkeiten von Dateien zu Dateien eines Anderen hat, der noch nicht fertig ist, sei es, das ein Programm als fehlerhaft getestet wurde oder ein Programmierer ein Problem hat, mit dem er allein nicht weiterkommt.

Damit Probleme direkt angegangen werden, haben die Listen In Progress und Blocked zusammen eine Maximalkartenanzahl, damit vom Arbeitsablauf schon formalisiert wird, das demjenigen im Team der ein Problem hat, geholfen wird.

==Ready for testing==
Sobald ein Teil des Projektes soweit fertiggestellt ist wird es in die Liste Ready for testing geschoben. Derjenige, der etwas testen will, auf welche Art und Weise auch immer, zieht sich die Karte in Test und stellt über Members seine Zuständigkeit für die Karte ein. Man könnte die Paralelle ziehen, das Ready for testig für die Tester so etwas wie Todo für die Ersteller ist.

Ready for testing hat zusammen mit der Liste Test eine zahlenmäßige Beschränkung, wieviel Karten zeitgleich hier enthalten sein können. Dies hat den Effekt, das wenn die Tester nicht hinterher kommen, andere ihnen helfen sollten, da anscheinend ein Ungleichgewicht existiert.

==Test==
Hier befinden sich Karten, die sich gerade im Test befinden zusammen mit der Kartenzugehörigen Zuständigkeit des Members der/die testet.

Wird ein Fehler gefunden, wird ein Bug-Label hinzugefügt und wieder in Todo geschoben. Hierbei darf wiederum nicht vergessen werden, die aktuelle Zuständigkeit von der Karte zu lösen.

Wird die Karte erfolgreich getestet und als funktionierend kategorisiert, wird sie in die Liste Done geschoben.

==Done==
Hier befinden sich Karten die fertig und erfolgreich abgearbeitet wurden.
Sie sollten eigendlich nicht weiter angefasst werden müssen, da sie zu dem fertigen, funktionierenden Projekt gehören.

==Potentielle Features==
Dies ist eine Liste, die nur von der Orga angefasst wird. In ihr landen potenzielle Features, sowohl Core-Features, als auch Nice-to-have's. Die Orgamitglieder entscheiden hierbei, was als nächstes ansteht, und befüllen damit die Liste Todo.

=Labels=
Labels sind hier Farbmarkierungen, die auch benannt werden können. Sie gehören zu den sehr variablen Möglichkeiten von Trello. Hier werden sie benutzt um Bug's und Gruppen zu markieren.

==Bug Label==
Das Bug Label ist ein rotes Label mit entsprechender Beschriftung und stellt dar, das eine Karte in der Liste Todo vorrang haben muss vor anderen für die Gruppen, die diese bearbeiten können.

==Gruppen Labels==
GruppenLabels sind verschiedenfarbige Labels mit entsprechender Beschriftung. Sie stellen dar, welche Gruppen eine Karte bearbeiten können.
Daher ist es auch Sinnvoll das Trello - Board nach Labels zu filtern, damit man nur Karten sieht, an denen man etwas ändern kann.

=Gruppenzugehörigkeit=
Die Gruppenzugehörigkeit der Personen muss erkennbar sein. Daher sollte jeder seine Gruppenzugehörigkeit in seinem Profil unter Bio notieren, damit man auf Bedarf nachsehen kann.

[[Kategorie:GameDevWeek]]

GameDevWeek/Trello

2015-03-13T16:06:29Z

Cypria: Die Seite wurde neu angelegt: „Trello ist ein web-basierte Projektmanagement Tool und wird zur GDW verwendet. In der GDW SS 2014/15 wird es zusammen mit einer angepassten Variante von Kanban…“

Trello ist ein web-basierte Projektmanagement Tool und wird zur GDW verwendet. In der GDW SS 2014/15 wird es zusammen mit einer angepassten Variante von Kanban verwendet. Im Gegensatz zu vorherigen GDW's ist es vonnöten, das ''jeder'' Trello nutzt. Es enthält einige Funktionalitäten mit denen man einen Kanban-Prozess abbilden kann, jedoch nicht alle. Die Limitierung für bestimmte Spalten werden beispielsweise nicht unterstützt, daher werden diese Manuell erwähnt und festgehalten.

=Listen=
Es gibt einige Listen die einen Kanban-Prozess unterstützen sollen.
==Todo==
Wird von der Orga mit Karten von der Liste Potentielle Features befüllt. Alle anderen beteiligten ''nehmen'' sich durch drag and drop Karten, die sie bearbeiten möchten und ziehen sie in die Liste In Progress. Die Liste Todo ist hierbei nicht durch eine maximalkartenanzahl beschränkt.
Wenn eine Karte mit einem Bug-Lable bestückt ist, hat diese für die Gruppen, die sie bearbeiten können, Vorrang.

===Checkliste===
Das kanbanartige Vorgehen hat den Vorteil, das man auch recht schwammig Anforderungen einpflegen kann. Solche Karten haben dann Markierungen für mehrere mögliche Gruppen, die sie bearbeiten können. Die detaillierteren Schritte können dann in Checklisten innerhalb dieser Karten angegeben werden.

Entschliesst sich ein Mitglied einer dieser Gruppen dazu einen Punkt der Checkliste zu bearbeiten, konvertiert er diesen Punkt zu einer Karte, markiert die neu entstandene Karte mit dem Gruppenlable, zieht die Karte entsprechend in die Liste In Progress und setzt sich in die Zuständigkeit.

Das die Karte aus einer Checkliste einer anderen Karte entstanden ist lässt sich unter Activity nachlesen, und somit zu seinem Ursprung verfolgen.

Karten mit Checklisten sollten nur in Todo stehen, jedoch lässt es sich nicht ausschliessen, das es auch Sinn machen kann welche in Ready for testing zu erstellen.

==In Progress==
Wird eine Karte bearbeitet, sei es von Designern, Programmierern, Töne-machern oder sonstigen, landet die Karte in In Progress. Die Person, die diese Karte bearbeitet, setzt seinen Trello-namen darunter, damit man sieht wer es bearbeitet.
Es ist gar möglich, das mehrere Leute an einer Karte arbeiten, dann setzen diese ihre Namen darunter.

Ist eine Karte erfolgreich abgearbeitet, landet sie in der Liste Ready for testing.
Gibt es ein Problem, wird die Karte in die Liste Blocked verschoben, im Idealfall mít einem kurzen Kommentar, wo das Problem liegt.

Es sollte nicht vergessen werden das, wenn die Karte fertig bearbeitet ist, die personelle Zuständigkeit des Bearbeiters von der Karte wieder gelöscht wird, sonst kann man später nicht mehr feststellen wer aktuell die Karte am bearbeiten ist. Sollte es notwendig sein, vorherige zuständige zu identifizieren, ist dies immer noch möglich, da man beim hinzufügen eines Members und beim löschen der Zuständigkeit Activitys auf der Karte hinterlässt, die weiterhin lesbar sind.

==Blocked==
Hier landen Karten die aus unterschiedlichen Gründen nicht weiterbearbeitet werden können. Sei es, das ein Designer Abhängigkeiten von Dateien zu Dateien eines Anderen hat, der noch nicht fertig ist, sei es, das ein Programm als fehlerhaft getestet wurde oder ein Programmierer ein Problem hat, mit dem er allein nicht weiterkommt.

Damit Probleme direkt angegangen werden, haben die Listen In Progress und Blocked zusammen eine Maximalkartenanzahl, damit vom Arbeitsablauf schon formalisiert wird, das demjenigen im Team der ein Problem hat, geholfen wird.

==Ready for testing==
Sobald ein Teil des Projektes soweit fertiggestellt ist wird es in die Liste Ready for testing geschoben. Derjenige, der etwas testen will, auf welche Art und Weise auch immer, zieht sich die Karte in Test und stellt über Members seine Zuständigkeit für die Karte ein. Man könnte die Paralelle ziehen, das Ready for testig für die Tester so etwas wie Todo für die Ersteller ist.

Ready for testing hat zusammen mit der Liste Test eine zahlenmäßige Beschränkung, wieviel Karten zeitgleich hier enthalten sein können. Dies hat den Effekt, das wenn die Tester nicht hinterher kommen, andere ihnen helfen sollten, da anscheinend ein Ungleichgewicht existiert.

==Test==
Hier befinden sich Karten, die sich gerade im Test befinden zusammen mit der Kartenzugehörigen Zuständigkeit des Members der/die testet.

Wird ein Fehler gefunden, wird ein Bug-Lable hinzugefügt und wieder in Todo geschoben. Hierbei darf wiederum nicht vergessen werden, die aktuelle Zuständigkeit von der Karte zu lösen.

Wird die Karte erfolgreich getestet und als funktionierend kategorisiert, wird sie in die Liste Done geschoben.

==Done==
Hier befinden sich Karten die fertig und erfolgreich abgearbeitet wurden.
Sie sollten eigendlich nicht weiter angefasst werden müssen, da sie zu dem fertigen, funktionierenden Projekt gehören.

==Potentielle Features==
Dies ist eine Liste, die nur von der Orga angefasst wird. In ihr landen potenzielle Features, sowohl Core-Features, als auch Nice-to-have's. Die Orgamitglieder entscheiden hierbei, was als nächstes ansteht, und befüllen damit die Liste Todo.

=Lables=
Lables sind hier Farbmarkierungen, die auch benannt werden können. Sie gehören zu den sehr variablen Möglichkeiten von Trello. Hier werden sie benutzt um Bug's und Gruppen zu markieren.

==Bug Lable==
Das Bug Lable ist ein rotes Lable mit entsprechender Beschriftung und stellt dar, das eine Karte in der Liste Todo vorrang haben muss vor anderen für die Gruppen, die diese bearbeiten können.

==Gruppen Lables==
Gruppenlables sind verschiedenfarbige Lables mit entsprechender Beschriftung. Sie stellen dar, welche Gruppen eine Karte bearbeiten können.
Daher ist es auch Sinnvoll das Trello - Board nach Lables zu filtern, damit man nur Karten sieht, an denen man etwas ändern kann.

=Gruppenzugehörigkeit=
Die Gruppenzugehörigkeit der Personen muss erkennbar sein. Daher sollte jeder seine Gruppenzugehörigkeit in seinem Profil unter Bio notieren, damit man auf Bedarf nachsehen kann.