Projektowanie gier

Projektując grę naszym głównym celem było przygotowanie fajnej rozrywki dla programistów, a także zrobienie czegoś ciekawego w ramach pracy w naszej firmie. Do tej pory nie mieliśmy żadnych kompetencji w tworzeniu gier, dlatego było to dla nas spore wyzwanie. W pierwszej kolejności skupiliśmy się na tym, czym ta gra tak naprawdę ma być. Po opracowaniu wstępnego planu przystąpiliśmy do działania.

W ramach prac nad grą zdecydowaliśmy się na hackathon i podział na grupy wykonujące konkretne zadania. Dzięki takiemu 8-godzinnemu podziałowi pracy udało nam się zrealizować wygląd przeciwników w grze, całą szatę graficzną oraz podwaliny zarówno zadań, jak i API całego systemu. W kolejnym etapie zbieraliśmy się na 4-godzinne spotkania raz w miesiącu, dzięki czemu udało nam się ukończyć grę w 3 spotkania.

Wdrożenie

Jako że specjalizujemy się w RubyOnRails, wybraliśmy tę technologię jako wiodącą. Gra nie miała być jednak tekstowa, dlatego podejście do niej znalazło odzwierciedlenie w aplikacji typu SPA. W ramach zadania pracowaliśmy nad dobrze znanym potokiem assetów z railsów (w 2016 roku w zasadzie nie było nic lepszego) oraz całą aplikacją. javascript w oparciu o nasze zastrzeżone kod z pomocą TypeScript. W aplikacji nastąpił standardowy podział obowiązków: Railsy jako źródło assetów i API, javascript i related jako interakcja z użytkownikiem. Tutaj jednak funkcjonowało to jako hybryda i część widoków była po prostu renderowana z Railsów, a część z JS.

Maszynopis

Był to nasz pierwszy eksperyment w tej dziedzinie. Były to czasy, kiedy ludzie wierzyli w sukces CoffeScript. Użycie TypeScript wymagało wprowadzenia gema typescript-rails. Niestety nie był to finał, gdyż typescript, jako język statycznie typowany, wymagał tego również od bibliotek domyślnie dołączonych do railsów.

https://github.com/codesthq/cody_the_game/blob/master/app/assets/javascripts/jquery.d.ts (szczególnie w przypadku korzystania z wbudowanego systemu zarządzania zasobami z szynami).

Cody jako gra wymagała sporej dynamiki po stronie przeglądarki, a także modyfikacji drzewa DOM. Użycie TypeScript zamiast vanilla javascript było ogromnym skokiem w jakości kodu, sama obecność klas i enkapsulacji była dla nas bardzo kusząca.

API i SPA

In 2019, SPA applications are managed by using the magnificent React or Vue libraries. However, in 2015, we did it in a different way. The previously mentioned typescript was helpful in the implementation of the game, while jQuery revoked all the work related to the xml http request. Now we can use fetch, whilst back in those days `$ .ajax` was all that was needed for the job. Take a look at our client api!

https://github.com/codesthq/cody_the_game/blob/master/app/assets/javascripts/services/api_client.js.ts

Jeśli było to api, to trzeba było jakoś rozwiązać problem uwierzytelniania, prawda? No właśnie. Ale w tym przypadku poszliśmy za (czy można tu napisać - użyliśmy zespołu?!) zespołem i w sesji rails stworzyliśmy cookie_key, a następnie zapisaliśmy go w bazie danych. Stąd wiedzieliśmy, że wszystko jest więcej niż w porządku.

https://github.com/codesthq/cody_the_game/search?q=cookie_key&unscoped_q=cookie_key

Stan gry był przechowywany w bazie danych, a informacje o tym, ilu użytkowników ma punkty, pochodziły z bazy danych (czy to ta sama baza danych? Czy możemy po prostu zmienić to zaimkiem?). ACID zawsze się przydaje, gdy nie ma buforowania po stronie systemu;)

W przypadku spa jest to najlepsze rozwiązanie bez przeładowywania strony. Rozwiązaliśmy to klasycznie i anchor html był najlepszym rozwiązaniem bez rozszerzania niepotrzebnych zależności. Bo kto by używał turbolinków?

SnapSVG

