Internet Based Games
Gliederung Die verschiedenen Spielgenres kurze Geschichte der Online-Spiele Die 2 grundlegenden Arten von Onlinespielen Kernprobleme bei der Implementation von Onlinespielen Die Zukunft der Onlinespiele
Spielegenres Action: Spiele laufen in Echtzeit ab Hohe Anforderungen an Internetverb. und PC des Spielers weil schnelle Spielerreaktion wichtig ist Adventures: : Story durchleben und dabei Rätsel lösen Hauptsächlich ein Einzelspielergenre Strategie: Spieler entscheidet über Ressourceneinsatz zur Erreichung eines Ziels Früher rundenbasiert,heute: Echtzeitablauf
Spielegenres Rollenspiele: Spieler steuert ein oder mehrere Charaktere um Aufgaben zu bewältigen Fixiert auf Entwicklung der Fertigkeiten der Char Simulation: Ziel=reale Welt nachbilden Casual Games: Brettspiele,Kartenspiele
Geschichte Erste Online-Spiele für PLATO(1965) ursprünglich als Basis für verteilte Lernsoftw. geplant Nächste Generation für MUDs(Multi User Dungeons;in den 70ern entwickelt) Clients nutzten Telnetprotokoll-Befehle per Texteingabe,die vom Server interpretiert werden Erste kommerzielle Online-Provider und somit auch erste kommerzielle Spiele bspw:habitat
Geschichte In den 90ern neue Art von Netzwerkspielen Persistent Worlds= beständige Welten Heute dass finanziell lohnendste Spielegenre überhaupt Bsp: : extrem erfolgreiches Ultima Online Heute: Lineage von NCSoft: : über 4 Millionen Abonnenten World of Warcraft=über 3,5 Millionen Spieler
2 grundlegende Online-Spiele Spiele-Arten Spiele,die das Internet nur zur Distribution benötigen Laufen meist in einem Browser->Java,Flash Meist einfachere Struktur Untergenres:Werbespiele,informelle Spiele,( Teaser Games ) Stellen nur einen sehr kleinen Teil der Onlinespiele
2 grundlegende Online-Spiele Spiele-Arten Die meisten Spiele sind Stand-Alones Spiele die das Internet für das Gameplay Gameplay benötigen Browser bieten nicht die benötigten Programmierschnittstellen Mittlerweile gibt es auch einige Onlinespiele für Konsolen->Vorteil für Entwickler durch feste Architektur
Arten der Stand-Alones Singe-Session-Spiele persistent World-Spiele -einmaliges Spie l-danach Ende bzw. neues Spiel Verbindung durch: -Spieler-zu-Spielerverbindungen -über einen dedicated Server bzw Lobby-Server (Service mit dem es möglich ist Spielserver zu suchen) -Spiel dauert immer an, auch wenn der Spieler gerade offline ist -Spiel ist nie zu Ende und somit kann der Spieler auf vorherige Erfolge aufbauen -oft mehrere tausend Spieler -werden daher als Massively- Multiplayer-Spiele berzeichnet(mmps)
Implementation von MMPs Genre, dass komplexeste Netzwerkarchitektur benötigt Ähnliche Probleme wie Echzeit-Virtual Virtual-Reality- Systeme Ziel eines VR-Systems: Welt nachbilden Ziel: Welt nachbilden, aber so dass es noch dem Spielspaß dient -> Gameplay wichtiger als Simulationsaspekt
Game Logic Command/ Reponse Multiplexor Character AL Handler Other Game- Spezific Modules Player Action Handler Client Client Database Cache Client Distributed Object Manager World Database Client Game Play Management Account Manager/ Online Customer Tools Account Database Buisness Process Management
Client-Server Server-Verbindungen Verbindung durch festgelegte Transferprotokolle 1.UDP : - hoher Datendurchsatz - aber keine Garantie auf Paketlieferung -> > Actionspiele 2.TCP: - hohe Zuverlässigkeit -> rundenbasierte Spiele XML wird meist verwendet um Nachrichten-Inhalt zu codieren XML bietet feste Strukturierungsmöglichkeiten an Aber: hoher Speicherbedarf-> > höherer Durchsatz nötig Statt vollständiger Aktualisierung -> > nur Aktualisierung der Objekte die sich verändert haben
Die Spielwelt Nicht nur auf einem einzelnen Server Verteilung auf mehrere Server Server-Shards die ein zusammenhängendes System bilden 2 Methoden zur Verteilung der Spielwelt auf die Shards Zoned Worlds Aufteilung nach geographischen Zonen 1 Zone = 1 Server oder Servercluster Spielerbewegung zw den Zonen nur eingeschränkt Durch Portale oder ähnliche Verbindungen
Die Spielwelt Seamless Worlds (übergangsfrei): Keine strengen, unüberwindbaren Grenzen Grenzen werden dynamisch verwaltet Vorteile: Welt wirkt realer Größere zusammenhängende geogr.. Gebiete Skalierbarkeit- Grenzen können noch nach Spielstart justiert werden bspw nach Rechenlast
Probleme bei Seamless Worlds Zonen gehen ineinander über Objekte die sich nah an der Grenze befinden, müssen auch auf dem anderen Server (Zone) sichtbar sein Lösung: Schaffung eines Proxy-Objekts auf dem anderen Server Weiteres Problem: Was ist wenn ein Objekt vom einem Shard auf den anderen bewegt wird?? ->Proxy muss wieder gelöscht werden und ein neues erstellt werden ->dynamische Proxyverwaltung nötig
Der Multiplexor Zwischenstück zw. Client und Server-Shards Shards Fungiert als Login-Management Management-System -> > verteilt Spieler auf die richtigen Shards Dynamische Verteilung der Spieler auf die Shards Dadurch Lastverteilung möglich
Speicherung des Spielweltstatus Wichtige Daten zum speichern: Geographie, Eigenschaften der Charaktere und Objekte müssen schnell verfügbar sein Entweder in einer Datenbank Oder in einem Cache (sehr schneller Zwischenspeicher) Nicht möglich alles in einem Cache zu speichern Lösung: wichtige Informationen im Cache Nur langsam benötigte in der Datenbank
Distributed Object Manager Aufgabe: Aktualisierung der Weltansicht der Clients Aktualisierungen werden nur an die Clients gesendet, die sie benötigen Zusätzlich: Extra Server für geschäftliche Abwicklung Bspw: Accounterstellung,, Zahlungsinformationen Betriebssystem der meisten Server:Linux (Ausnahme: Produkte von Microsoft) Clients aber meist für Windows Heute gibt es viele Programme von Drittanbietertn die Spieleentwicklung erleichtern durch Bereitstellung von Physik- oder Grafikengines
Konsistenz/Latenzprobleme Bei Veränderung im Spiel: Update an Clients notwenig Verzögerung (Latenz) sollte möglichst gering sein,2 Ansätze zur Vermeidung Dead Reckoning: Client erfasst sich bewegende Objekte und schätzt deren Bewegung ab wenn Aktualisierung durch Server ausbleibt: besser möglich durch Pathnodes oder: Server simuliert Weltzustände der Clients Alle übermittelten Nachrichten sind zeitlich markiert Wenn Antwort beim Server eintrifft->wie war der Zustand beim Client? ->Abarbeitung der Spielerreaktion mit seinem damaligen Weltzustand
Zukunft Handys, PDAs etc sollen künftige Spiele-Plattform bilden Schon 7 Mill. Menschen in den USA spielen auf diesen Plattformen Schätzung: ungefähr 70 Mill. Spieler bis 2007 Trend zur Setzung von Programmierstandards für diese Plattformen Java-> > Java 2 Micro Edition Mobile Information Device Profile eingeschränkte JVM Dadurch gängige Netzwekprotokolle,, Grafikstandards mgl. Alles auf die Leistung dieser Geräte zugeschnitten In Zukunft vllt Proxys möglich, die die Berechnung für den Client übernehmen->proxy zwischen Client & Server