GameDevWeek/Organisation

Aus /dev/null
< GameDevWeek
Wechseln zu: Navigation, Suche

Als Organisator übernimmt man die Position des Managements. In erster Linie wird die Planung der GDW von den Event Managern des Fachschaftsrats oder von Fachseminarteilnehmern übernommen. Zudem können Freiwillige Helfer bei der Organisation helfen.

Überblick

Wer Interesse hat mal seine Führungsskills und Teamfähigkeit etwas auszubauen sollte definitiv mal bei der GDW Orga mitmachen. Dabei ist verschiedenes zu tun:

  • Bei Ideenfindungstreffen helfen Grenzen und Probleme aufzuzeigen.
  • Technologien vorbereiten.
  • Ausarbeitung eines Ablaufplans
  • Teamerstellung und Arbeitsaufteilung
  • Betreuung eines Teams und koordintion mit den anderen Teams.
    • Oder als “Chef”- Orga die Organisatoren betreuen.
  • Überwachung des Fortschritts um Engpässe frühzeitig zu erkennen.
  • Kommunikation zwischen den Teams koordinieren.
  • Bei Problemen mit Versionskontrolle, Entwicklungsumbebung, etc. helfen
  • Einführungen in verschiedene Themengebiete geben, wie z.B. Git, libGDX oder Tiled.
  • Dokumentation der entstandenen Spiele auf der Webseite.

Raumreservierung

Der Dekan sollte vorher gefragt werden, ob die GDW am gewählten Termin stattfinden darf.. dem steht normalerweise nichts im Wege. Die Räume für die GDW selbst sollten möglichst früh reserviert werden, da es hier am ehesten zu Konflikten kommt. Die Räume für die anderen Termine können auch später reserviert werden, es sollte aber auch hier etwas Vorlaufzeit eingeplant sein.

Räume werden bei Manfred Stüber per EMail reserviert. Bitte nicht mündlich, da es da es dann nicht offiziell ist.

Für die Ideenfindung

Keine Raumreservierung notwendig.. sucht euch einen Ort wo Platz und Ruhe ist. Notfalls Fachschaftsraum.

Für das Bootcamp

  • Einen großen Poolraum im X- oder L-Gebäude. Mind. 4 Stunden einplanen.

Für die Ideenvorstellung

  • Idealerweise den großen Seminarraum im X-Gebäude (X15).
  • Alternativ auch L104.

Für die GDW selbst

  • Alle Räume 7 Tage von Morgens bis Abends außer dem Vorstellungsraum!
  • Idealerweise:
    • Die 3 Poolräume im X-Gebäude (X18, X19 und X20).
    • 1-2 der normalen Seminarräume im X-Gebäude (X16 und X17).
    • Den großen Seminarraum im X-Gebäude (X15) zumindest für die Vorstellung der Ergebnisse am Sonntag (15:30-17:00)
  • Alternativ:
    • Im L-Gebäude alle Räume (L1=>Seminarraum, L2 und L3 => Poolräume) im unteren Stockwerk.
    • L104 für die Vorstellung der Ergebnisse am Sonntag (15:30-17:00)

Vorbereitungen

Mitorganisatoren finden

Die Organisation der GDW ist nicht zu unterschätzen. Pro entwickeltes Spiel sollten mind. 2 Organisatoren vorhanden sein. C++ kommt in der Regel mit einem aus.

Wenn das Team nicht groß genug ist, sollten Studierende um Hilfe gebeten werden. Dies kann mittels Umschreiben im Verteiler geschehen. Es ist auch hilfreich einen Organisator innerhalb der Designer zu haben.

Vorstellung bei Informatik und Designstudenten

Eine Vorstellung bei den Informatikern ist mittlerweile nur bei den Erstsemestern notwendig. Diese Vorstellung kann mit Janine Kleinbauer abgesprochen werden und sollte idealerweise in der ersten oder zweiten Semesterwoche geschehen.

Die Vorstellung bei den Designern ist notwendig und sollte ausreichend früh durchgeführt werden, da es nahezu immer chronisch an Designern mangelt.

