Concurrent Game Play mit AWS am Beispiel des Videospiels “New World”

Amazon Games veröffentlichte 2021 mit dem Videospiel New World ein Massive Multiplayer Online Role Playing Game (MMORPG), das Amazon Web Services (AWS) für sämtliche serverseitigen Dienste nutzt. Trotz eher mittelmäßiger Rezensionen des Spiels mit durchschnittlich 3,2 von 5 Sternen auf der hauseigenen Amazon Webpage wollen wir in diesem Blogeintrag einmal unter die Haube des Spiels schauen und sehen, wie das Spiel in seiner Architektur funktioniert um Concurrent Gameplay zu ermöglichen und welche Probleme während des Releases und der Laufzeit auftraten.

New World statt Old World

New World ist ein 2021 erschienenes MMORPG aus den Amazon Game Studios, entwickelt von deren Abteilung Amazon Games Orange County. Es spielt im 17. Jahrhundert der fiktionalen Welt Aeternum und behandelt die Kolonisierung des Landes durch die Spieler. 

Wie für Amazon oftmals üblich, wird die Technik, die hinter dem Spiel steckt, als bahnbrechend bezeichnet. Es werden Vergleiche gezogen, in denen New World durch die Nutzung der AWS – im Vergleich zur “Old World” der traditionellen MMOs – selbstverständlich um Welten besser abschneidet. Was also steckt hinter den genutzten Services? Was macht das Spiel aus Sicht von Amazon zu einem Gamechanger? Oder handelt es sich hier eigentlich einfach nur um eine große Werbekampagne, um die Nutzung von AWS in der Spielentwicklung zu festigen?

Schauen wir uns dazu erst einmal die zugrundeliegende Serverarchitektur an.

Server Architektur

In New World sammeln Spieler Erfahrungen und  Items. Sie treffen dabei mit vielen anderen Spielern und KI-Einheiten zusammen. Im Gegensatz zu Session-Based Games verlieren Spieler die Errungenschaften ihrer Sitzung nach einem Logout nicht. Sämtliche Gegenstände, die gesammelt wurden, getroffene Mitspieler und Fähigkeiten, werden als Wachstum des Spielcharakters abgespeichert und sind beim nächsten Login wieder verfügbar. Amazon Games erklärt diese Mechanik dafür verantwortlich, dass die Immersion für den Spieler steigt, auch wenn diese Mechanik beinahe schon eine Voraussetzung für MMOs multimillionen Dollar schwerer Unternehmen sein sollte. [1]

Abb. 1: Architektur hinter New World. Eigene Darstellung in Anlehnung an [1]

Während der Entwicklung der fiktiven Welt wurde Wert darauf gelegt, auf keine Ladebildschirme beim Wechsel zwischen Spiel-Arealen auf der Karte zurückgreifen zu müssen. Zu den weiteren Anforderungen gehört ebenso das Handling von unzähligen Spielern, die gleichzeitig auf das Spiel zugreifen wollen. Das führte letztendlich zur Verwendung eines massiven verteilten Systems. [1]

Zuallererst legten die Entwickler fest, die Anzahl der Spieler in der Welt Aeternum auf 2500 zu begrenzen und Spieler auf mehrere Welten zu verteilen. Zusätzlich befinden sich darin circa 7000 KI-Einheiten und mehrere 100.000 interagierbare Objekte. [1,2]

Abb. 2: Server Architektur einer Welt in New World. Eigene Darstellung in Anlehnung [2]

Werfen wir einen Blick in eine dieser Welten.

Möchte sich ein Client in einer Welt einloggen, stehen ihm dafür vier Remote Entry Points (REPs) zur Verfügung. Diese sind der einzige öffentliche Zugangspunkt für das gesamte Spiel und handhaben die Sicherheit und Belastbarkeit des Systems. Die REPs sind auf Amazon Elastic Compute Clouds, näher EC2 C5.9xlarge Instanzen, basiert. [1,3]

Abb. 3: Hubs und deren zugehörige Regionen. Eigene Darstellung in Anlehnung an [1]

Hinter diesen REPs befinden sich sieben Hubs, bestehend aus computational processing units, die ebenso auf Amazon EC2 C5.9xlarge Instanzen umgesetzt sind. Jeder dieser Hubs ist für die Berechnung eines Teils der Spielwelt verantwortlich. Dazu wird die Welt Aeternum mithilfe eines übergelegten Grids in 14 Regionen eingeteilt. Ein Hub ist hier nun für zwei nicht aneinandergrenzende Kacheln zuständig. Verlässt der Spieler die Region eines Hubs, wird er dem jeweils zuständigen Hub der neuen Region übergeben. So wird sichergestellt, dass die Last gleichmäßig über die Instanzen verteilt wird. [1]

Zusätzlich zu den Hubs existiert ein Instance Pool bestehend aus EC2 Instanzen. Dieser ist für den session-based Modus des Spiels zuständig, in New World sind das temporäre Abenteuer, die beispielsweise in einem Dungeon stattfinden. Entschließt sich ein Spieler, eine dieser Missionen zu beginnen, wird diese Session auf einer verfügbaren EC2 Instanz dieses Pools betrieben. Ist die Mission abgeschlossen, kehrt diese Instanz wieder in den Instance Pool zurück und ist für eine nächste Session bereit. [1,2]

Die Instanzen des HUBs sind im Grunde stateless. Dadurch wird gewährleistet, dass die einzelnen Instanzen bei Problemen neu gestartet und die Game-States wiederhergestellt werden können, selbst wenn alle HUB-Instanzen zeitgleich ausfallen. Hierfür ist es aber natürlich notwendig, die Game-States regelmäßig zu sichern. Bei New World wird hierzu Amazons DynamoDB verwendet, eine NoSQL-Datenbank, die flexibel und im Idealfall ohne Codeänderungen skaliert werden kann. Das Spiel kommt so auf 800.000 Schreibvorgänge der Gamestates alle 30 Sekunden. [1,4,13]

Um ein solches verteiltes System zu verwalten, ist es wichtig, einen guten Einblick über die unterschiedlichen Komponenten zu besitzen – eine gute Observability. Hierfür ist es wichtig, Events zu loggen und auszuwerten, um sich andeutende Störungen im laufenden Betrieb frühzeitig zu erkennen. In New World wird hierzu Amazon Kinesis verwendet. Mithilfe von Kinesis Data Streams, einem serverless streaming data service, werden große Streaming-Datenmengen in Echtzeit und hoher Geschwindigkeit erfasst und analysiert. Mithilfe von Kinesis Data Firehose werden die Daten schließlich an Amazon Simple Storage Service (S3) gesendet, einem Objektspeicherservice. [1,2]

Pro Minute verlassen so 23 Millionen Events Kinesis in Richtung S3. Die Daten in S3 können anschließend durch Analyse-Services wie Amazon Athena und OpenSearch ausgewertet werden. Die ausgewerteten Daten können die Entwickler des Spiels anschließend nutzen, um beispielsweise herauszufinden, welche KI-Einheit am häufigsten bekämpft wurde oder auf welchem Pfad die meisten Spieler unterwegs waren. Auf dieser Basis können die Gamedesigner Aspekte des Spiels verändern und damit die Spielerfahrung in Echtzeit verändern und verbessern, angepasst an die gesammelten Daten. Ebenso kann auch ein Fehlverhalten der Server frühzeitig entdeckt und behoben werden. [1,2]

Für die operative Seite, die der Seite des Core-Gameplay gegenüber steht, wird Amazon API Gateway verwendet. Es ist dafür zuständig, die externen Applikationen zu managen und kümmert sich darum, dass die Spieleentwickler Programmierschnittstellen erstellen, veröffentlichen, warten, überwachen und sichern können. Über dieses Gateway werden 200 Millionen Calls pro Minute verarbeitet. Dahinter werden globale Services und lokale / Cluster Services gehandhabt. Für diese Services wird Amazon Lambda verwendet, eine eventgesteuerte, serverlose Computing Platform. Für die globalen Services betreibt Lambda Microservices für Achievements, Channels und eindeutige globale Usernames, während für die lokalen Services Queues, Contracts, Sessions und Notifications, etc. gehandhabt werden. Dabei läuft jede Lambda Funktion in einer isolierten Umgebung mit eigenen Ressourcen und Filesystem. [1,2,5]

Abb. 4: Serverless Microservices. Eigene Darstellung in Anlehnung an [2]

Durch diese gesamte Architektur besitzt New World eine gute Scalability und kann schnell auf unerwartet hohe Nachfragen von Seiten der Spieler reagieren. Beim Release des Spiels wurden beispielsweise 185 verschiedene Welten zur Verfügung gestellt, also eine Bereitstellung für nahezu 500.000 Spieler. Innerhalb der ersten zehn Tage wuchs die Anzahl der Welten bereits auf 500 an. Das sind genügend für 1,25 Millionen Spieler. Für das Scaling setzt Amazon Games auf Scaling Out. [1,2]

Gespannt auf den Release?

Abb. 5: Wait, it’s only a queue? [15]

Soviel zur Theorie, aber wie sieht es denn jetzt in der Praxis aus? Verlief der Release, wie wir jetzt erwarten könnten, ohne Probleme? Leider nein.

