Jak zbudowaliśmy Unicorn Games w 7 dni przy użyciu AI i otwartych standardów webowych

Jak zbudowaliśmy Unicorn Games w 7 dni: architektura, programowanie w parze z AI i lekkie standardy sieciowe

Współczesne gry przeglądarkowe znalazły się w ślepym zaułku. Wejdź na dowolny popularny portal z grami na telefonie lub laptopie. Zanim zobaczysz choćby jedną kartę czy planszę, zostajesz zalany oknami zgód na pliki cookie, trzydziestosekundowymi filmami reklamowymi, przesuwającymi się przyciskami i bibliotekami WebAssembly ważącymi po pięćdziesiąt megabajtów, które rozgrzewają urządzenie do czerwoności.

Postanowiliśmy udowodnić, że można podejść do tematu inaczej. Chcieliśmy sprawdzić, czy pojedynczy niezależny inżynier oprogramowania, współpracując intensywnie ze współczesnymi modelami sztucznej inteligencji, jest w stanie zaprojektować, zaprogramować i wdrożyć produkcyjny portal z ponad dziesięcioma klasycznymi grami w dokładnie siedem dni kalendarzowych.

Bez korporacyjnych zebrań. Bez ociężałych frameworków. Bez pułapek reklamowych w środku rozgrywki. Tylko klasyczne gry karciane i logiczne działające w stałych sześćdziesięciu klatkach na sekundę, uruchamiane natychmiast bez instalacji, zbudowane na otwartych standardach sieciowych.

Oto szczegółowy plan architektoniczny, codzienny dziennik inżynieryjny i decyzje techniczne stojące za Unicorn Games.

Manifest architektoniczny: bezkompromisowy minimalizm

Szybkość w sieci nie jest kwestią przypadku. To wynik świadomego odrzucania zbędnych rozwiązań.

Zanim w poniedziałek rano napisaliśmy pierwszą linijkę kodu, wyznaczyliśmy pięć nienegocjowalnych zasad technicznych:

1. Gotowość planszy poniżej jednej sekundy. Nawet przy słabym połączeniu mobilnym plansza gry musi załadować się w czasie krótszym niż tysiąc milisekund.

2. Brak zewnętrznych silników do gier. Żadnego Phasera, Unity WebGL czy eksportów z Godota. W przypadku klasycznych gier karcianych i planszowych takie narzędzia oznaczają megabajty zbędnego balastu.

3. Rysowanie na HTML5 Canvas 2D połączone z niezależnymi maszynami stanów. Logika gry musi działać jako czyste funkcje matematyczne, bez obciążania struktury DOM przeglądarki.

4. Całkowite renderowanie statyczne po stronie serwera dla stron przeglądowych. Każda gra, zestaw zasad i poradnik strategiczny musi istnieć jako gotowy plik HTML, co gwarantuje natychmiastowe indeksowanie przez wyszukiwarki bez przeskoków wizualnych.

5. Zerowe przesunięcia układu (CLS = 0). Żaden element nie może zmienić swojego położenia po początkowym wyświetleniu strony.

Te zasady zdefiniowały nasz zestaw narzędzi: Next.js z App Routerem do generowania stron statycznych i szybkiego dostarczania treści, czysty TypeScript do symulacji reguł gry, HTML5 Canvas 2D do płynnej grafiki oraz Firebase jako lekki magazyn danych.

Sprint 7-dniowy: inżynieryjny zapis dzień po dniu

Zbudowanie wielotytułowej platformy w sto sześćdziesiąt osiem godzin wymaga potraktowania każdego dnia jako zamkniętego etapu wdrożeniowego.

Dzień 1: Bezinfejsowe silniki kart i deterministyczny stan

Gry karciane wydają się proste, dopóki nie trzeba precyzyjnie opisać ich reguł w kodzie. Partia Klondike Solitaire czy FreeCella to nie seria animacji, lecz automat o skończonej liczbie stanów, który przy każdym ruchu musi weryfikować rygorystyczne warunki logiczne.

Poniedziałek poświęciliśmy na fundament: architekturę talii i kolumn napisaną w czystym TypeScripcie, całkowicie odciętą od warstwy wizualnej.

Podzieliliśmy system na trzy odrębne poziomy:

Dzięki oddzieleniu logiki od okna przeglądarki mogliśmy przeprowadzić setki tysięcy automatycznych testów w środowisku Node.js, zanim narysowaliśmy choćby jedną kartę na ekranie.

Dzień 2: Pakiet pasjansów (Klondike, FreeCell i Pająk)

Wtorek upłynął pod znakiem oprawy graficznej oraz obsługi sterowania myszą i dotykiem dla najważniejszych pasjansów.

Rysowanie kart na elemencie HTML5 Canvas wiąże się ze specyficznymi wyzwaniami:

