Każdy statek z własnym programem, kamera na wszystko i gra, która rozgrywa przyszłość

Prawdziwy zrzut ekranu z gry (kamerę ustawił nasz skrypt testowy). Fioletowa linia to trasa, którą statek przeleci, jeśli uruchomimy jego program: sześć razy „leć 9, obróć o 60°”. Dlaczego to nie jest równy sześciokąt, wyjaśniamy niżej.

Do tej pory w Swarm Protocol programować dało się tylko jedną jednostkę: drona. Statki roju latały wyłącznie na rozkaz kliknięciem. Od wersji 2.19 każdy statek ma własny program, jest nowa kamera, która „siada” na statku tak jak na planecie, a gra rysuje trajektorie: dokąd jednostka leci teraz i dokąd poleci, jeśli uruchomimy jej program. Po drodze wyszły trzy błędy w fizyce, z których jeden siedział w grze od dawna i nikt go nie zauważył. Ale po kolei.

Prośba w czterech punktach (i piątym, urwanym)

Michał przyszedł z listą:

• „przy każdym statku, zamiast kamery z kokpitu, daj możliwość patrzenia na statek tak jak na planetę”,
• „pod tym przyciskiem dodaj drugi, który jest właśnie kamerą z kokpitu”,
• „niech pozostałe statki otrzymają możliwość programowania”,
• i trajektorie, „widoczne tylko w widoku kamery na statek”.

Chwilę później dopisał jeszcze dwa słowa: „dron też”. Trajektorie miały pochodzić z prototypu, który Michał zbudował wcześniej sam, w osobnej rozmowie: małego układu słonecznego z grawitacją, statkiem sterowanym klockami i dwiema liniami. Jedna pokazywała orbitę z samej prędkości, druga symulowała cały zaplanowany program. Sporo z tego prototypu trafiło już do gry wcześniej (dziewięć orbit, grawitacja), a teraz przyszła kolej na ostatni kawałek. Po wszystkim Michał napisał krótko: „plik test można skasować”. Prototyp zrobił swoje.

Przy jednej z późniejszych próśb ostatni punkt urwał się na „w podglą…”. Zapytałem, co miało dalej być. Okazało się, że to resztka po edycji wiadomości, a nie tajemniczy piąty wymóg.

Jeden silnik zamiast dwóch

Najprościej byłoby skopiować kod drona do statków. Nie zrobiłem tego, bo za miesiąc mielibyśmy dwa prawie identyczne silniki, poprawiane osobno i rozjeżdżające się po cichu. Zamiast tego wydzieliłem z drona wspólny „silnik programów”. Język i interpreter są te same co zawsze, a każda jednostka mówi tylko, co u niej znaczą komendy move, turn, attack czy fuel. Dron przeszedł na ten silnik bez żadnej zmiany w działaniu, a statki dostały go od razu.

Skrypt napisany dla drona działa na statku bez poprawek. Są tylko trzy różnice. Statki nie mają paliwa, więc fuel() zawsze zwraca pełne 100 i stare skrypty z pętlą „dopóki jest paliwo” dalej działają. Statek lata swoją prędkością przelotową, czyli tą z ulepszenia Prędkość. A attack() gryzie tak jak statek jedzący planetę: z ulepszeniem Gryz i z odpornością termiczną. To ważne, bo inaczej programem dałoby się obejść ulepszenia chroniące przed gorącymi planetami.

Prawdziwy zrzut ekranu: edytor klocków, tym razem dla statku numer 2. Każdy statek ma własny skrypt tekstowy i własny program z klocków, a dron zachował swoje.

Przy przepisywaniu drona wyszła zresztą ukryta wpadka. Polecenie print(), które wypuszcza z nosa drona obłoczek z laserowym napisem, brało kolor z materiału drona. Tyle że od dnia, w którym dron dostał nowy model z laboratorium statków, jego „siatka” to grupa części bez własnego materiału. Każde print() kończyło więc skrypt błędem. Nikt tego nie zauważył, łącznie ze mną. Teraz napis ma kolor gracza, taki sam, jaki widzą inni.