Trotz der beschriebenen Möglichkeit, eine einfache Skalierbarkeit durch die Serverarchitektur zu besitzen, gab es zum weltweiten Release von New World am 28. September 2021 – ebenso wie auch bei anderen MMOs – große Probleme, um als Spieler auf den Server zu gelangen. In Warteschlangen sammelten sich meist zwischen 5.000 und 10.000 Spieler pro Welt, die bereits ihr Maximum an Spielern erreicht haben. Von einer schnellen Skalierbarkeit war nichts zu sehen. Um mehr Spieler pro Welt zuzulassen, wurden regional Tests gestartet, den initialen Wert von 2.000 auf bis zu 2.500 zu erhöhen. Hier wurde beobachtet, wie sehr sich die 2.500 Spieler über die gesamte Welt verteilen und ob sich nicht zu viele Spieler zeitgleich in der Region nur eines EC2 tummeln. Letzten Endes konnte die Spielerzahl nach positiv ausgefallenem Test erhöht werden. [6]

Why did the New World player cross the road? To get to the other queue!

Wieso also konnte – oder wollte – Amazon Games die Server trotz angepriesener Möglichkeit nicht skalieren? Das Problem liegt hier nicht unbedingt auf der Seite der Architektur. Beginnen wir beim Start eines neuen Spiels: der Spieler wählt eine Welt aus, auf der er spielen möchte. Auf dieser Welt wird nun der Spielcharakter erstellt. Ein Wechsel zu einer anderen Welt ist nicht möglich, es sei denn der Spieler erstellt einen neuen Charakter und startet von vorn. Ist eine Welt also voll besetzt, kann ein Spieler nicht einfach in eine andere Welt eintreten, deren Maximum noch nicht erreicht ist. Wie es beim Release von MMORPGs meist der Fall ist, gibt es vor allem in den ersten Wochen einen großen Andrang an Spielern, der sich jedoch meist wieder stark verkleinert. 

Abb. 6: New World Right Now [16]

Hätte Amazon also zum Start des Games direkt deutlich größer skaliert, um eine Wartezeit für Spieler zu vermeiden, wären die Welten in den ersten Wochen zwar gefüllt gewesen und alle Spieler glücklich, danach jedoch nur zum Bruchteil voll. Dies hätte dazu geführt, dass das Gameplay durch zu leere Gegenden leidet und viele Welten zusammengeführt hätten werden müssen, was wiederum für Downtimes der betroffenen Server gesorgt hätte. Für die Durchführung eines Merges sind einige Dinge zu beachten. New World Developer Kay sagte hierzu, es werde erst einmal sichergestellt, dass die neue Spitzenpopulation über 1.000 beträgt. Außerdem solle eine gleichmäßige Repräsentation der Fraktionen sichergestellt werden. Der komplexeste Punkt läge jedoch in der Sorge um eine Instabilität der Persistenz beim Merging von Häusern der Spielcharaktere. Diese könnte dafür sorgen, dass die Häuser der Spieler verloren gehen würden. [9,10]

An sich also ein logischer Schritt, Mergings zu vermeiden. Da das Spiel jedoch – sei es durch Bugs oder die zu langen Wartezeiten – nach dem anfänglichen Ansturm an Spielern schnell von 1,6 Millionen auf 150.000 Spieler pro Tag gesunken ist, konnten Merges von Welten nicht mehr lange vermieden werden. [8,14]

Und jetzt?

Nach dem Start des Games wurden verschiedene Exploits entdeckt, die es den Spielern unter anderem erlaubte, Ingame-Währungen und Items zu verdoppeln. Um diesen Fehler zu beseitigen, wurde ein Jahr nach dem Release angekündigt, sogenannte Fresh-Start-Server online zu nehmen. Diese Server beinhalten keinen Charaktertransfer aus den Welten älterer Server, und stellten damit sicher, dass kein Spieler von seinen Exploits profitieren konnte. Auch ein Merge zwischen alten und neuen Welten wird Stand jetzt nicht stattfinden. Somit fungierten die Server auch als Neustart des Spiels, bei dem sämtliche Spieler mit allen Verbesserungen, die das Spiel seit Release hatte, von vorn und auf demselben Stand beginnen konnten. Man könnte diese Fresh-Start-Server also auch einen zweiten Release des Games nennen. [7]

Why did the gamer quit playing New World? Because he couldn’t handle the “New” bugs every day!

Die fehlende Möglichkeit, zwischen Welten zu wechseln, wurde mittlerweile behoben. Amazon Games gab an aktive Spieler im November 2021 und Februar 2022 Tokens aus, um einen einmaligen Charaktertransfer zu ermöglichen. Diese Option wurde von vielen Spielern dringend erwartet, da Amazon Games zum Release des Spiels ankündigte, dass Spieler sich keine Sorgen machen müssten, wenn sie aufgrund der vollen Welten eine andere Welt als ihre Freunde wählten, da ein Servertransfer in Zukunft möglich sein würde. Etwas zu schön, einen Serverwechsel so simpel und vor allem kostenlos anzubieten, daher wurden ab April 2022 keine weiteren Tokens einfach so ausgehändigt, sondern für $15 USD im Ingame-Shop verkauft. 

Fazit

Stellen wir die ausgeklügelte Architektur mit den Problemen des Spiels vor allem während des Releases gegenüber, stellen wir fest, dass die Scalability nicht ganz wie angepriesen funktioniert hat. Zwar bietet die Architektur die Möglichkeit, schnell neue Welten für einen großen Andrang an Spielern mithilfe eines Scale-Outs zu öffnen, aber diese Möglichkeit ist angesichts der fehlenden Möglichkeit eines ebenso schnellen Scale-Downs relativ sinnlos. Durch den fehlenden Scale-Out während des Releases konnte man erkennen, dass dieses Problem den Entwicklern wohl bekannt war. 

Ein Merge von Welten hätte von Anfang an mit eingeplant werden müssen, das Team hätte an dieser Stelle also nicht nur an die Möglichkeit eines Scaling-Outs, sondern ebenso an ein Scale-Down denken müssen, um sich langfristig an eine dynamische Anzahl an Spieler anpassen zu können. Die fehlende Möglichkeit eines Transfers zwischen den Welten sperrte im späteren Verlauf Spieler in einer zu gering populierten Welt ein, in der zu wenige andere Spieler zur Interaktion vorhanden waren. Auch aktuell existieren Welten, in denen im Peak gerade nur einmal 500 Spieler aktiv sind [11]. An dieser Stelle hätten sich die Entwickler mit einem weniger statischen Management zwischen den Welten einige Probleme vor allem während des Starts des Spiels, aber auch im langfristigen Lauf erspart. 

Alles in allem muss man die aufgetretenen Probleme aber sicherlich auch auf den Aspekt des Arbeitsumfeldes in der Gaming-Branche schieben. Crunch ist mittlerweile zu einem Standard in diesem Sektor geworden und benötigte Alpha- und Betaphasen sind teilweise zu kurz angesetzt. Zwar wurde der Release von New World bereits um einige Monate nach hinten verschoben, um eine erkannte Instabilität der Server zu beheben – was auch ein schlechtes Licht auf AWS geworfen hätte – aber gerade der fehlende Scale-Down hätte ebenso mehr Zeit benötigt [12]. Vermutlich spielten hier Delays und Absagen von zwei weiteren Spielen, die Amazon Games zusammen mit New World 2026 ankündigte, eine Rolle. Aber das alles soll natürlich keine Ausrede für ein Multi-Milliarden Dollar Unternehmen sein. Und gerade für einen Anbieter, der das Scaling seiner Dienste anpreist, erntete das doch einige negative Kommentare und Artikel. 

Letzten Endes ist New World aber ein guter Startpunkt für folgende Releases und MMORPGs. Wenn Entwicklerteams aus den Fehlern des Spiels gelernt haben, könnte sich dahinter ein großes Potential für zukünftige Concurrent Games verstecken. (…Sofern die Beschreibung der zugrundeliegenden Architektur etwas sorgfältiger dokumentiert wird. Ich habe schon lange nicht mehr so viele Fehler und Inkonsistenzen zwischen Text und Diagrammen wie in Amazons selbst erstellten Beitrag gesehen.)

Quellen

[1] Nicholas Walsh und Amazon Game Tech Team, The Unique Architecture behind Amazon Games’ Seamless MMO New World. [online]. 06. April 2022. Verfügbar unter: https://aws.amazon.com/de/events/events-content/?awsf.filter-series=event-series%23reinvent&awsf.filter-session-type=*all&awsf.filter-level=*all&awsf.filter-topic=*all&awsf.filter-industry=*all&awsf.filter-language=language%23english&cards.q=new%2Bworld&cards.q_operator=AND&awsm.page-cards=2 (Zugriff am 19. Februar 2023)

[2] Werner Vogels und Amazon Web Services, AWS re:Invent 2021 – Keynote with Dr. Werner Vogels. [online]. 03. Dezember 2021. Verfügbar unter: https://www.youtube.com/watch?v=8_Xs8Ik0h1w (Zugriff am 21. Februar 2023)

