= Spezifikation für Core-Ecosystem
Jakob Gegeniger <Jakob.Ger@gmail.com>
v1.0.0, 2026-07-31
:toc: macro
:toc-title: Inhaltsverzeichnis
:sectnums:
:icons: font
:header: Spezifikation für Core-Ecosystem
:footer: Jakob Gegeniger <Jakob.Ger@gmail.com> - v1.0.0, 2026-07-31

toc::[]

== Einführung

Diese Spezifikation beschreibt die ersten Überlegungen zum Konzept der Erlebniswelt, welche schrittweise aus dem ersten Standort entstehen soll.
Das Konzept lehnt sich an Open-World-Spiele an. Es soll eine Erlebniswelt erschaffen werden, die durch die Erfahrbarkeit mit allen Sinnen besonders immersiv wirkt. 
Schrittweise soll die Erlebniswelt mit einem hohen Detailgrad zum Leben erweckt werden.

Teile der Erlebniswelt sind als spezialisierte Minispiele konzipiert. Diese sollen sich nahtlos in die Erlebniswelt eingliedern, indem sie thematisch darauf abgestimmt werden und zusätzlich übergreifende Herausforderungen bieten.

== Gliederung der Standorte

Die Struktur der Spiele: Ausgehend von der kleinsten Einheit soll das Gesamtkonzept folgende Elemente umfassen. 

NOTE: Da die Begriffe noch nicht final etabliert sind, werden im Folgenden einige Vorschläge gemacht.

. Zone/Space/Node: Die kleinste Einheit an einem Standort. Dies kann eine Gruppe von Challenge-Räumen sein, eine Attraktion wie das Axtwerfen, der Klettergarten oder auch eine Go-Kart-Bahn.
. Hub/Campus/Venue/Base: Ein Standort, in dem eine oder mehrere Nodes integriert sind.
. Grid/Gilde/Network: Filialen des Unternehmens, die an das gemeinsame Erfahrungssystem angeschlossen sind.
. Allianz: Kooperationen mit externen Partnern, die sich an unser System anschließen.

=== Allianz / Gilde

Die Standorte sollen auf ein gemeinsames System zugreifen können, in dem die spielerbezogenen Daten verwaltet werden.

image::pics/global/ConnectedBases.drawio.png[Globale Struktur, align="center"]

Die Struktur im Detail muss noch definiert werden. Wir werden jedoch, wo es sinnvoll ist, auf bestehende Services zurückgreifen.

=== Basis

include::text/baseDescription.adoc[Base Description]

==== Netzwerk

Ein geeigneter Hersteller, um die Anforderungen an das lokale Netzwerk umzusetzen, scheint *Ubiquiti* zu sein. Ein kleines Modellsystem soll im Vorfeld evaluiert werden. Mit Ubiquiti lassen sich folgende Aspekte abdecken:

* Roaming über den gesamten Standort funktioniert erfahrungsgemäß zuverlässig.
* Es lassen sich verschiedene WLAN- und VLAN-Subnetze einrichten, die separat verwaltet werden können. Diese entzerren nicht nur die Broadcast-Last im Netzwerk, sondern stellen auch sicher, dass lediglich Geräte aufeinander zugreifen können, die über entsprechende Berechtigungen verfügen.
* Firewalls lassen sich passend zu den Subnetzen konfigurieren.

==== IP-Kameras

Die IP-Kameras sollen großteils über das gleiche physikalische Netzwerk laufen, dabei einen eigenen VLAN-Bereich erhalten und vorzugsweise über PoE betrieben werden. Sofern dies aus Kostensicht vertretbar ist, wird hier im Idealfall ebenfalls die Lösung von *Ubiquiti* eingesetzt.

==== Sound

Die Klangkulisse wird durch eine große Anzahl an Lautsprechern realisiert, die im gesamten Haus verteilt sind. Im Idealfall handelt es sich dabei um IP-Knoten, die als virtuelle Audiogeräte fungieren. Es gibt Lösungen, diese Lautsprecher gebündelt oder individuell anzusteuern. Zunächst soll *Dante* evaluiert werden. Die Software kann virtuell bis zu 64 Eingänge auf bis zu 64 Ausgänge routen. Der Input wird dabei durch kleine Dienste bereitgestellt. Die Software unterstützt zudem ein offenes Broadcast-Protokoll, an das sich die Rechner in den Challenge-Räumen anbinden könnten. Damit könnte jede netzangebundene Komponente auch Teil des Soundsystems sein.

=== Diagnose 