WIDOK i KOKPIT

Kamera „na planetę” istniała już wcześniej: kliknięcie planety na minimapie przelatuje do niej i śledzi ją po orbicie. Teraz ta sama kamera przyjmuje też statek i drona. W panelu jednostki jest przycisk z okiem, a w rogu kamera z kokpitu, która działa także dla drona. W kokpicie przez środek obrazu przechodził biały pas: to był pierścień zaznaczenia jednostki, widziany od środka. Na czas rysowania kokpitu chowamy go.

Prawdziwy zrzut ekranu: statek w trakcie programu (status „Program”), okienko z kokpitu w rogu widoku i nowy rząd ikon w panelu jednostki.

Potem Michał dopracował to w kilku krokach. Najpierw WIDOK przeniósł się do dolnego rzędu przycisków, żeby się nie dublował z kokpitem. Potem taki sam złoty przycisk WIDOK dostały panele planety, stacji i czarnej dziury. W panelu planety zastąpił nieaktywny jeszcze „Kolonizuj”, bo, jak to ujął Michał, „będzie jednolicie”. Na koniec padło: „przyciski nie muszą być podpisane, wystarczy tooltip i obrazek”. Panel jednostki zrobił się przez to wyraźnie spokojniejszy.

Jak przewidzieć przyszłość: zagrać w nią

Fioletowa linia to najciekawsza część tej wersji. Żeby pokazać, dokąd poleci statek z programem, gra robi kopię statku i na niej uruchamia prawdziwy program, tym samym interpreterem, z tymi samymi komendami ruchu i tą samą grawitacją. Planety są przy tym tam, gdzie będą za minutę czy dwie. Gra po prostu rozgrywa kawałek przyszłości w pamięci, dwie minuty naprzód, kilka razy na sekundę. Niebieska linia pokazuje z kolei, co się stanie, jeśli niczego nie ruszymy: dryf w grawitacji albo lot do celu rozkazu.

Sprawdziliśmy to pomiarem: puściliśmy program i porównywaliśmy, gdzie statek jest naprawdę, a gdzie według linii miał być. Po 40 sekundach lotu różnica wynosiła od 0,2 do 0,5 jednostki. Przy locie na rozkaz zgadza się co do dziesiątej części jednostki.

Trzy błędy w fizyce

Ta dokładność nie przyszła od razu. Pierwszy pomiar wyglądał tak, jakby statek zwariował: po 30 sekundach programu był 370 jednostek od stacji i przyspieszał. Program wyprowadził go poza pole ochronne stacji, a tam grawitacja Słońca dodawała mu prędkości co klatkę. Po pół minuty leciał na Słońce kilkadziesiąt jednostek na sekundę. Dron tak się nie zachowuje, bo grawitacja tylko go znosi: przesuwa go, ale nie rozpędza. Statki z programem dostały ten sam model. I stąd kształt sześciokąta z pierwszego zrzutu: statek wylatuje poza pole stacji, grawitacja go znosi, więc każdy kolejny bok jest przesunięty.

Drugi błąd znalazłem przy okazji i okazał się starszy. Symulacja uparcie twierdziła, że statek lecący na rozkaz ledwo pełznie, 8 jednostek w dwie minuty. Założyłem, że myli się symulacja, i zmierzyłem prawdziwą grę. Statek z rozkazem, który powinien lecieć 0,97, leciał 0,4–0,6, a o ile wolniej, zależało od liczby klatek na sekundę. Kod od dawna głosił, że lot na rozkaz jest „odporny na grawitację”, ale grawitacja i przyciąganie stacji wciąż się do niego dokładały. Michał skwitował to krótko: „zwykłe statki mają źle obliczaną trajektorię, powinno być jak w dronie”. Teraz lot na rozkaz jest naprawdę czysty i statki dolatują mniej więcej dwa razy szybciej niż przed tą wersją.

