Mobile Game Development mit Fabian Fink von Lotum #108

0:01 Moin zu Folge 108 von einfach komplex heute zum Thema Mobile Games oder Mobile Game Development, mit dem Fabian Fink von Lotum. Und. Neben mir ist aber auch Burkhard bei uns. Moin Moin Hallo Gerrit, Ich freu mich auf dich. Auch Fabian wird heute ne spannende Folge glaub ich hab ich ganz wenig Ahnung von wir werden viel lernen glaub ich Gerrit und ich. Danke, dass ich da sein darf.

0:24 Ja, schön, dass du da bist. Und du bist ja auch schon Podcast erfahren, also können wir uns auf ne tolle Folge mit dir freuen. Vielleicht magst du dich kurz vorstellen, mal erzählen, was ihr bei Lotum macht, wie du zum Thema Mobile Game Development gekommen bist und aktuell dazu stehst vielleicht und erzähl auch gern n bisschen was über euren Podcast. Ja, genau, ich bin, wir nennen es intern Gamelied bei Lotum Lotum ist n Gamestudio aus Bad Nauheim, Wir entwickeln Mobile Games gestartet mit der Game Entwicklung für. Die native Plattform, also IOS und und den App Store, den App Store und den Play Store.

0:58 Und mittlerweile ist es so, dass wir 3 große Franchises haben, die wir entwickeln. Wir sind 55 verschiedene Teams, die an 5 verschiedenen Games entwickeln, 3 große Franchises haben jetzt letztes Jahr die eine Milliarde Downloadmarke über unsere Games hinweg geknackt und sind aber mittlerweile auf vielen Plattformen unterwegs.

1:13 Also wir sind ne Studie was uns glaub ich besonders macht, wir sind. Sehr stark im Webumfeld unterwegs. Also wir entwickeln Spiele zum Großteil auch auf Basis von Webframework sind da startet mit Games Plattformen zum Beispiel auf Facebook haben wir Games drauf, wo wir mit Webtechnologie entwickeln, sind aber ausgehend davon auch schon auf vielen anderen Plattformen gewesen, also gerade auf sozialen Plattformen, waren auf Snapchat, auf TIK tok, auf Discord, auf Reddit und entwickeln sozusagen überall da Games, wo Leute irgendwie n mobile Endgerät haben und wenn man uns so n bisschen einordnen würde, wir entwickeln Spiele für den. Casual Puzzle mag.

1:46 Vielleicht können wir auch später mal n bisschen drauf eingehen, was es denn eigentlich so für Genres da draußen gibt, aber ich würde mal sagen, so die ja jetzt nicht so die Strategie Long Term spielt, die man irgendwie am Abend stundenlang spielt, sondern eher mehrere Sessions über den Tag verteilt, so die die 3 größten Franchise wir haben ein Quizspiel, das nennt sich Quizplanet, wo es wirklich darum geht mit Freunden zusammen zu spielen, das ist glaub ich auch 1 unserer.

2:07 Ja, unter USPS, dass wir sehr soziale Games bauen. Also meistens spielt die mit seinen Freunden zusammenspielt, zum Beispiel Chris Benton, Word Blitz, Word, Blitz, eher ein Spiel, in dem man Wort auf einem Grid findet und unser größtes Franchise auch das längste bisher. 4 Bilder ein Wort, was in erster Linie zumindestens optimative Markt ne solo experience ist. Genau, wir sind.

2:25 Von der Personenanzahl ne relativ kleine Studie. Wir sind nur 55 Leute glaub ich standaktuell und weil unser Mantao ist Small Team big Impact. Also wir probieren immer mit möglichst wenig Leuten möglichst viel zu erreichen und wenn man auch sich unsere Downloadzahlen anguckt und unsere Größe von Games, dann ist das sehr sehr untypisch im Games Markt wie wir entwickeln und wie wir da vorgehen genau lotum ist die Brand mit der wir unsere Games machen wir wollen mal n bisschen was an die Community zurückgeben und haben. Unter anderem noch die Brand programmierbar, das unter dem wir auch den Podcast machen, wo wir an ja developer im deutschsprachigen Raum n bisschen was zurückgeben wollen. Das eine Format ist der Podcast,

2:58 den wir jetzt schon mittlerweile, ich bin jetzt bei Lotum seit. 8 Jahren und ich auch in meinem ersten Jahr haben wir auch diesen Podcast ins Leben gerufen, also machen jetzt glaub ich siebeneinhalb Jahre ungefähr diesen Podcast. Und wo wir auch wie ihr also machen Deep Dive zu verschiedenen technischen Themen, wir haben aber auch NCTO Special, wo wir deutsche CTOS einladen n bisschen darüber zu sprechen, wie sie dahin gekommen sind, wo sie sind und wir haben news Format im AI Umfeld als auch im normalen Development Umfeld. Genau.

3:22 Und ja, aber den Großteil meiner Zeit. Also Podcast nur ein Nebenprodukt, den Großteil meiner Zeit verbringe ich mit Spieleentwicklung und ich hab gestartet als Full Stack Entwickler bei Lothum und bin jetzt mittlerweile gamelead was man extern da draußen ist würde ich sagen, Product Manager die richtige Definition da draußen gamelead ist n eher bei uns geprägter interner Begriff.

3:41 Danke für die Intro. Ich glaube wir kommen bestimmt auf die andere andere Sache im Laufe des Gesprächs hier und da wieder zurück. Erstmal richtig cooler Rundumschlag und ich werd die Spiele auf jeden Fall mal ausprobieren. Ja, ich hab mir das im Vorfeld angeguckt. Casual Puzzle ist glaub ich genau mein Genre, wenn ich mal n bisschen am Handy zocke.

3:55 Ja OK, noch mal ganz kurz zu deinem Gamelead posten, du hast jetzt Produktmanager gesagt, ich hab mich gefragt, ist man dann jetzt eher für Features im Spiel zuständig oder geht es da eigentlich um technische Features? Also wie ich zum Beispiel n Spiel Bereitstelle für die für den Nutzer letzten Endes und vielleicht auch anschließend daran wie wie wichtig ist aus deiner Sicht eigentlich Technik im Vergleich zu Spielidee und ähnlichen Dingen?

4:20 Ja, also vielleicht, was ist die Aufgabe eines, nennen wir es mal Product Manager bei uns, bei Lotum, bei uns ist es so, dass wir, wenn wir ein Team haben, was ein Spiel entwickelt, bei uns ist jedes Team entwickelt ein Spiel, wir haben 5 Teams, die für einen jeweils für ein Spiel zuständig sind und n Team ist bei uns typische Größe wahrscheinlich so n bisschen hier das Pizza Size Teams wie man es auch von Amazon kennt also. Wir gucken, dass wir 6 Entwickler nicht überschreiten, mittlerweile auch n bisschen mehr Designer, vielleicht auch n bisschen geprägt durch AI First Workflows können wir später vielleicht noch mal drauf eingehen, dass wir sagen so 2 bis manchmal sogar 3 Designer

4:52 mittlerweile. Und mich dann als Product Manager als Beispiel und die Aufgabe des Product Managers ist, das Spiel erst mal, wenn man ganz grob sagt, das Spiel zum Erfolg zu führen. So und alles was dazu gehört. Also so ich glaub für Developer und Designer ist n bisschen klarer definiert was die Aufgabe ist.

5:06 Developer müssen es umsetzen, Designer sind bei uns aber auch sehr konzeptnah aber also arbeiten mit mir als Game Lead stark an den Konzepten, das genau wollen wir machen, aber sind dann eben auch für UX und UI zuständig und je nachdem in welchen Teams, manchmal auch für die Umsetzung wenn wir in Game Engines wie Unity arbeiten. Dann gehen Sie auch wirklich hands on da mit rein, aber ansonsten kann man sich das so vorstellen, wenn man jetzt mal vom New Game Bereich geht.

5:26 Meistens ist da eine grobe Idee für ein Spiel, da sagen wir mal wir wollen ein Word Game bauen mit einem mit einer zeitlichen Komponente, so bisschen detaillierter wird es aber relativ grob und ab dann ist es meine Aufgabe und dazu gehört eben die inhaltliche Konzeption, die ist auf jeden Fall hauptsächlich bei mir, aber wir probieren sehr empowert mit den Teams da vorzugehen und wollen wirklich.

5:48 Wir planen quartalsweise und überlegen wirklich, welche Features wollen wir da machen und diskutieren das im Team. Auch wenn ich die schlussendliche Verantwortung dafür habe, die richtigen Entscheidungen da zu treffen, wollen wir als Team empowered da entscheiden da so n bisschen inspiriert von Marty Kagen sein Buch Inspired so das ist so die Philosophie wie wir Product Management leben und dann gehört wirklich davon die typischen Planungsprozesse wir.

6:10 Gehen agil vor, aber jetzt nicht unbedingt nach Scrum. So jedes Team wählt sich so n bisschen die Methodiken aus, kann beim Scrum aber aus Methoden wie Shape, was für sie passt und wenn man schaut sozusagen von der Idee Konzeption bis hinzu Umsetzung mit dem Team. Was soll getan werden, wirklich die Planung bis hin dann später zur Auswertung, also auch gerade Datenanalyse liegt bei mir als Product Manager. Wir haben zwar NBI Team was supported für schwierigere Auswertungen so, aber grundsätzlich ist es so wir sind so empowered, dass wir.

6:36 Jegliche Auswertung selbst machen können und haben gerade bei den größeren Games n total datengetriebenen Datengetriebenen Entwicklungsflow. Ich glaub die Besonderheit ist wirklich bei Games, wir haben ne sehr sehr hohe Userzahl auch täglich wird super viel interagiert, das heißt alles was wir machen wird AB getestet und aus diesen AB Tests lernen wir und machen nächste Move so das ist bei neuen Games muss man vielleicht n bisschen mehr nach Erfahrung und Gefühl gehen, bei den Bestandsgames können wir super datengetrieben vorgehen und machen das auch sehr sehr stark aber im Grunde genommen ist mein Job das Notwendige zu tun um das Spiel zum Erfolg zu führen und das da gibt es sehr,

7:07 sehr wenig Abhängigkeiten. Also wir als Team sind auch komplett entscheidungsbefugt, sozusagen alles zu tun so, alle anderen sind inputgeber und selbst unsere Gründer, also Lotum und unsere, die Firmeninhaber, haben gegründet schon zu Schulzeiten verschiedene Firmen, am Ende ist lotum da rausgekommen und sie haben sich dann auf Games spezialisiert und auch die sind Inputgeber für uns.

7:26 So aber ist jetzt nicht so, dass dass sie da die die Entscheidung treffen, sondern die sind da sehr sehr erfahren und wir tauschen uns da super viel aus, weil wir als Teams sind für den Erfolg der Spiele zuständig. Genau. Und dann hast du noch gefragt, vielleicht kann ich als zweites noch darauf eingehen, weil du meintest Technik versus Produkt, also am Ende ist Technik immer das Vehikel um ein Produkt erfolgreich zu machen, ne und Technik muss das Produkt enablen und ich würde sagen es ist bei Spielen nicht anders als bei jedem anderen Produkt auch so es kann die Technik hat einen sehr großen Einfluss aufs Produkt und man kann auch die falsche Technologie wählen, aber erstmal hat die ist die Technik würde

7:59 ich sagen zweitrangig aber natürlich ein super super interessanter und mega wichtiger Teil und kann definitiv falsch entschieden werden. Das ist spannend, weil wir also bei uns wie wie bei euch in im programmierbarer Podcast, den ich übrigens wärmstens empfehlen kann, hör ich auch sehr gerne, wenn ich mal die Zeit dazu hab. Guck mir auch gerne so n bisschen unter die unter die Decke der Technik und das interessiert mich vor allen Dingen, auch weil ich ja privat aus Spaß n bisschen ne Spieleentwicklung gemacht hab, um einfach mal zu verstehen, was gibt es da für Frameworks und was kann man so machen, aber ansonsten hab ich bin ich da wirklich sehr sehr ahnungslos, deswegen will ich auch haben

