Zdecyduj, co gracz ma odzyskać
Postęp może oznaczać ukończone poziomy, wynik pojedynczej próby, ustawienia dźwięku albo dokładne miejsce przerwanej rozgrywki. Te dane nie muszą być zapisywane tak samo. Najpierw określ oczekiwanie: czy użytkownik wraca do początku poziomu, czy kontynuuje w ostatnim bezpiecznym punkcie? Brak jawnej zasady jest częstym źródłem rozczarowania nawet wtedy, gdy zapis technicznie działa.
W prostej grze logicznej można utrwalać ukończone plansze po każdej wygranej. W grze z długim poziomem potrzebne mogą być punkty kontrolne. Nie zapisuj każdej animacji tylko dlatego, że da się ją opisać. Wybierz minimalny stan wystarczający do odtworzenia rozgrywki zgodnie z zasadami. Krótszy, jednoznaczny model łatwiej sprawdzić i rozwijać.
Zapis lokalny upraszcza start, lecz ma granice
Dane na urządzeniu pozwalają rozpocząć grę bez zakładania konta. Trzeba jednak wyjaśnić, że nie pojawią się automatycznie w innej przeglądarce. IndexedDB oferuje mechanizmy przechowywania ustrukturyzowanych danych i transakcji, które można wykorzystać do zapisu większego stanu. Wybór takiego magazynu nie zwalnia z obsługi nieudanej operacji.
Gracz powinien zobaczyć komunikat, gdy zapis się nie powiódł. Nie pokazuj symbolu sukcesu wyłącznie po kliknięciu przycisku. Zapis może zależeć od dostępnego miejsca i ustawień środowiska; dane przeglądarki mogą też zostać usunięte. Dokumentacja opisuje limity i zasady ich utrzymywania, dlatego lokalny stan nie powinien być przedstawiany jako bezwarunkowo trwały.
Konto umożliwia przenoszenie, ale dodaje odpowiedzialność
Zapis serwerowy pozwala powiązać postęp z kontem i odczytać go na innym urządzeniu. Potrzebne są jednak uwierzytelnianie, kontrola dostępu i reguły utrzymania danych. Serwer musi sprawdzać, czy osoba rzeczywiście może modyfikować wskazany zapis. Sam numer użytkownika przesłany przez przeglądarkę nie stanowi dowodu uprawnienia.
Oddziel zwykły postęp od wartości mających wpływ na wspólną rywalizację lub rozliczenia. Zapisanie lokalnie ukończonej planszy i przyznanie punktów w publicznym rankingu to różne operacje. Dane przesłane przez urządzenie mogą wymagać dodatkowej weryfikacji. Nie traktuj konta jako mechanizmu, który automatycznie potwierdza prawdziwość każdej liczby otrzymanej od klienta gry.
Przygotuj wersję formatu zapisu
Wraz z rozwojem gry zmieniają się poziomy i reguły. Zapis powinien zawierać wersję struktury, aby program wiedział, jak go odczytać. Jeżeli dawny identyfikator planszy przestaje istnieć, zaplanuj mapowanie albo czytelny komunikat. Nie resetuj całej historii tylko dlatego, że dodano jedno pole. Migrację sprawdź na zachowanych przykładach z poprzedniego wydania.
MyTworzymy.pl realizuje projekty cyfrowe w całej Polsce, także gry dostępne przez przeglądarkę. Warto uwzględnić trwałość postępu już przy rozmowie o pierwszej wersji. Pozwala to dopasować zakres do celu: inaczej projektuje się krótką grę promocyjną, a inaczej kurs z zadaniami, do którego użytkownicy mają wracać przez kolejne tygodnie.
Ustal zachowanie przy dwóch urządzeniach
Ten sam użytkownik może uruchomić grę na telefonie i komputerze. Jeżeli oba urządzenia zapiszą stan, prosta zasada „ostatni zapis wygrywa” może usunąć świeżo ukończony poziom. Porównuj wersje i rozdziel elementy możliwe do połączenia od tych, które wymagają wyboru. Zbiór ukończonych plansz bywa łatwiejszy do scalenia niż bieżąca pozycja w jednej próbie.
Komunikat konfliktu powinien pokazywać zrozumiałe informacje, na przykład moment zapisu i osiągnięty etap. Nie wymagaj od gracza wyboru między dwoma technicznymi identyfikatorami. Przed nadpisaniem zachowaj możliwość odzyskania wcześniejszego wariantu, jeśli model gry na to pozwala. Jasna decyzja jest lepsza od cichego cofnięcia postępu po odzyskaniu sieci.
Punkt zapisu powinien być kompletny
Nie zapisuj oddzielnie numeru poziomu i ekwipunku w sposób, który po przerwaniu operacji pozostawia sprzeczny zestaw. Utrwalaj logicznie spójny stan i dopiero po potwierdzeniu uznaj checkpoint za zakończony. Przy synchronizacji przydatne jest rozpoznanie ponowienia tej samej operacji. Po utracie odpowiedzi gracz nie powinien otrzymać podwójnej nagrody tylko dlatego, że program spróbował jeszcze raz.
Przy planowaniu gry z MyTworzymy.pl warto poprosić o pokazanie nie tylko poprawnego zapisu, lecz również zachowania po przerwaniu sieci i po aktualizacji. Takie scenariusze pomagają ustalić realny zakres odpowiedzialności programu. Dla zleceniodawcy ważniejsze jest odzyskanie konkretnego etapu przez gracza niż obecność ogólnego hasła „zapis w chmurze” w opisie projektu.
Testuj odzyskanie, nie sam przycisk
Ukończ etap, zamknij kartę, otwórz ponownie i sprawdź wynik. Powtórz próbę w trakcie zapisu, przy braku miejsca i po wygaśnięciu sesji. Zmień konto na tym samym urządzeniu. Lokalny szkic jednej osoby nie może bez pytania trafić do zapisu innego użytkownika. Odbiór funkcji powinien obejmować również usuwanie danych i rozpoczęcie gry od nowa.
Udokumentuj, które informacje są przechowywane lokalnie, które na serwerze i jak wygląda przeniesienie gry gościa na konto. Nie obiecuj odzyskania danych, których nigdy nie zsynchronizowano. Dobrze zaprojektowany zapis daje graczowi przewidywalność: wie, co zostało zachowane i co może stracić. To część zasad gry, a nie niewidoczny dodatek techniczny.