Jeśli projektujemy grę, to musi być ona wydana tylko ze świetną grafiką i animacjami. Wtedy spędzaliśmy wiele godzin zastanawiając się jak sprostać tym wymaganiom w naszej aplikacji. Z jednej strony canvas potrafi zdziałać cuda, z drugiej w czystym htmlu dużo łatwiej się połapać i każdy o tym wie. Po żmudnych poszukiwaniach najlepszego rozwiązania doszliśmy do wniosku, że połączeniem tych dwóch rozwiązań jest svg. Pozwala on w łatwy sposób prezentować grafikę w wektorze, jest napisany w języku znaczników i co najważniejsze można go modyfikować w locie. Co ważne, istnieje biblioteka dla plików svg, która działa podobnie do jQuery i pozwala na operacje na obrazie w zunifikowany sposób. Jest to: http://snapsvg.io, Mamy bardzo miłe wspomnienia związane z tym konkretnym rozwiązaniem.

Przykład użycia snap.svg można znaleźć poniżej:

https://github.com/codesthq/cody_the_game/blob/master/app/assets/javascripts/intro.js.ts

Sam plik haml ze szkieletem graficznym:

https://github.com/codesthq/cody_the_game/blob/master/app/views/game/show.html.haml

Jak widać, jest to prawie jak normalne drzewo DOM i zwykła aplikacja railsowa!

TrustedSandbox

Cóż, w końcu mieliśmy API, Grafikę, SPA. Ale co z implementacją rozwiązań przesłanych przez użytkowników?

Pierwszą rzeczą, która przychodzi na myśl, jest metoda eval, ale nie jesteśmy szaleni;) W 2016 roku docker był na fali wznoszącej, więc wydawał się naturalnym wyborem. Same kontenery nie gwarantowały pełnej izolacji i ochrony, dlatego skorzystaliśmy z gotowego rozwiązania w Ruby o nazwie https://github.com/vaharoni/trusted-sandbox. Pozwoliło ono lepiej zabezpieczyć kod przed opuszczeniem piaskownicy i w ustandaryzowany sposób skonfigurować wymagania systemu operacyjnego. Bardzo ważne było odpowiednie ograniczenie czasu wykonywania kodu, pamięci potrzebnej do działania oraz cykli procesora. Nasza konfiguracja dostępna jest poniżej

https://github.com/codesthq/cody_the_game/blob/master/config/trusted_sandbox.yml.example

Oczywiście sama zaufana piaskownica niczego nie gwarantowała, dlatego wymyśliliśmy specjalną stronę internetową do uruchamiania kodu.

https://github.com/codesthq/cody_the_game/blob/master/app/services/task_runner/base_task.rb

Każde z zadań miało swój własny przypadek testowy, co pozwoliło nam zweryfikować poprawność zaimplementowanego rozwiązania. Dokonano tego poprzez wstrzyknięcie kodu użytkownika do przypadku testowego, tak aby wszystko było uruchamiane w izolacji.

https://github.com/codesthq/cody_the_game/blob/master/app/challenges/challenge/case.rb

Oczywiście czynność ta kosztowała sporo czasu, a podczas zbierania odpowiedzi nie mogliśmy sobie pozwolić na uruchomienie sandboxa, więc jedynie zapisywaliśmy kod w bazie danych, tworząc zgłoszenie, a następnie, korzystając z long poolingu, odpytywaliśmy endpoint w celu uzyskania statusu kodu. To pozwoliło nam odciążyć serwer aplikacji i odpowiednio zweryfikować dane. Oczywiście musieliśmy też zabezpieczyć się przed "zawaleniem skryptu", dlatego ograniczyliśmy liczbę zapytań do serwera za pomocą zmiennej ttl, co widać poniżej.

https://github.com/codesthq/cody_the_game/blob/master/app/assets/javascripts/level_controller.js.ts#L92

Podsumowanie konkursu

Do września 2011 roku statystyki gry wyglądały następująco:

- liczba sesji: 1945 - wysłane zadania: 4476 - wysłał prawidłowe odpowiedzi: 1624 - zakończył grę: 31

Jak widać, największe schody zaczęły się w zadaniu # 2, ponieważ nie był to już zwykły przykład hello world.

Czytaj także:

Szybkie zapoznanie się z Ruby 2.6. Co nowego?

Pisanie dokumentacji stało się łatwe dzięki VuePress

 Samouczek dotyczący podstaw Vue.js. Jak zacząć pracę z tym frameworkiem?