8:34 Fabi. Und ich? Ich brenne darauf so n paar mal so n paar Insights zu bekommen technische ich find es auch ganz spannend, dass es anscheinend auch gar nicht, also es gibt keine Silver Ballet, hab ich jetzt schon verstanden, es gibt verschiedene Games mit verschiedenen Ausrichtungen und so weiter die wahrscheinlich verschiedene Technologien mögen oder nicht so gut mögen und du hast gesagt Na ihr habt nativ angefangen mobile und so weiter kannst du wenn wir jetzt mal so n bisschen in Technik einsteigen vielleicht wenn wir ganz oben anfangen, dass wir erst mal die Schublade aufmachen und sagen, was gibt es grundsätzlich eigentlich? Für verschiedene Möglichkeiten, die tatsächlich im Moment auch noch aktuell sind.

9:08 Da ist natürlich auch alte Spiele Fireworks bei euch jetzt nicht mehr auftauen, aber wenn man heute n mobile Game macht, was gibt es eigentlich für Möglichkeiten von der Technik jetzt mal abgesehen von der Spielidee, aber was hab ich in der Schublade irgendwie mit was kann ich da loslegen? Genau also also erstmal super super viel ne ich glaub man kann vielleicht erstmal die. Allgemeinen Entscheide die allgemeinen Kategorien unterscheiden so das das erste wäre nimmt man eine Game Engine ja oder nein so und ne Game Engine. Ich würd mal sagen im mobile Markt die vorherrscht ne mit der die meisten Games wenn man es auf native schaut umgesetzt sind wäre Unity, ansonsten kennt man noch an die als die großen Engines gibt es auch sowas wie

9:43 Unreal die dann auch mehr bei vielleicht Triple A Titeln auch gerade so PC und Konsole irgendwie benutzt werden also Triple A. Ja ist ja so n bisschen so wie man es auch mit later Länder Rating kennt, so wirklich die sehr sehr high Polish die über mehrere Jahre hinweg eher. Besser Fallartig entwickelt werden.

9:58 Da spielt Unreal auf jeden Fall eine super große Rolle. Unreal jetzt im mobile Markt spielt eher wirklich eine untergeordnete Rolle, da ist Unity schon die vorherrschende Engine, trotzdem muss man auch sagen bei Game Engines da draußen gibt es noch super super viele andere Game Engines und da ist mal so ein bisschen die Frage, wofür entwickelt man denn? Und native Markt Unreal vorherrschend. Ich glaub sobald man in Richtung Web geht und das ist jetzt zum Beispiel was, was wir super viel machen, also Web bedeutet jetzt alles, was irgendwie in einem Browser läuft und wenn ihr jetzt vorhin gesprochen habt, wir machen native und wir machen aber auch Facebook und Snapchat und Reddit und so weiter im Grunde genommen kann man sagen,

10:32 alles was nicht native ist, ist eigentlich Web, weil jegliche sozialen Plattformen wie sie am Ende spiele eingebunden haben, ist, wenn man es ganz runter brechen würde auf einen i Frame. Also irgendwie hat man immer einen Webcontainer in dem man irgendwie baut. Und da ist natürlich n bisschen andere Anforderung, was jetzt irgendwie Bundle size angeht, weil es eigentlich jedes Mal runtergeladen wird, ist kein Game, was du jetzt dann einfach so installiert hast, sondern deswegen nennen sich Facebook diese Spiele auch Instant Games, weil sie instantan geladen werden und eben nicht eigentlich, ich muss es erst aus dem Store downloaden, dann irgendwie öffnen und nicht registrieren, sondern klickst da

11:00 drauf und dann kannst du im Grunde genommen starten und da war Unity ne sehr lange. Zeitlang hat Web Build supported, also man konnte mit Unity, das wird jetzt in C Sharp geschrieben und hat so n proprietären Editor, mit dem man auch viel visuell macht. Konnte nen Web Build generieren, aber hat halt super viel Overhead einfach mit dabei gehabt, weshalb es erstmal nicht die natürlichste Entscheidung war Unity für webbasierte Games zu benutzen.

11:23 Das hat sich mittlerweile n bisschen verändert. Sie haben da schon super viel investiert und auch gerade so bei Facebook Instant Game mittlerweile einige Games, die irgendwie Unity benutzen. Das heißt das stimmt nicht mehr so ganz, aber es gibt einige Engines, die einfach in erster Linie für Web gebaut wurden, zum Beispiel sowas.

11:38 Wir haben früher mal mit Pixie JS entwickelt, aber ganz viele Go dort oder ähnliche Game Engines, die das vielleicht besser supporten, ja. Das heißt, bevor du bevor du weitermachst, lass uns einmal kurz für die Zuhörer, glaub ich klarmachen. Weil du sagst einfach Game Engine und so weiter also ich hab ne Vorstellung was ne Game Engine ist und so weiter aber wer weiß ob unsere Zuhörer das jetzt so genau wissen. Ich ich ich geb mal was in den Ring und du du gleichst mich gleich wieder aus wenn wenn wenn das falsch ist. So ja also bei Games haben wir ja haben wir erstmal n ganz bestimmtes Konzept und wir brauchen relativ viel Physik glaub ich ja mal gucken ob das richtig ist und nicht und ich kenne die Unreal Engine halt

12:10 auch als. Quasi wieso eine Art implementierte Physik ja der der ganzen Naturgewalten? Ja, denn wenn man ein Spiel hat, dann dann, das fühlt sich ganz neu natürlich an, dass irgendwie ein Feld oder springt und so weiter und das sind alles so Bewegungen, die mit unserer normalen physikalischen Umwelt zu tun haben.

12:25 Tatsächlich steckt da drin aber richtig viel Mathe, implementierte, algorithmische Mathe, dass sich Bälle hüpfen und bewegen und so weiter, dass sich bestimmte. Ja, die gibt es ja auch. Ne, dann fahr ich auf dem Mond rum, dann hab ich ne ganz andere Gravitation und so weiter und sofort ja und das muss ich nicht alles jedes Mal neu entwickeln als Spiele Designer, sondern dafür gibt es halt ne Engine.

12:43 Ja wo diese ganze Physik drin ist und die kann ich dann kann ich quasi an Knöpfen drehen und sagen Gravitation ist jetzt halt n bisschen weniger also n bisschen mondmäßig jetzt hab ich n bisschen mehr oder irgendwas und sofort ja ist das erst mal richtig, dass wir erst mal diese Physikgrundlage haben in der Engine. Genau, also ich.

12:56 Ich würde wahrscheinlich, wenn man es noch allgemeiner beschreiben würde, würde ich sagen, ne Game Engine ist ein Stück Software was Aufgaben die jedes Game zu lösen hat probiert zu bundeln und einfach verfügbar machen und ich finde ein physiks Beispiel war ein sehr gutes Beispiel was eines der der grundlegenden Funktionen ist, die alle.

13:15 Game Engines meistens mit drin haben, ist sozusagen physics Simulation so, aber man muss natürlich auch dann zur Frage stellen, wie ist es überhaupt n 2 D oder n 3 D game. Es gibt bestimmte Engines die zu zum Beispiel 3 D überhaupt nicht und dann ist wiederum die Frage so wie. Wie erstellst du denn diese Spiele?

13:29 Machst du das alles wirklich nur in Code? Lädst da Modelle rein und baust dieses ganze Game wirklich nen Code oder brauchst du einen visuellen Editor, weil du zum Beispiel, wie es vorhin meinte Designer auch mit drin hast, die eben die visuelle Komponent des Games übernehmen? Also als nächstes gefragt ne ganz klar.

13:41 Also ich glaube, dass so ne moderne Engine wie Unity wahrscheinlich auch die Anwil Engine die bringt. Es ist n ganzes Ökosystem ne, also du hast ne du hast irgendwie du hast für die Entwicklung so quasi ne riesen SDK Bibliothek wie auch immer, also Funktionen noch und nöcher die genau diese Standardprobleme lösen gebandelt.

13:57 Und dann hast du wahrscheinlich sowas wie wir. Als Programmierer kennen nur viel spezieller eine Idee. Also du hast ein Integrated Development Environment, also irgendwie quasi ist es eine richtige Software, in der du dann auch anfangen kannst. Bei Unity ich vor Jahren das mal ausprobiert, aber da ging das halt auch schon, wo du dann einfach malen, malen ja, aber du kannst quasi Figuren animieren, das hilft dir quasi 3 d Szenerien aufzubauen und so weiter und du Codest das nicht, du benutzt ein Tool was das für dich macht und das das lässt quasi Code entstehen im Hintergrund der dann dein Spiel wird, richtig.

14:26 Also Unity wäre im Endeffekt beides. Also du hast einerseits den Editor, der einen bestimmten Teil für dich per per UI generiert, also ein bestimmter Part ist Code so die Engine bringt einen Part mit, dann werden visuelle Files meistens generiert und man kann Animationen eben über Animation Controller irgendwie designen, beispielsweise auch unser UI ist so, dass wir das, dass wir das im Editor bauen, also wir da gibt es auch verschiedene Arten, wie man das in Unity machen kann, die ist wirklich, man hat dann man. Wenn man jetzt mal sagt, was im Web vielleicht Screens sind, sind in unities Szenen.

14:55 Man hat verschiedene Szenen, die man auch nacheinander abspielen kann, Szenen am Spielset, die können 2, die können 3 designen kann man Elemente irgendwie überlagern und alles macht man in einem in einem visuellen Editor. Wenn es dann aber wirklich um die um die Logik geht, die Business beziehungsweise Spielelogik, die schreibt man in C Sharp und auch diese Skripte kann man dann mit jeglicher IDE schreiben, so wir machen es typischerweise mit Jet Brand Rider, aber manche machen es auch mit VS Code bisschen, je nachdem was der Entwickler gerne möchte.

15:18 Und das das Zusammenzurren passiert dann in dem visuellen Editor von Unity. Also die Skripte müssen dann auch da definiert werden, die hängen dann an Gameobjekten dran und so man ist schon sehr viel visueller unterwegs als wenn wir jetzt unsere Games, wie viele wir auch mit einem Webframework bauen, wir nutzen ja sonst sehr viel View es es ist sehr viel visuelleres vorgehen so, aber das Schöne ist es enablet auch zum Beispiel Designer mehr ich. Fand den Einschub jetzt super spannend. Ich hab mich tatsächlich gefragt so ne so ne Game Engine als nicht Softwareentwickler.

15:47 Was macht das eigentlich? Unreal Engine kenne ich so von irgendwelchen Computerspielen damals. Ja, du startest immer Unreal Engine OK du Unity ist aber viel im Einsatz und Du hattest jetzt gesagt im Bereich Web oder insbesondere bei euch nutzt ihr eigentlich andere Engines noch ne was zeichnet die dann aus oder warum sind die jetzt so gut geeignet? Eigentlich Hauptsache zum Grund Unity ist war damals mal, hat sehr viel Overhead mitgebracht, wenn man eben nen Webbild oder ne Webversion seines Games bauen wollte. Wir haben damals Pixie J erstmal genommen, das war einfach auch eine eine javascript basierte Game Engine, die so n Editor beispielsweise nicht mitgebracht hat. Da waren wir komplett IDE mäßig

16:25 unterwegs gewesen und weil wir halt ne Webversion bauen wollten, haben aber relativ schnell gemerkt, dass wir da. Die Engine uns eigentlich mehr Steine in den Weg legt, als sie uns irgendwie hilft, weil ihr habt ihr das jetzt gerade schon gemeint. Burger hat so ein Part, wenn man physics hat ist so ne Game Engine nimmt natürlich super viel ab, weil das will man eigentlich nicht wenn man nicht ein sehr sehr großes Gamestudio ist.

16:45 Ne super große Anforderung irgendwie an die Physics und Performance hat und alles irgendwie tweaken können will, dann will man das eigentlich nicht selbst entwickeln. Wenn man jetzt aber sagt was machen wir als lotum wir sind im Carreral Puzzle Markt unterwegs und wir können jetzt mal das Beispiel nehmen. Ist wirklich das prädestinierte Beispiel für aber Quiz Planet. Im Endeffekt ist das ein wir spielen dann n asynchronen Loop mit meinen Freunden, also runden Basiertes Quizspiel. Ich beantworte fragen, du beantwortest fragen, wer hat am Ende am meisten Punkte wenn man es mal runterbricht und was ja ein Quizspiel eigentlich nur ist, ist eine Textbox mit n paar Buttons und ich will einfach nur