[3] Jeff Barr, Now Available – Compute-Intensive C5 Instances for Amazon EC2. [online]. 06. November 2017. Verfügbar unter: https://aws.amazon.com/de/blogs/aws/now-available-compute-intensive-c5-instances-for-amazon-ec2/ (Zugriff am 21. Februar 2023)

[4] Amazon Game Tech Team, Stateful or Stateless? Choose the right approach for each of your game services. [online]. 22. Juli 2020. Verfügbar unter: https://aws.amazon.com/de/blogs/gametech/stateful-or-stateless/ (Zugriff am 22. Februar 2023)

[5] Jan-Dirk Kranz, Was ist AWS-Lambda und wozu nutzt man es?. [online]. 03. November 2021. Verfügbar unter: https://it-talents.de/it-ratgeber/programmieren-und-coden/was-ist-aws-lambda-und-wozu-nutzt-man-es/ (Zugriff am 21. Februar 2023)

[6] Peter Bathge, New World: Dass ausgerechnet Amazon Warteschlangen zulässt, ist ein Witz. [online]. 30. September 2021. Verfügbar unter: https://www.gamestar.de/artikel/warteschlangen-in-new-world-sind-ein-schlechter-witz,3373860.html (Zugriff am 22. Februar 2023)

[7] Anny, New World macht seine Neustart-Server so gut, dass kaum wer auf den alten spielen will – Muss jetzt handeln. [online]. 01. Dezember 2022. Verfügbar unter: https://mein-mmo.de/new-world-server-merge/ (Zugriff am 22. Februar 2023)

[8] Sean Murray, New World Faces Low Player Count Complaints – Again. [online]. 21. Januar 2022. Verfügbar unter: https://www.thegamer.com/new-world-low-player-count-server-merge/ (Zugriff am 24. Februar 2023)

[9] Susanne Braun, New World: Server-Transfers und Server-Merges – weiter geht’s im Jahr 2022!. [online]. 24. Dezember 2021. Verfügbar unter: https://www.buffed.de/New-World-Spiel-61911/News/Server-Transfer-Token-Merge-1386142/ (Zugriff am 24. Februar 2023)

[10] Susanne Braun, New World: Einmaliger Fraktions-Reset wegen Ungleichgewicht mit Server-Merge. [online]. 19. Dezember 2021. Verfügbar unter: https://www.buffed.de/New-World-Spiel-61911/News/Fraktions-Ungleichgewicht-Reset-Server-Merge-Housing-Problem-1385911/ (Zugriff am 24. Februar 2023)

[11] New World Server Status. [online]. Verfügbar unter: https://nwdb.info/server-status (Zugriff am 25. Februar 2023)

[12] Peter Steinlechner, Amazon liefert New World mit noch einer Verspätung. [online]. 05. August 2021. Verfügbar unter: https://www.golem.de/news/mmorpg-amazon-liefert-new-world-mit-noch-einer-verspaetung-2108-158687.html (Zugriff am 25. Februar 2023)

[13] Was ist Amazon DynamoDB?. [online]. Verfügbar unter: https://docs.aws.amazon.com/de_de/amazondynamodb/latest/developerguide/Introduction.html (Zugriff am 21. Februar 2023)

[14] New World Stats, Historical (5-years) breakdown of the player and subscriber populations for New World. https://mmo-population.com/r/newworldgame/stats (Zugriff an 22. Februar 2023)

[15] Abbildung verfügbar unter: https://preview.redd.it/jznitth3n4r71.jpg?width=640&crop=smart&auto=webp&v=enabled&s=f22cf4e8951034a17589d6d2cf1070fcd9c22079 (Zugriff am 24. Februar 2023)

[16] Abbildung Verfügbar unter: https://d13urrra316e2f.cloudfront.net/original/3X/8/5/85315c58aae1f624be145854dd9ec14a981d08a1.jpeg (Zugriff am 24. Februar 2023)

Einleitung

In den letzten Jahren hat die Künstliche Intelligenz (KI) einen enormen Aufschwung erlebt und ist zu einem wichtigen Teil unseres täglichen Lebens geworden. KI wird für eine Vielzahl von Aufgaben eingesetzt – von der Bilderkennung bis hin zur Sprachverarbeitung. Eine der neuesten Anwendungen von KI ist ChatGPT, ein System für die Generierung von Texten und hat in der Welt der künstlichen Intelligenz großes Aufsehen erregt, da es potentiell eine neue Ära des maschinellen Lernens einleitet, die es Maschinen ermöglicht, menschenähnliche Gespräche und Interaktionen zu führen. Das Modell wurde von OpenAI entwickelt und nutzt eine Technologie namens “Generative Pre-trained Transformer 3” (GPT-3), die es dem Modell ermöglicht, menschliche Sprache zu verstehen und darauf zu reagieren.

ChatGPT ist eine der fortschrittlichsten und leistungsstärksten Anwendungen von künstlicher Intelligenz. Es wurde entwickelt, um auf Anfragen in natürlicher Sprache zu antworten, indem es eine Vielzahl von Texten analysiert und ein tieferes Verständnis von Sprache und Bedeutung entwickelt. ChatGPT ist in der Lage, mühelos Millionen von Worten zu analysieren und zu verstehen, um intelligent auf Fragen zu antworten. Aber kann man nur mit ChatGPT einen kompletten wissenschaftlichen Artikel schreiben?

Diese Frage ist nicht leicht zu beantworten. Einerseits hat ChatGPT die Fähigkeit, viele Informationen aufzunehmen und in kürzester Zeit eine Unmenge an Text zu generieren. Andererseits ist es jedoch nicht in der Lage, die menschliche Fähigkeit zu ersetzen, logische Schlussfolgerungen zu ziehen und eine kritische Analyse durchzuführen. ChatGPT ist auch nicht in der Lage, den Kontext vollständig zu verstehen oder komplexe menschliche Emotionen wie Empathie und Mitgefühl zu zeigen.

Ein weiterer wichtiger Punkt, der bei der Verwendung von ChatGPT in Betracht gezogen werden muss, ist die Möglichkeit von Fehlern oder Vorurteilen. Wie bei jedem maschinellen Lernmodell hängt die Qualität der Ausgabe von ChatGPT von der Qualität der Eingabe ab. Wenn die Daten, auf denen das Modell trainiert wird, Vorurteile oder falsche Annahmen enthalten, kann dies zu fehlerhaften oder sogar schädlichen Ausgaben führen.

ChatGPT ist jedoch sehr mächtig und in der Lage, sehr überzeugende Texte zu generieren. Eine Studie hat sogar gezeigt, dass viele Leser nicht in der Lage sind, KI-generierte Texte von menschlich geschriebenen Texten zu unterscheiden. In dieser Studie, die von einem Forscherteam der Stanford University im Jahr 2020 veröffentlicht wurde, wurden Probanden gebeten, eine Reihe von Texten zu lesen und zu entscheiden, ob sie von einem menschlichen Schreiber oder von einer KI wie ChatGPT erstellt wurden.

Die Ergebnisse zeigten, dass die Teilnehmer nur in etwa 30% der Fälle richtig erkennen konnten, ob der Text von einem menschlichen Schreiber oder von einer KI stammte. Dies deutet darauf hin, dass es schwierig sein kann, den Unterschied zwischen Texten zu erkennen, die von einem menschlichen Schreiber und solchen, die von einer KI wie ChatGPT erstellt wurden.

Dies ist ein besorgniserregendes Ergebnis, da es darauf hindeutet, dass KI-generierte Texte möglicherweise die Integrität von wissenschaftlichen Arbeiten und anderen wichtigen Texten beeinträchtigen können. Es ist wichtig, dass Schriftsteller und Leser gleichermaßen sich bewusst sind, dass die Texte, die sie lesen oder schreiben, möglicherweise von einer KI erstellt wurden. Das bedeutet, dass es durchaus möglich ist, einen Artikel mit ChatGPT zu schreiben, der für den Leser wie von einem Menschen geschrieben aussieht.

Allerdings ist es wichtig zu betonen, dass dies nicht der beste Ansatz für das Schreiben eines wissenschaftlichen Artikels ist. Ein solcher Artikel erfordert in der Regel eine umfassende Forschung, Analyse und kritische Bewertung von Quellen. Ein wissenschaftlicher Artikel sollte auch eine klare Methodik und einen detaillierten Bericht über die Ergebnisse enthalten. Diese Aspekte können nicht einfach von ChatGPT generiert werden.

Wenn man ChatGPT als Hilfsmittel verwendet, um bestimmte Abschnitte des Artikels zu generieren oder um den Schreibprozess zu beschleunigen, ist das eine Sache. Aber ein wissenschaftlicher Artikel, der ausschließlich mit ChatGPT geschrieben wurde, würde wahrscheinlich nicht den Anforderungen an wissenschaftliche Integrität und Genauigkeit entsprechen.

Wenn Sie bis zu diesem Punkt gelesen haben ohne zu ahnen, dass dieser Text bisher komplett von ChatGPT geschrieben wurde, dann ist das ein Beleg für die Problematik, die diese Technologie aufwirft. 

