1
Eine Bearbeitung
Änderungen
K
todo..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.
todo.Ideenfindungstreffen sollten 2-3 Stück von der Orga mit einer Doodle Umfrage geplant werden.Der Ablauf ist grob unter [[GameDevWeek/Gamedesign]] beschrieben.
todo.Das Bootcamp läuft wie folgt ab: # Einführung LibGDX & CodeBase (Vortrag)# Git Theorie (Vortrag)# 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.
todoDie Ideen sollten idealerweise eine 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.
todoIst die Idee gewählt (oder die Ideen), so muss ein Plan her.Dieser wird in Trello dargestellt.* [[GameDevWeek/Trello|Beschreibung zu Trello]]* Beispiele vergangener GDWs:** [https://trello.com/b/1rRWWCKe/gdw-ss-15-minigames Balls of Steel]** [https://trello.com/b/jalv8Sf6/gdw-ss2014 Laser Chaser: Zombie Racer]** [https://trello.com/b/nq0tdyK3/gdw-ws-2014-15-pneumatic-man Pneumatic Man]* Beispiel für ein frisch erstelltes GDW Board, welches nicht genutzt wurde, da eine andere Idee umgesetzt wurde:* [https://trello.com/b/q1GH6nXp/gdw-ss-2014-15-hypnomon Hypnomon] 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 detailliert 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:[[Datei:gdw_ss2013_plan.png|600px|miniatur|left|Konzept zu Symbion]]<div style="clear: both;"></div>
todoEs 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 Fachseminar-Teilnehmerzu prüfen.d.h. jedem Fachseminar-Teilnehmer klar machen:* 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 der Fachseminar-Teilnehmer als durchgefallen.** Falls abgesprochen, muss die Zeit nachgeholt werden.
todoDer erste Tag sollte entspannt enden.Also idealerweise 18 Uhr Entwicklung stoppen:* Gemeinsames Abendessen (Grillen, Pizza ,...).* Offene Fragen besprechen.* Teams kennen lernen. Dieser entspannte Abend 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.
todoEs 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.
todo.Es sollte das Basisgameplay langsam stehen.Wenn nicht müssen Maßnahmen ergriffen werden.
todo.Freitag sollten die wichtigen Features fertig sein.Sie müssen noch nicht perfekt/fehlerfrei sein.
todo..Samstag sollte idealerweise nur noch für Bugfixes, Improvements, Tuning, Polishing verwendet werden.
todoSonntag 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.
todo* 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.
Ein paar grobe Rechtschreibfehler und Änderungen der Wortwahl.
Wer Interesse hat mal seine Führungsskills und Teamfähigkeit etwas auszubauen sollte definitiv mal bei der GDW Orga mitmachen.
Dabei ist verschiedenes Verschiedenes zu tun:
* Bei Ideenfindungstreffen helfen Grenzen und Probleme aufzuzeigen.
* Ausarbeitung eines Ablaufplans
* Teamerstellung und Arbeitsaufteilung
* Betreuung eines Teams und koordintion Koordination 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
=== Für die Ideenfindung ===
Keine Raumreservierung notwendig.. sucht euch einen Ort wo an dem es genug Platz gibt und Ruhe istherrscht. Notfalls auch im Fachschaftsraum.
=== Für das Bootcamp ===
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 für die Designer zu haben.
=== Vorstellung bei Informatik und Designstudenten ===
Diese Vorstellung kann mit [http://www.hochschule-trier.de/index.php?id=janine_kleinbauer 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/
* 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 Mails 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 aus Versehen in der alten Gruppe anmelden.
** Dazu den Zugang unter "Verwaltung" auf "Auf Anfrage" umstellen.
=== Terminfindung ===
Der Ideale ideale Termin:* Möglichst in der letzten Woche der Semesterferien.* Wenn Falls 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.
=== Vorträge organisieren ===
=== Transponder ===
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-Verzeichnisses.
Für beides Beides ist der Webmaster anzuschreiben (muss von einer Hochschul-Email Adresse verschickt werden!).
* GitHub: https://github.com/GameDevWeek/CodeBase/
=== Ideenfindungstreffen ===
=== Bootcamp ===
=== Ideenvorstellung/-wahl ===
=== Trelloboard/Plan erstellen ===
= Während der GameDevWeek =
=== Allgemeines ===
=== Tag 1 ===
=== Tag 2 ===
=== Tag 3/4 ===
=== Tag 5 ===
=== Tag 6 ===
=== Tag 7 ===
= Nachbereitungen =
[[Kategorie:GameDevWeek]]