17:15 ne Antwortmöglichkeit auswählen und das greift vielleicht schon n bisschen vorweg was dann am Ende unsere Lösung war zu sagen Hey eigentlich machen wir eigentlich bauen wir ne Webapplikation und. Wir haben nur sehr hohe Anforderungen an Micro Animations an generell Animationen wie das Ganze, die visuelle Aufmachung und irgendwie wie sich das ganze anfühlt, dass sich das Game hier anfühlt. Aber wir haben super viele Aufgaben mit was ist eigentlich screenrouting so wir es ist gerade die Flows, wie werden Leute durch die App gegeilt und so das ist das. Mit dem wir uns viel beschäftigen. Und dann haben wir damals, und das lag damals wirklich nicht auf der Hand, dass man Games auch in diesem casual Bereich irgendwie nicht mit einer Game

17:49 Engine entwickelt, haben wir gesagt, OK, dann lass doch mal probieren einfach nen Web Framework damit dafür zu benutzen. Wir haben damals uns für VIEW JS entschieden, n reaktives Framework, weil das eigentlich viele der Probleme die wir hatten einfach out of the Box löst und das hat wirklich n riesengroßen Unterschied für unsere Produktivität gemacht, sodass wir weg sind von der Game Engine und mussten sozusagen um Probleme der Engine rumbauen, weil eben. Beispielsweise wenn wir mal n bisschen in Game Kategorien denken.

18:15 Ich sag wir machen Casual und Puzzle Games so und im Endeffekt gibt es so sagen wir mal 4 Kategorien von Games, wenn man jetzt absieht davon, auf welcher Plattform sie sind. Es gibt Casual Hyper Casual mit Core und Hardcore und Hyper Casual ist zum Beispiel das Beispiel sowas wie Flappy Bird kennen die meisten da draußen, das ist einfach n ganz einfachen Core Loop physics. Man macht hier diesen Vogel mit n bisschen taps und probiert ihn da irgendwie durch durch diese Rohre zu navigieren. Und das ist die brauchen physics so es heißt schon mal Game Engine macht schon viel Sinn und sie sind so simpel, dass sie eigentlich was jetzt so Screenflows und sowas angeht haben die keine große Antwort,

18:49 die wollen halt am Anfang irgendein Game Menü haben, dann sollst du halt auf Start drücken, dann bist du eigentlich im Spiel drin so aber das ist bei diesen sozialen Spielen die wir bauen, da ist eben super wichtig wie navigiert man die Leute sozusagen verschiedene Screens, dann brauchst du irgendwie Übersichten von Punkten, jetzt ist der andere dran, so willst du wieder auf den Homescreen zurückkommen und der Physics Part ist für uns nicht wichtig und deswegen ist es so, dass wir sehr, sehr lange Zeit, als wir zum Wir haben, sozusagen so 34 Jahre viel unserer Zeit mit Instant Games Facebook verbracht, hauptsächlich mit View entwickelt haben. So und ist auch jetzt immer noch eine Technologie, die haben wir auch mittlerweile so sehr

19:21 gemeistert, dass wir so viele andere Spielekonzepte irgendwie benutzen, auch wenn wir zurück auf Native gehen, zum Beispiel Crispernet und Word Blitz gibt es auch in der native Variante im IOS, Android Store und auch da nutzen wir die Web Engine, haben eigentlich nur ne Art Webcontainer drumrum, der ist so wie Phone Gap haben wir alles selbst geschrieben.

19:38 Auch nur die Web App dann selbst im Native anzeigt, weil wir da mittlerweile auf einem Qualitätsniveau sind, so dass gar keinen großen Unterschied mehr macht, ob wir da wirklich was Natives nutzen oder einfach auch für die native Varianten Web und cool. Das heißt so n ja. Ihr müsst. Vielleicht auch mal beide Reinhaken. Ja, wir müssen beide noch mal kurz reinhaken genau, ich, ich, ich will vielleicht auch noch mal gern für unsere Zuhörer, wie weil wir wir jetzt, wir haben schon. Für also ich glaub bei bei programmierbar, da sind eure Zuhörer vielleicht noch n bisschen noch tiefer drin. Ich hol noch mal kurz n bisschen ab, also ja View JS, das ist erst noch mal hinschreiben in Lettern, also VUEJS und das auch noch mal kurz eingeordnet mit

20:15 mit View JS kann man auch ganz normale SPRS machen, Single Patch Applications die gar nichts mehr im Spiel zu tun haben und steht auf auf der gleichen Schublade wie zum Beispiel React, was man sehr gut kennt. React JS ist anders gemacht, aber am Ende des Tages ist es auch n Javascript. Framework, was dir CSS und javascript irgendwie zusammen, also wo du mit arbeiten kannst.

20:33 Ne und und ja HTML quasi gebandelt das alles und so weiter kannst du die ganzen Sachen machen, da gibt es von der Sorte noch so n Paar und ihr habt euch halt für UJS an der Stelle entschieden ne und um das noch mal kurz aufzugleisen dann hab ich gleich noch viele Fragen aber aber Gerrit hat hat auch noch was auf, du wolltest auch noch mal einhaken können, dass ich jetzt. Mal.

20:49 Ja, weil wir hatten jetzt vor kurzem mal diese Folge zum Thema einfach nicht mobile Game Development, sondern mobile App Development und. Da haben wir auch viel über native Apps gesprochen, mit auch mit einem Gast. Tatsächlich. Ich stell mir es jetzt so vor. Ich hab jetzt also da irgendwie ich entwickel jetzt in den Frameworks dieser dieser Betriebssysteme, hab dann aber ne Art Container n iframe oder irgendwas, wo ich dann aber eigentlich wieder wo ihr in eurem Fall jetzt doch wieder eure Webtechnologie nutzt für das für das für das Spiel ne, so ungefähr kann man sich es vorstellen.

21:18 Genau, ja. Also es ist wirklich. Im Endeffekt machen wir, wenn wir bei der native App, die öffnet sich, dann öffnen wir da drin einen Browser und dann rufen wir in Anführungsstrichen die URLS Games auch so, das ist eigentlich was, was wir da tun, so, und dann haben wir n paar Schnittstellen um irgendwie was was halt so die nativen Apps können, dass wir damit auch interagieren können, aber eigentlich ganz grundlegend ist es.

21:37 Das perfekt. Dann würde ich noch mal von der Thema, das interessiert mich nämlich auch, du hast ja gesagt, wir haben ganz andere Anforderungen an Games, also jetzt als zum Beispiel an der Webseite. Und wir haben jetzt kategorisiert, die Games nach ich kann es nicht wieder herbeten, also Hardcore mit Hardcore und. Mit mit Core Hardcore und Casual Hyper Casual. Perfekt.

21:55 Danke. Genau das ist jetzt so n bisschen mehr so wie wie wie wirkt das Spiel so, vielleicht kann man aber auch noch kategorisieren wenn ich jetzt wenn wenn ich jetzt n Spiel entwickeln würde wäre mir auch total wichtig zu wissen, ist denn das überhaupt n Multiplayer Spiel also n Online Multiplayer Spiel zum Beispiel oder hab ich es gibt ja auch ganz viele Spiele, das ist halt so Singleplayer ne also hab ich auf meinem Telefon ich dülle da irgendwas. Sag mal tetris ja oder oder wie heißt das Frozen Bubbles oder was weiß ich so was?

22:18 Nein und mir sind meine anderen Player ja ganz Wurst. So ja dann hab ich ja auch noch mal ne ganz andere Anforderung an das Spiel als wenn nicht und jetzt sind wir ja im Browser sowieso, also wir haben auch das Internet mobil und sofort, da kann man ja halt und du sagst ja selber gesagt soziale Spiele heißt ich tu das nicht alleine sondern im Quiz und so weiter hab halt quasi Mitspieler und hab jetzt Anforderungen an Skalierbarkeit. An Erreichbarkeit, an Multiplayer, Krams und so weiter eventuell will ich sogar live irgendwie wen sehen, der da mir mit reinschneidet während ich spiele und so weiter und sofort. Ja magst du da auch noch mal was sagen zu den zu den Entscheidungen die ich jetzt

22:51 nehme, kann Unity das und so weiter aber jetzt jetzt ist jetzt nicht mehr das Rendering so wichtig und die und das Bundle Ding sondern ich gehe so ein bisschen drauf aus wie es ist. Die Network Engine also basiert das auf Web sockets habe ich irgendwie DCP mit Brokers oder irgend so was ganz grob was gibt es da für Möglichkeiten ist das auch so? Zu breit, je nach Spektrum oder welche Schubladen können wir da aufmachen?

23:11 Ja genau, du hast ja schon richtig gesagt, wenn wir jetzt über Game Engines ist das Web oder wir haben sogar noch ganz andere Technologien flatter, setzen wir auch noch einen von Google, dann ist das ja alles die visuelle, die Frontend Komponente würden wir auch sagen ne und da das ist jetzt die Anforderung wenn wir sagen was soll denn.

23:26 Das Spiel können, so ist es ein Multiplayer Game oder spiele ich ein Singleplayer Game dann geht geht es von ich bau einfach nur ein Singleplayer Game und ich habe gar keine Backend Anbindung auch solche Games haben wir, es ist alles wirklich nur lokal und wir haben außer unser Tracking System angebunden haben wir eigentlich nichts, zumindest ist keine eigene Server Infrastruktur solche das ist sozusagen das das eine Ende des Spektrums, das haben wir dann geht es hinzu.

23:50 Das sind, was wir sehr viel machen, sind asynchrone Games. So, das heißt ich Spiele und danach spielst du. Wir können zwar gleichzeitig online sein, ich muss trotzdem warten, bis du da n Zug gemacht hast. Was unsere Quizspiele sind, dafür haben wir natürlich ne Server Infrastruktur da stehen und die ist aber auch da kann sich jedes Game Team bei uns selbst entscheiden was es irgendwie nutzt. Also wir sind alle in der Google Cloud unterwegs, alle Serverless unterwegs aber typischerweise also genau vielleicht müssen wir gar nicht so ganz in dieses Detail da reingehen, sehr technisch aber.

24:18 Da müssen im Endeffekt Server hin, Infrastruktur dafür dafür hinstellen. Wenn es jetzt in Richtung Realtimeness geht, so, dann ist einerseits auch in diesen asynchronen Games ist es ja so, wir wollen auf jeden Fall realtimes haben, dass ich weiß, wenn dein Zug beendet ist, dass ich nicht erst eine Seite refreshen muss, sondern dass wir wirklich realtime die Updates bekommen, dann unterhalten wir uns da auch über eine Web socket Verbindung, da haben wir auch von uns selbst geschriebene Sachen, wir nennen das intern lifelines, also so ein über die Game Teams gesharedes System wo alle Spiele mit diesem Socket Server verbunden sind und darüber Updates gepusht werden können und sich damit.

24:48 Damit dann auch die UI wirklich reaktiv direkt neu rendert, das ist sozusagen der eine Part und wenn es dann aber um wirklich live geht, das heißt mehrere Leute spielen gleichzeitig dann, dann wird es schon tricky und da gibt es aber auch viele verschiedene Lösungsmöglichkeiten, so. Weil du vorhin gefragt hast, ist es eigentlich egal, was man benutzt, ob du Game Manager oder Web benutzt.

25:09 Eigentlich alles komplett egal. Alles davon kann das grundsätzlich. Die Implementierung ist mindestens anders, wirklich nur ne Frage wie setzt du die Serverinfrastruktur auf? Zum Beispiel hatten wir bei crispernate mal ne Zeit lang eine, haben uns vorhin erst in dem Meeting mal wieder drüber unterhalten, wir hatten mal ne live Show wir haben. Immer um 08:00 Uhr in allen Ländern weltweit immer gescoped auf ein Land also.