Die Veröffentlichung ChatGPTs am 30. November 2022 war ein bahnbrechender Schritt in der IT-Branche. Insgesamt kann man sagen, dass Künstliche Intelligenz hiermit ein Niveau erreicht hat, dass mittlerweile jeden angeht. Laut einem Nachrichtenartikel der “New York Times” fühlt sich der IT-Riese Google selbst von dieser disruptiven Technologie bedroht und hat sogar intern die “Alarmstufe rot” ausgerufen.
ChatGPT kann sehr vielseitig eingesetzt werden. Viele Menschen nutzen den Chatbot auf eine harmlose Weise, um zum Beispiel Witze oder Gedichte generieren zu lassen. Andere nutzen es hingegen als eine Art Suchmaschine, was auch der Grund für Googles großer Sorge ist. 

Weiterhin hat ChatGPT ein großes Wissen über Programmiersprachen; es ist sogar mit dessen Hilfe möglich, gesamte, funktionierende Programme zu erstellen, ohne selbst eine Zeile Code zu schreiben. Der Anwendungsbereich von ChatGPT ist also sehr breit. Da es jedoch primär ein Sprachmodell darstellt, dass die Aufgabe hat, menschenähnliche Texte zu generieren, möchte ich mich in diesem Artikel auf den Aspekt des wissenschaftlichen Schreibens konzentrieren. 

Das Ende der akademischen Integrität?

Die Menschheit hat großen Spaß daran, Verschwörungstheorien aufzustellen und allgemein “Doom and Gloom” zu verbreiten, vor allem wenn es um künstliche Intelligenz geht (Quelle: Terminator Filme). Mit ChatGPT ist das nicht anders. Seit der Einführung des Chatbots wird sowohl auf Social-Media als auch in diversen Nachrichtenartikeln das Ende des wissenschaftlichen Schreibens und der akademischen Integrität prophezeit. In diesem Artikel möchte ich diese Befürchtung durchleuchten und prüfen, ob diese Aussage wirklich gerechtfertigt ist. Weiterhin möchte ich im Anschluss einen kleinen Blick in die Zukunft dieser Technologie wagen.

Betrachten wir zunächst den generierten Text von weiter oben. Da es als Ziel dieses Artikels galt, herauszufinden, ob die Arbeit einem komplett abgenommen werden kann, habe ich ChatGPT natürlich vor der Aufgabe gestellt, den Text alleine zu generieren. Meine erste Anweisung lautete wie folgt:

Schreibe einen wissenschaftlichen Artikel über ChatGPT. Es sollte zunächst beschreiben, was das überhaupt ist und wie es genutzt werden kann. Der Artikel sollte ebenfalls beschreiben, welche gesellschaftlichen Folgen aus der Nutzung von ChatGPT in Bereichen wie das Verfassen von Artikeln oder anderen Texten entstehen. Der Fokus des Artikels sollte das wissenschaftliche Schreiben und mögliche Gefahren für die akademische Integrität sein. Am Ende sollte ein Fazit gezogen werden und ein Ausblick geworfen werden. Der Text sollte ca. 1000 Wörter umfassen.

Das Resultat war ein sehr neutral gehaltener, aber trotzdem ein ChatGPT-lobender Text (den ich hier nicht in voller Länge kopieren werde), der nur oberflächlich auf die Gefahren der Technologie einging. Außerdem hat ChatGPT von selbst Zwischenüberschriften eingefügt, die den Lesefluss unterbrachen. Nicht sehr überzeugend. Daraufhin habe ich noch ein paar weitere Anweisungen hinzugefügt:

Danke. [Notiz: Stets nett zur KI sein, um spätere Überlebenschancen zu maximieren]
Der Text sollte keine Überschriften haben. Ich möchte stattdessen einen Fleißtext mit Übergängen. Nimm außerdem ChatGPT gerne noch mehr in die Kritik. Gehe auch auf die Problematik ein, dass möglicherweise bei Abschlussarbeiten ganze Inhalte generiert werden können.

Der Text verbesserte sich nach weiteren Anweisungen immer weiter. Aber um den gesamten Text zu generieren war es ein ziemlicher Kampf. Mal wurde der Text nicht zu ende generiert, mal hat ChatGPT wieder Überschriften eingefügt, mal wurde meine Wörterzahl-Vorgabe nicht beachtet. Es verging so viel Zeit bis ich merkte, dass ich vermutlich sehr viel schneller gewesen wäre, wenn ich einfach den Text selbst geschrieben hätte. Naja. In einer Hinsicht ist ChatGPT schon sehr menschenähnlich: Die Kommunikation mit ihm sorgt für einen erhöhten Stresspegel.

Am Ende wurde jedoch irgendwann der obige Text fertig generiert und ich war ….. enttäuscht. Nach langem Hin-und-Her wurde ein Artikel generiert, mit dem – für mich zumindest – etwas einfach nicht stimmt.

Lass uns diesen Text einmal näher analysieren. Folgend nenne ich ein paar Dinge, die mir beim Lesen aufgefallen sind:

• Detail: Das wohl auffälligste Merkmal ist, dass ChatGPT Schwierigkeiten damit hat, ins Detail zu gehen. Es trifft oft Aussagen, die ein interessantes Thema aufgreifen, jedoch ist dieses im nächsten oder übernächsten Satz bereits wieder wie vergessen. Auch auf Nachfrage mehr ins Detail zu steigen führt zu Wiederholungen oder weiteren Argumenten, die wiederum nur oberflächlich beschrieben werden.
• Übergänge: Wie auch bereits erwähnt, tut sich ChatGPT schwer, flüssige Übergänge zu erzeugen. Beim wissenschaftlichen Schreiben wird einem immer wieder der Begriff des “Roten Fadens” eingetrichtert und ist ein sehr wichtiger Bestandteil einer ernstzunehmenden wissenschaftlichen Arbeit. Ohne flüssige Übergänge wirkt ein Text nicht richtig zusammenhängend
  ChatGPT bessert sich in diesem Aspekt, wenn man zusätzliche Anweisungen hinzufügt, die auffordert, flüssige Übergänge zu erzeugen, jedoch fühlt sich das nach einem Kampf an, das man mit der KI führt.
• Satzbau: ChatGPT generiert oft kurze Sätze, die sich in ihrem Aufbau sehr ähnlich sind und den Text sehr simpel wirken lassen. Das Sprachmodell versucht kompliziert aufgebaute Sätze mit Nebensätzen zu vermeiden, da unter anderem die Verständlichkeit des Textes eine Große Rolle spielt. Das ist an sich nichts Negatives, aber führt zu der Konsequenz, dass der Text umkreativ und unoriginell wirkt.
• Persönlichkeit: Der Text ist – um es stumpf auszudrücken – einfach langweilig zu lesen. Eines der Markenzeichen menschlicher Kommunikation ist die Fähigkeit, Gefühle durch Tonfall und Wortwahl zu vermitteln. Daran scheitert ChatGPT in vollem Ausmaß. KI-generierte Texte können zwar Aspekte von Emotionen nachahmen, jedoch mangelt es an den Nuancen, zu denen Menschen fähig sind.

Okay, aber was ist wenn mir diese Faktoren alle egal sind? Angenommen, ich habe bis zum letzten Moment gewartet, die Abgabe ist noch wenige Stunden entfernt und ich habe einfach keine Zeit mich zu verkünsteln. Ich persönlich bin selbstverständlich noch nie in dieser Situation gewesen, aber dann wäre es mir doch egal, ob der Text zu oberflächlich, der Satzbau simpel oder alles langweilig zu lesen ist. Mein einziges Ziel: Bestehen. Vier gewinnt. Nicht auffliegen. 

Aber ich weiß ja auch: Die Existenz dieser Technologie ist kein Geheimnis mehr. Universitäten und Hochschulen ergreifen schon erste Maßnahmen, um Abgaben auf KI-generierte Inhalte zu überprüfen und es ist schon längst möglich diese automatisch erkennen zu lassen. 

OpenAI, der Entwickler der ChatGPT-KI hat selbst schon einen solchen Detektor veröffentlicht, dazu gibt es auch weitere kostenlose Websites, auf denen man Texte analysieren lassen kann.

Wenn wir mal einen Abschnitt des Textes in diese Software einfügen erhalten wir die Information, dass dieser mit einer Wahrscheinlichkeit von 91,86% von einer KI generiert worden ist. 

Andere Prüfseiten weisen ähnliche Zahlen auf. Von 85% bis 99,86% ist alles dabei. Schade. Aber, ChatGPT ist doch die Lösung der unendlichen Möglichkeiten. Was passiert, wenn ich einfach sage

Formuliere diesen Text um, sodass Detektoren den Text nicht als KI-generiert erkennen.

Das Ergebnis:

Ausgetrickst. Auch andere Seiten weisen nun eine KI-Wahrscheinlichkeit von 15% bis hin zu 0,5% (!) auf. Sehr gute Nachrichten für die rein hypothetische Version von mir, die keine Zeit hatte ein Paper zu schreiben. 