Eine fertige Präsentation zur GDW kann hier gefunden werden: http://prezi.com/dlak_mcgcnxq/gamedevweek-info/

Stud.IP Gruppe(n) erstellen

Es wird eine Stud.IP Gruppe benötigt. Dabei ist das Format: GameDevWeek <Semester>, also z.B.:

  • GameDevWeek SS15
  • GameDevWeek WS15/16

Zu erstellen ist diese im Stud.IP unter: Community->Studiengruppen->Neue Studiengruppe anlegen. Als Modul wird lediglich "Forum" benötigt. Der Zugang sollte "offen für alle" sein.

In dieser Gruppe sollten wichtige Informationen gesammelt werden:

  • Kurzinfos in die Beschreibung und detailliertere Infos ins Forum.
  • Spielideen können im Forum vorgestellt und diskutiert werden.
  • Zudem kann die Gruppe genutzt werden um allen Teilnehmern Infos zu schicken.
    • Spätestens nach der Ideenvorstellung sollte keine Mail mehr über den Studentenverteiler gehen müssen, sondern über die Gruppe gehen.

Weitere Infos:

  • Das Feature "Ankündigung" verschwindet nach einiger Zeit, vermeidet es also.
  • Es gibt immer nur einen Gruppengründer, also Vorsicht mit der Funktion "Gruppengründer: xxx << [yyy]". Man verliert dabei also den Gruppengründer Status.
  • Die Stud.IP Gruppe sollte nach Ende der GDW geschlossen werden, damit sich nicht Teilnehmer für die nächste GDW ausversehen in der alten anmelden.
    • Dazu den Zugang unter "Verwaltung" auf "Auf Anfrage" umstellen.

Terminfindung

Der Ideale Termin:

  • Möglichst in der letzten Woche der Semesterferien
  • Wenn möglich mit einem Tag Puffer vor dem Semesterstart (zum Erholen).
  • Sollte in dieser Woche ein Feiertag sein, um eine Woche vorziehen.
  • Im Notfall einen Doodle an alle Studierenden schicken.

Am Freitag vorher, ggf. wegen Feiertagen an einem früherem Tag sollte die Ideenvorstellung stattfinden.

Sobald diese beiden Termine stehen sollten die Räume entsprechend reserviert werden. Sollten nur wenige Tage später weitere Termine für Raumreservierungen stehen, so kann darauf natürlich gewartet werden.

Einschränkungen definieren

Um nicht jedes mal sehr ähnliche Spiele zu erstellen, sollten leichte Vorgaben gemacht werden. Folgendes sind Vorgaben von vergangenen GDWs:

  • Ein Netzwerkspiel (Kann nur dann gemacht werden wenn es Netzwerkprogrammierer gibt, muss vorher feststehen)
  • Ein Multiplayerspiel ohne Netzwerk (an einem PC)
  • Kein Top-Down Arena Spiel (da zu oft vorgekommen)
  • Thema Magnetismus (war allerdings zu einschränkend)

Für die Java Gruppe gilt generell immer:

  • Es muss ein 2D Spiel sein

In der C++ Gruppe wurde bisher hingegen immer ein 3D Spiel umgesetzt (dies musste vom Umfang her allerdings sehr überschaubar sein).

Vorträge organisieren

Während des Bootcamps und währen der GDW werden Vorträge benötigt zu folgenden Themen:

  • Bootcamp:
    • IDE Aufsetzen
    • GIT
    • LibGDX
    • CodeBase
  • GDW:
    • OwnCloud
    • Trello
    • Map Editor

Falls die Organisatoren dafür keine Zeit haben, müssen sie Studenten anschreiben.

Transponder

Es wird ein Transponder benötigt mit Zugang für die jeweiligen Gebäude und Räume. Dies ist ein elektronischer Schlüssel, den man vorher beantragen muss. Die Kontaktperson hierfür ist Christian Bettinger.

Dies sollte idealerweise noch vor der Readingweek geschehen, da sonst ggf. keine Transponder mehr verfügbar sind.