25:28 In Deutschland gab es die Quizband Live Show, wo du um 08:00 Uhr Reinkamst und du hast dann gegen mehrere 1000 Leute 15 Fragen gespielt und sobald du eine falsch beantwortet hast, bist du rausgeflogen. Am Ende gab es den großen Pott so, das heißt, dann waren wirklich mehrere 1000 Leute gleichzeitig live und wollten sozusagen das Update über eine Live Show bekommen, ganz simpel gesagt, auch das wurde über Web Socket geregelt, aber man kann sich jetzt schon vorstellen, so ein Server kann keine x 1000 Web socket Verbindung irgendwie halten. Und das war jetzt aber auch was von uns eigen entwickelt ist so, wenn man auf ne technische Ebene geht, hatten wir da nen nen Reddit Cluster, was sozusagen

25:57 die ganzen Daten gehalten haben, dann mehrere Server sich damit verbunden und sozusagen hatten dann immer einen kleinen Chart von Clients die sie geupdatet haben, aber das ist erstmal einfach von uns komplett eigens entwickelt, so dann. Weil das ist ja also wenn du da, du, du erzählst das so im im im im Nebensatz ne, also mit einem Reddit Cluster und dann den Charts upgedatet und sofort ne also als Projektmanager find ich das auch cool so es. Jetzt gucke ich mal gerade in meiner aus meiner Entwicklerbrille raus, wo man wo man sagt, so, das machst du jetzt aber auch nicht gerade im Nebensatz und im Vorbeigehen. Ja, und das muss ja auch krass, also allein das ganze Testing und so weiter ja, weil ja da

26:31 sind, da sind wir noch nicht, lass mal noch mal kurz aus, aber das musst du ja erst mal irgendwie verproben, dass da irgendwie dann auf einmal 10000 Leute da irgendwie über webdockets gleichzeitig da sind und so weiter ja, das ist alles gar nicht so einfach, ja. Da habt ihr dann aber, das ist dann ja richtig AND Arbeit im Prinzip, wenn ihr das vor allen Dingen auch selber gemacht habt, ja dann, da geht ja schon n bisschen Zeit rein, dann für so n für so n Spiel.

26:48 Ja das muss sich ja auch die Architektur erstmal so n bisschen. Überlegen auf jeden Fall. Also das ist da steckt, da steckt viel Komplexität drin, so und kann auch gern noch andere Beispiele liefern, das das hat aber auch, das ist auch das, was mich damals, als ich war ja vorher Full Stack Entwickler und diese Live Show war auch 1 was ich mitentwickelt hab, beispielsweise das.

27:05 Ist das, was mich auch super gereizt hat an dieser Spielentwicklung. Ich hab ja vorher schon mal gemeint, für mich als Product Manager super interessant, wir haben sowas von viele User, dass wir wirklich AB Tests innerhalb von Tagen eigentlich auswerten können, weil halt pro Tag mehrere 100000 User auf dieses Spiel kommen und man wirklich sehr sehr schnell damit Ergebnisse sieht und aber auch diese Skalierung bringt natürlich auch an Problemstellungen, die man gar nicht so häufig in seinem Entwickleralltag überhaupt lösen muss, zum Beispiel auch bei Quizbind war es mal so, dass wir zeitweise an die. 4000000 täglich aktive User hatten, und da kamen wir einfach an ganz einfache Skalierungsprobleme, dass wir eben nicht mehr

27:41 vertikal skalieren konnten, was unsere Datenbank angeht. Wir kamen einfach in der Google Cloud an das Limit, dass wir gesagt haben wir damals noch ne My SQL Datenbank, Wir wir haben die größte Instanz, wir können nicht mehr mehr dazu machen was wir was machen wir jetzt, wenn da auch mehr Leute dazu kommen.

27:55 Das stürzt zusammen. Wir können, da bringt es nicht mehr Server hinzustellen, die Datenbank kommt mit der Last nicht mehr hin. So wir haben schon gecasht was wir irgendwie cashen können, was was tun wir denn als nächstes so und da. Waren es Kopfschmerzen nämlich? Ja, genau. Da kriegst du Kopfschmerzen.

28:07 Das war auch echt so, wo man irgendwie dann probiert hat, sich daran zu bedienen. Was machen denn die großen Social Networks eigentlich, wie können wir uns bei denen irgendwie bedienen und sind natürlich technische Probleme, die super interessant sind, aber auch herausfordernd, seine Zeitkosten und ja, da ist aber so, ich hab ja schon gemeint, wir sind auch nur 55 Leute so aber wir haben nen.

28:25 Sehr, sehr hohen Anspruch an die Leute, die hier bei uns irgendwie arbeiten. Also es ist nicht so, dass es daran liegt, dass wir irgendwie niemanden einstellen, sondern wir führen wöchentlich Bewerbungsgespräche und sind eigentlich immer auf der Suche nach Leuten, aber haben halt was das angeht, wenn wir sagen, wir wollen Small Team, Big Impact haben, wollen wir wenige Leute da haben, die sehr, sehr viel dann in diesem Rahmen leisten können und genau das ist aber ja, es ist auch auch, wir schwitzen dann dabei und sowas aufzusetzen, aber. Vielleicht auch noch einen Unterschied zu Games im Vergleich zu wenn wir jetzt Enterprise Applikationen machen, wenn mal nen Tag lang was schief läuft, dann ist es auf jeden Fall kacke und dann kommen auch

29:00 prompt einige User nicht mehr wieder so aber wir können das besser verkraften, weil wir natürlich on the Long run irgendwie sagen wir haben nen wir haben viele neue User die irgendwie immer reinkommen und manchmal verproben wir auch etwas live bevor wir es wirklich sagen. Es muss nicht immer komplett bulletproof sein bevor es rausgeht so das ist natürlich die erste Live Show, es gab dann auch. Die Tage in den ersten Wochen war jeden Abend 08:00 Uhr und so saßen wir da und aber da ist natürlich auch immer mal was schief gegangen und dann muss man sich halt damit beschäftigen und dann ja, es ist.

29:26 Nicht so. Es ist nicht so wie bei bei Zalando, wenn du dann irgendwie was komplett verrockst so und es kann halt einfach einen Tag lang keiner einkaufen, dann dann geht glaub ich mehr Geld die Bäche runter als jetzt, wenn wenn jetzt irgendwie mal was spiel irgendwie n bisschen ruckelt oder irgend so was. Ja genau das find.

29:38 Den Vergleich zu Zalando gar nicht gar nicht so passen, sondern ich dachte eher an an uns. Jetzt ja, wir bauen, wir haben Lösungen für einen großen Enterprise Customer. Der vielleicht 3 User hat aber extrem überlebenswichtige Anwendungen laufen hat quasi auf unserer Plattform jetzt, da darf halt nicht schiefgehen, sozusagen weil es steht vielleicht ne Produktion, im schlimmsten Fall, so ist schon ganz krass, aber und mit Verlaub, das Klang jetzt n bisschen so fabi, ihr könnt euch auch mal erlauben ne Stunde lang n paar User zu verprellen weil ihr habt ja eure User Generation Engine, irgendwas läuft da ja, dass ihr immer neue User bekommt oder?

30:12 Oder ihr habt so n so n so n what of Mouse was so groß ist oder so. Dass wir wieder neue kommen, ne. Ja, vielleicht so n bisschen extrem ausgedrückt. Natürlich ist bei uns auch so und es ist super wichtig, dass wir keine Downtime haben und das hat natürlich auch bei uns n großen Business Impact, aber wenn wir so n neues Feature rausbringen wie ne live Show und irgendwie, dann wissen wir einfach OK, da kann auch mal was schiefgehen aber ich mein ist ja auch, ist ja nur ein kleiner Teil der Experience wenn sie jetzt zu einer live Show kommen dann doch bei n paar Usern, was hängt so dann ist es notfalls so also wir können auch verkraften ein Paar zu verlieren, so dass das das ist schon so, also das

30:41 ist glaub ich anders, ich hab früher auch Enterprise Apps für die Deutsche Bank, ich hab Berater Apps entwickelt auf I Pads, da war natürlich wenn auch bei einem User irgendwas nicht funktioniert, dann sind sie bei mir auf der Matte, das ist bei uns nicht der Fall so und notfalls sagen wir OK ja wenn wir n Paar verlieren, dafür kriegen wir vielleicht ein paar 1000 mehr wenn wir es dann aber dafür irgendwann richtig hinbekommen. Gott, falls hier vielleicht gerade reinpasst. Wie finanziert ihr das denn eigentlich? Oder ihr jetzt?

31:03 Klar, ihr könnt natürlich das Beispiel an Notum machen, aber n bisschen auch allgemeiner und vielleicht dann auch. Und du hast jetzt paar mal gesagt, ihr seid n kleines Gamestudio. Was heißt denn eigentlich n kleines und großes Gamestudio? Ich kann mir vorstellen, dass nicht alle so erfolgreich sind, was die Userzahlen angeht et cetera, ne. Also ne, ich beantworte letzte letzte Folge kurz zuerst. Also wir sind n kleines Gamestudio was die Mitarbeiteranzahl angeht, aber wir sind n großes Gamestudio was die Useranzahl angeht so ich glaub das ist die Besonderheit jetzt Monetarisierung.

31:34 Vielleicht macht an der Stelle mal Sinn, dass ich noch mal kurz einen Überblick dafür gebe, was was ist denn eigentlich für also noch mal auf diese Spielekategorien und spielearten und wo eigentlich wieviel Geld so ein bisschen drin steckt und dann kann man auch darauf eingehen aus den Kategorien wie da eigentlich monetarisiert wird, also wenn wir noch mal sagen Spiele, es gibt mobile PC und Konsole und ich weiß jetzt nicht was ihr jetzt vorher gedacht habt, aber wenn ihr jetzt irgendwie sagt, was was ist denn so der Umsatzanteil von Mobile im Vergleich zu den beiden anderen?

32:00 Also dass ich mich zuerst mal bestelle, hat es mich eher überrascht. Mobile macht 50% des Gesamtumsatzes aus von dem Games Markt. Also im Endeffekt macht Mobile so viel zusammen wie PC und Konsole, was erst mal was ich erst mal überraschend fand und wenn man jetzt auf Mobile blickt, dann haben wir noch mal diese. Hypercasual Casual und sagen wir mal mit Core. Diese beiden Einstufungen von Komplexitäten von Spielen Hardcore lass ich mal raus, weil es in erster Linie eigentlich ne Kategorie ist, die hauptsächlich für PC Spiele und so gedacht es gibt auch mobile, aber es geht so n bisschen aus dem vor weil die haben unterschiedliche Monetarisierungsstrategien eigentlich so Hypercasual das

32:34 beste Beispiel ist Flappy Bird, früher war es wirklich so, die haben einfach nur einen kleinen Core Loop der so sehr repetitiv ist, aber im besten Fall sehr addictive und am besten auch noch so, dass die Leute darüber sprechen und über. Sich verbreitet, da war es in erster Linie so, dass sie über Werbung monetarisieren. Ist Candy Crush auch in der Kategorie eigentlich. Nee, Candy Crush wäre jetzt sozusagen schon dann die nächste Kategorie.

32:57 Casual, also Hyper casual. Das Grundprinzip sehr, sehr einfache Core Loop, die sich gar nicht groß verändert über das Spiel hinweg meistens auch nicht unbedingt Level basiert, ist so, sondern ist einfach sehr, sehr einfache Core Loop, repetitiv und in der Vergangenheit hauptsächlich über Werbung monetarisiert, das heißt nach Versuchen wird ja einfach, man nennt das Interstitial eine kurze Werbung angezeigt und es gibt. Noch irgendwie vielleicht mal ein nenn es rewarded Video, wo sich ein Nutzer aktiv entscheidet, dass er irgendeinen Benefit bekommt und sich dafür mal 30 Sekunden lang Werbung anschauen, dann kommen wir in den Bereich Casual, wo man schon sagen muss, ist ein elaborierterer Core Loop so der mehr Varianz bietet, sich über

33:32 die Zeit verändert und da ist ja zum Beispiel die größte das größte Spielprinzip darin ist Match Three, das ist sozusagen dieses Spielprinzip was Candy Crush ist. Heutzutage gibt es da aber auch noch größere Vertreter als Candy Crush, zum Beispiel Royal Match. Ist einer der Matt Three Genre Vertreter der sehr sehr groß ist im Markt und diesen Hyper Casual Artigen Games vorantreibt. Und da ist so das Grundprinzip, du hast n meistens n levelbasiertes Gameplay was sich über die Zeit immer komplexer wird, aber trotzdem noch eher in der Kategorie ist. Man kann das so n bisschen nebenbei spielen mehrere Sessions am Tag und die sind sehr sehr gut darin. Wir nennen das Live Ops zu betreiben, das heißt dass meistens um dieses Core

