Mit einer funktionierenden Spielschleife beginnen und den Fortschritt zuverlässig machen
Ein Idle-Spiel braucht mehr als einen Zähler, der steigt, während eine Seite geöffnet ist. Spielende erwarten, dass gekaufte Upgrades eine Aktualisierung überstehen, ein späterer Besuch sinnvollen Fortschritt gewährt und spätere Updates ihre Arbeit nicht löschen. Behandeln Sie Speichern, Offline-Abrechnung und Kompatibilität als getrennte Verhaltensweisen mit eigenen Prüfungen.
Dieser Workflow führt ein anschauliches Gewächshausdesign fort, kein bestehendes generiertes oder getestetes Projekt. Klicken bringt fiktive Münzen; jeder gekaufte Gärtner produziert eine Münze pro Sekunde. Der nächste Gärtner kostet ceil(10 × 1.15^n), wobei n die bereits vorhandene Anzahl ist. Beginnen Sie mit einer funktionierenden Spielschleife zum Verdienen und Kaufen. Sie definieren einen Speichervertrag, berechnen eine begrenzte Rückkehrbelohnung und bewahren den Fortschritt bei einer späteren Änderung, ohne lokalen Speicher mit Cloud-Speicherung zu verwechseln.
Festlegen, was sich das Spiel merken muss
Schreiben Sie den Speichervertrag, bevor Sie Code anfordern. Eine minimale Version enthält eine Schemaversion, den aktuellen Münzstand, die Gärtnerzahl, gekaufte Upgrades und den Zeitpunkt, bis zu dem Erträge bereits abgerechnet wurden. Bewahren Sie Regeln zur Produktionsrate zusammen mit den Upgrade-Definitionen auf. Speichern Sie die Käufe, die dem angezeigten Guthaben zugrunde liegen, statt widersprüchlicher Kopien abgeleiteter Zustände.
Bitten Sie während der Entwicklung um eine lesbare Speicherzusammenfassung, damit Sie Spielzustand und gespeicherten Zustand vergleichen können. Vermeiden Sie private Informationen in Diagnoseausgaben. Unterscheiden Sie außerdem einen lokalen Speicherstand von einem kontobasierten. Browserspeicher gehört zu einem Browserprofil und kann gelöscht werden. Er verspricht weder geräteübergreifenden Fortschritt noch sichere Wettbewerbswerte oder eine Wiederherstellung, nachdem Spielende Websitedaten löschen.
Verwenden Sie diese begrenzte Anfrage:
Füge einen versionierten lokalen Speicherstand für Münzen, Gärtner, gekaufte Upgrades und den letzten Abrechnungszeitpunkt hinzu. Stelle den Zustand wieder her, bevor ein spielbarer Bildschirm angezeigt wird. Validiere geladene Werte. Falls kein Speicherstand existiert, beginne ein neues Spiel. Ist ein Speicherstand ungültig, erkläre das Wiederherstellungsverhalten, statt stillschweigend unmögliche Guthaben zu erzeugen. Halte vorhandene Grafiken und Verdienstregeln unverändert.
Speichern Sie nach bedeutsamen Käufen und legen Sie periodisches Speichern fest, falls das Spiel es benötigt. Verlassen Sie sich nicht ausschließlich auf ein Seiten-Schließen-Ereignis: Ein Browser oder Gerät kann stoppen, ohne das erwartete letzte Ereignis zu liefern.
Abwesenheitsbelohnungen einmalig und mit klarer Obergrenze berechnen
Offline-Fortschritt bedeutet gewöhnlich, bei der Rückkehr eine Belohnung zu berechnen. Das Spielskript muss dafür nach dem Schließen des Browsers nicht dauerhaft laufen. Eine transparente Regel lautet:
Belohnung = anrechenbare gespeicherte Produktionsrate × min(max(Rückkehrzeit − letzter Abrechnungszeitpunkt, 0), acht Stunden)
Legen Sie vor der Umsetzung fest, was die anrechenbare Rate bedeutet. In diesem einfachen Design ist es die Produktionsrate der beim Verlassen gespeicherten Gärtner und Upgrades. Verschieben Sie komplexe Simulationen, bis die grundlegende Abrechnung funktioniert.
Zur Prüfung des Erwartungswerts würden zwei Gärtner mit jeweils einer Münze pro Sekunde in einem kontrollierten Intervall von zehn Minuten 1.200 Münzen verdienen. Bei zehn Stunden Abwesenheit würden mit der Beispielobergrenze nur acht Stunden berücksichtigt. Verwenden Sie die Berechnung als Erwartungswert im Durchlaufprotokoll.
Nach der Gutschrift muss das Spiel den Abrechnungszustand aktualisieren, damit eine Aktualisierung dieselbe Abwesenheit nicht erneut belohnt. Fordern Sie eine Rückkehrmeldung an, die berücksichtigte Dauer und gewährte Belohnung zeigt. Beschreiben Sie die berechnete Gutschrift, ohne einen dauerhaft laufenden Server zu suggerieren.
Rechenbeispiele: Offline-Belohnungen
Diese Beispiele setzen eine feste Produktionsrate, fiktive Münzen und dort, wo angegeben, eine Obergrenze von zwei Stunden voraus. Sie beschreiben erwartete Berechnungen, keine gemessenen Ergebnisse eines getesteten Spiels.
| Szenario | Berechnung | Erwartete Gutschrift |
|---|---|---|
| 1 Gärtner, 10 Minuten abwesend | 1 Münze/Sekunde × 600 Sekunden | 600 fiktive Münzen |
| 2 Gärtner, 30 Minuten abwesend | 2 Münzen/Sekunde × 1.800 Sekunden | 3.600 fiktive Münzen |
| 1 Gärtner, 3 Stunden abwesend, 2-Stunden-Grenze | 1 Münze/Sekunde × min(10.800, 7.200) Sekunden | 7.200 fiktive Münzen |
| Direkt nach der Abrechnung neu laden | Das bereits abgerechnete Intervall wird nicht erneut gezählt. | 0 zusätzliche Münzen für dieses Intervall |
Speichern getrennt von der Zeitabrechnung testen
Verdienen Sie zunächst ein bekanntes Guthaben, kaufen Sie einen Gärtner und aktualisieren Sie die Seite. Bestätigen Sie, dass Guthaben und Kauf erhalten bleiben. Schließen Sie anschließend den Browser, warten Sie ein gemessenes Intervall und kehren Sie zurück. Notieren Sie Anfangszustand, tatsächlich verstrichene Zeit, beobachtete Gutschrift und Endzustand. Aktualisieren Sie sofort und prüfen Sie, dass dieselbe Belohnung nicht erneut vergeben wird.
Verwenden Sie für lange Intervalle eine kontrollierte Testuhr und für den normalen Ablauf eine echte Prüfung durch Schließen und Rückkehr. Testen Sie eine negative verstrichene Zeit, ein unplausibel großes Intervall, einen leeren und einen beschädigten Speicherstand. Legen Sie jeweils das erwartete Verhalten fest, bevor Sie das Ergebnis betrachten. Ein negatives Intervall sollte verdiente Währung nicht abziehen. Ein großes Intervall sollte die Obergrenze nicht umgehen.
Spielende können die lokale Gerätezeit ändern. Das Begrenzen der verstrichenen Zeit hilft, offensichtliche Fehler zu vermeiden; es macht eine lokale Ökonomie aber nicht manipulationssicher. Wettbewerbs- oder Zahlungsökonomien benötigen ein separates Design für maßgebliche Abrechnung und Sicherheit.
Testmatrix für den Rückkehrbesuch
| Aktion | Erwartetes Verhalten | Wenn die Prüfung fehlschlägt |
|---|---|---|
| Upgrade kaufen und dann aktualisieren | Gespeichertes Guthaben und gekauftes Upgrade werden gemeinsam wiederhergestellt. | Untersuchen, welche Felder wann gespeichert wurden. |
| Nach einem gemessenen Intervall zurückkehren | Die Gutschrift folgt dokumentierter Rate und Zeitobergrenze. | Gespeicherten Abrechnungszeitpunkt, Rate und verstrichene Zeit vergleichen. |
| Direkt nach der Rückkehrgutschrift neu laden | Dasselbe Intervall wird nicht doppelt vergütet. | Prüfen, ob der Abrechnungszeitpunkt mit der Gutschrift fortgeschrieben wird. |
| Anderen Browser oder anderes Gerät öffnen | Das Verhalten entspricht dem angegebenen lokalen oder kontobasierten Speichermodell. | Prüfen, ob ein geräteübergreifender Synchronisationsmechanismus existiert. |
| Nach einer Regeländerung einen älteren Speicherstand laden | Käufe und Guthaben folgen der dokumentierten Migration. | Speicherversion und Migrations- oder Wiederherstellungsweg untersuchen. |
Ein späteres Upgrade vornehmen, ohne Spielende zurückzusetzen
Wenn das Speichern funktioniert, fordern Sie eine kleine Inhaltsänderung an:
Ändere den Grundpreis des Gärtners für zukünftige Käufe von zehn auf acht Münzen und behalte den Wachstumsfaktor 1.15 bei. Bewahre vorhandene Münzen, Gärtner, besessene Upgrades, Grafik und Offline-Abrechnung. Unterstütze die aktuelle Version der gespeicherten Daten. Zeige, wie ein älterer Speicherstand migriert wird, falls der neue Zustand zusätzliche Felder benötigt.
Bewahren Sie vor dieser Anfrage einen echten Speicherstand von vor der Änderung und einen funktionierenden Build auf. Laden Sie den Speicherstand in die überarbeitete Version und vergleichen Sie resultierendes Guthaben, Käufe und Produktionsrate. Das Hinzufügen eines Feldes sollte nicht dazu führen, dass der gesamte Zustand verworfen wird, nur weil der alte Speicherstand es nicht enthält. Entscheiden Sie vor der Änderung der Ökonomie, ob frühere Käufe ihre Vorteile behalten.
Verschwinden Upgrades, prüfen Sie Migration und Laden, bevor Sie Funktionen hinzufügen. Eine neue Schaltfläche belegt keine Speicherkompatibilität.
SEELE für begrenzte Persistenzänderungen verwenden
SEELE bietet einen promptgesteuerten Workflow zum Erstellen von Spielen und Anfordern späterer Änderungen. Die relevante Eingabe ist hier die funktionierende Ökonomie samt einem bestimmten Speichervertrag; das gewünschte Ergebnis ist ein Änderungskandidat, dessen Lade- und Abrechnungsverhalten Sie prüfen können. Fordern Sie die kleinstmögliche Persistenzänderung an, bevor Sie Migration oder neue Upgrades verlangen.
Bewahren Sie einen funktionierenden Build und einen Referenzspeicherstand außerhalb der zu bewertenden Änderung auf. Melden Sie bei einer fehlgeschlagenen Prüfung genaue Zustandsunterschiede, einschließlich der Frage, ob das Problem beim Laden, bei der Rückkehr oder beim Kauf auftrat. Die Produktpositionierung allein belegt weder Cloud-Speicherstände noch sichere Uhren, Migrationsgarantien oder die Zuverlässigkeit einer bestimmten lokalen Speicherimplementierung.
Erst fortfahren, wenn der Rückkehrbesuch nachvollziehbar ist
Ein zuverlässiges Idle-Spiel sollte erklären, woher seine Zahlen kommen: wodurch die Belohnung entstand, welches Abwesenheitsintervall gezählt wurde und welche Käufe erhalten bleiben. Nutzen Sie KI-Unterstützung für begrenzte Änderungen an diesen Regeln und beurteilen Sie jede Änderung im laufenden Spiel. Tauschen Sie keinen funktionierenden Speicherstand gegen eine längere Funktionsliste ein.
Nutzen Sie SEELE, um in Ihrem bestehenden Projekt einen lokalen Speicherstand und eine begrenzte Rückkehrbelohnung anzufordern. Bewahren Sie eine nachweislich funktionierende Version auf, bevor Sie eine weitere Änderung der Ökonomie anfordern. Der nächste Meilenstein ist kein größeres Versprechen, sondern ein überprüfter Rückkehrbesuch, bei dem der frühere Fortschritt erhalten bleibt.
FAQ
Bedeutet Offline-Fortschritt, dass das Spiel bei geschlossenem Browser läuft?
Nicht unbedingt. Ein gängiger Ansatz speichert Zustand und Abrechnungszeitpunkt und berechnet die Belohnung beim nächsten Besuch. So kann ein Offline-Belohnungsdesign ohne dauerhaft laufenden Browserprozess funktionieren. Prüfen Sie die tatsächliche Implementierung, bevor Sie sie beschreiben. Serverseitige Simulation ist eine andere Architektur und sollte durch eine lokal berechnete Belohnung nicht suggeriert werden.
Wird ein Browser-Speicherstand auf ein anderes Gerät übertragen?
Gehen Sie nicht davon aus. Lokaler Browserspeicher bleibt normalerweise an das Browserprofil und den Websitedatenspeicher gebunden. Geräteübergreifende Speicherstände benötigen eine ausdrückliche Synchronisation oder ein Kontosystem sowie Entscheidungen zur Konfliktbehandlung und zum Datenschutz. Sagen Sie Lesenden, was die getestete Demo tatsächlich verwendet, statt ein lokales Persistenzbeispiel als Cloud-Speicherfunktion darzustellen.
Kann ich Upgrade-Preise ändern, nachdem bereits gespielt wurde?
Ja, wenn das überarbeitete Design festlegt, wie vorhandene Käufe und gespeicherte Zustände behandelt werden. Bewahren Sie einen Referenzspeicherstand auf, entscheiden Sie, welche Vorteile erhalten bleiben, und testen Sie die Migration vor Veröffentlichung der Änderung. Das bloße Überschreiben der Preisliste beweist nicht, dass alter Fortschritt gültig bleibt. Ist das Verhalten noch ungetestet, beschreiben Sie es als Anforderung und nicht als erfolgreiches Update.
