Meine ersten Hackathon-Erfahrungen

2.08.2018 - Lesezeit: 6 Minuten

Es hat lang genug gedauert, doch letzte Woche war es so weit: Ich habe an meinem ersten Hackathon teilgenommen. Unter dem Motto "Geek for Good" haben sich Teilnehmer aus Deutschland und Ägypten zusammen gefunden um in 42 Stunden Projekte umzusetzen, welche dabei helfen sollen soziale Probleme zu lösen. In diesem Beitrag beschreibe ich nun zunächst den Ablauf und dann was ich dabei fachlich, organisatorisch und kulturell gelernt habe.

Der Ablauf

Der Ablauf war im Grunde in vier Phasen untergliedert. Zunächst gab es eine kurze Einführung mit einem Vortrag zu Hackathons im Allgemeinen und Game Jams im Speziellen. Dort wurden Tipps gegeben worauf es bei einem Hackathon ankommt - neben Selbstverständlichkeiten wie die Nutzung einer Versionsverwaltung (z.B. git) wurde auch angesprochen, dass man sich besser zunächst auf die grundlegendste Spielmechanik fokussiert und weitere Aspekte erst später hinzufügt. Auch wurde uns geraten, keine allzu abstrakten oder philosophischen Metaphern zu nutzen, da diese ein Potential für Fehl- oder Überinterpretation bergen. Stattdessen solle man das was man rüber bringen möchte klar formulieren und ebenso klar rüber bringen. In der zweiten Phase ging es darum, in gemischten Gruppen, also bestehend aus Deutschen und Ägyptern, soziale Probleme zu diskutieren und Ansätze zu finden wie Diese mit Hilfe von Virtual Reality (VR) oder Augemented Reality (AR) gelöst oder abgemildert werden können. Die Bandbreite der diskutierten sozialen Probleme reichte dabei von mangelndem bezahlbarem Wohnraum, über Defizite in der Pflege und Sexismus bis hin zum Umgang mit psychischen Krankheiten. Anschließend wurden dann die jeweils als am interessantesten bzw. am wichtigsten eingestuften Problematiken gewählt und Teams aus vier bis fünf Mitgliedern gebildet welche diese dann bearbeitet haben. Das war zeitgleich auch der Start der dritten Phase in der die eigentliche Implementierung durchgeführt wurde. Sie startete gegen 18 Uhr am ersten Tag und sollte eigentlich um 10 Uhr am dritten Tag enden, allerdings wurde das Ende später auf 12 Uhr verschoben. Während der vierten Phase ging es dann "nur noch" darum das Produkt des Hackathons möglichst attraktiv zu präsentieren, die Jury einen Gewinner auswählen zu lassen und diesen dann zu küren.

Was ich gelernt habe

Trotz des einführenden Vortrags der die größten Stolpersteine auf dem Weg zur Seite rollen sollte gab es noch einiges zu lernen was beim nächsten Hackathon anders laufen sollte. Dabei erhebt die folgende Liste keinen Anspruch auf Vollständigkeit:

• Arbeiten mit Unity: Meine Erfahrungen mit Unity zum Zeitpunkt des Hackathons waren auf ca. 2 Stunden "Crashkurs" beschränkt. Deshalb habe ich in diesem Bereich wohl auch am meisten gelernt. Das umfasst beispielsweise die Animation von Figuren mit Hilfe des AnimationControllers, die Wegfindung von Figuren mit Hilfe des NavMesh sowie das Skripten der Umgebung.
• Fettnäpfchen in Ägypten: Da sich unser Projekt um das Vermeiden von Fettnäpfchen in anderen Ländern und Kulturen dreht, habe ich quasi nebenbei auch noch einiges über die ägyptische Kultur und Mentalität gelernt. Beispielsweise stimmt das im Internet kursierende Gerücht es wäre unhöflich pünktlich zu kommen nicht, während man sich den Ratschlag anderen nicht die Schuhsohle zu zuwenden durchaus zu Herzen nehmen sollte.
• Einschränkungen von git: Eins der Learnings bezieht sich auch auf einen Punkt, der mir vorher bewusst war, den wir nun aber am eigenen Leib erfahren konnten: git funktioniert bei Textdateien wie Quellcode ausgezeichnet, bei Binärdateien kommt es aber schnell an seine Grenze. Bereits nach wenigen Commits mit Binärdaten wie 3D-Modellen und Sounds wurde das git-Repository riesig und das klonen dauerte ewig.
• Aufteilen der Arbeit in kleinere Unterpakete: Wir haben probiert das ganze Projekt möglichst arbeitsteilig anzugehen, das heißt jeder hatte sein eigenes "Spezialgebiet", beispielsweise die Eingabe mit Hilfe der Oculus Rift Controller oder das Bauen der dreidimensionalen Umgebungen. Das hat insgesamt auch ganz gut geklappt, allerdings gab es auch Phasen in denen es entweder nicht möglich war die Arbeit in kleinere Häppchen einzuteilen oder dies nicht sinnvoll erschien. Das hat insbesondere gegen Ende des Projekts dazu geführt, dass einige der Teammitglieder herum sitzen mussten während sie darauf warteten, dass andere ihnen zuarbeiten. Hier wäre also durchaus noch Optimierungspotential zu holen gewesen.
• Die Sache mit dem Schlaf: Schlafen ist in einem Hackathon eine sehr ambivalente Sache. Einerseits kostet schlafen Zeit und Zeit ist insbesondere während eines Hackathons ein sehr kostbares Gut. Auf der anderen Seite ist man ohne Schlaf auch deutlich weniger leistungsfähig. Also, wo ist die optimale Balance? Das wüsste ich auch gerne. Wir haben es jedenfalls so gehandhabt, dass wir in der ersten Nacht relativ normal geschlafen haben (5-7 Stunden), in der zweiten Nacht dann aber gar nicht mehr. Lediglich ab und zu konnte in die oben beschriebenen Wartepausen ein kleiner Powernap auf oder unter einem Tisch eingeschoben werden.

Zum Schluss muss noch eine Frage geklärt werden: Haben wir gewonnen? Die Antwort: Leider nein. Aber woran lag es? Hierbei kommen unterschiedliche Faktoren zusammen. Zum einen hat bei uns die abschließende Version nicht so funktioniert wie sie hätte funktionieren sollen, insbesondere die Steuerung per Handcontroller hat noch Probleme bereitet. Außerdem muss man auch neidlos anerkennen, dass das Siegerteam zwar eine einfachere Idee hatte, diese aber so gut und spaßig umgesetzt hat, dass der Sieg vollkommen verdient war.

Alles in allem bin ich mit meinem ersten Hackathon sehr zufrieden. Die Stimmung sowohl im Team also auch zwischen den Teams war super, jeder hat den anderen geholfen wenn er konnte. Außerdem war es eine gute Gelegenheit in sehr kurzer Zeit einen recht guten Einblick in neue Technologien zu bekommen und neue Leute kennen zu lernen. Ich jedenfalls freue mich bereits auf den nächsten Hackathon, der dann in Kairo stattfinden wird.