Obraz musi uwzględniać ekrany telefonów o wysokim zagęszczeniu pikseli. Rysowanie na zwykłym canvasie na nowym telefonie sprawia, że karty są rozmyte. Stworzyliśmy moduł skalujący, który sprawdza współczynnik pikseli ekranu, mnoży wewnętrzny bufor rysowania przez tę wartość i dopasowuje wymiary za pomocą stylów CSS. W ten sposób uzyskaliśmy ostre krawędzie kart i czytelne napisy.

Obsługa zdarzeń wymagała ujednolicenia kliknięć myszy, piórka cyfrowego i dotyku palcem. Gdy gracz dotyka ekranu, system przelicza punkt fizyczny na wirtualne współrzędne canvasu, rozpoznaje wskazaną kartę i sprawdza próg przesunięcia przed rozpoczęciem unoszenia karty.

Do północy we wtorek Klondike, FreeCell i Pasjans Pająk działały w pełni płynnie przy stałych sześćdziesięciu klatkach na sekundę.

Dzień 3: Gry lewowe i reguły sztucznej inteligencji

W środę przyszedł czas na gry lewowe: Kierki (Hearts) i Piki (Spades).

Gry tego typu opierają się na poziomie gry wirtualnych przeciwników. Gdy grają chaotycznie, partia traci sens. Gdy próbują przeliczać wielkie drzewa prawdopodobieństwa dla pięćdziesięciu dwóch kart, przeglądarka zaczyna się zacinać.

Zbudowaliśmy lekki mechanizm decyzyjny oparty na regułach taktycznych:

W Spades boty oceniają swoje karty przed pierwszym wyjściem, zliczając Asy, chronione Króle i potencjalne przebitki, by zgłosić zrównoważoną deklarację. Jeśli partner licytuje Nil, bot staje się jego obrońcą: wychodzi w swoje długie kolory, by pomóc partnerowi zrzucić groźne karty, i przejmuje niepewne lewy wysokimi atutami.

W Hearts boty śledzą ubytki kart u pozostałych graczy. Jeśli ktoś w pierwszej lewie nie dokłada do Trefla, bot zapamiętuje ten brak. Polując na Damę Pik, zagrywają niskie Piki, by pozbawić rywali ochrony, zachowując własne wysokie figury zabezpieczające.

Decyzje zapadają w czasie poniżej dwóch milisekund, gwarantując natychmiastowe reakcje bez szarpania animacji.

Dzień 4: Siatki logiczne i łamigłówki (Saper i 2048)

W czwartek przenieśliśmy się ze stołów karcianych na matematyczne siatki liczbowe.

Saper wymaga bezwzględnej ochrony gracza przy pierwszym ruchu:

Pierwsze odsłonięte pole nigdy nie może zawierać miny. Plansza rozmieszcza miny dopiero w momencie tego pierwszego kliknięcia wokół wskazanego pola, gwarantując bezpieczny początek partii.

Do odkrywania połączonych pustych pól użyliśmy iteracyjnego przeszukiwania wszerz (BFS). Metody rekurencyjne grożą przepełnieniem stosu na dużych planszach; prosta kolejka w pętli while odkrywa wolną przestrzeń w czasie poniżej trzech milisekund nawet na planszy zaawansowanej o wymiarach trzydzieści na szesnaście pól.

Dla 2048 stworzyliśmy silnik przekształceń macierzy. Pisanie osobnych funkcji dla czterech kierunków prowadzi do bałaganu w kodzie. Ujednoliciliśmy mechanizm: każdy ruch obraca planszę tak, by wybrany kierunek wskazywał w lewo, wykonuje jedną standardową funkcję łączenia kafelków i przywraca planszę do pierwotnego położenia.

Dzień 5: Wielojęzyczność i statyczna budowa stron

Piątek przeznaczyliśmy na infrastrukturę platformy, dostępność i pełną obsługę językową.

Strona z grami dostępna wyłącznie po angielsku pomija większość graczy na świecie. Zbudowaliśmy strukturę adresów obsługującą dziesięć pełnych języków: angielski, hiszpański, niemiecki, francuski, włoski, portugalski, holenderski, polski, chiński i hindi.

Zamiast skryptów tłumaczących działających w przeglądarce, które spowalniają ładowanie i powodują przeskakiwanie tekstu, wbudowaliśmy tłumaczenia bezpośrednio w etap generowania stron w Next.js.

Każda gra, artykuł i poradnik powstaje jako gotowy, statyczny plik HTML dla każdego z dziesięciu języków. Gdy gracz wchodzi na stronę z Warszawy czy Madrytu, otrzymuje treść w ojczystym języku w czasie poniżej czterdziestu milisekund.

Dzień 6: Dopracowanie dotyku, pamięć podręczna i synteza dźwięku

Sobota była dniem eliminowania drobnych zacięć i optymalizacji pamięci operacyjnej.

Osiągnęliśmy trzy kluczowe ulepszenia:

Po pierwsze: likwidacja opóźnień dźwiękowych. Pobieranie plików audio przez sieć powoduje słyszalne opóźnienia przy szybkim przekładaniu kart. Zamiast plików MP3 generujemy dźwięki przesunięć kart bezpośrednio w przeglądarce za pomocą Web Audio API przy użyciu oscylatorów programowych. Brak zapytań sieciowych, dźwięk pojawia się dokładnie w chwili dotknięcia ekranu.

