Rolling Dices: od asystenta RPG do virtual tabletop w czasie rzeczywistym.

Grupa RPG śledzi karty postaci, kości, zasady, ekwipunek, rany, notatki i pozycję. Większość virtual tabletopów zaczynała od mapy. My pytaliśmy, co aplikacja może przejąć, nie odbierając kontroli graczom ani prowadzącemu.

Zaczęliśmy od telefonu wspierającego grę przy fizycznym stole, ale ta sama sesja musiała działać zdalnie. Powstało jedno założenie: responsywna aplikacja użyteczna zarówno obok stołu, jak i zamiast niego.

Pierwsze wydanie organizowało konta, postacie i zaproszenia, ale ledwie dotykało gry. Testy ujawniły ważniejsze pytania: co widzi każda rola, kto rozpoczyna akcję i które elementy sesji muszą być trwałe?

Wspólna sesja zastąpiła konto w centrum produktu. Jej dziennik połączył rozmowę, rzuty, zdarzenia i zmiany stanu; każda wydana pętla ujawniała kolejną odpowiedzialność — od kontekstu postaci po zasoby i wspólną przestrzeń.

Jedno nie przesunęło się nigdy: fikcja i prawo prowadzącego do rozstrzygania o niej. Każdy szczebel zdejmował ze stołu księgowość — nigdy decyzję należącą do ludzi wokół niego.

Więcej zasad usuwało więcej księgowości, ale odbierało produktowi uniwersalność. Odpowiedzią był konfigurowalny system motywów — najambitniejszy zakład projektu.

Rzut wywołany mieści naraz pomysł produktowy i architekturę. Prowadzący wybierał gracza, atrybut i trudność; silnik wyliczał kości i utrwalał oczekującą akcję; gracz rzucał, a zdrowie, energia i wyposażenie kształtowały wynik, który trafiał do wspólnego dziennika. Kości pozostawały widocznym momentem rozstrzygnięcia, ale aplikacja rozumiała dość kontekstu, by ocenić akcję i zachować jej konsekwencje.

Na telefonie Rolling Dices działało jak pas z narzędziami: jeden skupiony kontekst naraz, więc telefon wspierał grę przy fizycznym stole, zamiast z nią konkurować. Nasze pierwsze założenie było odwrotne — wczesna wersja blokowała małe ekrany. Potem telefon stał się wymogiem podstawowym, łącznie z dotykowym drag-and-dropem na planszy walki.

Desktop przestał być większym telefonem i stał się przestrzenią pracy: drużyna, dziennik sesji, kości, eksploracja i plansza widoczne razem, a rzadsze operacje otwierane jako zadania modalne. Model domeny nie zmieniał się nigdy; zmieniała się tylko kompozycja.

Rolling Dices było aplikacją SPA w React i TypeScript połączoną bezpośrednio z Supabase. Redux trzymał tożsamość i nawigację, React Query — projekcje serwerowe, a interakcje o wysokiej częstotliwości — kości, przeciąganie, zaznaczenia — zostawały lokalne aż do zapisu. Osobna warstwa engine liczyła kości, statystyki pochodne, XP, energię i inicjatywę. Supabase zastąpiło naraz serwer aplikacji, uwierzytelnianie i websockety: wyjątkowo lekka architektura multiplayer jak na trzech inżynierów, z których tylko jeden pracował w pełnym wymiarze.

Model spójności brzmiał: zdarzenie, invalidacja, ponowne pobranie. Przeglądarka zapisywała zmianę w Postgresie, Supabase emitowało zdarzenie, pozostałe klienty unieważniały projekcję i pobierały świeży stan. Realtime nie był dodatkiem — był modelem spójności. Postgres pełnił też rolę backend-for-frontend, składając funkcjami SQL projekcje gotowe dla UI, podczas gdy zapisy nadal trafiały do kilku tabel wprost z przeglądarki.

Na początku 2024 roku Rolling Dices miało pełny zarys przeglądarkowego VTT — postacie, wspólne sesje, kontekstowe rzuty, trwały dziennik, ekwipunek, zdrowie, zasoby drużyny, eksplorację, planszę walki z inicjatywą, terenem i widzeniem. Mogło leżeć na telefonach wokół fizycznego stołu albo samo być stołem.

Zakres był realny; walidacja nie. Dowiedzieliśmy się dużo o tym, jak ludzie grają, ale zbyt mało z nich zmieniało utrwalone zachowania w sposób uzasadniający dalszą inwestycję. W kwietniu 2024 zamknąłem produkt, zamiast pomylić tempo techniczne z dowodem rynkowym. Założenie produktu oznacza odpowiedzialność za kryteria zatrzymania tak samo jak za wizję.