GitLab & OwnCloud

Die Codebasis liegt auf GitHub, allerdings bringen wir sie temporär während der GDW für die Spiele auf GitLab, damit uns Internetausfall und GitHub Downtimes nicht stören. Der Masterbranch der CodeBase sollte auf GitLab geklont werden und dann ein "develop" Branch abgezweigt werden. Für jede Java Gruppe muss ein separates Repo angelegt werden.

Dateisharing mit Designern geschieht mittels eines eines Owncloud Verzeichnises.

Für beides ist der Webmaster anzuschreiben (muss von einer Hochschul-Email Adresse verschickt werden!).

Pre-Events

Ideenfindungstreffen

Ideenfindungstreffen sollten 2-3 Stück von der Orga mit einer Doodle Umfrage geplant werden. Der Ablauf ist im groben und ganzen unter GameDevWeek/Gamedesign beschrieben.

Bootcamp

Das Bootcamp läuft wie folgt ab:

  1. Einführung LibGDX & CodeBase (Vortrag)
  2. Git Theorie (Vortrag)
  3. Hilfestellung für:
    • Git Conflict Übungen
    • IDE Aufsetzen

Die Reihenfolge ist wichtig, da der Punkt Hilfestellung sehr lange dauern kann und einige dies nicht benötigen. Jeder der dann schon fertig ist kann gehen.

Ideenvorstellung/-wahl

Die Ideen sollten idealerweise 1 Woche vor der GDW eingereicht werden. Entweder in Form eines Dokuments oder in Form einer Vorab-Präsentation, so dass die Orga noch anmerkungen geben kann was die Vollständigkeit und das Verständnis angeht.

Bei der Ideenvorstellung hat dann jeder die Möglichkeit seine Ideen vorzustellen. Danach werden die Ideen noch einmal aufgelistet und mit Handzeichen abgestimmt:

  • Jeder hat eine Erststimme und eine Zweitstimme.
  • Das Spiel mit den meisten Erststimmen gewinnt.
    • Gibt es keine eindeutige Mehrheit, bestimmt die Zweitstimme.
    • Ist auch dann das Ergebnis nicht eindeutig, kann nochmal unter den populärsten 2-3 Ideen abgestimmt werden.

Falls zwei oder drei Spiele umgesetzt werden, wird das Verfahren oben natürlich entsprechend angepasst. Ist eine gewählte Idee nicht genug ausgearbeitet oder zu umfangreich, müssen die Teilnehmer abstimmen, ob neu gewählt wird, oder die Idee noch einmal überarbeitet wird. Im letzteren Fall muss ein Team sich im Anschluss der Wahl darum kümmern dies zu tun.

Trelloboard/Plan erstellen

Ist die Idee gewählt (oder die Ideen), so muss ein Plan her. Dieser wird in Trello dargestellt.

Wie man bei einigen der Beispielen sehen kann, wird zum Ende hin gern mal die Pflege des Board vernachlässigt. Hier muss man dann Nachdruck verleihen.

Wichtig bei diesem Board ist vor allem:

  • Es sollte schnell zu einem Prototypen kommen der die Basisfeatures umsetzt.
  • Aufgaben sollten Detailiert genug beschrieben werden, dass klar ist worum es geht. Bei Details kann auch auf die Ideenbeschreibung verwiesen werden.
  • Das Backlog beinhaltet zu Beginn alle Tasks die zu tun sind, hier dürfen nur die Organisatoren ran.
    • Bei Bedarf Ziehen die Orgas Tasks vom Backlog in die Todo Liste.
  • Die Todo Liste sollte immer etwas für jeden Bereich (Physik, Rendering, etc.) beinhalten um konstante Beschäftigung zu gewährleisten.
    • Allerdings auch nicht zu viel pro Bereich, da sonst nicht klar ist was als Nächstes zu tun ist oder zu viel parallel bearbeitet wird.