Iterativ soll das Gesamtsystem so konzipiert werden, dass Prozessparameter permanent gemessen werden und bei Bedarf Alarm ausgelöst werden kann. 

* Die Managed Switches bieten eine Möglichkeit, die Netzwerkauslastung zu überwachen.
* Die Software und Firmware der Spiele sind so zu gestalten, dass die Prozesse permanent überwacht werden und auftretende Abweichungen sofort gemeldet werden. Konkret soll ein Rechner, der mit einem IoT-Gerät kommuniziert, jeweils die Antwortzeit messen. Übersteigt die Zeit ein definiertes Limit, wird eine Wartung als Log-Meldung ausgelöst; kommt es zu einem Timeout, wird ein Fehler gemeldet. 
* Die Informationen werden an einer zentralen Stelle gesammelt. Daraus lässt sich ein Dashboard erstellen, das den Gesundheitszustand der Anlage abbildet. 

IMPORTANT: Ziel ist es, ein System zu etablieren, das Frühwarnungen liefert, sobald die Lösung instabil wird oder ein Spiel ausfällt – idealerweise, bevor Kunden dies bemerken und melden müssen.

== Spielmodi

Es soll flexibel auf die individuellen Kundenwünsche eingegangen werden. 

NOTE: Hier werden im zukünftigen Betrieb voraussichtlich noch einige Anpassungen notwendig werden. 

Folgende Kundengruppen sollen adressiert werden: 

. Laufkundschaft/Tagesgäste: Jeder Kunde soll die Möglichkeit erhalten, die Attraktionen ohne großen Aufwand zu erleben. Sie sollen nach einer niederschwelligen Einführung direkt an dem Erlebnis teilnehmen können, das der Grund für ihren Besuch ist.
Denkbar sind kurze Einstiege, die Teil der Sicherheitsunterweisung sind oder einen Überblick über den Standort geben, um auch neuen Tagesgästen das Erfahrungssystem nahezubringen.
. Adventure-Gäste: Diese Gäste haben das Ziel, Quests zu lösen sowie Gegenstände und Erfahrungspunkte zu sammeln. Sie sollen bewusst zu Beginn zunächst ein gewisses Level erreichen, um an bestimmten Attraktionen teilnehmen zu dürfen. Im Idealfall ist eine Art Tutorial vorgeschaltet, in dem die Spieler neben der Sicherheitsunterweisung alle wesentlichen Spielmechaniken erlernen.

== Belohnungssystem

Die Adventure-Spieler sollen im Laufe des Spiels verschiedene Gegenstände und Erfahrungen sammeln können:

. Gegenstände: Verteilt in der offenen Welt.
. Errungenschaften: Abgeleitet von:
    * der Art der gesammelten Gegenstände/Errungenschaften (z. B. Schätze gefunden, versteckte Spiele entdeckt)
    * der Vollständigkeit der Sammlung (z. B. ersten Schatz gefunden, 50 % der Schätze gefunden, alle Schätze gefunden)
    * der erreichten Punktzahl bei ausgewählten Attraktionen (z. B. Highscore in den oberen 25 %, 10 % oder 5 % erreicht)
    * der gesamten Spieldauer
. Daraus abgeleitet soll dem Spieler ein Erfahrungslevel zugeordnet werden, woraus sich wiederum das Spieler-Level ergibt. 
. Bestimmte Errungenschaften sollen direkte Belohnungen wie ein Heißgetränk, Kaltgetränk oder zusätzliche Spielzeit freischalten.
. Bestimmte Attraktionen sind für die Spieler erst ab einem festgelegten Level zugänglich.

== Benutzer

Der Buchungs- und Anmeldeprozess soll jede anwesende Person einer Gruppe anhand ihrer ID einem Benutzerprofil zuordnen. 

Tagesgäste erhalten ein temporäres Profil, in dem primär die Zugänge zu den Spielen geregelt werden.
Adventure-Gäste erstellen initial ein permanentes Profil, das mit ihrer E-Mail-Adresse verknüpft wird.

Auf der Spielfläche wird jeder Benutzer mittels eines RFID-Armbandes identifiziert. Der Benutzer erhält dieses bei Eintritt und muss es, sofern es sich nicht um ein Einwegarmband handelt, beim Ausgang wieder abgeben.

=== Profilpflege

Tagesgäste und Adventure-Gäste können ihr Profil an einem Self-Service-Terminal verwalten. 
Adventure-Gäste erhalten zusätzlich einen Online-Zugriff auf ihr Profil, worüber sie ihr Inventar und ihre Errungenschaften einsehen können. 

