Tag Patterns

Game Design Patterns: PvP Herausforderungen 0

Apr9

Ich habe mir in letzter Zeit Gedanken darüber gemacht, wie Spieler in unserem Browserspiel gegeneinander antreten können. Hintergrund: es soll möglich sein, dass zwei bis vier Spieler in einzelnen “Auseinandersetzungen” gegeneinander antreten können. Die Frage ist nun: wie kann man organisieren, dass eine solche Auseinandersetzung stattfindet?

Ein Beispiel, um das Thema zu verdeutlichen: nehmen wir an, jeder Spieler repräsentiert einen Piloten eines Jets (Raumschiffs, Rennwagens). Als reguläre Spieloberfläche hat jeder Spieler eine Auflistung seiner Möglichkeiten auf dem Flughafen (Flugzeugträger, Raumschiff, Fahrerlager, ..), unter anderem sich mit anderen Piloten zu Übungszwecken zu duellieren. Bis zu insgesamt 4 Spieler können in “Dogfights” (Wettrennen) gegeneinander antreten. Nachdem sich 2-4 Spieler gefunden und geeinigt haben, starten sie. Die Oberfläche wechselt zu einem Cockpit, in dem nun jeder Spieler sein Jet (Raumschiff, Rennwagen) steuert (Wechsel von “Nicht Auseinandersetzung” zu “Auseinandersetzung”).

Gemäß des Aufrufs von Bernd Kreimeier in Gamasutra beschreibe ich kurz mal das Problem und skizziere die Lösungen, auf die ich gekommen bin. Die Problemstellung ist bei allen gleich:

Problem: “2-4 Spieler sollen in Auseinandersetzungen gegeneinander antreten können. Es steht während der Auswahl keine grafische Repräsentation der Spielwelt zur Verfügung. Die Auseinandersetzungen selbst finden in einer grafischen Repräsentation statt und sind so “losgelöst” von der sonstigen Oberfläche. Wie können sich Spieler finden, die gegeneinander antreten wollen? Wie können Spieler gezielt gegen spezifische Spieler antreten? Wie können die Spieler kontrolliert von der Oberfläche der “Nicht-Auseinandersetzung” in die der “Auseinandersetzung” wechseln?”

Skirmish

Lösung: Der Spieler gibt die Anzahl seiner gewünschten Mitspieler ein und bestätigt seine Wahl. Er wird in eine Warteschlage aufgenommen, die alle Spieler enthält, welche die gleiche Anzahl an Mitspieler wünschen. Er wartet so lange, bis diese Anzahl erreicht ist. Anschließend wechselt der Kontext für alle Spieler in der Warteschlage und sie treten in der Auseinandersetzung gegeneinander an.

Konsequenz: Das Finden der Mitspieler wird vom System automatisch übernommen. Ein Spieler kann nicht gezielt gegen spezifische Spieler antreten. Der Spieler hat keinen direkten Einfluss wann das Spiel stattfinden wird, sondern wird gezwungen passiv zu sein.

Beispiel: Battlegrounds in World of Warcraft. Skirmisch-Modus in Echtzeit-Strategiespielen.

Lobby

Lösung: Der Spieler gibt die Anzahl seiner gewünschten Mitspieler ein und bestätigt seine Wahl. Dies eröffnet einen neuen Raum mit der Anzahl an Mitspielern als offene Slots. Andere Spieler sehen diesen Raum und können diesen betreten. Wenn alle Slots von Spielern gefüllt sind, beginnt das Spiel.

Konsequenz: Das Finden anderer Mitspieler ist für den Ersteller des Spielraums nicht möglich, nur für die teilnehmenden Mitspieler. Der Spieler kann durch eigene Absprachen gegen spezifische Mitspieler antreten. Abhängig von der Implementation haben die Spieler Kontrolle über den Übergang auf die Oberfläche der Auseinandersetzung.

Beispiele: Viele Rennspiele implementieren eine vom Ersteller des Raums gesteuerte Variante: der Ersteller muss, nachdem andere Spieler seinen Spielraum betreten haben, manuell die Auseinandersetzung bestätigen bzw. beginnen. Er hat also Kontrolle über den Übergang. Echtzeit-Strategiespiele implementieren meistens eine Variante, in der jeder teilnehmende Spieler die Spielrunde bestätigen muss = alle Spieler haben Kontrolle über den Übergang.

Direkte Herausforderung

