Sieben Learnings aus sieben Tagen Programmierung
Als Kind hatte ich immer davon geträumt, meine eigenen Game-Boy-Spiele zu entwickeln. Diesen Kindheitstraum habe ich mir nun erfüllt: Ich (eigentlich kein Entwickler) habe bei einem Game Jam mitgemacht und ein Game-Boy-Spiel in 7 Tagen entwickelt. Dabei habe ich extrem viel gelernt – nicht nur über Programmierung. Die 7 spannendsten Erkenntnisse möchte ich gerne mit euch teilen:
1. Lösungen sind wichtiger als Problemursachen
Wer suchet, der findet? Nicht unbedingt. Bei einem Fehler im Spiel hatte ich bestimmt drei Stunden lang nach der Fehlerquelle gesucht. Gefunden habe ich sie trotzdem nicht. Dabei war das Problem mit einem anderen Ansatz innerhalb von 5-10 Minuten zu beheben.
Für die Lösung eines Problems ist es oft egal, wodurch es verursacht wurde. Nach den Ursachen kann man immer noch suchen, wenn man Zeit dafür hat. Um ähnliche Probleme in Zukunft vermeiden zu können, kann das durchaus sinnvoll sein. Aber wenn die Deadline näher rückt, gilt es erst einmal Lösungen zu finden.
2. Priorisierung ist essenziell
Man kann viel machen und trotzdem wenig schaffen. Zum Schluss meiner Arbeit am Spiel hatte ich teilweise nach einzelnen Pixeln gesucht, die nicht richtig eingefärbt waren. Das war Zeit, die ich definitiv besser z. B. ins Sound-Design und in die Komposition von zusätzlichen Musikstücken hätte investieren können.
Manchmal kann es eben sinnvoll sein, erst einmal einen Schritt zurück zu treten, das Gesamtbild anzuschauen und sich zu überlegen, an welcher Stelle man seine Kraft am gewinnbringendsten einsetzen kann.
3. Communities sind Gold wert
Schaut eure Entwickler:innen nicht komisch an, wenn sie gerade einmal nicht am Code werkeln, sondern in Foren oder Messengern unterwegs sind. Online-Communities sind eine überragende Quelle für Wissen, insbesondere wenn es um Coden geht. Obwohl ich nur eine Woche mit der Entwicklung beschäftigt war, hatte ich viele nette Kontakte in der Game-Boy-Dev-Community. Teilweise sind wir noch immer in Kontakt. Es ist ein Geben und Nehmen.
4. Dokumentieren spart Zeit
Man muss nicht alles wissen. Man muss nur wissen, wo es steht – sofern es denn irgendwo steht. Parallel zur Programmierung habe ich die wichtigsten Variablen und die Bedeutung ihrer einzelnen Werte in einer Excel-Tabelle aufgeführt. Dieser Aufwand hat sich extrem ausgezahlt. Ich hatte unzählige Male in die Tabelle geschaut, um schnell etwas nachzuschauen, insbesondere, wenn ich ältere Stellen noch einmal anpassen musste.
Wenn ich jedes Mal all diese Informationen aus dem Code hätte zusammensuchen müssen, hätte das nicht nur viel länger gedauert, sondern vermutlich auch zu deutlich mehr Fehlern geführt. Sobald Projekte komplexer werden, ist eine ordentliche Dokumentation unersetzlich – nicht nur im Development-Bereich.
5. Alle Nicht-Programmierer:innen sollten programmieren
Ganz ehrlich: Ich bin davon überzeugt, dass viele Unternehmen davon profitieren könnten, wenn sie auch ihre Nicht-Devs in Workshops einmal etwas programmieren lassen würden. Ich hätte vorher von mir behauptet, grobes theoretisches Wissen über Entwicklungsprozesse zu haben. Aber einmal selbst in der Praxis zu erleben, wie die einzelnen Schritte ablaufen, ist noch einmal etwas ganz anderes.
Solch eine praktische Erfahrung dürfte in vielen Teams dabei helfen, die Zusammenarbeit zwischen Nicht-Devs und Devs zu verbessern. Außerdem verschafft einem dieser Blick über den Tellerrand auch wertvolle Learnings, die sich auf andere Bereiche übertragen lassen.
6. Programmierung braucht Ruhe
Die allermeisten Fehler, die ich beim Testen gefunden hatte, waren durch Ablenkung entstanden. So hatte ich einige Funktionen nicht zu Ende gebaut oder manche Änderungen nicht an allen relevanten Stellen implementiert. Es war auch sehr deutlich, dass die Bug-Dichte an manchen Stellen (bei denen ich abgelenkt war) deutlich größer war als an anderen nahezu bugfreien Stellen.
Also lasst eure Entwickler:innen in Ruhe. Schreibt lieber Mails oder Nachrichten und geht nicht wegen jeder Kleinigkeit zu ihnen an den Tisch. Und besorgt ordentliche Noise-Cancelling-Kopfhörer für alle Entwickler:innen, die welche haben möchten. Das ist eine Investition, die sich durch geringere Debugging-Aufwände schon im ersten Monat rentieren dürfte.
7. Alles ist besser als nichts.
Für den Game Jam hatten sich über 400 Teilnehmende registriert. Tatsächlich eingereicht wurden jedoch nur 87 Spiele. Alle, die überhaupt etwas abgegeben hatten, gehörten also automatisch zum erfolgreichsten Viertel der registrierten Teilnehmenden.
Insofern sollte man keine Angst haben, Neues auszuprobieren und die Ergebnisse mit der Welt zu teilen. Im schlimmsten Fall bekommt man hilfreiches Feedback, wie man es beim nächsten Mal besser machen kann.
Beim Game Jam habe ich übrigens den 3. Platz belegt. Probiert das Spiel gerne selbst einmal aus – direkt im Browser unter: https://playinstinct.itch.io/my-friendly-little-island
(Die Steuerung für den Web-Player steht weiter unten auf der Seite)