Spezialfolge –

Teaser: Engineering Kiosk #221 - Mobile Game Entwicklung mit Fabi Fink von Lotum

18.11.2025

Shownotes

Unser programmier.bar Crew-Mitglied Fabi war im Engineering Kiosk Podcast zu Gast und hat dort über seine Arbeit als Game Lead bei Lotum und das Thema Mobile Game Development gesprochen.

Das ganze Gespräch mit Fabi und dem Team vom Engineering Kiosk Podcast findet ihr unter https://engineeringkiosk.dev/podcast/episode/221-mobile-game-entwicklung-mit-fabi-fink-von-lotum/

/transkript/programmierbar/spezialfolge-teaser-engineering-kiosk-221-mobile-game-entwicklung-mit-fabi-fink-von-lotum
Fabi
Hi, hier ist der Fabi. Ich hab mal wieder 'n Podcast aufgenommen, aber diesmal nicht in der programmier.bar, sondern im Engineering Kiosk. Die Jungs haben mich eingeladen, ein bisschen über Mobile Game Development zu reden und ich hab aus dem Nähkästchen geplaudert, wie wir bei Lotum Spiele entwickeln. Wir haben 'n paar Ausschnitte für euch zusammengeschnitten und falls es euch gefällt, schaut doch mal vorbei, den Link haben wir in die Shownotes gepackt. Viel Spaß damit. Unser Mantra bei Lotum ist ja Small Team Big Impact. So, wir probieren ja wirklich, so klein es geht zu bleiben. Der Vorteil natürlich auch an solchen kleinen Teams und 'ner kleinen Firma ist, dass wir sehr viel über Kommunikation regeln können und sehr wenig über Prozessregeln müssen so. Jedes Game Team hat die komplette Hoheit über das Tech Stack. Also ob Sie jetzt im Frontend View einsetzen, ob Sie die alle Services auf der Google Cloud Konsole, auf ABS laufen lassen, ob Sie irgendein Game Framework wie Nakama nutzen, kann da jedes Team für sich selbst entscheiden, ob Sie Serverless gehen, sie 'n Kubernetes sehen. Wir haben eigentlich jeden Flavor hatten wir irgendwann mal gehabt und an Datenbanken muss man sagen, haben wir eigentlich noch das gesamte Potpourri so. Also da ist da ist irgendwie alles im Einsatz je nach Spiel. Word Blitz, eine unserer anderen 3 großen Franchises, das muss ultrasnappy sein. Da war's am Ende so, den Core Loop unseres Games, den haben wir komplett mit plane JavaScript entwickelt, weil's da wirklich auf das letzte Send der Performance ankam, so wo wir gemerkt haben, okay, grade wenn wir da irgendwie das Reaktivitäts Framework irgendwie obendrauf machen und irgendwie jegliche Inputs irgendwie über View laufen, das das hält einfach nicht mit der Performance. Und da haben wir wirklich gemerkt, okay, da müssen wir drauf achten. So, es gab immer so einzelne einzelne Stellen. Eigentlich wollen wir nach einem halben Jahr 180 Tagen rohes positiv sein, das heißt, nach 180 Tagen soll dieser Schwellwert von was haben wir ausgegeben zu was haben wir eingenommen überschritten werden. Das ist auch so typisch, je nachdem wie risikobeit man ist, so. 90, 180, 360 Tage sind so die typischen Dinge, die im Gamingbereich sich angeschaut werden und je nachdem, wie risikobeit man ist, kann man diesen Zeitraum wählen. Die KPI, die wir maximieren wollen, ist, möglichst viele Lächeln in Gesichter zaubern. So, das ist so intern so das, was wir was wir als als Main KPI haben, die wir die wir maximieren wollen, was im Endeffekt, wenn man's runterbricht, bedeutet, wir wollen möglichst viele User erreichen. Und dadurch, dass das dass das vorher unser Ziel war und unser Vehikel, das zu erreichen, war Viralität. Also wir haben Games gebaut, die sich unter Leuten durch virale Features, also durch Sharing Features im Endeffekt verbreitet haben und wir dann gesagt haben, hey, wenn wir's hinbekommen, genug Leute zu erreichen, dann folgt der Umsatz so.
Feedback