Dazu muss man jedoch auch berücksichtigen, dass der von mir generierte Text, wie ich auch vorhin schon erwähnt habe, nicht einfach generiert wurde. Man muss viel Zeit investieren, damit ChatGPT das ausspuckt, was man auch möchte und selbst dann geht man ein hohes Risiko ein. Ein von KI generierter Text löst bei dem Leser eine gewisse Skepsis aus. Als Student möchte man dieser Skepsis möglichst aus dem Weg gehen. 

Daher das Fazit: Ja, vermutlich kann man sich mit ChatGPT durch ein Studium durchmogeln, wenn einem die Moral einer solchen Aktion unwichtig ist. Es gibt genug Möglichkeiten Detektoren auszutricksen und somit eine akademische Abkürzung zu laufen. Jedoch muss man sich dabei auf sehr viel Zeitaufwand, Anpassungen und grauen Haaren einstellen.

Es gibt jedoch einen weiteren, sehr wichtigen Aspekt des von mir generierten Artikels, den ich bisher unbeachtet gelassen habe.

Down the rabbit hole

Blicken wir noch einmal auf den obigen Text. Gegen Ende des Artikels schreibt ChatGPT folgendes:

In dieser Studie, die von einem Forscherteam der Stanford University im Jahr 2020 veröffentlicht wurde, wurden Probanden gebeten, eine Reihe von Texten zu lesen und zu entscheiden, ob sie von einem menschlichen Schreiber oder von einer KI wie ChatGPT erstellt wurden.
Die Ergebnisse zeigten, dass die Teilnehmer nur in etwa 30% der Fälle richtig erkennen konnten, ob der Text von einem menschlichen Schreiber oder von einer KI stammte.

Okay. Interessant. Woher stammt diese Studie denn? Wer hat sie durchgeführt? Da habe ich natürlich weiter nachgefragt.

Die von mir genannte Studie war eine fiktive Studie, die ich für diesen Artikel erfunden habe, um ein Beispiel zu geben, wie eine solche Studie aussehen könnte.

Krass. Hier wurde es kurz wieder gruselig. Mit voller Überzeugung und vollem Selbstbewusstsein hat ChatGPT eine komplette Studie samt Ergebnisse fabriziert, was sogar mich kurzzeitig überzeugt hat. Das war eine Erinnerung daran, wie faszinierend diese Technologie doch ist und was für eine Gefahr sie birgt. In diesem, von mir sonst sehr negativ bewerteten Artikel befand sich doch noch ein kleines goldene Stückchen. Ich habe mir die Frage gestellt, ob ich ChatGPT nicht unterschätze.

Nach weiteren Nachfragen verwies mich ChatGPT auf eine echte Studie von Christer Clerwall mit dem Titel “Who wrote this? Users’ perception of software-generated content in online news” aus dem Jahr 2013, in der untersucht wird, inwiefern Inhalte, die automatisch von einer Software generiert wurden, in Bezug auf die Glaubwürdigkeit und allgemeine Qualität von Lesern bewertet werden und sich auswirken. 

Dann kam bei mir der Lichtblitz: Ich verwende ChatGPT ganz falsch! Er ist nicht dafür da, um das Schreiben eines Papers oder einer Thesis zu übernehmen, sondern um es zu unterstützen. ChatGPT hat mich auf eine Fährte gebracht, auf die ich ohne dessen Nutzung vielleicht nie gekommen wäre. 

In diesem Aspekt glänzt ChatGPT. Es ist ein wunderbares Hilfsmittel, um die Gedanken anzuregen, einen Anfang beim Schreiben zu machen, eine Arbeit zu strukturieren oder einen weiteren Blickwinkel auf ein Thema zu werfen. 

Ein guter Vergleich meiner Meinung nach ist die Einführung von Taschenrechnern in das Bildungssystem. Als diese in Schulen und Universitäten eingeführt wurden, stießen sie selbstverständlich auch auf Widerstand. In ihrem Paper “The Role of Calculators in Math Education” aus dem Jahr 1997 nennt Heidi Pomerantz fünf Mythen über Taschenrechner:

• “Taschenrechner sind eine Krücke. Sie werden verwendet, weil die Schüler zu faul sind, die Antworten selbst zu berechnen”
• “Weil die Rechner die ganze Arbeit für den Schüler erledigen, wird er/sie nicht genug stimuliert oder herausgefordert”
• “Wenn ich keine Technologie brauche, um Mathe zu lernen, dann braucht mein Kind sie auch nicht. Schließlich habe ich mich gut entwickelt.”
• “Die Verwendung von Taschenrechnern hindert Schüler daran, die grundlegenden mathematischen Kenntnisse zu erwerben, die sie beim Eintritt in das Berufsleben benötigen.”
• “Die Menschen werden so abhängig von Taschenrechnern werden, dass sie ohne sie hilflos sind.”

Ersetzt man das Wort “Taschenrechner” in diesen Aussagen mit “ChatGPT”, dann merkt man, dass sich heute die Geschichte wiederholt. Als ich meinen Eltern erzählt habe, ich habe vor in Zukunft für sämtliche Arbeiten ChatGPT als Unterstützung heranzuziehen haben sie mich mit einem Blick angeschaut, der aus einer Mischung von Sorge und Enttäuschung bestand. Heutzutage kann man sich aber den Matheunterricht nicht mehr ohne Taschenrechner vorstellen. Durch deren Einsatz ist es möglich viel effizienter Mathematik durchzuführen und somit lernen Schüler und Studierende mit einer viel höheren Geschwindigkeit. 

Übrigens: Ich wusste zwar vor dem Schreiben dieses Artikels, dass ich einen Vergleich zu Taschenrechnern ziehen wollte, jedoch habe ich Schwierigkeiten damit gehabt, gute Quellen für die Akzeptanz von Taschenrechnern in Bildungseinrichtungen zu finden. Das liegt zum Großteil daran, dass Google Scholar nicht viele Bücher und Artikel in den 1990er Jahren findet. Meine Lösung: ChatGPT nach Quellen fragen. Er antwortete mit Buchtiteln, die ich dann wiederum googeln konnte. 

Taschenrechner sind nicht das einzige Beispiel. Computer. Das Internet. Google. YouTube. DeepL. Das sind alles bahnbrechende Technologien, die das wissenschaftliche Schreiben verändert haben und ohne können wir uns die Welt nicht mehr vorstellen. Die Nutzung keiner dieser Tools wird heutzutage verpönt oder beim Verfassen von wissenschaftlichen Arbeiten verboten.

Fazit

Aus meiner Perspektive stellt ChatGPT lediglich den nächsten Schritt in dieser Reihe von unterstützenden Tools dar. Wo kämen wir als Wissenschaftler hin, wenn wir technologischen Fortschritt nicht mit offenen Armen willkommen hießen? 

Sollte es Einschränkungen geben? Selbstverständlich. Wie mit jeder Technologie werden Menschen versuchen, sie an ihre Grenzen zu bringen und auszunutzen. Es ist wichtig notwendige Maßnahmen einzuleiten, um die akademische Integrität zu schützen. Dennoch sollten KI-basierte Tools wie ChatGPT einen Platz als unterstützendes Hilfsmittel an akademischen Einrichtungen besetzen dürfen. 

Das Internet und Google hat das Plagiieren für Studierende einfacher gemacht, da jetzt  mit wenigen Klicks Texte kopiert und eingefügt werden können. Was hat man dagegen gemacht? Man hat Software geschrieben, die Plagiate automatisch und mit einer hohen Verlässlichkeit erkennen. Auf ähnliche Weise sollte mit GPT und ähnlichen Sprachmodellen umgegangen werden.

ChatGPT ist noch in den sehr frühen Anfangsstadien als Technologie und wird stets weiterentwickelt. Ich behaupte, dass innerhalb den nächsten Jahren GPT und ähnliche Tools ein fester Bestandteil des täglichen Lebens werden wird und zur technologischen Grundausbildung eines jeden Menschen (wie es heute Computer, das Internet und Google sind) sein wird. 

Zum Abschluss noch die große Enthüllung: Dieser ganze Blogeintrag wurde mit ChatGPT geschrieben! Nein, Scherz. Oder vielleicht doch…? 

A Question of Time and Causality

TL;DR

Through the usage of atomic clock and GPS in datacenters, Google is able to determine a worst-case clock drift that may develop between set intervals, after which the normal quartz clocks of the machines will be synced with the atomic clock. By already having a very good estimate of the actual physical time and knowing the worst-case drift, an interval will be delivered to planned transactions, that are ready to be committed. Once received, the transaction will wait for the duration of the interval and thus ensuring causal consistency of a following transaction will be fulfilled. The key to solving this issue turns out to be atomic clocks, GPS receivers, testing to determine the uncertainty interval and a regular synchronisation of all sub-systems, not directly connected to their True Time service. 

What is Google’s Spanner?

Google Spanner [B017] is a relational database service provided by Google Cloud, designed for processing and storing petabytes of structured data. Spanner provides global distribution of data with high consistency and availability, as well as horizontal scalability. According to the CAP theorem [GL02], Spanner is therefore a CA system. It supports SQL-like query languages as well as ACID [C970] transactions (Atomicity, Consistency, Isolation, Durability) and is capable of providing both horizontal and vertical scalability to achieve better performance.