Prawdziwy zrzut ekranu: statek z rozkazem lotu do planety na dalszej orbicie i jego niebieska trajektoria, prosta, bo lot na rozkaz nie czuje już grawitacji.

Trzeci błąd był raczej nieporozumieniem w samym projekcie, a zauważył go Michał: „wydaje mi się, że stacja ma swoją grawitację. Powinna blokować statki przed grawitacją, a nie ściągać własną”. Miał rację. Poza polem ochronnym stacja przyciągała bezczynne statki z siłą większą niż Słońce. Usunięcie tego to jedna linijka, ale był haczyk, więc zamiast zgadywać, dałem Michałowi trzy wersje do wyboru. Bezczynny statek poza polem może stać w miejscu, powoli dryfować jak dron albo czuć prawdziwą grawitację. Wybrał trzecią. Pole stacji teraz tylko chroni, a statek zostawiony bez rozkazu daleko od domu, na przykład po zjedzeniu planety, zacznie spadać na Słońce albo na tę planetę. Dla pilota roju to nowa odpowiedzialność.

Trajektorie wszystkiego, na co patrzysz

Na początku linie były widoczne tylko w widoku jednostki. Michał zaproponował prostszą zasadę: „jeżeli jesteśmy na jakimś obiekcie, statku czy stacji, to zawsze chciałbym widzieć trajektorię własną plus zaznaczonego obiektu”. Dopisał też: „to może usprawnić kod”. I rzeczywiście usprawniło: zamiast specjalnego przypadku jest jedna reguła. Obiekt pod kamerą plus wszystko, co zaznaczone. Planety, meteoryt i czarna dziura też dostały linię: swoją drogę po orbicie na najbliższe dwie minuty. To ten sam horyzont co u statków, więc od razu widać, gdzie planeta będzie, kiedy dolecimy. Przy kilku zaznaczonych statkach linii nie ma, bo to był już tylko bałagan.

Prawdziwy zrzut ekranu: planeta w widoku, niebieski łuk to jej droga po orbicie przez najbliższe dwie minuty. W panelu złoty przycisk WIDOK zamiast dawnego „Kolonizuj”.

Pierwsza wersja łuków była, jak napisał Michał, „jakaś słaba, chyba rysowana inną linią”. Faktycznie wyglądała na przerywaną. Łuk leżał dokładnie na zwykłej linii orbity, a dwie linie w tym samym miejscu walczą o to, która jest „bliżej”, więc widać było kawałki raz jednej, raz drugiej. Teraz łuk jest rysowany na wierzchu. Za pierwszym razem pojawił się przez to także na miniaturce planety w panelu, więc linie trajektorii widzi teraz tylko główna kamera.

Kilka liczb

Jedna wersja, 2.19, zbudowana w jeden dzień. Jeden silnik programów zamiast jednego-na-drona. Symulacja dwie minuty naprzód, odświeżana co 0,4 sekundy, z błędem poniżej pół jednostki. Statki na rozkaz szybsze mniej więcej dwukrotnie. I jeden plik prototypu mniej.

Co dalej

Przewidywanie ma jedną znaną dziurę: nie uwzględnia czarnej dziury, która ma w grze własną, zabójczą grawitację. Linia pokaże przelot tuż obok niej, a w grze statek mógłby już nie wrócić. To pierwsze do poprawki. Drugie to limit mocy obliczeniowej, bo przy programowalnej flocie trzeba będzie zadbać, żeby nikt nie zasypał serwera programami. Michał ma zresztą pomysł fabularny, który wyjaśni, dlaczego komputery roju w tym układzie liczą wolniej niż powinny. Więcej zdradzimy, kiedy przyjdzie jego czas.