34:08 Spielprinzip herum. Viel, viele Events gestartet werden, die über ein paar Tage sind, wo man dann irgendwie bestimmte Dinge im Spiel sammeln muss, dafür Rewards bekommt und die sind sehr sehr gut da drin. So ein Live System um das Core Game herum zu bauen und da ist so die Haupteinnahmequelle sind Inappercheses, da ist Werbung, spielt ein Kleinteil beziehungsweise bei den meisten Games auch gar keine Rolle.

34:29 Es gibt auch hybride Modelle, aber eigentlich probieren alle in über. Irgendwie in Appertice zu integrieren, weil es natürlich n sehr sehr viel größeres Umsatzpotenzial hat und warum das wichtig ist, können wir gleich noch mal drauf eingehen, wenn wir uns vielleicht auch über User Acquisition unterhalten.

34:42 Also wie kommen überhaupt User dahin und dann gibt es die dritte Kategorie, das wär dann midcore, da ist sowas wie n sehr großes spielstudio Supercell aus Finnland, die machen sowas wie Clash of Clans oder Clash Royale, das ist dann wirklich da gibt es sehr viele strategische Komponenten, da zum Beispiel hat man so ne Art. Deckbilder Card geben, dass man sich überlegt, welches Kartenset nehm ich jetzt mit und das sind dann häufig auch so Player versus Player Spiele wo man wirklich gegen einen anderen Spiel überlegt welches Set nehm ich mir mit strategisch überlegen muss, wenn der das jetzt was jetzt ich dann und hyper casual und casual eher soloplayer Experiences sind so und und die mit Core eher eher

35:17 gegen andere Spieler eher PVP und ne hohe strategische Komponente haben und insgesamt wenn man auf den gesamten mobile Markt blickt, ist der größte Teil des Umsatzes liegt bei in der Purchases und n kleinerer Umsatz liegt bei der Werbemonetarisierung. Und gar kein Umsatz bei der bei dem Kosteninitial der App zum Runterladen hat sie das doch gar nicht erwähnt. Kein Wort.

35:36 Also ja, gibt ja auch Apps, die Kosten mal irgendwie 7,50€ oder irgendsowas ja weiß ich nicht, vielleicht auch nicht viele, vielleicht sind die meisten umsonst. Ja oder ist das oder ist das was vom Marketing wo man sagt das mach ich lieber nicht, sonst lädt das verdammt keiner runter, ich mach es erstmal frei und geh dann irgendwie, zieh dann die Schraube an, ja. Ja ist würd ich sagen, wenn man jetzt wirklich anschaut, was macht den großen Umsatz wahrscheinlich vernachlässigbar so.

35:56 Also es ist ist nicht so, dass es nicht getan wird, aber wenn man jetzt auf den IOS, also auf den native Markt blickt und sich fragt, wie werden Spiele groß, dann gab es früher vor einigen Jahren war Viralität, also World of Mount, Ich baue etwas und Leute erzählen es sich, ein großer Part, dann hat man irgendwie was dafür getan mit n bisschen UA irgendwie hoch in die Chartplatzierung zu kommen, sodass man einmal n paar ne kritische Masse erreicht und hab dann.

36:19 Das ist jetzt eher wie ein Lauffeuer. Heutzutage ist der vorherrschende Weg, auf native erfolgreich zu sein, User Acquisition zu betreiben und da ist es eine ganz einfache Rechnung. Man überlegt sich, wird man mit dem Game Roos positiv, also CPI die Cost per Install das was ich für die Werbung ausgebe ist das kleiner als mein LTV, das ist der Lifetime Value über eine bestimmte Zeit, also Lifetime LTV 180 Tage wäre wieviel Geld ich nach 180 Tagen mit meinen Usern verdient habe und.

36:46 Damit es funktionieren soll, muss der Betrag größer sein als das, was ich ausgegeben habe. Und damit das wirklich sinnvoll funktioniert, weil mittlerweile kostet Werbung zu schalten für Spiele je nach Spielprinzip schon ordentlich Geld, muss man eigentlich in der Purchase integriert haben, weil sonst kommt man nicht auf den LTV Betrag, der irgendwie wirklich über dieser CPI Grenze gibt. Es gibt Ausnahmen, aber der Großteil ist wirklich dann in der Purchase Monetarisiert von diesem mobile Gaming Markt. Und deswegen merkt man auch so n bisschen gerade diese Hyper casual Titel, diese spielestudios. Das ist so ne ganz andere entwicklungsart wenn man sich die beiden Extreme anguckt.

37:18 Triple A hab ich vorhin gemeint, über mehrere Jahre hinweg irgendwie wasserfallartig bis hinzu dem anderen extremen Hyper casual, da ist es so, da werden mehrere Game Prinzipien pro Woche irgendwie rausgebracht, weil man eigentlich immer guckt OK was was dick, was finden die Leute irgendwie gut, da machen Studios mehrere 100 Titel irgendwie im Jahr um irgendwie was zu finden was funktioniert und die sind aber.

37:38 Zum großer, eher Werbemonetarisiert und das wird immer schwieriger. Überhaupt ne kritische Usermasse darauf zu bekommen, weshalb auch die probieren mehr von diesem, was ich vorhin meinte live, ob es was eigentlich der Casual Markt mehr etabliert hat mehr rein zu bekommen, irgendwie Komponenten um dieses sehr einfache Spielprinzip drumherum zu bekommen, wie live Events und wo man dann sich immer wieder Sachen freischaltet wo sie einfach Wege finden wollen.

37:58 Wie kann ich in der Pertice in mein sehr in mein Hyper Casual Game integrieren? Also das ist wirklich so da wo sich der Markt hinbewegt, einfach weil. UA der einzige wirkliche Wachstumskanal im native Markt ist. Ganz kurz, das interessiert mich als Marketing Mensch LTV 180 Tage, also rechnet ihr damit, dass n Durchschnitts User bei euch oder allgemein bei so einem Game 180 Tage dran bleibt und dann wieder weg ist.

38:21 Also dass das die Lifetime ist. Ja, das nee, auch diese 180 Tage, das muss im Endeffekt jede Spielstudie für sich selbst entscheiden, was dieser Wert ist. Also LTV ist ein, den kann man mit jede Zahl hinten dranhängen, es gibt NLTV genau. Bei uns sind es eher so 5 Jahre oder so was ne wenn wir mal ne Software verkauft haben und das deswegen geh ich da so rein, ja. Ja, es ist auf jeden Fall im Gamemarkt ganz, ganz anders. Also im Endeffekt ist es immer eine, was du definierst als den Zeitpunkt, wann du das Geld wieder drin haben willst, hängt. Davon ab, wie retain deine User, also wieviel wieviel Potenzial ist da nach 180 Tagen überhaupt noch was zu verdienen, weil das was nach 180 kommt ist dann ja

39:00 das Plus, also es es heißt ja nicht nur wir wollen Break even sein, sondern wir wollen dir im besten Fall mehr damit machen, das heißt was ist realistisch, dass irgendwie sich der LTV wirklich noch aufbaut bis zu einem gewissen Zeitpunkt und wieviel kannst du es dir leisten auf dein Geld wieder zu warten, so also wie was was für ne Ron Rate hast du als Firma, wie ist dein Kapital? So das hat natürlich auch n großen Faktor und wenn wir auch da wieder auf die Spielekategorie gehen Hyper Casual die probieren mal.

39:22 Meistens ein Rohr ist positiv nach 7 Tagen zu sein. Die sagen LTV Seven, weil die Nutzer sind so schnell wieder weg, da kannst du gar nicht gucken, du musst eigentlich nach 7 Tagen profitabel sein, hinten raus passiert nicht mehr viel so dann gibt es diese midcause Strategy Titel, die werden wahrscheinlich eher was ein Jahr plus haben wir haben uns so bei 180 und 90 bis 180 Tage ist relativ typisch für so diesen casual Bereich und weil du sagst 5 Jahre typische wenn du jetzt im native Markt anguckst so typische für gute Games Retention Kurven sind so. Day One Wenn noch 50% der User an Tag 1 da sind, ist es sehr gut und dann halbiert sich das von 1 auf 7 auf 30. Also nach Tag 7 sind noch 25%

40:00 der User da, die es an Tag 0 installiert haben. An Tag 30 sind noch so zwölfeinhalb da, das sind so typische Kurven wo man sagen würde das ist das ist n gutes Fundament um daraus n langfristig gutes Game zu bauen. OK, perfekt, dann lass uns gern den Marketing User Acquisition Growth Part wird ein bisschen verlassen und technischer werden. Aber wenn ihr mögt, ja.

40:21 Also ja genau mehr dazu. Ich wollte noch mal reingehen in in 2 Themen, das eine ist UXUI, das andere ist diese Skalierbarkeit auf Abruf nenn ich es mal vielleicht vielleicht machen wir das sogar zuerst. Ihr habt ja nicht von Sekunde 1 plötzlich also ich hab jetzt gelesen 150 gelöste Rätsel pro Sekunde oder sowas ne bei bei bei 4 Bilder ein Wort heißt das glaub ich ne das ist ja krass ja also jede Sekunde sind da mindestens 150. Aktionen irgendwie so ne passiert ja nicht von heute auf morgen oder von der ersten Sekunde auf die andere. Das heißt wie stellt ihr euch da von der Infrastruktur auf, dass also Google Cloud hast schon gesagt, aber wie wie macht man das konkret, was man sich da

41:01 ordentlich für aufstellt für den Erfolgsfall, weil ihr geht ja davon aus, dass das Reinschlägt und gut wird, aber ohne vielleicht zu viel zu investieren, also nicht richtig all in zu gehen, weil es gibt ja auch durchaus das Risiko, dass so n Ding mal flop nehm ich an, ne. Ja, dann dein Beispiel mit 4 Bildern ein Wort.

41:18 Ist wiederum ein Beispiel. Das ist natürlich ganz nett, das skaliert sehr gut, weil es arbeitet mit sehr wenig serverinfrastruktur so, also da ist für ein gelöstes Level brauchen wir theoretisch keinerlei Serverinfrastruktur als, außer dass wir Tracking haben, und wir haben zum Beispiel ja auch n Service, den ich gebaut hab, wir haben einen globalen Tracking Service über alle unsere Spiele hinweg und das ist zum Beispiel auch ein ein Service, der sehr sehr gut skalieren muss, weil wenn der ausfällt, haben wir jegliche Insider in unsere Games irgendwie verloren und.

41:45 Ich würde sagen, wir haben n bisschen Lehrgeld gezahlt in den letzten Jahren. So und wenn ich das Beispiel vorhin hatte mit Quizplanet, wo wir irgendwie 4000000 täglich aktive User hatten, da hatten wir mehrere 1000 requests an unsere Services pro Sekunde, die wir irgendwie handeln mussten und da haben wir auf jeden Fall n paar Infrastrukturentscheidungen getroffen, die beispielsweise eine MSQL Datenbank, die wir nur vertikal aber schwierig horizontal out of the Box skalieren können, ist vielleicht für dieses Setup nicht nicht die beste Wahl?

42:12 So und damals haben wir so n Paar. Grundlegende Technologieentscheidung getroffen wo wir gesagt haben, Hey, unser Setup, wenn wir der Google Cloud sind, wir nehmen so n paar Grundkomponenten und dann sind wir erstmal dafür aufgestellt, dass wir auch in einem gewissen Scale irgendwie relativ gut entwickeln können.

42:25 Man muss ja schon sagen, auch die Cloud Provider nehmen einem da mittlerweile wirklich viel ab, also wenn man jetzt sagt, was ist jetzt der einfache Webserver den wir da stehen haben, auch da entwickeln wir unterschiedlich viele. Ich würde vorherrschend sagen, nutzen wir type Script als Sprache auch im Backend, dann sind es irgendwelche Note basierten Service oder da gibt es auch irgendwelche anderen Frameworks. Haben auch Bun Server da stehen aber Note sagen wir Note Type Script ist so ein ganz typisches Ding und da sind wir Server des unterwegs und hauptsächlich nutzen wir da in der Google Cloud Cubanetes oder Cloud Run wo man sagen muss. Da kannst du dich schon eigentlich gut drauf verlassen, dass die Skalierung da

