Ein Game-Backend zu entwickeln klingt zunächst nach einer Liste technischer Funktionen: Anmeldung, Cloud Save, Leaderboards, Remote Config und Crash Reporting. Diese Funktionen sind wichtig. Ein nutzbares Backend-as-a-Service entsteht aber erst, wenn API, Dashboard, SDKs, Dokumentation, Preislogik und Betrieb zusammenpassen.
Genau diese Erfahrung machen wir mit horizOn. Die Plattform richtet sich an kleinere Studios, Indie-Entwickler und Teams, die Backendfunktionen nutzen möchten, ohne dafür eine eigene Serverplattform aufzubauen.
horizOn ist für uns nicht nur ein Game-Projekt. Es ist ein umfangreiches SaaS-Produkt, an dem sich viele allgemeine Lektionen über Softwareentwicklung und Live-Betrieb zeigen.
1. Die API ist nur ein Teil der Nutzererfahrung
Ein technisch sauberer Endpunkt hilft wenig, wenn ein Entwickler nicht weiß, welchen Schlüssel er benötigt, wie er ein Projekt anlegt oder wo ein Fehler sichtbar wird.
Deshalb besteht horizOn aus mehreren verbundenen Oberflächen:
- einem Dashboard für Projekte, API-Schlüssel und Live-Ops-Funktionen,
- einem Backend mit getrennten Admin-, App- und öffentlichen APIs,
- SDKs für Unity, Godot und Unreal,
- einer REST-Anbindung für weitere Sprachen und Engines,
- Quickstarts, Beispielen und Videoanleitungen,
- Monitoring, Support und Änderungsprotokollen.
Der horizOn Quickstart beginnt deshalb nicht mit einer vollständigen API-Referenz. Er führt durch den kleinsten erfolgreichen Ablauf: Konto anlegen, Projekt erstellen, Konfiguration herunterladen, SDK installieren und verbinden.
2. Ein SDK ist Produktcode, keine Nebenaufgabe
Für den Betreiber wirkt ein HTTP-Endpunkt eindeutig. Für einen Spieleentwickler zählt, wie gut sich derselbe Ablauf in der eigenen Engine anfühlt.
Unity, Godot und Unreal haben unterschiedliche Paketmodelle, Lebenszyklen und Konventionen. Ein gutes SDK versteckt nicht jede technische Tatsache, aber es übersetzt sie in die Sprache des jeweiligen Werkzeugs.
Daraus folgt zusätzliche Produktarbeit:
- Installationen müssen reproduzierbar sein.
- Konfiguration darf nicht aus verstreuten Geheimnissen bestehen.
- Fehlermeldungen müssen im Editor verständlich sein.
- Beispiele müssen zum aktuellen SDK passen.
- Eine Änderung am Backend darf veröffentlichte Spiele nicht unerwartet brechen.
Deshalb werden die SDKs mit Beispielprojekten, Quickstarts und klaren Kompatibilitätsgrenzen entwickelt.
3. Live-Ops-Funktionen brauchen ein gemeinsames Modell
Cloud Saves, Leaderboards und Remote Config sind keine isolierten Schalter. Sie arbeiten mit denselben Projekten, Nutzern, API-Schlüsseln und Berechtigungen.
Wenn jede Funktion ihr eigenes Modell erfindet, wird die Plattform für Entwickler unvorhersehbar. Wir haben deshalb getrennte Zugriffsbereiche:
- Dashboard-Nutzer verwalten Projekte und Einstellungen über die Admin-API.
- Spiele und Apps greifen mit Projekt-API-Schlüsseln auf die App-API zu.
- Öffentliche Abläufe bleiben bewusst begrenzt.
Diese Trennung macht nicht jede Funktion einfacher. Sie verhindert aber, dass ein Schlüssel aus einer Anwendung plötzlich Verwaltungsrechte besitzt.
4. Preislogik ist eine Architekturentscheidung
horizOn setzt auf feste, transparente Pakete statt einer Rechnung pro API-Aufruf. Das ist eine Produktpositionierung, beeinflusst aber auch die Technik.
Feste Preise funktionieren nur, wenn Kapazitäten, Limits und Betriebskosten verständlich modelliert werden. Die Plattform muss wissen, welche Ressourcen zu einem Paket gehören, ohne Entwickler mit einer langen Liste kleiner Einzelpreise zu belasten.
Wir wollten vermeiden, dass ein erfolgreicher Launch automatisch zu einer kaum kalkulierbaren Rechnung führt. Gleichzeitig benennen wir offen, dass feste Kapazität nicht dasselbe ist wie unbegrenztes dynamisches Skalieren.
Diese Ehrlichkeit ist Teil des Produkts. Eine Preisvorteilsaussage ohne technische Grenze wäre nur Werbung.
5. Betrieb in mehreren Regionen vervielfacht Verantwortung
Niedrige Latenz in verschiedenen Teilen der Welt klingt nach einer Infrastrukturfrage. In der Praxis betrifft sie fast jeden Betriebsprozess:
- Deployments müssen kontrolliert ablaufen.
- Datenbanken benötigen Backups und Wiederherstellungstests.
- Monitoring muss Unterschiede zwischen Regionen sichtbar machen.
- Zertifikate, DNS und Netzwerkregeln dürfen nicht nur auf einem Server funktionieren.
- Fehler brauchen genug Kontext, um eine betroffene Region einzugrenzen.
Der öffentliche horizOn Status zeigt den Betriebszustand. Dahinter liegt laufende Arbeit an Cluster, Datenbank, Backups, Alarmierung und Releaseprozessen.
Ein SaaS-Produkt ist nicht fertig, sobald die Anwendung lokal funktioniert. Es wird erst durch wiederholbare Betriebsabläufe belastbar.
6. Eigene Produkte sind der härteste Integrationstest
ProjectMakers nutzt horizOn selbst, unter anderem für Authentifizierung und Cloud-Speicherung in BodySeasons. Dadurch begegnen uns dieselben Fragen wie externen Teams: Wie schnell ist eine Integration möglich? Welche Fehlermeldung hilft wirklich? Was passiert bei einer unterbrochenen Verbindung?
Diese Nutzung ist wertvoll, weil sie Probleme sichtbar macht, die in einem isolierten Demo-Projekt nicht auftreten. Gleichzeitig ersetzt sie nicht das Feedback anderer Entwickler. Deshalb gehören Quickstarts, Supportfragen und echte Integrationen in denselben Verbesserungsprozess.
7. Ein offener Ausstieg reduziert Lock-in
Ein Backend ist eine langfristige Abhängigkeit. Entwickler müssen wissen, was passiert, wenn Anforderungen wachsen oder ein Anbieter nicht mehr passt.
Neben der verwalteten Plattform gibt es deshalb den horizOn Simple Server auf GitHub. Die bewusst kleine PHP-Variante ist mit den SDK-Grundfunktionen kompatibel und kann selbst betrieben werden.
Sie ersetzt nicht alle Funktionen des verwalteten Produkts. Sie schafft aber einen nachvollziehbaren Einstieg und einen Weg, zentrale Abläufe selbst zu kontrollieren.
Was wir aus horizOn in andere SaaS-Projekte übertragen
Die wichtigsten Lektionen haben wenig mit einem bestimmten Game-Engine-Logo zu tun:
- Der erste erfolgreiche Ablauf ist wichtiger als die vollständige Funktionsliste.
- Integrationen und SDKs gehören zur Nutzererfahrung.
- Preisversprechen brauchen technische Grenzen.
- Monitoring, Backup und Support sind Produktfunktionen.
- Ein glaubwürdiger Ausstieg stärkt Vertrauen.
Auf horizOn.pm sind Plattform, Funktionen, Preise, Quickstart und Grenzen öffentlich beschrieben. In unserem Portfolio zeigen wir zusätzlich, welche Rolle ProjectMakers bei Produkt, SDKs und Betrieb übernimmt.
Wenn Sie eine Plattform, API oder ein SaaS-Produkt planen, können wir gemeinsam den ersten nutzbaren Ablauf und die Betriebsgrenzen definieren. Sprechen Sie mit uns über Ihr Produkt.
