Kapitel 1 – Der ursprüngliche Bedarf: POCs schneller erstellen
OpenGate entstand aus einem konkreten operativen Bedarf: die Erstellung von Proof of Concepts (POC) für Mixed- und Augmented-Reality-Erlebnisse zu beschleunigen. In einem Umfeld schneller Experimente wie bei Metagate war jeder Tag ein Wettlauf gegen die Zeit. Ideen gab es viele, XR-Geräte wie Meta Quest 3 wurden immer leistungsfähiger, doch es fehlte ein leichtes, dynamisches und zentralisiertes Werkzeug, um den Zugriff auf Inhalte und die Datenverwaltung zu orchestrieren. Das Ziel war klar: mehr Erlebnisse in kürzerer Zeit entwickeln, mit mehr Kontrolle und besseren Iterationsmöglichkeiten.
Damals war Google Sheets das flexibelste und unmittelbarste Werkzeug. Eine gemeinsam genutzte Tabelle, die sich in Echtzeit aktualisieren ließ und auch von Unity einfach ausgelesen werden konnte, reichte für die ersten Tests mit Multimedia-Assets (Bilder, 3D, Sounds) und dynamischen Links aus. Es genügte, eine URL einzufügen, einen Parameter zu aktualisieren oder eine Koordinate zu ändern, und das Erlebnis im Headset passte sich sofort an. Eine No-Code-Lösung, mit der Kreativteam und Entwicklung ohne unnötige Strukturen zusammenarbeiten konnten.
Parallel dazu wurden kleine APIs in Google Apps Script entwickelt, die direkt mit den Tabellen verbunden waren. Diese Skripte automatisierten die Zeilenverwaltung, extrahierten bestimmte Daten, erzeugten Zugriffstoken oder änderten sogar in Echtzeit die Konfiguration eines MR-Erlebnisses. Jede API war ein kleines Werkzeug für einen bestimmten Zweck: ein Beschleuniger, um eine Szene, eine Figur oder eine interaktive Mechanik schneller zu testen. So entstand eine agile, leichte und dennoch erstaunlich leistungsfähige Mikro-Infrastruktur.
Obwohl dieser Ansatz nur als Übergangslösung gedacht war, erwies er sich sofort als effektiv. Das Team konnte mehrere XR-Projekte gleichzeitig verwalten, mit einem zentralen Setup, das Remote-Eingriffe in bereits auf den Headsets installierte Erlebnisse erlaubte. Eine Tabelle öffnen und einen Wert ändern genügte, um die digitale Umgebung in Echtzeit zu verändern. Für ein Startup wie Metagate, das ständig zwischen Events, Ausstellungen und Demos unterwegs war, war diese Flexibilität entscheidend.
Allerdings waren die Grenzen offensichtlich. Der auf Google Sheets basierende Ansatz bot keine echte Skalierbarkeit. Es gab kein strukturiertes System für Zugriffskontrolle, Avatar-Integration, komplexe Szenen oder Interoperabilität mit NFT-Plattformen. Außerdem war der mit den Tabellen verbundene Code fragmentiert geschrieben, häufig mit „Vibe-Coding“-Lösungen: schnell und kreativ, aber langfristig nur schwer wartbar.
Genau in diesem Moment entstand die Idee, das provisorische System in etwas Solideres, Modulareres und Skalierbareres zu verwandeln.
Kapitel 2 – Die ersten Tests mit Alpha-Testern
Nachdem die Mikro-Infrastruktur aus Google Sheets und APIs funktionierte, war es Zeit für den Praxistest. So bezogen wir die ersten Alpha-Tester ein: Künstler, Entwickler, Kuratoren und fortgeschrittene Nutzer, die der Metagate-Community bereits nahestanden. Wir wollten herausfinden, ob dieses leichte, dynamische System die Erstellung und Nutzung von Mixed-Reality-Erlebnissen tatsächlich vereinfachen konnte.
Das Feedback war sofort ermutigend. Die Alpha-Tester schätzten die Möglichkeit, Inhalte spontan zu ändern, ohne das Unity-Projekt neu kompilieren zu müssen. Ein Link in einer Tabelle wurde aktualisiert, und das Erlebnis im Headset passte sich in Echtzeit an. Damit eröffneten sich neue Möglichkeiten für Live-Workshops ebenso wie für Tests vor Veranstaltungen.
Einige Nutzer ohne jede Programmiererfahrung konnten bereits 3D-Assets spawnen, Bilder und Videos anzeigen, indem sie einfach einen Link in eine Zelle einfügten. Der No-Code-Charakter der Lösung war entscheidend, um die Zusammenarbeit zwischen sehr unterschiedlichen Rollen zu ermöglichen.
In dieser frühen Phase gab es noch keine richtige UI: Die Oberfläche war die Tabelle selbst. Doch das genügte, um das Potenzial des Ansatzes zu erkennen. Es fühlte sich an, als hätten wir eine neue, direkte und gemeinsame Art gefunden, XR-Erlebnisse zu komponieren. Das Mixed-Reality-Erlebnis wurde manuell und physisch in der realen Welt aufgebaut! Ein neuer Ansatz für einen „Builder“, halb physisch, halb digital – ganz im Stil von Mixed Reality.
Diese Begeisterung gab den entscheidenden Impuls, etwas Strukturierteres zu entwickeln. Das System funktionierte, musste aber die Tabelle verlassen und zu einer echten Plattform werden, um sich weiterzuentwickeln. OpenGate, damals noch ohne Namen, stand kurz davor, wirklich geboren zu werden.
Kapitel 3 – GPT-o3, Vibe Coding und die Weihnachtsferien
Während der Weihnachtsferien geschah etwas Unerwartetes. Marco Pizzini, mit wirtschaftlichem Hintergrund und ohne IT-Ausbildung, begann aus Neugier mit GPT-o3 zu experimentieren. Die Idee war einfach: herauszufinden, ob KI beim Schreiben von Code helfen konnte, um das bereits verwendete System zu erweitern und zu verbessern.
Es begann eine Phase reinen „Vibe Codings“: ein ständiger Austausch zwischen Intuitionen, generativen Prompts und sofort praktisch eingesetztem Code. Jede neue Funktion – von der Integration neuer Asset-Typen bis zur Verwaltung von Nutzer-IDs – entstand mit Unterstützung der KI. Das Fehlen starrer Regeln, kombiniert mit der Flexibilität des bestehenden Systems aus Sheets und schlanken APIs, machte diese Phase äußerst produktiv.
Schon bald entstanden echte Produktkomponenten: ein erstes Login, eine grundlegende Avatar-Verwaltung, eine erste Vorstellung einer Cloud. Alles war noch handgemacht, aber es funktionierte. Und vor allem war es funktionsübergreifend von einer nichttechnischen Person mit Unterstützung einer künstlichen Intelligenz aufgebaut worden.
In diesem Moment wurde uns klar: Wenn wir mit GPT so weit kommen konnten, dann konnte OpenGate wirklich für alle sein.
Daraus wurde eine Herausforderung: Wie weit lässt sich zumindest der Web-App-Teil nur mit GPT entwickeln?
Kapitel 4 – Die Webapp nimmt Gestalt an
Nach den ersten Experimenten und erfolgreichen Tests lag es nahe, die Sammlung aus Tabellen und Skripten in etwas Solideres zu verwandeln. So entstand der erste Prototyp der OpenGate-Webapp, entwickelt mit Flutter und Supabase. Das Ziel war klar: einen zentralen Hub für Assets, Nutzer und interoperable Funktionen zwischen Mixed-Reality-Erlebnissen zu schaffen.
Zuerst wurden die am häufigsten genutzten Funktionen migriert: die Cloud zum Hochladen von Multimedia-Assets, die Oberfläche zum Verbinden von Web3-Wallets wie Metamask und WalletConnect sowie die Anbindung an Ready Player Me zum Erstellen und Speichern von 3D-Avataren. Hinzu kam ein Basissystem zur Verwaltung von KI-Assistenten mit OpenAI, die mit Avataren verknüpft waren.
Die Stärke dieses Ansatzes lag in der Kontinuität mit der App für XR-Headsets, die weiterhin Google Sheets auslas. Nun konnten jedoch dieselben Daten und Inhalte direkt über die Webapp angesprochen werden, wodurch das Ökosystem zusammengeführt wurde.
Die Architektur war zwar noch in einem frühen Stadium, wurde aber zunehmend modular. Jeder Block – Cloud, NFT, KI, Avatar – war als eigenständige, aber verbindbare Komponente gedacht. Damit wurde die eigentliche Mission von OpenGate sichtbar: eine modulare Brücke zwischen digitalen Welten zu werden.
Kapitel 5 – Abschied von Google Sheets
Der Wechsel von Google Sheets zur Webapp ging schneller als erwartet. Obwohl die Tabellen in den ersten Monaten unverzichtbar gewesen waren, wurden ihre Grenzen spürbar: unsichere Zugriffe, fragile Struktur und Schwierigkeiten bei komplexen Inhalten oder mehreren Szenen. Mit dem Supabase-Backend und einem funktionierenden Flutter-Frontend übernahm die Webapp.
Die Migration war konsequent. Zuerst wurden dieselben Felder aus den Tabellen in der Datenbank nachgebildet, anschließend begann die Headset-App direkt aus Supabase zu lesen. Gleichzeitig wurden neue Nutzer in der Webapp registriert und nicht mehr über Google. Das Ergebnis war ein skalierbareres, sichereres und konsistenteres System.
Innerhalb kurzer Zeit wurden Google Sheets vollständig aus der App entfernt. Was als provisorisches Werkzeug begonnen hatte, war durch eine echte, integrierte und entwicklungsfähige Infrastruktur ersetzt worden. OpenGate wurde sichtbar mehr als ein Experiment: ein Projekt mit Vision, Nutzern und echtem Wachstumspotenzial.
Kapitel 6 – Brainstorming zur Interoperabilität
Nachdem die Webapp gefestigt war, stellte sich eine zentrale Frage: Was können wir jetzt wirklich damit machen? In diesem Moment fand ein entscheidendes Brainstorming statt. An einem realen oder virtuellen Tisch begannen wir, über das eigentliche Potenzial von OpenGate nachzudenken: eine Brücke zwischen Plattformen zu werden, ein Werkzeug für Interoperabilität zwischen unterschiedlichen Welten.
Es ging nicht mehr nur darum, Assets hochzuladen oder sie in Mixed Reality zu spawnen. Die Idee war viel ambitionierter: Nutzern die Freiheit zu geben, ihre Inhalte, Avatare und Daten mitzunehmen – von einem Metaverse zum nächsten, von einem Erlebnis zum anderen, bei gleichzeitiger narrativer und identitärer Kontinuität. NFTs, Ready Player Me-Avatare, KI-Assistenten, Cloud-Assets … alles sollte überall wiederverwendbar sein.
In diesem Moment begann sich OpenGate als echte Verbindungsinfrastruktur zu definieren. Nicht nur als Mixed-Reality-Builder, sondern als übergreifende Ebene und Schnittstelle. Eine Interoperabilitätsoberfläche, kompatibel mit XR, Gaming, Web3 und digitaler Kultur.
Das war ein Paradigmenwechsel. Aus einem operativen Werkzeug für Metagate entwickelte sich OpenGate zu einem eigenständigen Produkt mit einer klaren Mission: Kontinuität zwischen digitalen Ökosystemen schaffen, die heute noch in Silos existieren, zugleich aber Raum für Lösungen dieser Art lassen, deren Potenzial bislang niemand vollständig ausgeschöpft hat.
Kapitel 7 – Skalierbare Neustrukturierung und neue UI für die Headset-App
Nachdem die Vision von OpenGate als modulare, interoperable Infrastruktur klar war, wurde uns bewusst, dass die Schwachstelle gerade die Headset-App war. Sie hing noch an der alten Google-Sheets-Logik und war zu einer Ansammlung von Patches, schnellen Tests und spontan geschriebenem Code geworden. Sie funktionierte, war aber fragil, schwer wartbar und vor allem wenig skalierbar.
Also begann ein weiteres Brainstorming, diesmal mit dem Fokus darauf, die UI der XR-App aufzuräumen und neu aufzubauen. Die ursprünglich für schnelle Tests gedachte Oberfläche hatte im Laufe der Zeit unnötige Strukturen, nicht optimierte Schritte und Logiken angesammelt, die aus einer Phase stammten, in der jedes Element hardcodiert oder direkt aus Google Sheets gelesen wurde.
Wir wollten stattdessen eine UI für Endnutzer, nicht nur für Entwickler: flüssig, modular, konsistent und in Mixed Reality leicht navigierbar. Ziel war eine für mehrere Projekte wiederverwendbare Struktur, deren Komponenten sich an unterschiedliche Erlebnisse anpassen ließen – von Ausstellungen bis zu kollaborativen Spielen.
Parallel begannen wir, die Module logisch zu trennen: Assets, KI, Multiplayer, NFT, Cloud. Jeder Block sollte eigenständig funktionieren und zugleich mit den anderen kommunizieren. Das war der Beginn der eigentlichen Transformation von OpenGate zu einem flexiblen XR-System.
Kapitel 8 – Auswahl bei BeFuture und Unterstützung durch KNOBS
Mitten in dieser Neustrukturierung kam eine Nachricht, die einen Wendepunkt markierte: OpenGate wurde als eines der Gewinnerprojekte von BeFuture ausgewählt. Das Programm für Innovation und Experimentieren brachte uns zwei entscheidende Dinge: Glaubwürdigkeit und Ressourcen. Endlich konnten wir den Code systematisch ordnen und die Plattform sicherer, stabiler und produktionsreif machen.
Dank der erhaltenen Mittel – die in den folgenden Monaten verfügbar werden sollten – konnten wir die nächsten Schritte präzise planen, diesmal mit einer klaren Vision und einem gemeinsamen Aktionsplan. Insbesondere begannen wir den Austausch mit dem Team von KNOBS, um einen Weg für technisches Refactoring, bessere Compliance und die Absicherung der Webapp zu planen.
Das Ziel war ehrgeizig: das gesamte Backend bereinigen, den Code modularisieren, Sicherheitskontrollen integrieren, das Login stärken, APIs optimieren und die langfristige Robustheit des Systems gewährleisten. Zu diesem Zeitpunkt war davon jedoch noch nichts operativ: alles befand sich noch in Definition und Planung.
Parallel lief die Arbeit am sichtbarsten Teil weiter: der Headset-App, die im Sommer die ersten öffentlichen Releases aufnehmen sollte. Die eigentliche technische Arbeit mit Unterstützung von BeFuture sollte kurz darauf beginnen.
Kapitel 9 – Zwei Wege: neue UI in Entwicklung, alte UI für den Meta Store angepasst
In den Frühlingsmonaten entwickelte sich OpenGate auf zwei parallelen Wegen. Einerseits arbeitete Daniele an der neuen UI/UX der Headset-App: eine vollständige, klare und modulare Neugestaltung für eine flüssige und intuitive Interaktion der Endnutzer. Das Design wurde von Grund auf neu aufgebaut, mit besonderem Augenmerk auf verständliche Abläufe, Skalierbarkeit und visuelle Konsistenz.
Gleichzeitig entschieden wir uns, nicht auf die neue Oberfläche zu warten, bevor wir OpenGate mit der realen Welt konfrontierten. Paolo und Giada konzentrierten sich daher auf eine andere Priorität: die alte UI mit ihren aus der Google-Sheets-Phase stammenden Strukturen aufzuräumen und anzupassen, damit sie zumindest im Meta Store veröffentlicht werden konnte.
Das Ziel war pragmatisch: so früh wie möglich live gehen, selbst mit einer eingeschränkten Version, um den Submission-Prozess zu testen, mögliche technische oder bürokratische Hürden zu erkennen und die oft undurchsichtigen und komplexen Veröffentlichungsrichtlinien von Meta besser zu verstehen. Es war ein kontrollierter Realitätscheck, um künftige Probleme vorwegzunehmen und den Boden für spätere Versionen zu bereiten. Risiko reduzieren.
So machte OpenGate seinen ersten Sprung aus dem Labor: noch nicht perfekt, aber real.
„Wenn dir dein erstes Produkt nicht peinlich ist, hast du es zu spät veröffentlicht!“ – Zitat.
Kapitel 10 – Erstes kostenloses Release im Juni und Test beim ATLAS MEET
Im Juni war es Zeit für das erste öffentliche Release von OpenGate. Obwohl die UI noch eine provisorische Lösung war, gerade ausreichend angepasst, um die Meta-Store-Submission zu bestehen, entschieden wir uns, die erste Version kostenlos zu veröffentlichen. Ziel war noch nicht, Nutzer zu gewinnen, sondern die technische Belastbarkeit und das Verhalten der Plattform in einer realen Umgebung zu testen.
Die perfekte Gelegenheit war das ATLAS MEET, eine Veranstaltung des MEET Digital Culture Center in Mailand, zu der uns Maria Grazia Mattei zum zweiten Jahr in Folge einlud. Für das Event starteten wir eine Call for Artists, mit der Inhalte in kürzester Zeit auf das Headset geladen und in Mixed Reality angezeigt werden konnten.
Es war in jeder Hinsicht ein wichtiger Test: Die Cloud-Verwaltung funktionierte gut, das System blieb stabil und wir konnten tatsächlich Assets „spawnen“, ohne Code zu schreiben. Gleichzeitig sammelten wir direkt vor Ort Feedback: Was funktionierte, was nicht, was war unklar und wo konnte das Erlebnis verbessert werden?
Dieser erste öffentliche Einsatz war ein symbolischer Moment: OpenGate war kein internes Projekt und kein Prototyp mehr, sondern eine XR-Plattform, die bereit war, Menschen zu begegnen.
Kapitel 11 – Zweites Release im Juli und Test im Broletto di Novara
Im Juli erschien das zweite OpenGate-Release, diesmal mit einem wichtigen Fortschritt: der ersten Version der neuen UI, Ergebnis der Arbeit der vorangegangenen Monate. Sie war noch nicht endgültig, bot aber bereits ein flüssigeres, konsistenteres und moderneres Erlebnis als die Vorgängerversion, die lediglich für die Veröffentlichung im Store vorbereitet worden war.
Für den Test war die Einladung zum Broletto di Novara entscheidend, dank der Zusammenarbeit mit Andrea Barbara Romita und der Unterstützung von Marta Ballara. In einem künstlerischen und kulturellen Umfeld präsentierten wir OpenGate als No-Code-Werkzeug, um digitale Inhalte in Mixed Reality zu verwalten, mit einer interaktiven Demo für unterschiedliche Zielgruppen.
Die Erfahrung war äußerst wertvoll: Der neue Interaktionsfluss vereinfachte die Bedienung der App tatsächlich und machte sie auch für Personen zugänglicher, die noch nie ein XR-Headset verwendet hatten. Cloud-, Avatar- und KI-Funktionen begannen in einer einheitlichen Oberfläche zusammenzuwachsen.
Kapitel 12 – Drittes Release im August: Multiplayer, Szenen und persistente Welt
Das dritte OpenGate-Release, im August veröffentlicht, markiert einen echten Wendepunkt. Es ist die erste wirklich strukturierte und vollständige Version der Headset-App, mit einigen der meist erwarteten Funktionen: Multi-Szenen-System, synchronisierter Multiplayer und Persistenz von Objekten in der realen Welt.
Nutzer können nun zwischen verschiedenen Szenen navigieren, jeweils mit eigener Umgebung, eigenen Regeln, Inhalten und Layouts. Jede Szene lässt sich in Echtzeit verändern und vor allem wiederverwenden, wobei Konfigurationen in der Cloud gespeichert werden. Die große Neuerung ist jedoch, dass erstmals alles, was im Mixed Space platziert wird – Assets, Objekte, Elemente – gespeichert und synchronisiert bleibt, auch nach einem Neustart. So wird das Erlebnis persistent und gemeinsam.
Der Multiplayer ermöglicht mehreren Nutzern, sich in derselben Szene zu befinden und Objekte an derselben Position zu sehen. Damit öffnet sich der Weg für Zusammenarbeit, Spiele und interaktive Multi-User-Ausstellungen. Es ist der erste konkrete Schritt zu einem kollektiven XR-Raum.
Das Release ist erst seit wenigen Tagen live und wir befinden uns nun in einer Phase aktiver Beobachtung: Wir wollen verstehen, wie Menschen diese Werkzeuge nutzen, welche Inhalte sie erstellen und wohin uns diese neue Form augmentierter digitaler Präsenz führt.
Kapitel 13 – Backend-Sicherheit und Skalierbarkeit mit KNOBS
Nachdem das dritte Release endlich online war, musste ein entscheidender Punkt angegangen werden: die Absicherung des Backends. Bis dahin war der Code schrittweise und funktional geschrieben worden, häufig entlang kreativer Anforderungen und kontinuierlicher Tests. Obwohl die Struktur hielt, war klar, dass für Zuverlässigkeit und Skalierbarkeit ein gezielter technischer Eingriff notwendig war.
In dieser Phase wurde KNOBS operativ eingebunden. Die Aufgabe bestand in einer gezielten Korrektur des bestehenden Codes, um das bereits Funktionierende zu konsolidieren und gleichzeitig vor künftigen Problemen zu schützen.
Die Prioritäten waren klar: Schutz der API-Schlüssel, Verbesserung der Zugriffssicherheit, zentrale Verwaltung sensibler Variablen und vor allem die Vorbereitung einer robusteren Struktur, damit Updates sicher getestet und eine wachsende Zahl von Nutzern und Inhalten aufgenommen werden kann.
Abonniere unseren Newsletter und sichere dir alle Vorteile!
Videos unserer Erlebnisse findest du auf Instagram, YouTube und Twitter.
Unsere Links findest du auf Linktree oder kontaktiere uns!
Von Marco Pizzini