Po drugie: wyeliminowanie przestojów na odśmiecanie pamięci. Ciągłe tworzenie nowych obiektów zmusza przeglądarkę do krótkich przerw na porządki, co powoduje szarpnięcia animacji. Wprowadziliśmy pule gotowych obiektów do wielokrotnego użytku dla współrzędnych i zdarzeń dotykowych. Płynność wyświetlania stała się nienaganna.

Po trzecie: konfiguracja pamięci podręcznej w sieci Cloudflare. Ponieważ nasze pliki statyczne nie ulegają zmianom, serwery na całym świecie serwują kolejne wejścia prosto ze swojej pamięci podręcznej, odciążając serwer główny.

Dzień 7: Wdrożenie globalne, ocena jakości i uruchomienie

Niedziela była dniem oficjalnej premiery. Podłączyliśmy docelową domenę, skonfigurowaliśmy grafiki podglądu w mediach społecznościowych i przeprowadziliśmy audyty jakościowe.

Wszystkie podstrony spełniły oficjalne normy Core Web Vitals firmy Google:

W niedzielę wieczorem Unicorn Games działało na całym świecie: dziesięć dopracowanych gier, błyskawiczne działanie na telefonach i komputerach, bez żadnych reklam psujących zabawę.

Świadome decyzje: czego celowo nie stworzyliśmy

Jakość projektu inżynieryjnego wynika także z rozwiązań, których świadomie uniknięto.

Oto technologie, które przeanalizowaliśmy i odrzuciliśmy:

Odrzuciliśmy WebGL i Three.js. Trójwymiarowe efekty obracania kart robią wrażenie na prezentacjach, lecz błyskawicznie wyczerpują baterię telefonu i wydłużają czas ładowania. Przy klasycznych grach dwuwymiarowych dopracowany Canvas 2D zapewnia stałe sześćdziesiąt klatek na sekundę przy minimalnym zużyciu energii.

Odrzuciliśmy zewnętrzne skrypty śledzące. Kody reklamowe dodają setki zbędnych kilobajtów, instalują pliki cookie i obniżają wskaźniki wydajności w Google. Wybraliśmy proste, wewnętrzne liczniki uruchomień, które nie naruszają prywatności graczy i nie obciążają ich urządzeń.

Odrzuciliśmy nawigację jednostronicową dla bazy wiedzy i poradników. Gotowe statyczne pliki HTML są czytane bez opóźnień przez roboty wyszukiwarek i wyświetlają się natychmiast przy wejściu na stronę.

Rzeczywista rola sztucznej inteligencji w projekcie

Nie ukończylibyśmy platformy Unicorn Games w siedem dni bez wsparcia modeli sztucznej inteligencji. Jednak nasz sposób pracy znacznie różnił się od popularnych wyobrażeń.

Nigdy nie prosiliśmy modeli o samodzielne wygenerowanie całej gry. Taka droga daje kruchy kod, który wykłada się na pierwszym nietypowym przypadku.

Sztuczna inteligencja była metodycznym pomocnikiem przy trzech zadaniach:

Po pierwsze: pisanie zestawów testów. Dla silników karcianych AI przygotowała setki scenariuszy sprawdzających zachowanie reguł w nietypowych układach.

Po drugie: wstępne szkice funkcji matematycznych. Przy obrotach planszy i algorytmach odkrywania pól AI dostarczyła pierwsze zarysy struktur, które następnie samodzielnie zoptymalizowaliśmy i wdrożyliśmy do silnika graficznego.

Po trzecie: tłumaczenia językowe. Przekład tysięcy słów specjalistycznych reguł na dziewięć języków obcych zająłby ręcznie wiele tygodni. AI wykonała to zadanie w kilka minut z zachowaniem właściwej terminologii.

Sztuczna inteligencja nie była natomiast w stanie pomóc przy fizycznych odczuciach z gry: czułość przesuwania kart, sprężystość animacji odkładania i eliminacja opóźnień dotykowych wymagały ręcznych prób i ludzkiego wyczucia.

Wyniki w liczbach

Efekt tego intensywnego tygodnia widać w twardych danych:

Cały kod JavaScript potrzebny do rozegrania pełnej partii Klondike Solitaire na Unicorn Games waży po skompresowaniu poniżej dziewięćdziesięciu kilobajtów. To mniej niż pojedyncza grafika reklamowa na typowym portalu z grami.

Czas ładowania z dowolnego miejsca na świecie utrzymuje się poniżej ośmiuset milisekund. Plansza pojawia się na ekranie od razu po odebraniu pliku HTML.

Sieć nie potrzebuje kolejnych przeładowanych portali, które traktują graczy jak odbiorców reklam. Potrzebuje szybkiego, czystego oprogramowania opartego na otwartych standardach internetowych.