Draft for Specification

.vscode/settings.json

@@ -0,0 +1,5 @@
+{
+        "workbench.colorTheme":  "Light Modern",
+        "plantuml.render": "PlantUMLServer",
+        "plantuml.server": "http://www.plantuml.com/plantuml"
+}

.vscode/tasks.json

@@ -0,0 +1,24 @@
+{
+    // See https://go.microsoft.com/fwlink/?LinkId=733558
+    // for the documentation about the tasks.json format
+    "version": "2.0.0",
+    "tasks": [
+        {
+            "label": "Build AsciiDoc PDF",
+            "type": "shell",
+            "command": "docker",
+            "args": [
+                "run",
+                "--rm", // autoremove after exit
+                "-v",
+                "${workspaceFolder}:/documents",
+                "-w",
+                "/documents",
+                "asciidoctor/docker-asciidoctor",
+                "asciidoctor-pdf",
+                "${relativeFile}"
+            ],
+            "group": "build"
+        }
+    ]
+}

00_RoadMap.adoc

@@ -0,0 +1,26 @@
+= RoadMap
+Jakob Gegeniger <Jakob.Ger@gmail.com>
+v1.0.0, 2026-07-31
+:toc: macro
+:toc-title: Inhaltsverzeichnis
+:sectnums:
+:icons: font
+:header: Roadmap
+:footer: Jakob Gegeniger <Jakob.Ger@gmail.com> - v1.0.0, 2026-07-31
+
+toc::[]
+
+== Einführung
+
+
+== Roadmap 
+
+Gesetz den Fall wir können im Dezember / Januar mit dem Bau beginnen sollten wir die erste Etappe im Spätsommer fertig stellen. 
+
+Ziel für Spätsommer 2027:
+
+
+Ziel für Spätsommer 2028:
+
+
+Ziel für Spätsommer 2029:

01_BasisSpec.adoc

@@ -0,0 +1,192 @@
+= 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:
+----

02_ChallengeRoomSpec.adoc