42:57 funktioniert und das ist auch meistens dann am Ende das nicht der Bottle lag. Da kannst du einfach gerade bei Server ja einfach den nächsten Server hinstellen und dadurch, dass da wenig State im Server liegt alles was state ist ist es immer einfach zu skalieren. Alles was stateful ist ist sehr viel schwieriger so das ist natürlich die nächste Grundkomponente, dass eigentlich alles was wir cashen können müssen wir irgendwie cashen, also dass du irgendwie ne reddits da mit drin hast ist n Absolutes, das gehört einfach zum täglich Brot dazu und einfach.

43:21 Mittlerweile verstehen wir diese Technologie sehr, sehr gut. Ich hab vorhin bei Crispanet Life erzählt damals, dass ich da gesagt hab, da haben wir dann n reddes und auch n reddes Cluster hingestellt, das hat gab es damals in der Google Cloud nicht, das heißt damals gab es nur gemanagte Services, ne einzelne reddes Instanz Cluster musstest du selbst hosten, das heißt Wir haben da n Kubanetes hochgefahren, wo wir mehrere Reddes hingestellt haben, man musste uns erst mal beibringen, wie bauen wir denn überhaupt so n reddes Cluster auf und wie Main tain wir sowas heute ist auch das out of the Box, heute kannst du auch ein reddes Cluster out of the Box hier holen damals. War das n bisschen schwieriger

43:52 und Datenbanktechnologien? Ehrlicherweise muss man sagen, My SQL ist immer nur ne Technologie, die kann man gut wählen, so ne also wir haben zum Beispiel userdaten und so, wir nehmen immer noch relationale Datenbanken super viel und wir sind auch nicht so, dass wir jedes unserer Games absolut immer an diesem Limit ist, wie wir es damals waren mit Chris Planet, aber wir haben einige Datenbanken da in unserem Toolbett zum Beispiel Big Table von Google ist eine Technologie, die wir auch viel einsetzen, das einfach.

44:17 Würde ich sagen, wo Skalierung definitiv nicht mehr n Problem ist, so, aber dafür upfront sehr viel mehr kostet. Aber ich will mal eine. Vielleicht ist es falsch, aber eine Erkenntnis, die ich auch gerne wiederhole, was ich immer schwierig finde, auch vielleicht bei juniorikerinnen Entwicklern oder irgendwas, das wird immer, ich höre so viele Leute, die deren erstes Problem ist irgendwie scalability, ja, die, die haben noch nicht mal n Produkt, die haben noch gar keinen einzigen User, noch kein Success und nichts und machen sich 1000 Gedanken über verteilte Datenbanken und so weiter und sofort, ja und ich fand es schön wie du gesagt hast. Und My SQL ist eigentlich schon ne ganz gute Lösung. Ja und aus dem Munde von

44:49 jemanden der also mobile App Development macht, wo wirklich Skalierung irgendwie auch mal n Punkt sein kann, wo es irgendwie mal rums macht und du hast irgendwie richtig viele Nutzer dran und das wäre jetzt auch mal so mein Level. Ja Kinder habt ja nicht so viel Angst jetzt davor auch n Postgress oder My Sequel Datenbank der Scheiß ist halt hochoptimiert ja die sind ja auch nicht stehen geblieben bei 1980 ja wenn wenn du heute die letzte Version von My Sequel als SQL vorsichtig ich glaube das ist ne offizielle es geht schon The hin und her ich weiß nicht je nachdem mit wem man spricht.

45:16 Oder postcurs Halt nimmst und du packst das Ding halt einfach mal auf n dickes Brett Hardware was es ja auch gibt. Ja unsere Hardware ist ja auch nicht stehen geblieben, dann kannst du damit schon ganze lange Zeit was abfräsen. Ja wenn du es nicht und wenn du es n bisschen elegant programmierst vielleicht noch ja würd ich mal so sagen, ja und das ist es ist nicht gleich das erste Problem was du hast.

45:33 Ja dass du ne verteilte Datenbank brauchst, ja. Total. Und was sie auch vorhin meinte mit diesem My Sequel, so dass wir überhaupt an diese Grenze kamen mit die größte Datenbank hat nicht mehr ausgerechnet, hätte ja noch Lösungen gegeben, wie wir mit My Sequel weitergegangen wären. Also man hätte das, ja, wir sind ja global unterwegs, wir hätten das entweder schaden können nach nach countries oder so und hätten das Halt probieren können vertikal zu skalieren. Das ist natürlich dann sehr sehr viel mehr Aufwand, aber dass man da erst mal hinkommt, ich sag mal ich würd sagen, seitdem hätte ich jeden Use Case mit jeder Datenbank entwickeln können, es wäre theoretisch.

46:03 Egal gewesen, weil wir, weil danach auch n paar andere Optimierungen wir gemacht hätten, wo wir wahrscheinlich gar nicht mehr in dieses Limit groß gekommen wären oder vorher uns Gedanken darum gemacht hätten. Was genau machen wir denn in My Sequel und wie wie schaden wir es vielleicht vorher. Aber eigentlich ist diese datenbankfrage super zweitrangig und halt eher die Frage, was hast du für Use Cases und bieten diese Datenbanken irgendwie einen eine Anwendungsmöglichkeiten die es einem leichter macht es umzusetzen und skalierungen.

46:30 Ja, es steht nur die Zeit rein. Am Ende kannst du es immer noch lösen, selbst wenn du dieses Problem läufst. Ich will noch mal kurz drauf, weil wir haben es. Wir haben es zwar erklärt und ich glaube, für die Techniker ist es klar, aber vielleicht noch mal für die Zuhörer, die jetzt noch da sind. Wir waren ja schon paar Minuten auf der Uhr, aber vielleicht ist es trotzdem noch mal ganz interessant, das, was Gerrit gefragt hat, will ich noch mal genau auseinander nehmen, weil du hast so n paar Passwords fallen lassen wenn wir stateless sind, das ist alles einfach, dann nehmen wir kubaniert es und so weiter und dann haben wir dieses Reddit und sofort ja lass lass uns das noch mal.

46:54 Diese 2 Dinge sind nämlich sehr unterschiedlich, lass uns die kurz noch mal. Für die Interessierten, die es wirklich verstehen wollen, versuchen noch mal auf die Turnspur zu bringen. Also wenn wir eine mobile mobiles Spiel haben, dann braucht es einen Webserver, der einfach mal das ne ich geb ja da im Prinzip geb ich auch nur ne UL ein, ja wie auch immer das ist das das kann versteckt sein, lädt sich automatisch aber am Ende des Tages muss der Browser n Java Script Paket abholen von einem Webserver Punkt und der muss irgendwo sitzen so und dieser Webserver ist das wo du sagtest das macht ihr n type Script.

47:24 Mit No Jazz und so weiter im Backend. Ja, und der ist stateless warum ist der Stateless, weil wenn wenn ich als Nutzer einfach nur dieses Paket abholen muss, ja dann ist das wurscht ob das ob ich das Paket von der IP adresse 10 50371 abhole oder 10 5037 2. Da kommt das gleiche Paket zurück, die können alle gleich aussehen.

47:41 Ja sowas packe ich dann halt in Kybernetis rein und das ist clever genug quasi zu fühlen wie. Wie ist der Druck? Ja, wie viele, wie viele Fragen jetzt hier gerade an, das macht vorher das Macht hatten wir auch schon mal. Das macht vorher so nen Ingrid Server typischerweise also so n so n ach jetzt komm ich eh aufs Road. Balancer.

47:58 Ja, load Balancer ganz genau, also quasi so n Portal ganz am Anfang, der guckt sich nur an, wie viele kommen da rein, ja und wie viele Anfragen muss ich jetzt hier abschicken und dann hab ich quasi im Hintergrund das kubanitis Cluster und im besten Fall wenn das cool läuft, dann hab ich wenn da immer nur einer pro Tag fragt, dann hab ich da genau einen Webserver.

48:14 Der liefert das alles schön ab. Ja, und wenn er, wenn jetzt die Quest steigen und ich habe jetzt ich komme mal 100 pro Sekunde ein oder irgend so was und und das Ding kommt unter load, dass man alles messen kann mit Latenzen und so weiter alles klar bei der Technik, dann wird einfach ein neuer gestartet und zwar ein neuer Container auf virtualisierter Hardware, das ist die Cloud, das Macht die Google Cloud ja startet neuen Server genau den gleichen und weil der Statelist ist kann er genau die gleiche Antwort mitkriegen und der der der der 10 tausendste Nutzer der jetzt runterlädt weiß gar nicht, dass er jetzt nicht mehr von dem Server von dem.

48:41 Also am Anfang, da ist es dann auf einmal ganz frisch und der gerade initiiert wurde, runterlädt ja, so funktioniert die Skalierung der Webserver so und jetzt haben wir aber das löst das wenn ich kein State und das Reddit ist noch mal n anderes Ding, das erklärst du noch mal kurz fabi, weil ich bin auch gar nicht so n reddit Typ was ich weiß, das ist quasi ich glaub man kann einfach sagen ich will cashen ich muss ich muss anfragen machen ständig ans Backend und ich will die nicht durchschleifen bis zur Datenbank weil bis zur Datenbank muss ich da muss ich sehr weit gehen die Datenbank.

49:09 Wird quasi ja sehr belastet und es gibt ne schnellere Möglichkeit ne ne schnelle Antwort zu haben, die auch n bisschen temporärer ist. Ja vielleicht erklärst du das dieses Zwischenebene Reddit noch mal. Wo liegt das wo Cash das weil dieses ganze Cashing ist sehr kompliziert. Es gibt ja auch noch Cashing, das will ich auch noch mal sagen im Browser vielleicht um das auch noch mal rauszuholen. Ja ganz am Anfang sagtest du, es gibt ja die Spiele ohne Backend, die passieren nur im Browser, aber selbst da kannst du quasi wenn das zweite Mal reinkommst hast du vielleicht immer noch deine Highscores und so weiter.

49:37 Weil auch der Browser ne Datenbank drin hat, die Index DTB zum Beispiel kannst du nutzen oder du nimmst einfach Local Storage. Das ist auch da, das ist so ein synchroner Speicher, dann bleibt das alles quasi in deinem Browser bis du sagst Lösch meine Browserdaten, dann bist du wieder genullt, dann verlierst du quasi alle Informationen zu dem Spiel, da gibt es, da gibt es auch schon mal einen Cash, der ist quasi für jeden Client an sich, ja.

49:58 Redes ist aber jetzt nicht beim Client, sondern schon bei euch hinten im sogenannten Backend. Ja, ich will jetzt nur noch 23 Worte zum redes, ich glaub dann haben wir es mit dem Caching Day ja so n bisschen und mit der Skalierung ja n bisschen besser aufgegleist. Ich glaub um Redes zu verstehen, noch mal 2 Sätze zu dem super erklär ich mal noch eine Ergänzung zu Webserver und der Datenbank, also der Server wo du meintest du die App spricht über ne URL mit dem Server, sagt hier am Ende mal kurz mitnehmen. Gib mir mal mein aktuelles Spiel mit dem Gerrit und alle Informationen dazu.

50:25 So der Server kriegt dann diese Anfrage, davon können da ganz viele sein und die Aufgabe vom Server ist nur zu das Zusammenzupacken und irgendwo die Informationen herzuholen, aber der hat die Informationen selbst nicht, das heißt der Server der ist was Dates bedeutet ist wenn der mal runtergefahren wird oder hochgefahren wird ist das gar kein Problem weil der kann jegliche Informationen verlieren sobald er ne Anfrage kommt ist macht er zur Laufzeit während die Anfrage ist holt er sich alle Informationen die notwendig sind aber er muss sich nichts merken.

