Eine Visual Novel kann hohe Anforderungen stellen, selbst wenn sich auf dem Bildschirm wenig bewegt. Große Charakterporträts, Hintergründe, Clips und Audio tragen alle zur Downloadzeit, zum belegten Speicherplatz, zur Dekodierung und zum Arbeitsspeicherbedarf bei. Echtzeitszenen verursachen zusätzlich Aufwand für Animation, Beleuchtung und Rendering. Auch eine statische Szene braucht ein Budget.
Gehe vom freigegebenen Erscheinungsbild und einem Budget für die Zielgeräte aus. Browseremulation kann Layoutprobleme aufdecken, doch die Leistung auf physischen Geräten muss auf physischen Geräten getestet werden. Halte für jede Aussage zur Leistung das Gerät, den Browser oder die Laufzeitumgebung, den Build und die Testbedingungen fest, damit sich das Ergebnis reproduzieren lässt.
Repräsentative Szenen und Geräte auswählen
Wähle eine ruhige Szene, eine Szene mit mehreren großen Ressourcen, eine Sequenz mit häufigen Übergängen sowie alle Video- oder Echtzeitabschnitte. Lege das schwächste unterstützte Gerät und ein verbreitetes Gerät fest. Berücksichtige den kleinsten Bildschirm, auf dem Spieler Text lesen und Entscheidungen treffen können müssen.
Miss einen Kaltstart, einen erneuten Start, Szenenübergänge und längere Interaktionen. Trenne den ersten Ressourcendownload von Durchläufen mit zwischengespeicherten Daten. Erfasse fehlende Texturen, langsame Dekodierung, Eingabeverzögerungen und Neuladevorgänge als eigenständige Fehler; eine durchschnittliche Bildrate kann diese Probleme verbergen.
Das Budget der ausgelieferten Ressourcen messen
Halte für jede ausgelieferte Ressource die Exportabmessungen, die Dateigröße und die Anzahl der Ressourcen fest, die sich gleichzeitig im Arbeitsspeicher befinden können. Die Downloadgröße sagt nicht aus, wie viel Arbeitsspeicher ein dekodiertes Bild belegt: Durch Komprimierung kann die Datei erheblich kleiner sein. Bewahre bearbeitbare Quelldateien getrennt von den Exportdateien auf, die an Spieler ausgeliefert werden.
Passe die Exportgröße daran an, wie die Ressource tatsächlich auf dem Bildschirm erscheint. Vergleiche mögliche Formate in der Ziellaufzeitumgebung, bevor du die gesamte Bibliothek konvertierst, und prüfe transparente Kanten, Farbverläufe, Text und Gesichter anhand der freigegebenen Grafiken. Eine kleinere Datei ist ein schwacher Trost, wenn die Komprimierung die Nahaufnahme eines Charakters ruiniert.
Video als eigene Last behandeln
Gib Video einen eigenen Eintrag im Budget. Erfasse Auflösung, Dauer, Kodierung, Bitrate, Audio und ob jeder Clip vorab geladen wird. Teste auf dem Zielgerät den Wiedergabestart, die Schleifenwiedergabe, das Pausieren und die Ausweichlösung. Die Wiedergabe in einem Desktopeditor belegt nicht, wie sich der Clip in einem Browser oder einem paketierten Mobil-Build verhält.
Lade die Varianten, die die Szene benötigt, statt alle Varianten auf einmal. Biete, soweit das Design es zulässt, ein Vorschaubild oder ein Standbild als Ausweichlösung an und gib dem Spieler Steuerelemente für die Wiedergabe. Miss den gesamten Übergang einschließlich der Dekodierung und aller gleichzeitig vorhandenen Grafiken; die Dateigröße des exportierten Clips deckt nur einen Teil der Last ab.
Die Interaktion reaktionsfähig halten
Sorge für lesbaren Text und ausreichend große Bedienelemente. Teste schnelle Navigation, Größen- oder Ausrichtungsänderungen, Einstellungsänderungen während der Wiedergabe und die Rückkehr aus dem Hintergrund. Prüfe während eines laufenden Vorgangs, dass jede Eingabe nur einmal angenommen wird und keine doppelten Aktionen auslöst.
Prüfe bei Browserspielen gegebenenfalls das Verhalten von Tastatur, Touch und Fokus. Selbst eine flüssige Szene wirkt fehlerhaft, wenn ein Overlay die nächste Auswahl verdeckt oder ein Übergang Eingaben unbemerkt blockiert. Betrachte sichtbare Rückmeldungen und erreichbare Bedienelemente als Teil der Reaktionsfähigkeit.
Optimierungskandidaten einzeln testen
Ändere jeweils nur eine relevante Ressource oder Renderingbedingung und vergleiche sie mit der Referenz. Halte neben der Leistungsmessung auch die visuelle Abnahme fest. Vergleiche bei 3D-Arbeiten Änderungen an LOD, Texturen und Beleuchtung in derselben Szene mit derselben Kamera.
Halte das Original für einen direkten Vergleich verfügbar. Ein geringerer ausgelieferter Datenumfang allein belegt noch keine Leistungsverbesserung. Komprimierung kann den Aufwand für Dekodierung oder Upload verändern, und Änderungen am Renderer können das Erscheinungsbild beeinflussen. Miss die Kennzahl, die mit dem Fehler zusammenhängt, den du beheben möchtest.
Das Releasebudget festlegen und durchsetzen
Nutze die Beobachtungen aus dem spielbaren Ausschnitt, um praktikable Grenzen für die ausgelieferte Größe, Übergangsverzögerungen, speicherbedingte Fehler und die Reaktionsfähigkeit der Steuerung auf den Zielgeräten festzulegen. Prüfe erneut, wenn ein neues Kapitel oder ein neuer Ressourcentyp die Last erhöht. Das Budget sollte widerspiegeln, was der Build und die Geräte bewältigen können.
Archiviere den Gerätebericht zusammen mit dem Buildkandidaten und kennzeichne ungetestete Geräte als ungeprüft. Akzeptiere eine Optimierung, wenn sie die freigegebene Darstellung erhält und das angestrebte Spielerlebnis unter reproduzierbaren Bedingungen verbessert.
Wichtige Entscheidungen
- Erfasse Downloadgröße, Arbeitsspeicherbedarf nach der Dekodierung und Renderingaufwand getrennt.
- Miss repräsentative Szenen auf physischen Zielgeräten.
- Vergleiche eine einzelne vorgeschlagene Änderung mit der freigegebenen Referenz.
- Nutze Emulation für Layoutprüfungen und Gerätetests für Aussagen zur Leistung.
Dateien zum Leitfaden
Ressourcenverzeichnis ↓Gerätetestmatrix ↓Externe Modell-Communitys und Veröffentlichungsseiten können explizite Inhalte enthalten. Links zu den Quellen öffnen sich in einem neuen Tab; dieser Leitfaden lädt deren Vorschauen nicht.
Quellen und weiterführende Lektüre +
Zuletzt geprüft 5. Oktober 2026.