Lösung: Ein Spieler wählt aus einer Liste der existierenden und verfügbaren Mitspieler 1-3 weitere aus und bestätigt seine Wahl. Der Spieler wechselt direkt in den Kontext der Auseinandersetzung, die allerdings noch nicht beginnt. Es wird eine Benachrichtigung mit einer Herausforderung an die gewählten Mitspieler versendet, die einen Link enthält. Der Link führt die Spieler direkt in die Auseinandersetzung. Die Auseinandersetzung beginnt, sobald alle Mitspieler im Kontext der Auseinandersetzung sind.

Konsequenz: Die Spieler können gezielt gegen spezifische Mitspieler antreten. Sie haben allerdings kaum Kontrolle über den Wechsel – sie müssen warten, bis alle anderen Mitspieler der Herausforderung gefolgt sind. Die Zeitspanne dafür ist nicht absehbar und die Herausforderer müssen unter Umständen lange auf eine Reaktion warten. Spieler können sich gegenseitig über eine Liste der verfügbaren Mitspieler finden.

Beispiel: Einige Browsergames arbeiten mit dieser Art von Herausforderung. Bei einer Herausforderung ist es dabei üblich eine Mail zu versenden bzw. zusätzlich auf der Oberfläche des Browsergames die Herausforderung kenntlich zu machen. Seltener sind Benachrichtigungen per IM und SMS (eigentlich nur bei mobilen Spielen üblich).

Fällt euch noch ein Pattern ein? Falls ja, beschreibt es bitte als Kommentar. Und was mich noch interessieren würde: welches der drei vorgestellten Patterns sagt euch mehr zu? Ja, ich weiß, das ist abhängig vom Spielprinzip und der Implementation, aber wenn ihr einfach aus dem Bauch heraus antwortet: welches wäre das dann?

Oh, und den oben erwähnten Gamasutra-Artikel kann ich wirklich empfehlen :)

Das Zeitgeist Nachrichtensystem 2

Nov23

Jetzt mal ernsthaft – ihr könnt euch ruhig trauen hier im Blog mit Hilfe der Kommentare zu fragen, anstatt mir umständlich eine Mail zu schreiben.

Die Frage war:

Was ist dieses angesprochene Message-System?

Nun, einfach gesagt: Die Message-Klasse stellt Funktionalitäten bereit, um systemweite Textnachrichten zu verwalten.

Das Prinzip der systemweiten Nachrichten sollte vielen bekannt sein, die schon einmal etwas tiefer in die  Dektop-Programmierung eingestiegen sind. Man kann es sich als eine Art Modul vorstellen, das von überall her angesprochen werden kann. An dieses Modul können Nachrichten übergeben und umgekehrt wieder angefordert werden. Auf diese Weise können alle Module eines Projekts miteinander kommunizieren.

Weiterlesen »

Der Motor: Zeitgeist 0

Jul29

Wir haben an dieser Stelle bereits einiges zu unserem Framework fallen gelassen. Hier nun die im letzten Post versprochene Überraschung: es ist an der Zeit nähere Details über den Motor unserer Projekte zu veröffentlichen: Zeitgeist.

Ursprünglich wurde Zeitgeist geplant und entwickelt für unser erstes Browserspiel-Konzept: Zeitalter3. Und daher auch der Name: es ist der gute Geist, welcher Zeitalter3 antreibt. Jedoch wurde das Framework frühzeitig mit dem Fokus entwickelt ein generischer Unterbau für alle Arten von webbasierten Mehrbenutzersystemen zu sein. In so fern ist das Framework weder auf ein einziges Spiel spezialisiert, noch ist es nur auf Spiele festgelegt. Ob Browserspiel, Webapplikation oder Community – alle Webanwendungen können theoretisch auf der Basis von Zeitgeist entwickelt werden.

Technisch basiert Zeitgeist auf PHP5 mit einer Datenbank im Hintergrund. Es ist voll objektorientiert und stellt Klassen für viele Bereiche der Webentwicklung zur Verfügung. Features sind zum Beispiel:

  • Debugging der gesamten Anwendung, inklusive Tracing
  • Einfache Konfiguration der Applikation
  • Datenbankanbindung, inklusive rudimentäres SQL-Profiling
  • Transparente Session- und Benutzerverwaltung
  • Transparente Validierung aller eingehenden Parameter
  • Automatische Formularvalidierung und -Handhabung
  • AJAX-Datenserver
  • Lokalisierung
  • Templatesystem, basierend auf Dreamweaver-Templates

Zeitgeist bietet also Hilfen und fertige Klassen für einen großen Teil der üblichen Aufgaben von Webprojekten. Aber wie ist nun eine Implementation eines Zeitgeist-Projekts aufgebaut?

Weiterlesen »

Zeitalter3 – Browsergames Entwicklerblog is powered by WordPress
Theme based on FREEmium Theme, developed by Dariusz Siedlecki by FreebiesDock.com