@@ -0,0 +1,113 @@
+= Spezifikation für Challenge-Rooms
+Jakob Gegeniger <Jakob.Ger@gmail.com>
+v1.0.0, 2026-07-31
+:toc: macro
+:toc-title: Inhaltsverzeichnis
+:sectnums:
+:icons: font
+:header: Spezifikation für Challenge-Räume
+:footer: Jakob Gegeniger <Jakob.Ger@gmail.com> - v1.0.0, 2026-07-31
+:plantuml-server-url: http://www.plantuml.com/plantuml
+
+toc::[] 
+
+== Einführung
+
+Im Folgenden werden die Anforderungen an die Challenge-Räume definiert. 
+Challenge-Räume sind kleine Räume in einer Größe von 3x3 m bis 6x6 m, in denen verschiedene Aufgaben und Herausforderungen aufgebaut sind.
+
+* Die Besucher können diese Herausforderungen in mehreren Schwierigkeitsstufen absolvieren. 
+* Für jede Herausforderung steht den Spielern eine fest definierte Zeit zur Verfügung.
+* Zum Abschluss wird ein Ergebnis angezeigt, anhand dessen die Spieler ihre Leistung mit vorherigen Ergebnissen sowie mit anderen Gruppen vergleichen können.
+
+== Aufbau
+
+Der elektronische Aufbau eines Challenge-Raums ist im Folgenden dargestellt. 
+
+image::pics/challengeRooms/challengeRoom.drawio.png[Challenge-Raum Aufbau, align="center"]
+
+Der Raum besteht aus folgenden Komponenten:
+
+. PC: Zur zentralen Steuerung des Raums. Der PC betreibt alle nötigen Dienste, um folgende Aufgaben zu erfüllen:
+    * Zugangskontrolle 
+    * Spielsteuerung
+    * Soundkulisse
+    * Rückmeldung der Errungenschaften
+    * Integration der Quests
+. Lock: Physische Verriegelung der Tür, damit die aktuell spielende Gruppe nicht durch nachrückende Besucher gestört wird.
+. Registration: Ein RFID-Lesemodul, an dem sich die Spieler anmelden können.
+. Gastmonitor: Ein Monitor, der für den Außenbereich gut sichtbar angebracht ist. Besucher können ablesen, ob der Raum aktuell belegt ist, welches Thema er beinhaltet und wie der aktuelle Highscore lautet.
+. Raum-Monitor: Ein in den Raum gerichteter Monitor für die aktiven Spieler. Hier werden Spielanweisungen angezeigt, der Schwierigkeitsgrad kann gewählt und gegebenenfalls die Sprache umgestellt werden. Während des Spiels liefert er weitere Hinweise und zeigt den Score sowie die verbleibende Zeit an.
+. Audio: Ein lokal verbauter Verstärker beschallt den Raum eigenständig. Im Idealfall lässt sich die lokale Anlage auch bei Notfällen mit der Zentrale zusammenschalten, um Störungen oder Warnmeldungen durchzusagen.
+. GameTerminal: Wo nötig, werden zusätzliche Bedieneinheiten für die Spielsteuerung verbaut. Diese bestehen in der Regel aus Tastern, Knöpfen und Signallichtern.
+. Hub-Electronics: Steuerungshardware, die über IP mit dem Raum-PC verbunden ist und als Schnittstelle für weitere Sensoren/Aktoren dient (z. B. in Form eines PoE-Switches).
+. Node (Knotenpunkt): Nodes sind Mikrocontroller/Elektroniken, die I/O via serieller Schnittstelle oder IP bereitstellen. Es gibt spezialisierte Nodes für unterschiedliche Aufgaben:
+    * Einfache digitale I/O-Module zum Erfassen und Schalten von digitalen Signalen.
+    * LIDAR-Nodes: Zur Flächenüberwachung, um unzulässige Bewegungen zu registrieren.
+    * Media-Nodes: Audiovisuelle spezialisierte Terminals mit autarken Spielelementen, die über TCP/IP gesteuert werden.
+. Success-Terminal: Diese Einheit wird am Ende eines Parcours aufgestellt. An diesem Terminal loggen sich die Spieler aus, um das erfolgreiche Ende der Strecke zu bestätigen.
+
+WARNING: Die Türsteuerung ist eine sicherheitsrelevante Komponente. Es muss sichergestellt sein, dass sich die Tür im Bedarfsfall durch externe Signale zuverlässig öffnen lässt.
+
+== Ablauf
+
+Der generelle Ablauf wird in der folgenden Übersicht zusammengefasst:
+
+image::out/pics/challengeRooms/gameRun/gameRun.png[Spielablauf, align="center"]
+
+. Anmeldung: Die Spieler melden sich mittels ihres RFID-Tags an.
+    * Es wird serverseitig geprüft, ob das Tag gültig ist.
+    * Bei erfolgreicher Autorisierung wird der Spieler mitsamt seiner Gruppe dem Raum zugeordnet. Das System wartet dann auf die Registrierung der restlichen Teammitglieder.
+    * Sind alle Gruppenmitglieder abgemeldet, wird das Spiel freigegeben.
+. Spielmodus wählen: Die Spieler erhalten die Möglichkeit, am Bildschirm den Schwierigkeitsgrad auszuwählen und bei Bedarf die Sprache zu ändern. Sobald der Schwierigkeitsgrad festgelegt wurde, verriegelt die Tür und das Spiel startet.
+. Das Spiel wird autark durch den lokalen Raum-PC verwaltet. Der Raum-PC steuert dabei:
+    * Die Spielmechanik
+    * Die Musik und Soundkulisse
+    * Die Auswertung der erreichten Punkte (Score)
+. Nach Ablauf des Spiels werden die Spieler aufgefordert, den Raum zu verlassen, und die nächste Gruppe kann sich zur Anmeldung vor der Tür einfinden.
+
+== Alternative Modi
+
+Wenn ein Spieler den Raum betritt, ohne einen Schwierigkeitsgrad auszuwählen (und folglich den normalen Spielablauf nicht auslöst), befindet sich der Raum im Quest-Modus. 
+
+Das bedeutet: Löst der Spieler ein speziell im Raum verstecktes Rätsel, wird dies über den Raum-PC gemeldet, als würde es sich um ein von der Halle losgelöstes I/O-Gerät handeln. 
+
+== Themen 
+
+Das Angebot umfasst eine Reihe thematisch unterschiedlich ausgerichteter Challenge-Räume:
+
+* Skills / Geschick / Geschwindigkeit
+* Fitness / Kraftausdauer
+* Intelligenz / Logik
+
+Es ist vorstellbar, diese Grundausrichtungen in das Thema der altgriechischen Elemente einzubinden, wie zum Beispiel:
+
+* Erde
+* Luft
+* Wasser
+* Feuer
+
+== User-Interface 
+
+Nachfolgend werden die vorgeschlagenen Ansichten für die Benutzer im Empfangsbereich (Gast) und innerhalb des Raumes dargestellt.
+
+=== Gastmonitor
+
+image::pics/challengeRooms/GuestScreen.drawio.png[Gast-Monitor, align="center"]
+
+Das Interface im Gastbereich soll folgende Informationen auf einen Blick liefern:
+
+. Art des Spiels
+. Benötigte Fähigkeiten / Anforderungen
+. Kurzbeschreibung
+. Highscore
+
+=== Raum-Monitor
+
+image::pics/challengeRooms/RoomScreen.drawio.png[Raum-Monitor, align="center"]
+
+Die Anzeige im Innenbereich des Raums bietet dem aktiven Team folgende Informationen:
+
+. Verbleibende Zeit
+. Aktueller Score
+. Spielanweisungen und Hinweise

