Sąd Odyna. Jak z głupiego pytania powstała działająca gra
Cześć, z tej strony Kuba.
Mam pewną przypadłość.
Kiedy pojawia się pytanie, na które absolutnie nie potrzebuję odpowiedzi, istnieje spora szansa, że zamiast je zignorować… napiszę do niego aplikację.
Tym razem pytanie brzmiało:
czy programista po śmierci trafia do Walhalli?
Oczywiście można było pośmiać się przez trzy minuty i wrócić do normalnej pracy.
Więc naturalnie zrobiłem odwrotnie.
Powstał Sąd Odyna.
Najpierw żart. Potem logika.
Początkowo chodziło tylko o kilka absurdalnych reguł.
PHP + Linux + terminal?
Odyn odsuwa krzesło.
Deploy w piątek o 17:00 bez backupu?
Znacznie bardziej skomplikowana sytuacja.
Excel używany jako baza danych?
Tu nawet bogowie nordyccy potrzebują chwili na konsultację.
Problem pojawił się wtedy, kiedy tych wyjątków zaczęło przybywać.
Bo jeżeli chcemy zrobić quiz, w którym odpowiedzi naprawdę wpływają na wynik, samo:
A = 1 punkt, B = 2 punkty
bardzo szybko przestaje wystarczać.
Pojawiły się:
przewinienia,
odkupienia,
modyfikatory,
kombinacje odpowiedzi,
immunitety,
wyjątki,
ukryte ścieżki
i kilka przypadków, w których użytkownik powinien zostać natychmiast przekazany lokalnemu przedsiębiorstwu gospodarki odpadami.
I nagle żart zaczął przypominać mały system decyzyjny.
Właśnie za to lubię małe projekty
W dużym projekcie przed pierwszą linijką kodu często pojawiają się:
brief,
specyfikacja,
warsztat,
estymacja,
harmonogram
i człowiek, który chce spotkanie o spotkaniu.
Tutaj było odwrotnie.
Jednoosobowy dział R&D.
Pomysł → prototyp → logika → test → publikacja.
Dzięki temu bardzo szybko można sprawdzić, czy sama mechanika daje frajdę.
Nie trzeba od razu budować idealnego produktu.
Najpierw musi istnieć coś, co można kliknąć.
Dopiero potem zaczyna się najważniejsza część.
Testy na ludziach
Testy automatyczne potrafią sprawdzić, czy system policzył to, co miał policzyć.
Nie powiedzą natomiast:
czy pytanie jest śmieszne,
czy wynik daje satysfakcję,
czy użytkownik rozumie zasady,
czy chce przejść quiz drugi raz,
ani czy znajdzie sposób na rozwalenie logiki, którego autor oczywiście nie przewidział.
Dlatego wersja 0.1 poszła publicznie.
Nie jako skończona gra. Jako działający eksperyment.
I to jest dokładnie sposób pracy, który bardzo lubimy również przy normalnych projektach.
Nie siedzieć trzy miesiące nad perfekcyjną wersją czegoś, czego nikt jeszcze nie użył.
Zbudować rozsądne MVP.
Puścić ludzi.
Patrzeć.
Poprawiać.
Co jest pod spodem?
Vanilla JS (dane, zasady, silnik) i trochę CSS-a (tu podziękowania dla LLM-a – nie miałem mocy ani pomysłu a chciałem, aby jakoś to wyglądało).
Najciekawsza nie jest nawet sama warstwa wizualna.
Pod spodem siedzi logika scoringowa, która pozwala łączyć odpowiedzi, nakładać modyfikatory i kierować użytkownika do różnych rezultatów.
Dzisiaj są nimi Walhalla, Midgard i kilka miejsc zdecydowanie mniej reprezentacyjnych.
Jutro dokładnie ten sam rodzaj mechanizmu może obsługiwać:
quiz produktowy,
konfigurator,
kalkulator,
formularz kwalifikacyjny,
rekomendację oferty
albo onboarding klienta.
I właśnie dlatego uwielbiam projekty, które pozornie są kompletnie niepoważne.
Bardzo często testują całkiem poważne mechanizmy.
Czy programista trafia do Walhalli?
Nie wiem.
Ale możemy to policzyć.
Publiczna wersja Sądu Odyna działa tutaj:
Grajcie.
Psujcie.
Szukajcie przypadków brzegowych.
Bo prawdopodobnie najlepsza rzecz, jaka może przydarzyć się wersji 0.1, to użytkownik, który zrobi dokładnie coś, czego autor nie przewidział.
Saku Media
Budujemy rzeczy poważne.
Czasami tylko punkt wyjścia jest podejrzany.