Bevor Trello benutzt wurde, kamen andere Verfahren zum Einsatz. Dieses Beispiel für Symbion zeigt den Ablauf der einzelnen Bereiche recht gut:

Konzept zu Symbion

Während der GameDevWeek

Allgemeines

Es existiert ein Trelloboard, welches die zu erledigenden Aufgaben abbildet. Dieses wird für jede GDW einfach gesäubert/zurückgesetzt: https://trello.com/b/doWpU1xv/gdw-orga

Abseits dessen ist täglich die Anwesenheit der Fachseminarteilnehmer zu prüfen. D.h. jedem Fachseminarteilnehmer klarmachen:

  • Er/sie muss sich bei der Orga an- und abmelden.
  • In der Kernzeit anwesend sein.
  • Mind. 8 Stunden am Tag (Sonntag nur 6).
  • Bei erster nicht abgesprochener Nichteinhaltung Mahnung aussprechen.
    • Beim zweiten Mal gilt es als durchgefallen.
    • Falls abgesprochen muss die Zeit nachgeholt werden.

Tag 1

Der erste Tag sollte entspannend enden. Also idealerweise 18 Uhr Entwicklung stoppen:

  • Gemeinsames Abendessen (Grillen, Pizza ,...).
  • Offene Fragen besprechen.
  • Teams kennenlernen.

Dieser Entspannungsteil hat sich als hilfreich erwiesen, da der Stress am ersten Tag besonders hoch ist und über Di, Mi und Do nicht abgebaut werden kann.

Falls noch nicht geschehen sollte eine Mail an Studierende, Professoren und Mitarbeiter geschickt werden mit dem Hinweis auf die Vorstellung der Ergebnisse am Sonntag um 16:00.

Tag 2

Es sollten nun alle am Arbeiten sein. Wenn noch jemand am Setup sitzt, sollte er/sie:

  • es entweder selbst innerhalb von 1-2 Stunden hinbekommen
  • nicht mit wichtigen Aufgaben betreut sein
  • ggf. auf Level Editing und Testing umsteigen.

Tag 3/4

Es sollte das Basisgameplay langsam stehen. Wenn nicht müssen Maßnahmen ergriffen werden.

Tag 5

Freitag sollten die wichtigen Features fertig sein. Sie müssen noch nicht perfekt/fehlerfrei sein.

Tag 6

Samstag sollte idealerweise nur noch für Bugfixes, Improvements, Tuning, Polishing verwendet werden.

Tag 7

Sonntag können bis 14:00 Uhr letzte Änderungen durchgeführt werden:

  • Um 14:00 werden dann alle gebeten die Arbeit niederzulegen.
  • Um 14:30 sollten nur noch eine handvoll Personen am Code sitzen. Alle anderen sollen den Raum verlassen.
  • Um 15:00 sollte alles abgeschlossen sein.
  • Jemand, der nichts mehr zu tun hat sollte eine Präsentation vorbereiten.
  • Ein Entwickler wird bestimmt, der den letzten Cleanup durchführt und das Spiel lauffähig zusammenpackt.
    • Parallel sollte jemand sich drum kümmern dass die Poolrechner alle mit dem Gastaccount (der zu besorgen war) eingeloggt sind, so dass Besucher alle das Spiel testen können.
  • 15:30 Sollte das Spiel fertig gepackt sein und somit auf die Poolrechner kopiert werden können. Am besten auf NetPrint ablegen und von dort auf alle Rechner ziehen (auf den Desktop).
  • 16:00 Wird die Präsentation gehalten und danach in die Poolräume zum testen eingeladen.

Nachbereitungen

  • Die Stud.IP Gruppe sollte geschlossen werden, so dass sich niemand mehr anmelden kann.
  • Je Spiel sollte eine Wikiseite erstellt werden. Dies kann auch idealerweise direkt während der GDW geschehen.
  • Der Code sollte von GitLab zurück auf GitHub, aber das ist nicht all zu dringend.
Abgerufen von „https://fsi.hochschule-trier.de/wiki/index.php?title=GameDevWeek/Organisation&oldid=1030“