50:50 Das ist sozusagen der Server, der muss sich gar nichts merken, der ist Date ist. Dann gibt es die Datenbank der ihre, wo es mal Sikulum, der ihre Aufgabe ist, sich alles zu merken und wenn wir das hoch und runterfahren, die muss sichergehen, dass diese Daten niemals verloren gehen, weil es ist, das ist das Brain, wenn wenn das Weg ist, dann sind alle Daten weg, so das ist. Deswegen ist die ganz klare Anforderung, Hey, bei dir möchte ich alles ablegen, du solltest sie so ablegen können, dass ich mir die Daten sinnvoll abfragen kann und du musst immer alle Daten haben.

51:16 Weil aber die Datenbank die Anforderung hat eben. Immer alles zu speichern, sich darum zu kümmern, dass wenn ich da was ablege, dass da nicht irgendwie Daten überschrieben werden und da sehr viel Overhead hat, ist vielleicht Performance wichtig, aber kommt manchmal in seine Limitierung und da kommt im Endeffekt dann ein Caching Layer ins Spiel.

51:33 Redes ist eine technische Implementierung diesen Caching Layer zu betreiben, der einfach sagt wie in der Datenbank stehen halt meine Spiele immer in einer Tabelle genau der einen Art, aber mein Server der fragt diese Spiele irgendwie sekündlich an und das jedes Mal die Datenbank zu machen jedes Mal auf die Festplatte gucken muss. Irgendwie rausholen muss und dann rausschicken muss. Das ist braucht sehr viel Zeit, also lass doch einfach diese Daten in dem Reddit auch ablegen und der Reddit, weil der sie nicht auf auf die Festplatte speichern muss, sondern sie wirklich nur in Memory hält, weil auch der Reddit, wenn ich den Reddit runterfahre, wieder hochfahre, der darf die Daten verlieren, so falls er sie nicht

52:05 hat, geht er auch an die Datenbank, nur sagt dann ich merk sie mir ab jetzt wenn der Server mich wieder anfragt. Dann hab ich sie ja schon hier memory. Ich kann sie direkt schnell rausliefern, muss gar nicht an die Datenbank fragen und weil wenn man es wirklich ganz und ob ich einfach nur die der Red ist die Anforderung nicht hat, ich muss das Persistieren sondern ich darf sie auch wieder verlieren, kann ja ganz anders mit den Daten umgehen und in einem Cachinglayer ist es auch OK wenn ich die wenn ich das.

52:25 Die Spieledaten einmal, wenn ich meinen Zwischenstand zwischen Spielen wissen will, auf die eine Art speichert und wenn ich dann im Spiel kurz ein Update bekomme auf eine andere Art, weil er weiß, ich kann diese Daten hier duplizieren. Es ist wichtiger, dass ich sie möglichst schnell im richtigen Format liefert, dann dupliziere ich sie lieber mehrmals.

52:39 Es ist eine ganz andere Anforderung, weshalb es dann am Ende so ist. Das Ziel vom Caching Layer ist, weniger Anfragen auf die Datenbank, dass ich sie höher skalieren kann, nicht jede Anfrage dahin durchkommt und schnellere Antwortzeiten für unsere User, dass sie eben nicht Sekunden darauf warten müssen, sondern Millisekunden im Besten.

52:53 Fall. Perfekt klingt, klingt total einfach. Cashing Layer heißt immer ich muss, also ich kann es haben, ich muss aber nicht, selbst wenn der Cash tot ist, dann wird halt wieder von der originalen Single Source of Truth abgefragt und aber was passieren muss, vor allen Dingen wenn ich schreibe ist, das ist unter dichter Hase im Pfeffer und dann ist es doch gar nicht so einfach und das weiß jeder Softwareentwickler, der mit Cashes arbeitet.

53:12 Ich muss schon den Kram synchronisieren, denn wenn wenn wenn ich ich habe für den Moment, dass der Cash da ist, hab ich so ne Art Split brain 22 sources of Truth und wenn das Cashing dann nicht läuft und so weiter das Synchronisieren des Cashes und das der eigentlichen Datenbank nicht funktioniert, guck ich auch kurz mal komisch und das muss man schon hinkriegen. Ja, aber das sind ja auch trotzdem, das sind ja trotzdem alles Sachen, die ja heutzutage.

53:33 Länglich gelöst sind, da gibt es viele Rezepte, wie man das zu machen hat. Ja und? Vielleicht hat es ja vereinfacht dargestellt. Dann fragt der Reddes bei der Datenbank an. In der Realität fragt nicht der Reddes an, sondern der Webserver fragt Reddes an, wenn es da nicht ist, geht an die Datenbank und sagt dann Reddes komm mal hier, die Daten hattest du nicht, nimm sie jetzt mal. Und klar, das ist die Aufgabe des Entwicklers, dieses diese Kommunikation zu tun, ich hab es vorhin n bisschen vereinfacht dargestellt.

53:53 Ja, alles gut, aber ich glaub jetzt haben wir es noch mal n bisschen mehr aufgedröselt. Ja ich glaub das war vielleicht noch mal ganz cool, das war nicht nur. Die Buzzwords klingeln lassen. Ja danke auch Fabi, dass du noch mal mit uns in die Tiefe gegangen bist. Auch wenn man als Entwickler da sagt, so OK das ist, das ist eigentlich täglich Brot und Butter, aber wir wollen ja noch mal n bisschen unter die mal n bisschen drunter, sehr gerne.

54:11 Gut für das, für das cool gut ist natürlich jetzt auch ne große Aufgabe, mobile Game Development in einer Stunde ja tatsächlich zum Antworten von Marketing über tiefe Technik bis Server und auch was passiert auf dem Gerät und so weiter und sofort, aber so ist ja schon ganz cool, wenn es für euch OK ist. Lasst uns noch mal ganz kurz oder auch gerne. Länger, je nachdem, wie lange wir brauchen. UXUI an anreisen zumindest.

54:34 Ich glaube das ist bei euch extrem wichtig unterstütte jetzt mal um um User zu gewinnen und sie dann auch zu im Spiel zu halten und und wiederkehren zu lassen und da können glaub ich viele andere Branchen dann auch was von lernen inklusive uns wahrscheinlich was sind da so deine aus der Praxis heraus deine Top Top Learnings? Ja worauf worauf kommt es an um um Nutzer. Süchtig zu machen, ne im im im schlimmsten Fall ausgedrückt, aber irgendwie so so ne Stickinist zu haben als als App, als Anwendung, als Spiel ne wo Leute auch Lust haben dabei zu bleiben.

55:04 Ich glaub es gibt kein Geheimrezept. Erstmal ne und auch wenn man sich jetzt Games vorstellt und oder im Vergleich zu anderen Webapplikationen oder Webseiten die man baut, so erstmal musst du glaub ich das was du machen willst einfach. Richtig machen und es ist nicht so, dass man sagt, Nimm diese Rezepturen, die kannst du überall drauf werfen und dann wird es wird aus was Schlechtem, was gut und so. Also erstmal geht alles aus von der Idee und wenn man jetzt vom Game spricht von dem Core Loop, also so die Frage und das ist auch immer super wichtig für was entwickelst du denn so? Und die Antwort ist so unterschiedlich, wenn man mit sehr viel sind wir auf Native gegangen, ich glaub mein da kauft man User ein das stimmt

55:37 für Native auf Facebook ist es so, da ist eben nicht user einkaufen sondern da stimmt noch viralität, das heißt wir bauen dann Produkte haben wir auch dieses so was ich meinte asynchrone Gameplay Man spielt nacheinander. Da ist es einfach super, super wichtig, dass du dir klar darüber bist. Du entwickelst ein Spiel für Facebook. Wie wird dieses Spiel überhaupt auf Facebook erfolgreich, was sind Spieleprinzipien, die den Leuten Spaß macht und wie kann ich es umsetzen, wirklich einen einfachen Flow, was baue ich denn, dass es in diesem Ökosystem gut funktioniert, so also wenn ich da anfange und sage, ich baue jetzt hier ein synchrones Spiel, wo die Leute direkt miteinander spielen können, wenn sie online sind,

56:09 dann wirst du damit, egal wie high Polish das ganze baut, nicht erfolgreich sein, weil in der Realität ist. Auf der Plattform sind die Leute nicht gleichzeitig online, sondern sie wollen dann spielen, wenn Sie gerade reinkommen. Kommen und wollen nicht irgendwie ihrem Freund erst Bescheid geben? Komm doch mal online, wir spielen jetzt so, das ist nicht der Use Case dieser Plattform, das heißt am Ende ist erstmal so, mach deine Hausaufgaben gut was das Grundprinzip angeht und dann würde ich sagen was UX und so was angeht ist es auch, da hat es keine anderen Anforderungen als jetzt irgendwie ne Social Plattform oder irgendwie ne Webseite so ich glaube das was dann der der Unterschied ist von. Games hinzu einer Web

56:44 Applikation, so dass natürlich der I Candy eine gewisse Rolle spielt. So und ich glaube schon, dass auch gerade wenn du jetzt im native Markt bist, so früher auch auch bei Games gehen wir MBP getrieben vor, also minimal viable Product was ist das Minimalste was wir bauen können, um unsere Hypothese, dass ein Spiel funktioniert, dass wir das validieren können, so und da. Da würde ich sagen, ist der, der der größte Unterschied zur Webprävention, dass ein gewisses I. Candy, wenn es also sozusagen Animation irgendwie visual Appeal und so einfach auch notwendig ist. So und klar sind vielleicht noch mal so Aspekte wie wenn du im native Markt bist, dass du dir überlegen musst, willst du ne Story da drin integrieren,

57:21 brauchst du character, die irgendwie mit dir sprechen und du musst irgendwie ne narrative möglicherweise dafür bauen und da gibt es schon sehr viel mehr Arten, über die du nachdenken musst. Aber im Grunde genommen sind alles. Features selbst eine Story zu bauen oder Caritas zu integrieren sind Features und du musst überlegen. Glaubst du, dass dieses Feature notwendig zum Erfolg ist? So, und dann geht es eigentlich fast nur darum irgendwie nen nen guten Job zu machen und für Animationen ist es so, da haben wir natürlich super super viel mittlerweile investiert wie wir die ganzen bauen, also gerade was jetzt in den Webframeworks angeht wissen wir halt auch sehr gut so welche. Welche CSS Animationen wir

57:54 irgendwie nutzen können, die auf der GPU laufen und damit performant sind. Wir nutzen Tools, was wir aber auch mittlerweile, wir haben letztens hier n Talk gehabt von einem unserer Designer der über Micro Animations gesprochen hat und auch da auch gemeint hat, wie man in Enterprise Applikation mit Micro Animations noch viel rausholen kann und da haben wir zum Beispiel über n Tool gesprochen wie Rive nennt sich das ist zum Beispiel auch ein eine Engine um Animationen zu machen die man in die man sowohl im Web mit Java Script als auch in allen möglichen Game Engines einfach integrieren kann wo Designer was. Visuell designen können ein kleines File an die Devs übergeben und die dann damit per

58:26 Code interagieren können. Wirklich auch so State Machines haben, das ein Charakter sein kann der winkt und dann läuft er wieder und das kann man aber auch zum Beispiel für Buttons nutzen, also dass du aber wenn du so einen einfachen Toggle hast so ich mache jetzt hier was an, dass du das wirklich irgendwie so machen kannst, dass da richtig coole und irgendwie haptische Feedbacks kommen, die einfach super cool aussehen und einfach Spaß machen und da ist aber auch bei uns immer wieder eine Diskussion, wieviel ist genug und das ist nicht einfach zu, das ist überhaupt nicht einfach zu sagen, ist auch schwierig zu testen, so ne da ist irgendwie da zählt, da spielt irgendwie Erfahrung mit rein und auch da ist es

58:54 schwierig irgendwie n Patentrezept zu liefern und auch wir fragen uns immer, wo sind wir Lin genug, wo wo sind wir wirklich Time to market so schnell wie möglich und wo verrennen wir uns vielleicht und sagen OK oder also ich meine, da kannst du ja auch, da kannst du ja auch, das ist ja auch n ungelöstes Rätsel, ja die das ändert sich ja, es gibt ja auch noch keinen allgemeinen Geschmack, du hast ja auch die neuen Nutzer, die reinkommen, die wieder was anderes haben wollen und so weiter das was ja. Vorgestern funktioniert hat, funktioniert übermorgen nicht mehr und so das glaub ich ein ständiges Ausprobieren und hin und her deswegen ja auch das das das viele Zurückfunken der der Usability euer euer Spiele glaub

