In den letzten zwei Jahren, in denen ich Chain Games beobachte, habe ich das Gefühl, dass es ziemlich "gegen die Intuition" ist: Es liegt nicht daran, dass es nicht genug Spielweisen gibt oder die Grafik nicht gut genug ist, sondern dass die meisten Teams LiveOps als "Notlösung" betrachten - wenn das Interesse nachlässt, wird ein Event gestartet, wenn die Zahlen schlecht sind, werden Belohnungen verteilt, und wenn die Community unruhig wird, gibt es Airdrops. Kurzfristig sieht es so aus, als würden die Spieler zurückgeholt, aber langfristig verbrennen sie das Wirtschaftssystem: Die Belohnungen werden immer gleichgültiger, der Preis der Coins/die Preise steigen und stürzen ab, und die, die wirklich bleiben, sind keine Spieler, sondern Bots und Farmen.
Deshalb sehe ich neuerdings die "Engineering von LiveOps" als den Weg von PIXELS, besonders nachdem sie Stacked als belohnenden LiveOps Engine positioniert haben (nicht als irgendeine Belohnungs-App). Die gesamte Logik macht jetzt Sinn: Es geht nicht darum, "mehr zu verteilen", sondern "genauer, kontrollierter und nachvollziehbarer zu verteilen". Mit anderen Worten, LiveOps ist nicht mehr etwas, was die Betriebsmitarbeiter nach Gefühl planen, sondern ein iteratives, testbares und überprüfbares Wachstumssystem.
Zuerst eine Sache, die ich für am wichtigsten halte: Das Wesen von LiveOps ist nicht die Aktion selbst, sondern „welche Signale du nutzt, um zu beurteilen, wie der Spieler als Nächstes weitergeht“. Die Signale traditioneller On-Chain-Games sind ziemlich grob – das Wallet war da, es wurden Aufgaben gemacht, es wurden Belohnungen abgeholt. Also kann das Operations-Team nur noch grobere Mittel einsetzen: einheitliche Auszahlungen, einheitliche Schwellen, einheitliche Zeit. Das Ergebnis: Alle werden als dieselbe Art Person behandelt – Neulinge, Reaktivierte, Core-Spieler, Pay-to-Win-Spieler, sozial orientierte Spieler und sogar Bots landen alle in einem einzigen Topf. Je größer die Belohnung, desto mehr zieht sie Wool an; je kleiner die Belohnung, desto weniger fühlen echte Spieler „dass es sich lohnt“; je höher die Auszahlungsfrequenz, desto schneller kommt Inflation; je niedriger die Frequenz, desto schneller bricht die Retention ein. Es wirkt wie „LiveOps ist schwer“, aber eigentlich sind die Signale einfach zu schlecht – damit ist keine Feinsegmentierung möglich.
Stacked verstehe ich als „die Inputsignale von LiveOps fein zu machen und die Output-Aktionen in experimentierbare Form zu bringen“. Oben drüber hängt ein AI game economist. Viele Projekte benutzen diesen Begriff als Marketing-Aushängeschild, aber im LiveOps-Kontext – wenn es wirklich arbeitet – sollte es drei Dinge lösen: Erstens: In Kohorten (Spielersegmentierung) einzuteilen ist nicht nach irgendwelchen Labels „so wie du es dir vorstellst“, sondern nach Verhaltenspfaden. Zweitens: Abwanderungspunkte nicht aus dem Bauch heraus zu raten, sondern die Bruchstellen der kritischen Pfade zu quantifizieren. Drittens: Belohnungen nicht nach Gefühl auszuteilen, sondern als Eingriffsmaßnahme A/B- oder Multi-Variable-Experimente zu fahren und am Ende auf harte Kennzahlen wie Retention, Revenue und LTV zurückzukommen.
Ich erkläre das mit einem konkreteren Beispiel. Stell dir vor, du stellst fest: „Nach Tag 3 fallen besonders viele raus“. Die traditionelle Vorgehensweise wäre: „An Tag 3 ein großes Paket schicken“. Aber wenn du wirklich Daten gemacht hast, wirst du sehen, dass die Gründe fürs Abwandern völlig unterschiedlich sein können: Manche stecken bei Ressourcen fest, andere reißen an der Aufgaben-Kette, wieder andere haben Social nicht abgeholt, jemand findet die Erträge zu langsam – und es gibt auch eine Gruppe, bei der Skripte durch deine Betrugs-Kontrollen fälschlicherweise getroffen wurden. Wenn du allen das gleiche Paket gibst, erzeugst du nur zwei Nebenwirkungen: Echte Spieler werden mit „One-Size-Fits-All“-Belohnungen abgespeist und lernen „es wird ja sowieso umsonst gegeben“, Skripte hingegen lernen, am Tag 3 gebündelt einzusteigen und abzuernten. Der wirklich effektive Ansatz wäre: das Verhalten rund um Tag 3 in Scheiben schneiden, schauen, welche Aktionen stark mit Retention korrelieren, und welche stark mit Bezahlung/Contribution zusammenhängen. Dann die Belohnungen in eine Kombination aus unterschiedlichen „Zielfunktionen“ zerlegen: Leuten mit Engpass schneller zum Durchkommen verhelfen, social orientierte Spieler schneller in Gilden/Allianzen bringen, potenziell wertvolle Spieler mit längerfristigen Incentives unterstützen – und bei verdächtigen Verhaltensmustern stärkere Validierung und Einschränkungen ausgeben. Das ist die richtige „LiveOps“-Öffnung: Belohnung ist kein Zucker, sondern ein Skalpell.
Das führt mich zum zweiten Punkt, der mir besonders wichtig ist: Betrugsabwehr ist nicht „ein Zusatzfeature“, sondern die Voraussetzung dafür, dass LiveOps überhaupt funktionieren kann. Das On-Chain-Belohnungssystem bricht so leicht zusammen nicht, weil das Konzept „Belohnung“ falsch ist, sondern weil es von Natur aus Gegner anzieht. Solange Belohnungen vorhersehbar sind, Schwellen reproduzierbar und Pfade skriptfähig, entstehen spezialisierte Farm-Aktivitäten: Mehrere Clients öffnen, Skripte, Arbeiten lassen, Arbitrage, Wash-Mining – am Ende wird das Belohnungsbudget abgezogen, und das Wirtschaftsmodell wird zu „Subventionen für Black-Produkte“. Viele Teams scheitern genau hier: Sie glauben, sie machen Operations – in Wirklichkeit füttern sie den Gegner mit Daten und Budgets.
Also wenn Stacked Fraud Prevention, Anti-Bot und Verhaltensdaten in den „Kern des Engines“ packt, dann sehe ich darin den Grund, warum das eher wie eine Infrastruktur und weniger wie ein Veranstaltungstool wirkt. Denn nur wenn du „echtes Spielerverhalten“ und „gefälschtes Verhalten“ kontinuierlich erkennen kannst, kann LiveOps präzise Ausspielungen machen; nur wenn dein Belohnungsbudget nicht von Black-Produkten stabil abgezogen wird, traut man sich zu langfristigen Incentives; und nur wenn du in der Produktionsumgebung den echten Nutzern und Angreifern standhalten kannst, ist „nachhaltiges P2E“ keine bloße Parole. Sonst ist es heute noch so lebhaft, aber morgen kracht ein Daten-„Push“ durch und die Wirtschaft stirbt zuerst.
Der dritte Punkt, den ich für leicht zu übersehen halte: Wenn LiveOps eine gewisse Komplexität erreicht, dann fehlt dem Projekt nicht primär „Ideen für Spielmechaniken“, sondern „die Integration von Insight in Action“. Viele Teams machen auch Analysen und schauen sich Dashboards an – aber die Umsetzung hängt am Ende doch an Leuten, die Konfigurationen, Aufgaben, Belohnungen und Wahrscheinlichkeiten anpassen. Das dauert lange, Probieren und Irren ist langsam, und der Review-Zyklus schließt sich nicht. Man sieht eine sehr typische Situation: Der Betriebsteam hat das Gefühl, dass A-Event funktioniert, also wird nachgelegt; aber eigentlich war der Effekt neue Inhalte, die durch das gleichzeitige Versions-Update kamen. Oder man glaubt, B-Belohnungen erhöhen die Retention, aber eigentlich hält man nur Spieler mit geringem Wert fest – das LTV fällt sogar. Ohne strenges Experimentdesign und geschlossene Ausführung wird LiveOps zu „je mehr man sich anstrengt, desto mystischer wird es“.
Der Teil der Stacked-Erzählung, den ich am meisten schätze, ist, dass es LiveOps zu einem System macht, das „stellbar, experimentierbar und ausführbar“ ist: Du fragst „Warum verlieren wir Spieler an Day 3?“, und es gibt dir nicht nur eine Grafik – es führt dich dazu, wie du segmentierst, welche Metriken du auswählst und wie du Belohnungsinterventionen designst, und ordnet dann die Interventionsaktionen direkt auf Konfigurationen und Ausspielungen ab. Genau so sollte ein AI game economist wirklich arbeiten – nicht um dir Berichte zu schreiben, sondern um dein Belohnungsbudget in einen steuerbaren Wachstumsmotor zu verwandeln.
Wenn wir weitergehen: Auf dieser Linie ist es bei PIXELS besonders interessant, dass es diese Engine als „Belohnungsebene über mehrere Spiele hinweg“ angeht – nicht nur für ein einzelnes Spiel. Die Decke eines einzelnen On-Chain-Games ist offensichtlich: Lebenszyklus, Content-Angebot, Spieler-Mindset und Marktzyklus klemmen dich fest. Wenn du einmal „Explosion – Viral – Farmisierung – Wirtschafts-Kollaps – Spieler zerstreuen sich“ erlebt hast, verstehst du, wie fragil es ist, Token an nur eine Spielmechanik zu binden. Umgekehrt, wenn die rewarded LiveOps engine in mehreren Spielen wiederverwendbar ist, dann akkumuliert sie etwas, das viel schwerer zu kopieren ist: Erfahrung in Betrugsabwehr, Verhaltensdaten als Asset, Design-Weisheit für Belohnungen und ein Experimentier-Framework über Produkte hinweg. Das ist weitaus schwerer als „noch ein Aufgaben-System bauen“.
Auch in externen Informationen wird mehrfach erwähnt, dass Stacked bereits in production läuft und nicht nur in der Whitepaper-Phase steckt. Außerdem wird beschrieben, dass es Produkte wie Pixels, Pixel Dungeons, Chubkins unterstützt, dass es Größenordnungen wie „Hunderte von Millionen Belohnungsereignisse“ verarbeitet und „Millionen von Spielern“ abdeckt. Dazu gibt es sogar eine öffentliche Behauptung, es habe zu „mehreren Dutzenden Millionen US-Dollar Einnahmen“ beigetragen. Für mich ist der wichtigste Wert dieser Art Zahlen nicht, um sie anzupreisen, sondern um Folgendes zu zeigen: Wenn es wirklich in diesem Maßstab durchläuft, dann hat es zwangsläufig massenhaft Grenzbedingungen durchlebt – Betrugsabwehr, Missbrauch von Belohnungen, wirtschaftliche Inflation, Ermüdung durch Events, Takt für Content-Updates, Kosten der Spieler-Migration … Viele dieser Fallen sieht man bei kleinen Projekten nicht; erst wenn du wirklich groß wirst, merkst du, wie brüchig das System ist wie Papier. Ein LiveOps-Engine, der in der Produktion laufen kann, beweist zumindest, dass es nicht nur eine PPT-Struktur ist.
Natürlich werde ich das nicht allein wegen dieser Erzählungen einfach als „unbesiegbare Antwort“ akzeptieren. Ich sehe es eher als eine Richtung, die sich lohnt, kontinuierlich zu beobachten: Wenn Stacked wirklich zu einer Infrastruktur werden will, muss es sich in ein paar Punkten dauerhaft selbst beweisen. Erstens: Die Erklärbarkeit der Belohnungs-Ausspielungen muss stark genug sein – sonst werden Spieler „präzise“ als „Manipulation“ interpretieren, und das Vertrauen der Community sinkt. Zweitens: Die Anti-Betrug-Strategie muss die Kosten für Fehlalarme mitdenken – zu streng vertreibt echte Spieler, zu locker wird von Black-Produkten durchlöchert, und die Balance ist extrem schwer. Drittens: Die übergreifende Belohnungsebene bringt neue Spieltheorie mit sich. Unterschiedliche Spiele haben unterschiedliche Wirtschaftsstrukturen – verursacht das Weiterleiten von Belohnungen in verschiedenen Spielmodi neues Arbitrage-Potenzial? Wie begrenzt man, dass das „am einfachsten zu farmende“ Spiel das gesamte System rückwärts verschmutzt? All das sind Ingenieurfragen, denen LiveOps begegnen muss, sobald es zur Infrastruktur wird.
Aber egal wie: LiveOps von „Geschenke verteilen“ zu „Belohnungsbasiertem Wachstumsmotor“ aufzurüsten – und den Motor von einem einzelnen Spiel auf eine übergreifende, plattformweite Ebene zu bringen – dieser Weg ist zumindest eher, als würde man die älteste Web3-Gangkrankheit lösen: Sobald Belohnungen auftauchen, wird gespooft; sobald die Wirtschaft hochfährt, wird sie ausgehöhlt; am Ende bleiben nur noch Blasen und Beschwerden.