This is an answer that one can formulate after a few minutes of using the Google search engine. But what defines the service? What unique features make Google’s Spanner stand out and how are they technically formulated and implemented? This will be conveyed in the course of this blog post.

What defines Google’s Spanner? 

To make our lives easier while explaining and understanding what actually defines Spanner, the significant descriptive characteristics of Spanner are separated into two sections: Consistency properties and techniques used to realise them. 

Properties of Consistency:

Serializability writes

In transactional systems, there exists an execution plan for parallel execution. This plan is called history and indicates the order in which the different operations of the transaction shall be executed. Such a history will be serializable, if and only if it will lead to the same result as the sequentially executed sequence of the history’s transactions. 

Linearizability reads and writes

This is a concept in database systems that ensures that the execution of concurrent operations on a shared object or resource appears as if they occurred in some sequential order. This means that even though operations are being executed concurrently, they appear to be executed one after the other.

Serializability vs Linearizability

Did those two sound too similar? They are not! Subtle details make a big difference here: Even if both serializability and linearizability are concepts related to concurrency control in database systems, they have different goals and focus on different aspects of concurrency. While serializability ensures that concurrent transactions produce the same result as if executed sequentially, maintaining data integrity and equivalent results to executing transactions sequentially; Linearizability ensures that concurrent operations on a shared object or resource appear to be executed sequentially, maintaining data consistency and equivalent outcomes to executing operations sequentially.

Techniques in use:

Sharding

Spanner supports a custom sharding algorithm called “Zone Sharding.” [AR18]. This algorithm partitions data across zones, which are groups of machines in a single datacenter or across multiple datacenters. Each zone contains multiple tablet servers that hold the data for a subset of the database’s tables. The Zone Sharding algorithm is designed to ensure that data is replicated and distributed for high availability and fault tolerance, while also providing efficient access to data with low latency. Especially the low latency is of tremendous importance, for many of the services of Google.

State machine replication (Paxos protocol)

The Paxos protocol [L998] is a consensus algorithm that helps distributed systems agree on a single value despite failures or network delays. First it was described by Leslie Lamport in 1989 and has since become widely used in distributed computing systems. It operates in three main phases:

1. Prepare Phase: A proposer suggests a value to the other nodes and asks them to promises not to accept any other value in the future.
2. Accept Phase: If the majority of nodes promise to accept the proposed value, the proposer sends an “accept” message to all the nodes, including the proposed value.
3. Commit Phase: If the majority of nodes accept the proposed value, the proposer sends a “commit” message to all the nodes, indicating that the proposed value has been agreed upon.

The Paxos protocol has been used in a variety of distributed systems, including databases, file systems, and messaging systems. It is known for its simplicity, generality, and ability to tolerate failures. However, it can be complex to implement and can suffer from performance issues in certain scenarios.

Two-Phase locking for Serializability 

Two-phase locking (2PL) [G981] is a concurrency control mechanism used in database management systems to ensure serializability of transactions. The goal of 2PL is to prevent conflicts between transactions by ensuring that a transaction holds all necessary locks before performing any updates.

The two-phase locking protocol operates in two main phases:

1. Growing Phase: During this phase, a transaction can acquire locks on database objects (such as rows, tables, or pages) in any order. However, once a lock is released, it cannot be re-acquired.
2. Shrinking Phase: During this phase, a transaction can release locks but cannot acquire any new ones. Again, once a lock is released, it cannot be re-acquired.

The 2PL protocol ensures serializability by guaranteeing that conflicting transactions acquire locks in a consistent order. Specifically, two transactions conflict if they access the same database object and at least one of them performs an update.

Two-Phase Commit for cross-shard atomicity
The Two-Phase Commit (2PC) [H983] is a distributed algorithm used to ensure atomicity in transactions that involve multiple nodes or resources. The protocol works in two main phases:

1. Prepare Phase: In this phase, the transaction coordinator asks each participant to vote on whether to commit or abort the transaction.
2. Commit Phase: If all participants vote to commit, the coordinator instructs each participant to commit the transaction. If any participant votes to abort, the coordinator instructs each participant to abort the transaction.

2PC ensures that a transaction is either committed or aborted atomically across all participants involved in the transaction, but can suffer from performance issues and a higher risk of aborts. Alternative protocols, such as optimistic concurrency control or decentralised commit protocols, can be used to address some of these issues.

Multi-Version Concurrency Control

Multi-Version Concurrency Control (MVCC) [B981] is a database concurrency control mechanism that allows multiple transactions to access the same objects simultaneously while maintaining consistency and isolation. It creates multiple versions of a database object and allows each transaction to access the version that corresponds to its snapshot of the database. MVCC provides benefits such as reduced lock contention, improved scalability, and higher degree of concurrency and isolation, and is used in various database systems like PostgreSQL [PSQL] or MySQL [MSQL]

Now, how does MVCC actually work? Short answer, with strong implications: A timestamp is being attached to every read-write transaction taking place. If a transaction is going to change an object, we will not simply allow it to change its state, but rather make a copy of the object, change the copy and tag it with the timestamp of the transaction . This is to ensure, that if a read-only transaction comes in, interested in the old state of the object (with a timestamp ), we still can serve it. Now, a new read-only transaction comes in, tagged with where . This transaction can simply ignore all states of objects where and pick those with the most recent state .

So far, even if implementing the above correctly would bring quite an engineering challenge to the table, there is nothing new or innovative. Nothing special that is required to be mentioned, other than framing and explaining the used technologies. Spanner provides support for read-only transactions without the need for locks, a feature not found in other database systems – at least if MVCC is not implemented. This is a significant improvement over 2PL, which requires objects to be locked before access. However, in the real world, large read-only transactions are common. Take the example of a database backup, which is a major read-only transaction that can span multiple petabytes in a globally-distributed database. It is clear that users would not be happy about waiting for such a process to succeed. Imagine it fails and has to restart shortly after. A horrible scenario for every impatient user, if locks may be taken during that process. Spanner’s support for lock-free read-only transactions ensures that such processes can be carried out quickly and efficiently, enhancing user satisfaction and improving the overall performance of the system.
But, the really interesting part about Spanner is how it acquires said timestamps. 

Consistent Snapshots

First, let us establish what it means to have a consistent snapshot. To illustrate this, we can use the example of a large read-only transaction, for example a backup, and clarify the requirements for ensuring snapshot consistency   

What does it mean for a snapshot to be consistent? 

A read-only transaction will observe a consistent snapshot if: . This means that if a consistent snapshot contains the effect of transaction  , it must contain the cause . So if  happened before and we have a snapshot that contains the writes by , it must also contain the writes mades by . Likewise, if we see a snapshot that does not contain the writes made by , is shall not contain the writes made by . In other words, snapshots must be consistent with causality – hence the title of this blog. 

The above will be achieved by making use of MVCC.

True Time

Why do we need true time for a service like Google’s Spanner?

As any being interested in this subject matter will tell you: There is no free lunch in ultra large scale systems; most certainly, there cannot be a thing like a true time. Or maybe…

In the paragraph explaining what it means for a snapshot to be consistent, we clarified that we need to take measures to ensure a reliant way of dealing with the problem of chronological ordering, namely causality. Even though logical clocks like Lamport Clocks where specifically designed to address this problem, there are scenarios in which they would fail. Imagine a case in which a user would read a result from replica , perform an action on that data and may persist it on replica . A one-sentence scenario, in which Lamport Clocks would fail to solve the problem, simply because there was no assured communication between the two replicas. Sure, we could rely on the front-end developer to transport the timestamp for the write transaction on replica , but this is not guaranteed. Neither can we rely on the user to manually type in a timestamp. So, what can we do in this case: We go back to physical clocks. But, we have to adjust the physical clocks and do some extra measure, to ensure that causality is satisfied. 

I’m on the hook, pull me in!

The way spanner achieves this, is by using its service called True Time. True Time [B017] is a system of physical clocks, that explicitly captures the always present uncertainty within the resulting timestamps and communicates it to the requestor. To help understand the impact achieved, we will use the following illustration as an example.

In this illustration, we have two replicas: and . A write transaction  will be performed on replica  and a follow-up transaction  will be performed on replica . Here, we have that physical time dependency between the two, such that their timestamps fulfil . 

When is ready to be committed, it requests the interval  from the True Time Service. So, we do not just get a timestamp, as it is required for MVCC. Rather the requestor will receive two: . The first one  indicating the earliest possible and the second  indicating the latest possible actual time for the commit request to actually happen. Since there can not be a perfect synchronisation between the different clocks, within a datacenter, we can never be totally certain that a timestamp would represent the actual physical time of that moment. By accepting this fact and using an uncertainty bound through the received interval, we can ensure that the physical time would lie somewhere within that closed interval. 

Spanners system is now delaying the transactions commit for the duration of the interval . During that wait-time, the system will continue to hold all the locks mandatory and be ready to release them. Once interval  is elapsed, the transaction will actually be committed. This extra wait is the key concept here.

Now let us say that replica  receives transaction  and starts executing it. Similar to the procedure of , once is ready to be committed, it requests its pair of earliest and latest possible time , waits for the -time to elapse and commits its transaction. Remember, we have the physical time dependency . The white arrow in the illustration, going from left to right, indicates the actual time elapsed between the end of  and the start of .

