Browser management game to gra menedżerska uruchamiana w przeglądarce. W tym formacie wygodnie połączyć krótką wizytę z dłuższym planem: gracz podejmuje decyzję, zostawia sprawy w toku i wraca po wynik. Powodzenie takiej gry zależy jednak od zasad czasu, zapisu oraz informacji zwrotnej, nie od samego faktu, że otwiera się w karcie.
Kilka minut na decyzję, czytelny powrót po wynik
Własny przykład projektu gry: gracz prowadzi zakład, przyjmuje zamówienie i wybiera, czy zwiększyć produkcję. Po powrocie widzi wynik, obciążenie maszyn i przyczynę ewentualnego opóźnienia. Nie musi przeglądać wszystkich zakładek, żeby ustalić, co zmieniło się podczas jego nieobecności.
Dobry ekran powrotu może pokazać trzy rzeczy: wydarzenia od ostatniej wizyty, sprawy wymagające decyzji i najbliższy termin. Szczegółowy raport powinien pozostawać dostępny, ale nie wypierać informacji, która pozwala wykonać następny ruch.
Świat gry i zegar karty to dwa różne mechanizmy
W projekcie asynchronicznym serwer może przechowywać stan i ustalać zakończenie operacji niezależnie od otwartej karty. Przeglądarka wyświetla wtedy wynik i wysyła polecenia. Inna gra może działać całkowicie lokalnie, a jeszcze inna zatrzymywać upływ czasu po wyjściu. Te zasady trzeba opisać graczowi.
MDN wskazuje, że przeglądarki ograniczają wykonywanie timerów w kartach działających w tle. Odliczanie na ekranie nie powinno więc samo rozstrzygać, czy w grze sieciowej zakończono produkcję. W zaproponowanym przykładzie zlecenie ma zapisany moment zakończenia, a po ponownym wejściu gracz otrzymuje aktualny stan.
Sprawdź także scenariusz dwóch otwartych kart. Ponowne wysłanie tego samego polecenia nie powinno kupować maszyny dwa razy tylko dlatego, że gracz nie zobaczył pierwszego potwierdzenia.
Zapis lokalny nie oznacza automatycznej kopii konta
Przechowywanie danych w przeglądarce może pomóc w grze lokalnej lub działaniu bez sieci. MDN rozróżnia przechowywanie trwałe i domyślne best-effort oraz wskazuje różnice limitów i usuwania danych między przeglądarkami. Użytkownik może też sam wyczyścić dane strony.
Jeśli postęp istnieje wyłącznie na danym urządzeniu, trzeba to jasno pokazać i przewidzieć sposób zachowania kopii. Jeżeli zapis jest związany z kontem, sprawdź powrót na drugim urządzeniu oraz to, jak gra informuje o nieudanej synchronizacji. Widok działający offline nie dowodzi, że serwer zaakceptował nową decyzję.
Przeglądarka nie zwalnia z pracy nad interfejsem
Tabela jest przydatna do porównania maszyn lub zespołów, ale na telefonie potrzebne mogą być krótsze zestawienia i osobne szczegóły. Obok wartości pokaż jednostkę, okres oraz znaczenie zmiany. „Koszt 120” bez waluty i informacji, czy jest jednorazowy, nie pozwala uczciwie ocenić ruchu.
Warto też potwierdzać przyjęcie polecenia, odróżniając je od zakończenia operacji. Gracz powinien wiedzieć, czy czeka na wynik symulacji, czy na odpowiedź połączenia.
Aktualizacja i test sesji
Nowe pliki na serwerze nie gwarantują natychmiastowej zmiany wszystkich otwartych sesji. MDN opisuje m.in. oczekiwanie nowego service workera, gdy wcześniejsza wersja nadal obsługuje strony. W takim rozwiązaniu aktualizację i zgodność zapisu trzeba zaplanować.
Przetestuj powrót po zamknięciu karty, utratę sieci podczas polecenia, drugą kartę, drugi ekran i zmianę wersji gry. Przeglądarkowy format sprawdza się wtedy, gdy te sytuacje nie odbierają graczowi informacji o własnych decyzjach i postępie.