== Infoterminals 

Im Spielbereich sollen kleine Infoterminals platziert werden, die im Wesentlichen aus einem Touchpad und einem RFID-Leser bestehen. Die Kunden können dort ihr Tag scannen, ihren Account verwalten sowie Inventar- und Profildaten einsehen. 

== Bezahlung

Auf dem gesamten Campus sollte der Gast mit dem RFID-Tag bezahlen können. 
Für minderjährige Gäste sollte es möglich sein, dass die Eltern das Tag im Vorfeld mit Guthaben aufladen. 
Erwachsene Gäste dürfen, sofern möglich, auch per Anschreiben konsumieren und die offenen Beträge beim Checkout begleichen. 
Bargeld sollte ausschließlich im Empfangsbereich entgegengenommen werden; die Terminals müssen jedoch bargeldlose Systeme unterstützen.

Insbesondere im Hinblick darauf, dass Gäste den geschlossenen Bereich temporär verlassen könnten, um gegebenenfalls im Biergarten einzukehren, muss sichergestellt werden, dass dies nur mit ausgeglichenen Konten möglich ist. 

== Anmeldung / Buchung

Für die Buchungen und Anmeldungen werden wir voraussichtlich ein kommerziell etabliertes System nutzen.

Bei der Buchung muss gegebenenfalls zwischen den beiden Spielerklassen unterschieden werden. Eventuell reicht diese Differenzierung auch erst vor Ort am Terminal.

Für Adventure-Gäste soll die Möglichkeit geschaffen werden, eine Vorab-Anmeldung durchzuführen, bei der das Profil angelegt wird und man eine Kennung zur Anmeldung (z. B. einen QR-Code oder ähnliche Mittel) erhält.

== Registrierung

Am Standort soll es zwei Möglichkeiten geben, die Spieler zu registrieren: 
* Direkt an der Kasse.
* Am Self-Service-Terminal.

Es wird zwei Klassen von GameTags geben: 
* Jedem Tagesgast steht es frei, einen GameTag zu wählen, der noch nicht von einem Adventure-Gast belegt ist.
* Ein Adventure-Gast kann einen beliebigen GameTag wählen, auch einen, der bereits durch einen Tagesgast in Verwendung war. 
* In den Highscores und Übersichten wird visuell zwischen permanenten und temporären GameTags unterschieden.

=== Terminal

Bei Tagesgästen muss es möglich sein, einen GameTag und eine Gruppenzugehörigkeit am Self-Service-Terminal oder an der Kasse festzulegen.
Ähnliches gilt für Adventure-Gäste. Hierbei ist jedoch zu beachten, dass im Anschluss an die Anmeldung die Gruppenzugehörigkeit definiert sowie das Benutzerprofil eingesehen und verwaltet werden kann.

=== Kasse

Die Kasse vereint alle Funktionen des Self-Service-Terminals, wird jedoch durch das Personal bedient, welches mit erweiterten Rechten ausgestattet ist, um bei Bedarf korrigierend einzugreifen.

== Zukunft

Perspektivisch soll das Identifikationssystem erweitert werden. 

. Als nächster Schritt sollen Smartphones eingebunden werden. Über eine zugehörige App, die mit dem Spielerprofil verknüpft ist, können dann Inventar, Errungenschaften und Profildaten angezeigt werden.
. Später soll es den Spielern ermöglicht werden, die Spielwelt über eine kartografische Darstellung abzurufen. Der Spieler kann dann auf der Karte einsehen, welche Bereiche bereits besucht wurden und wie viele Quests er in den jeweiligen Zonen bereits gelöst hat.
. Denkbar ist auch die Einführung von Smartwatches, die mit dem Standort vernetzt sind und die Kommunikation abwickeln. 
Auf lange Sicht würde dies bedeuten, dass die RFID-Lesegeräte vom Aktiv- in den Passivmodus umgeschaltet und der Standort mit rein passiven Tags ergänzt wird.

== Modelle

Im Folgenden ein Vorschlag für das Benutzermodell für Tagesgäste und Adventure-Gäste. 

[source,yaml]
----
guest:
    GameTag:
    TagId:
    Notes:
    Group:
    RegisterTime:
    Deadline:
    CreditsLeft:
    MoneySpent:
    Experience:
----

[source,yaml]
----
player: 
    player: # all attributes of guest
    Email:
    FirstName:
    Lastname:
    BirthDate:
    Gender:
    Notes:
    Level:
    MoneySpentTotal:
    ExperienceTotal:
    Inventar:
----