What we just achieve ensures that the uncertainty intervals we receive from the True Time Service are warranted to be non-overlapping ant thus ensures that the causal dependency will be reflected. After the wait-time, MVCC will receive the maximum timestamp from and and the database only contains the effect, when its cause is present.

How uncertain do we have to be?

Of course, we want to have as little waiting-time as possible. This forces us to have a pretty precise notion of uncertainty. This is achieved by atomic clock servers, with GPS receivers in every datacenter. Even tough maintaining both probably costs quite some money, it is cheaper than dealing with potential inconsistencies in their system.

As the illustration shows, machines not directly connected to the True Time service will continue to drift apart form the physical time and continue to do so, until the clock synchronisation happens. After that, the discrepancy is immediately reduced to the irreducible error , resulting from the time the request takes from a machine to True Time and back. During the 30-second intervals between periodic clock synchronisations, a node’s local quartz oscillator determines its clock. The error introduced during this period is influenced by the drift rate of the quartz. To err on the side of caution, Google assumes a maximum drift rate of 200ppm, which is much higher than the drift rate observed under typical operating conditions. Furthermore, Google keeps track of each node’s drift and informs administrators of any unusual occurrences. 

Summary

True Time utilises precise accounting of uncertainty to establish both upper and lower bounds on the current physical time. It achieves this by incorporating high-precision clocks, which work to reduce the size of the uncertainty interval. Meanwhile, Spanner is designed to ensure that timestamps remain consistent with causality by waiting out any lingering uncertainty. By leveraging these timestamps for MVCC, Spanner is able to deliver serializable transactions without necessitating locks for read-only transactions. This method helps maintain transaction speed while also eliminating the need for clients to propagate logical timestamps.

References

1. GL02
   S. Gilbert, N. Lynch; 2002
   Brewer’s Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services
   https://www.comp.nus.edu.sg/~gilbert/pubs/BrewersConjecture-SigAct.pdf
2. C970
   E. F. Codd; 1970
   A Relational Model of Data for Large Shared Data Banks
   seas.upenn.edu/~zives/03f/cis550/codd.pdf
3. CD12
   James C. Corbett, Jeffrey Dean, Michael Epstein, Andrew Fikes, Christopher Frost, JJ Furman, Sanjay Ghemawat, Andrey Gubarev, Christopher Heiser, Peter Hochschild, Wilson Hsieh, Sebastian Kanthak, Eugene Kogan, Hongyi Li, Alexander Lloyd, Sergey Melnik, David Mwaura, David Nagle, Sean Quinlan, Rajesh Rao, Lindsay Rolig, Yasushi Saito, Michal Szymaniak, Christopher Taylor, Ruth Wang, Dale Woodford; 2012
   https://static.googleusercontent.com/media/research.google.com/de//archive/spanner-osdi2012.pdf
4. AR18
   Muthukaruppan Annamalai, Kaushik Ravichandran, Harish Srinivas, Igor Zinkovsky, Luning Pan, Tony Savor, and David Nagle, Facebook; Michael Stumm, University of Toronto; 2018
   https://www.usenix.org/system/files/osdi18-annamalai.pdf
5. L998
   Leslie Lamport; 1998
   https://dl.acm.org/doi/pdf/10.1145/279227.279229
6. G981
   Jim Gray, Paul McJones, Mike Blasgen, Bruce Lindsay, Raymond Lorie, Tom Price, Franco Putzolu, Irving Traiger; 1981
   https://dl.acm.org/doi/pdf/10.1145/356842.356847
7. H983
   Theo Haerder, Andreas Reuter; 1983
   https://cs-people.bu.edu/mathan/reading-groups/papers-classics/recovery.pdf
8. B981
   Phillip A. Bernstein, Nathan Goodman; 1981
   https://dl.acm.org/doi/pdf/10.1145/356842.356846
9. PSQL
   https://www.postgresql.org/docs/7.1/mvcc.html
10. MSQL
    https://dev.mysql.com/doc/refman/8.0/en/innodb-multi-versioning.html
11. B017
    Eric Brewer; 2017
    https://storage.googleapis.com/pub-tools-public-publication-data/pdf/45855.pdf

Introduction

You all know racing games. From the realistic, simulated ones like Formula 1 or Forza Motorsport to the playful, arcade-heavy ones like Super Mario Kart or Need For Speed.

The range is large, but somehow pretty standard. So we want to take it a little crazier. After all, who says that it always has to be cars as vehicles? Why not a turbine? Or yes – directly a whole rocket engine? Yes! And the driver sits directly on the drive train! And players shoot each other down with hilarious and mean attacks and traps. Something like this:

I know it’s not strictly a racing game – more of a flying game, but from a technical point of view we have the same parameters per player such as the position or speed of the players and other objects on the track and the collisions of these objects with each other.

Ok, now that we have our crazy game idea, we also need to somehow ensure that our players can enjoy playing together on different devices.

But how are we gonna do this? What multiplayer architecture approaches are there? What are their pros and cons? What data do we need to exchange between players? And how do we trade different latencies to give every player a smooth, zero-latency gaming experience?

Exactly these questions are answered in this blog entry. Thus, this blog entry can be seen as the first starting point into the world of online multiplayer architecture.

Requirements

To narrow things down a bit, let’s first establish a few rules for our game:

• Each race takes place on a closed race track / There is no open world
• There are 10 different racetracks and 7 different vehicles.
• A maximum of 10 players play together in a lobby or on a race track
• The graphic representation takes place exclusively on the end device of the user
• The gaming experience should take place in real time
• Players are matched to a lobby
• There is a global player ranking
• Each player can accelerate, brake and steer
• Each player can pick up items on the racetrack and use them to attack other players or place traps on the racetrack
• Each player must be authenticated in order to play
• The system should initially be able to trade around 250,000 users per hour and scale accordingly
• The system should be operated as cheaply as possible; however, we also want to offer our players a smooth, fun and immersive gaming experience

As can be seen in the requirements, in this article we will focus exclusively on the pure racing game experience – for example driving, overtaking and collision between vehicles and objects. For the time being, we neglect the use of universally popular social functions such as managing friend lists or joining friend lobbies.

Architecture approaches 

Now that we’ve defined some basic requirements, let’s first look at the most popular architectural paradigms that connect players around the world. Underlying these approaches is a common goal: to provide players with a synchronous, latency-free and fluid gaming experience in near real-time. 

Hosted Peer-to-Peer (Hosted P2P) 

In times when cloud solution is always touted as the all-purpose weapon, it is almost unbelievable that an old approach like peer-to-peer is still so widespread. But popular games like Demon’s Souls, Dark Souls, Bloodborne, GTA Online, Red Dead Online, Animal Crossing: New Horizons, Super Smash Bros. Ultimate or F1 2021 partly operate their online worlds via peer-to-peer networks ¹.

The principle of a hosted P2P network seems simple at first: One player is the host of the game, i.e. the player’s computer acts as a “server”. The host inputs, as well as the inputs of the other players, arrive at the host. The current game events (state) are calculated and sent back to the players (Img.1). 

So as a company, there is no need for a server at this point, so we gonna save these costs, which can be an enormous sum with a targeted utilization of 250,000 players. The scaling and the corresponding rush of incoming players can also be easily distributed among several host players. Unlike a dedicated server, thousands of games are not calculated on one machine, but on a selected player – the host – calculates exactly one game and transmits the results to the other players (in our example max. 10 players in a lobby, so 25,000 host players must be found with a planned load of 250,000 players).

Conversely, this also means that the other players in a lobby are dependent on the host in many ways. The host migration – which player is the best host? – is crucial. Because if the host has a miserable download or upload speed, this creates high latencies for the other players – delays and a bad gaming experience for these players are the consequences. One solution would be that the host is the player who has the lowest average ping time among all other participating players. Or only players who are geographically close to each other are assigned to a lobby. But what do we do if a player from Tokyo wants to play with a player in Berlin? In addition, the host user must provide enough free hardware resources such as CPU and RAM in order to be able to calculate the entire gameplay and display his own gameplay. But what if that’s not the case? Likewise, the host receives the results on his PC first – simply because of the short geographic and physical transmission path and the resulting lack of ping – so that this can also lead to asynchronous gameplay. This must also be prevented so that all players get a synchronous, simultaneous gaming experience. 

Another challenge in a hosted P2P network is host cheating or host hacking. How can we trust the host and make sure they aren’t cheating and manipulating gameplay? Because all player events are calculated on his PC. To solve this requires a solution such as a separate authoritative server ² .

In summary, there are the following reasons for or against a hosted peer-to-peer approach:

In particular, the problem of the trustworthiness of the host poses a major challenge for the P2P approach. Another popular approach is the “dedicated server” architecture. This approach solves the trust problem through a central authority. Let’s take a closer look.

Dedicated Server