59:29 ich das hast du am Anfang glaub ich den Punkt hattest du gemacht, dass ihr relativ viel drauf angewiesen seid auf das Tracking also was wird geklickt wo ist wo ist man schnell wieder raus und so weiter um daraus Schlüsse zu ziehen wo kann ich UIUX mäßig noch n bisschen was verbessern ne? Was aber rüberkommt ist, ihr habt es auf jeden Fall.

59:45 Ziemlich stark priorisiertes Thema, oder? Also ihr denkt viel darüber nach, in euren euren Prozessen UX und UI. Ja, also das ist super, super wichtig. Also ich mein, Ich hatte ja vorhin gemeint, für mich als Project Manager ist die aufgefallen, das ist die Gruppe Gameday jetzt für sie mal zum Erfolg, dann sind meine Hauptaufgaben mir das Konzept zu überlegen und das wirklich mit unseren Designern zusammen.

1:00:06 UX ist ein Riesenthema und darüber diskutieren wir super super viel UUI das visuelle das ist dann würde ich wirklich sagen, da haben die Designer die Hoheit da sind so. Da sind Sie, die Experten. Aber gerade was UX angeht, ist ich als Product Manager zusammen mit unseren Designern gepaart mit was lernen wir aus den Daten, das ist unser tagtäglich Brot, überlegen uns Features, wir überlegen, wie ist der Flow, wir testen 23 verschiedene Flows, nab, Tests überlegen was waren die Ergebnisse, warum können diese sein, was können wir daraus lernen, was können wir beim nächsten Mal verändern und das ist meine Hauptaufgabe so also mir die ganze Zeit zu überlegen was was könnte an diesem Flow nicht stimmen, was

1:00:42 könnte ich zu einem neuen integrieren um etwas besser zu machen und. Und dieses datengetriebene ist der glaub ich wirklich der große Unterschied, auch im Vergleich zu wie hab ich Enterprise entwickelt? Ne, da ist halt da machst du dann n großen Teil über User Interviews so also wenn du irgendwie Insights generieren willst die Datenmengen haben nicht ausgerichtet, da konnte ich über Monate hinweg vielleicht irgendwie Trends sind, aber dass ich jetzt wirklich daraus ableiten konnte, was an Feature auch wirklich manchmal so kleine Details so, wir haben auch teilweise Tests wirklich gehabt, wo du.

1:01:06 Hat zuerst letztens wieder ein Spiel von the Seas the Test. Das war so ein Spiel wo Freunde sich besser kennenlernen konnten. Wirklich persönliche Fragen über sich beantwortet haben und der Freund hat probiert einen dazu einzuschätzen und da war es wirklich so, dass der Aufbau eines Screens und das war innerlich eigentlich 1 und 1 das gleiche, wir haben einmal oben noch mal irgendein Profilbild angezeigt, ein paar Pfeile hingemacht, die Buttons noch mal expliziter gemacht hat, ein Feature von.

1:01:29 Das hat einen negativen Impact und zwar -7% Viralität. 7% weniger User sind reingekommen als wir dieses Feature implementiert haben. Hinzu Wir haben nur diesen Screen verändert, dass Design des Screens hinzu 7% plus verändert, weil wir einfach gemerkt haben okay, da hat man uns sagen, davor haben wir vielleicht einfach einen schlechten Job gemacht, so aber so auf diesen Details zu überlegen, was kann vielleicht auch der Screen das Problem sein und gar nicht das Feature ist, ist jetzt der seltenere Fall, dass es wirklich so extrem ist. Aber auf diesem Detail gerade unterhalten wir uns natürlich tagtäglich und gehen das wirklich durch. OK, und vielleicht jetzt noch mal anschließend dazu, weil du es auch ganz am Anfang mal

1:02:01 erwähnt hattest. Workflows wie ihr arbeitet, du hattest so gesagt AI Workflow. Vielleicht kommen wir darauf noch mal zurück im Laufe des Gesprächs hast du da besondere Erkenntnisse. Wie nutzt ihr KIAI irgendwie ganz besonders viel an spezielleren Stellen als als als üblich? Ja, was auch immer üblich heißt.

1:02:19 Genau ich, das ist glaub ich die Frage, was ist üblich. Ich würde wahrscheinlich wir unterhalten uns ja auch auch durch den Podcast ja auch. Mit vielen anderen auch, wie es so in Firmen eingesetzt wird. Ich würde schon sagen, dass wir KI sehr, sehr exzessiv einsetzen, wir probieren wirklich jeden bei uns dazu zu enablen und wirklich AI first irgendwie zu denken, also als Vehikel haben wir da verschiedene Dinge als beispielsweise wir machen einmal im Quartal firmenweit eine AI Week, also jedes Quartal gibt es eine Woche lang wo alle alle stehen und liegen lassen und im Endeffekt nur AI machen was auch immer das bedeutet, also am Ende ist es so, dass aus diesen Wochen immer.

1:02:55 Einerseits sehr, sehr viele Erkenntnisse kommen. Man kann das einfach als komplette Forschungswoche nutzen, einfach nur sich damit zu beschäftigen, zu gucken, was weiß ich darüber noch nicht, was für Tools kenn ich noch nicht, aber meistens ist es so, dass sich Leute daran setzen, entweder kleine Games zu bauen oder einfach das Tooling zu optimieren, also alles was wir irgendwie automatisieren können jetzt durch AI probieren, wir zu automatisieren und ansonsten, das ist nämlich ganz interessant, jetzt auch mal, wenn wir auf diesen Game Engine Aspekt kommen ne ich hab ja vorhin gemeint Unity hat einen visuellen Editor und hat einen Teil in C Sharp und. Wenn man jetzt einfach mal sieht, auch gerade in den letzten im letzten halben Jahr

1:03:27 was für n Sprung AI da einfach noch mal gemacht hat, wenn man wirklich sieht wieviel man auch wirklich, wenn man jetzt so n bisschen negativ belastet wirklich komplett Vibe coden kann, so also wie gut die AI mittlerweile Full Stack im webbereich Applikationen bauen kann, ist das ja schon super, super beeindruckend und da muss man sich schon die Frage stellen, so zum Beispiel in Unity haben wir da einen gewissen Nachteil davon, weil Unity hat?

1:03:50 Kann zum Beispiel mit dem ganzen Visuellen eigentlich nur über Schnittstellen im AI Bereich heißt es ja MCP so ein Standard über eine Schnittstelle damit interagieren. Man merkt es ist sehr sehr viel schlechter das zu bauen, sodass wir im Moment auch zum Beispiel am Diskutieren sind, so sollten wir mal probieren neue Gameprototypen wirklich komplett AI first und nur mit AI zu bauen, wir haben da schon einige Gameprototypen wir haben zum Beispiel bei einem Spiel ist es so, dass wir. Eine in Unity entwickelte Variante haben und der Product Manager hat parallel nur Gewibecoded das gleiche Spiel parallel gebaut und er ist eigentlich im Parallelen Bauen weiter als dieses Team es macht, obwohl sie auch AI enabled, also super viel AI first arbeiten

1:04:28 aber halt die Unity eine gewisse Grenze hat, natürlich immer n bisschen andere Anforderungen an den Prototypen des Product Managers sind, aber wir da auch so Diskussionen führen wie hey sollten wir sich auch einfach wirklich probieren den den. Das produktive oder das das Endprodukt komplett AI First zu bauen und doch wieder wegzugehen von von der Game Engine in dem Fall und da also AI ist eigentlich überall in Fused bei uns so und hat auf jeden Fall den Arbeitsprozess total verändert, auch gerade was irgendwie.

1:04:56 Reviews angeht, ob wir sie teilweise überhaupt noch machen, wieviel wir Entwickler allein machen lassen und eben nicht mehr im im Pair dann was Reviews angeht, weil man im Endeffekt bei manchen Dingen auch einfach nur noch der Reviewer ist und gar nicht mehr derjenige der es erstellt. Das heißt man ist ja eigentlich schon im Reviewer, sieht so n bisschen und ja, aber deswegen ist natürlich schwierig zu sagen, was machen wir anders als andere, ich würde sagen wir probieren die die Grenzen aus, also schon mal schon sehr stark die Grenzen auszuloten und auch sowas.

1:05:22 Wir in erster Linie die Leute zu enablen und dann werden sie schon selbst auf die sinnvollen Lösungen kommen. Also da ist auch so jegliches AI Tour, was die Leute irgendwie nutzen wollen können Sie nutzen, komplett unlimitiert und so viel wie sie das Ganze wollen. Wir haben Communities of Practice, wo wir probieren die besten AI Learnings irgendwie zu teilen, probieren haben wir haben jede Woche einen all hands mit der gesamten Firma wo. Eigentlich alle Teams so ein bisschen zeigen. Woran arbeiten Sie gerade, was haben wir in der letzten Woche gelernt und ein Teil ist auch davon, dass Leute, wenn sie in der letzten Woche irgendwas Interessantes mit AI gemacht haben, dass auch in der Firma

1:05:52 Firmenwald irgendwie Time, wenn sie kleine Tools gebaut haben, wenn Sie irgendwas Neues gelernt haben, genau und auch durch den Podcast ist natürlich was wir haben die AI News alle 2 Wochen wo wir auch einfach immer sehr nah am Zahn der Zeit sind, aber da ist es glaube ich schwierig abzusehen was wir da vielleicht anders als andere mal probieren einfach alles zu nutzen was geht. Ich glaub da das ist das hat Vorbildcharakter für einige so vom Gefühl her.

1:06:15 Ja, da kann man sich schon einiges von abgucken und das sind ja auch ganz konkrete Dinge, die ihr da tut mit euren AI weeks. Also du hast es glaub ich genannt, ne. Ja, genau. Die AI eure AI gemachten Spiele spielt, dann sind wir fertig. Dann dann ja, oder? Aber gut, das ist, wenn sie auch Werbung kaufen, wenn wir damit Geld verdienen, ist das OK wollt. Grad sagen ja, dann dann ist es auch noch sehr ja. Gut das das klingt so n bisschen wie das Ende oder? Oder dass wir jetzt zum Ende des Podcasts kommen. Oder Fabi haben wir noch irgend so n Aspekt vergessen wo du sagst, da musst du noch mal was zu loswerden, da wolltest du gerne was zu sagen.

1:06:48 Nee, ich glaube, wir sind ja hier auch schon mal. Wir haben irgendwie viele Bereiche davon gestriffen. Man kann könnte den vielen noch sehr viel weiter ins Detail reingehen, aber ich denke es hat n ganz guten Überblick gegeben. Ich hoff, dass wir jetzt nicht vielleicht zu technisch an unserer Stelle waren, aber das hat gepasst so.

1:07:02 Ja glaub bei uns das, das kann man auch so sagen das das Publikum ist von bis ne da sind alle dabei von wir haben Juristen, von denen hab ich schon gehört, wir haben ja auch Softwareentwickler die sich in neue Bereiche damit vorwagen also es passt ganz genau es wär alle immer n bisschen. Was dabei ja abschalten wird es ihm zu technisch, wird ja wieder anschalten, wenn da irgendwas, wenn da irgendein Thema ist, was nicht ganz so technisch ist. Ja genau, genau genau.

1:07:22 Dann ja, bleibt mir erstmal nur zu sagen, vielen herzlichen Dank. Ich fand es total spannend, richtig cool. Ich werd mir eure Spiele noch mal genauer angucken, hab da Bock drauf n bisschen zu probieren, vielleicht wollen das ja die anderen anderen Zuhörer auch mal ausprobieren. Wir verlinken die Website von euch ja auf jeden Fall und ja, damit vielen herzlichen Dank Fabi. Danke euch, vielen Dank, dass ich da sein durfte. Kann mich nur anschließen.

1:07:44 Fabi ist super cool, vielen Dank weiterhin viel Erfolg, danke und bis denn ciao. Dieser Podcast wurde dir präsentiert von Heisenware, deiner Plattform für visuelle Programmierung und Digitalisierung. In der Industrie. Starte jetzt deinen kostenlosen Test. Unterheisenware.com einfach komplex.