Defitionen.txt

@@ -0,0 +1,2 @@
+Tages-Gast
+Adventure-Gast

pics/challengeRooms/gameRun.puml

@@ -0,0 +1,58 @@
+@startuml
+|Player|
+start
+:scan RFID Tag;
+
+|RoomPc|
+:Auth query;
+
+|Globaler Server|
+:check Auth;
+
+if (Valid?) then (yes)
+  |RoomPc|
+  :Reserve to player and team;
+  :unlock door;
+  
+  if (All members registered?) then (no)
+    :wait for final player;
+    detach
+  else (yes)
+    :enable game;
+  endif
+
+else (no)
+  |RoomPc|
+  :Show error;
+  stop
+endif
+
+|Player|
+:enter room;
+:select language;
+:select difficulty;
+
+|RoomPc|
+:lock door;
+:start game;
+
+fork
+  :game mechanics;
+fork again
+  :music & effects;
+fork again
+  :score;
+end fork
+
+:time out;
+:show score;
+:Send score to server;
+:unlock door;
+
+|Globaler Server|
+:update player and group score;
+
+|RoomPc|
+:set room available;
+stop
+@enduml

text/baseDescription.adoc

@@ -0,0 +1,40 @@
+An jedem Standort sind alle oder zumindest Teile der folgenden Bereiche vorgesehen:
+
+image::pics/local/BaseLayout.drawio.png[Layout im Standort, align="center"]
+
+. Empfangsbereich: Hier finden der Empfang der Kunden und der reguläre Ticketverkauf für die Laufkundschaft statt.
+    * Angemeldete Spieler sollen sich zügig einchecken können, idealerweise direkt an einem Self-Service-Terminal.
+    * Auch die Laufkundschaft kann im Optimalfall ihre Tickets eigenständig am Self-Service-Terminal erwerben, notfalls steht der klassische Service an der Kasse zur Verfügung.
+. Garderobe: Dient der Aufbewahrung von Kleidung und Wertgegenständen. Dieser Bereich könnte auch als eine Art Tutorial geschickt in die Quest-Reihe eingebaut werden.
+. Verwaltung / IT: Hier befinden sich die Verwaltung des Standorts sowie die lokalen Server- und Überwachungsräume.
+. Event-Bereich: Eine Art Fest- oder Mehrzweckhalle, die in freien Zeiten ebenfalls Bestandteil der Quest-Umgebung werden kann.
+. Spielbereich: Das Kernstück der Anlage. Der Spielbereich setzt sich aus den verschiedenen Einzelattraktionen wie Challenge-Räumen, LaserTag und weiteren Spielen zusammen. Dabei können die Spielzonen in einem übergreifenden oder mehreren spezifischen Themenbereichen gestaltet sein. Gegebenenfalls gehen die Areale fließend ineinander über.
+
+Die IT-Struktur wird im Folgenden erläutert.
+Jeder Standort verfügt für die latenzfreie Spielabwicklung über sein eigenes, lokales System, welches fortlaufend mit dem globalen Hauptsystem synchronisiert wird.
+
+image::pics/local/BaseIt.drawio.png[IT-Struktur im Standort, align="center"]
+
+Diese IT-Struktur sieht folgende Elemente vor:
+
+. Router: Da wir auf externe Dienste angewiesen sein werden, muss eine stabile Internetverbindung gewährleistet sein. Über diese Leitung lassen sich bei Bedarf auch Gastgeräte mit dem Internet verbinden. 
+. Haus-Server / Server-Gruppe: Diese Server stellen lokal alle relevanten Betriebs- und Steuerungsdienste bereit:
+    * Einen Dienst zur Steuerung der gesamten Spielmechanik.
+    * Einen API-Dienst, der die Datenbankabfragen (Queries) zentral kapselt und bereitstellt.
+    * Einen Dienst für die Verarbeitung von Log-Daten.
+    * Eine lokale Datenbankinstanz zur Vorhaltung der Kundendaten.
+. Verwaltung: Die Rechner der Administratoren ermöglichen es, den Status des kompletten Standorts zu überblicken, bei Störungen direkt in das Geschehen einzugreifen und neue Spielszenarien zu konfigurieren.
+. Switches / Access Points: Zur kabelgebundenen und kabellosen Netzwerkintegration der gesamten Hardware werden primär Managed Switches und Access Points eingesetzt. 
+. Kundengeräte: Privatgeräte wie Smartphones der Kunden können in das separate Gastnetzwerk eingebunden werden. Dies ist erforderlich, um den Spielern den uneingeschränkten Zugriff auf ihre digitalen Profile zu ermöglichen.
+. IoT-Geräte: Sie bilden einen wesentlichen interaktiven Teil der Erlebniswelt und decken unterschiedliche Funktionen ab, zum Beispiel: 
+    * Einfache RFID-Lesegeräte
+    * Steuerbare Lichtquellen
+    * Autarke, smarte Requisiten
+    * Interaktive Tore, Schatztruhen etc. 
+    Alle Geräte sind tief mit der Spielmechanik verzahnt.
+. Kameras: Im gesamten Standort sollen strategisch zur Sicherheit und Spielüberwachung Kameras positioniert werden.
+. IP-Speaker: Ein Netzwerk aus IP-Lautsprechern stellt standortweit die musikalische Grundstimmung sowie die Soundkulisse sicher. Sie können außerdem genutzt werden, um auf spielspezifische Ereignisse zu reagieren oder sicherheitsrelevante Durchsagen zu tätigen.
+. Point of Sale (PoS): Die Kassensysteme; hier wird im Idealfall eine etablierte kommerzielle Lösung mit Netzanbindung eingesetzt.
+. Self-Service-Kiosk (SSK): Terminals, an denen Kunden eigenständig buchen können (ebenfalls als Eigenentwicklung oder zugekaufte Lösung).
+. Infoterminal: An diesen Touchscreens kann jeder Spieler verschiedene standortspezifische Informationen abrufen. Adventure-Spieler, die nicht ihr Smartphone nutzen möchten, können an diesen Terminals ihr Inventar prüfen oder ihre Konten pflegen.
+. Node / Spaces: Dies sind autarke Sub-Systeme, die eigenständig einen lokalen Spielverlauf steuern. Sie tauschen im Hintergrund Daten mit der Zentrale aus, damit Spiele ordnungsgemäß freigegeben und erreichte Leistungen zurückgemeldet werden. Gleichzeitig stellen einige Nodes physische Schnittstellen zur Lösung versteckter Quests in den Arealen bereit.