With a “dedicated server” architecture, all game events – the inputs of the players – are sent to a central server. The server calculates the resulting state for each player and sends this state back to the players (Img. 2). The server is neither part of the game nor a separate player as in the hosted P2P approach. A dedicated server is only responsible for calculating the gameplay. Other social functions such as matchmaking are usually outsourced to other servers, since a dedicated server and all its resources are only provided for this one task – calculating the current state. Accordingly, dedicated servers usually do not have a GPU, since a graphical game display is not necessary. Instead, they have a high number of CPUs and RAM, since game lobbies and their state have to be kept and calculated during the game. 
A large number of currently very popular multiplayer games such as Fortnite, Minecraft, Apex Legends, Rocket League, Among Us, Rainbow Six Seige, Ghost of Tsushima Legends or Roblox use this principle ¹.

Compared to the hosted P2P approach, there are definitely costs associated with operating dedicated servers. Depending on the infrastructure and scaling pattern, this can result in different costs ³. Furthermore, scaling can also be a challenge if the servers are operated “on-premise”, because there must be enough servers available, they must be maintained and operated. And in addition, these servers are sometimes “dead capital” if they are not fully utilized. 

On the other hand, there are advantages that eliminate some of the disadvantages of the hosted P2P approach: When operating a dedicated server, you can count on consistently high performance, because we know about the performance of our servers and know how many users can play on one unit at the same time. This is usually not the case with hosted P2P, since the performance and networking capability can vary greatly depending on the host’s end device. This also makes it easier to estimate and plan capacities. If we operate our servers using the cloud, we can relatively easily scale horizontally (more servers) and vertically (more resources per server) depending on the corresponding demand from the players. Operation in the cloud also ensures consistent global performance, since the servers are distributed around the world and are not in a central location. This is mostly not the case in the hosted P2P approach, since a gaming lobby is dependent on the performance and location of the host, which does not need to be close to the other players.

However, one of the biggest advantages of the dedicated server approach is the reliability and security of the game state, as it is calculated on an independent, secure instance, making it very difficult for players to cheat. While the hosted P2P approach allows a host to manipulate its position on the racetrack, for example, this is made significantly more difficult with approaches such as server-side reconciliation. Because the server always knows the last position of the player. If this delivers unrealistic values ​​as input, the server can compare this with the value of the last frame and determine that there is an abnormal value and send adjustments to the player accordingly ⁴. 

In summary, there are the following reasons for or against the dedicated server approach:

Hybrid solutions & services 

In addition to the approaches just mentioned, there are also mixed approaches. It is not uncommon for a dedicated server or hosted P2P architecture to be expanded by additional, separate game services. Such services are operated on standalone servers and deal with things like matchmaking, grouping up players and picking a dedicated server or (for peer to peer games) sharing IP addresses between players so they can connect together. They handle other things such as leaderboards, player progress, unlocks, chatting and friend lists etc. In this way, areas of responsibility are clearly separated and the load is distributed to different machines (Img. 3). 

Well-known examples of such a solution are the games GTA Online, Warframe or Among us, whose players are connected to each other via a hosted P2P network, but the matchmaking runs on an own server. This model has been the subject of some criticism due to the potential for host cheating. However, the developers mostly has implemented several separate Measurement Services to prevent cheating in the game like Client-Side-Validation that includes checks for speed hacks, aimbots, and other forms of cheating and Activity- and System Monitoring that checks for suspicious activity on the player’s system like memory manipulation, injection attacks, and other forms of hacking ⁴.

Game States: Racing World & Player Data

Now that we’ve gotten to know the common architecture approaches in online gaming, we have to ask the question of what data we have to exchange in order to determine the current state of the game. But before we get into the data, what exactly is the state anyway? To shed more light on this, let’s look at the multiplayer approach of one of the most well-known game engines – the Unreal Engine 5 – here for example, a distinction is made between three different units: GameMode, GameState and PlayerState ⁵ (see Figure 5). Other game engines like Unity use a similar approach, but the implementation varies ⁶.

Let’s explain the orange part of the image above (Img. 4) using our racing game ⁷: 

The GameMode manages the global rules of a race. In our case these are for example: 

• The minimum number of players needed to start a race (min. 2)
• The maximum number of players in a race (10 players)
• The number of laps each player must complete to finish the race
• The spawn location and order of players on the racetracks
• The time of the countdown
• The allowed weapons and traps

The GameState manages global information about the current gameplay that is relevant for all players, such as: 

• The number of currently connected players
• The start and finish time of each individual player
• The current ranking (based on each player’s current position)
• The position of all players
• The location and state of all fired weapons and traps
• The position and state of each checkpoint on the track.

The PlayerState will exist for every player connected to the game on both the server and the clients. This class can be used for replicated properties that all clients, not just the owning client, are interested in like the current

• car model
• round on the race track
• position of a player  
• speed of a player 
• direction of a player
• steering angle of a player
• down force of a player
• amount of a specific collected item of a player
• status of a specific collected item (fired or not and target player)
• collisions of a player with another player or object

By continuously updating the game state and all player states based on these inputs, we can provide a seamless and engaging experience for all players involved.

In addition to identifying what data makes up the state, it is important to understand how the player state is computed taking into account different latencies so that all players feel like they are sharing a synchronous gaming experience with other players at all times. How this works is explained in the next section.

State Simulation

Almost all modern 3D online games have to face an essential challenge: How do we balance the latency of the client-server communication (or client-host player in P2P) so that each player can experience smooth, latency-free gameplay locally, but at the same time uses the current state of the server. 

Client prediction 

During a multiplayer online game, each player communicates with the server (dedicated server) or the host player (hosted P2P). This communication happens asynchronously so that the player can experience a smooth gaming experience: For example, the player sends his new position to the server. Instead of waiting until the answer comes back from the server and freezing the player’s screen for the response time (latency) of for example 300 ms (that would be synchronous), the next frame is rendered directly and the player (in our case the racing car) is located directly at the new position. This approach is known as client prediction. Assuming that the game world is deterministic, the player’s input can lead directly to the desired action locally (for exmaple a new position, an animation or a physics calculation) and this will in most cases also correspond to the state of the server ^8,9.

Server reconciliation 

Since in a racing game the communication between player and server should take place as quickly as possible, UDP is used as the network protocol in most online multiplayer games and frameworks ^10,11. In contrast to TCP, the order of the incoming packets is not guaranteed with UDP. Depending on the latency between player and server, the responses from the server can sometimes arrive at the player at different times and in a different order, so that the position of the server no longer has to match the new local position of the player (because the player is already moving in the game, for example). Thus, the player game state and the server game state are desynchronized. However, since the server game state is the trusted game state ¹², the game now has to process the new information from the server and make an adjustment, for example reset the player locally to the server’s position. However, since the player has already moved locally, this would lead to an unclean gaming experience (glitches) and breakes immersion – and we want to avoid that at all costs! So what do you do in such a case?

One solution to this problem is server reconciliation. A sequential number is added to each input sent by the player to the server to ensure the order of actions. This input is stored both on the player and on the server. If the player now receives a response from the server that matches the player state, the associated number can be removed locally and the next number follows in order. However, if the server’s answers follow in a different order, the player now knows locally that an answer to a specific number is still missing. However, since the player knows the answer to the actions before and after the missing answer, he can simulate the current state, which is then validated again by the server afterwards. This means that the server and player always synchronize with a slight delay in comparison to the next frame. However, this also ensures that the gameplay is represented graphically fluently ⁸.

Interpolation

Now that the simulated state between two states (the result of the server-side reconciliation) also graphically leads to a smooth transition movement, we use the concept of interpolation. Interpolation algorithms are part of every common game engine ^14,15.  There is linear interpolation to calculate states between two positions and spherical interpolation to calculate states between two degrees of rotation. This algorithm always requires two states (for example two positions on the race track) in order to calculate the positions in between and then display them in a fluid movement. In our case, these are the two positions that have been successfully validated and transmitted by the server before and after a certain input from the player. Based on these positions, the intermediate positions are now calculated, which are required for the execution of the graphic representation ¹³.

The combination of client-side prediction, server-side reconciliation and interpolation can help ensure a smooth and responsive online multiplayer game experience. By using these techniques, game developers can minimize network latency issues and keep players synchronized across multiple devices and network connections. To make these three approaches easier to understand, I will highly refer to a Live-Demo at this point.

Conclusion

With this article we took the first step into the world of online-multiplayer-architecture. We discussed architectural approaches for multiplayer games, got to know the game and player state and understood which data we have to exchange between our players. Finally, we looked at concepts that compensate the latencies between player and server by simulating an intermediate state.

When choosing a suitable architecture for an online game, it has been shown that P2P, dedicated servers or hybrid approaches are technical solutions that present developers with different challenges. As it turned out, hybrid solutions in particular are preferred in order to keep costs as low as possible while still being able to offer players an immersive and fun gaming experience through server-based, separate services such as match-making or activity monitoring. P2P solutions are ideal for small, unknown games with little to no budget, while games with predictable, stable sources of income have more money for their own server infrastructures. However, by using free tiers, smaller games with a few players at start can also take advantage of Dedicated Cloud Servers to launch their game in the first place ^2,16.

In order to make a final decision regarding the architecture of our racing game, further research is required, such as a detailed cost comparison, comparison of different frameworks or cloud providers and implementation details.

Sources