Niech ten artykuł zdementuje raz na zawsze pojęcia związane z narzędziami do tworzenia gier! Silnik gry to NIE to samo, co framework. Tym bardziej to nie biblioteka. Wszystkie te trzy kluczowe pojęcia NIE są sobie równe! Zapraszam po wyjaśnienia czym się różnią między sobą. Konkretnie, nie poszlakowo.

TYP NARZĘDZIA "SILNIK GRY"

Przeglądając Reddit czy wstukując słowa kluczowe w Google, często pojęcia choć dotyczące tego samego przeznaczenia, są ze sobą utożsamiane i traktowane jak synonim. Nie, nie można ich porównywać! Patrzcie na te pojęcia jak na różne rodzaje czy też ścieżki do zrobienia własnej gry.

Silnik gry jest całym oprogramowaniem zaopatrzonym w wiele osobnych komponentów takich jak edytor wizualny, fizyka lub możliwość eksportu za pomocą jednego kliknięcia myszką. Jest on najbardziej rozbudowanym typem narzędzia przeznaczonego do tworzenia gier, które ma najbardziej wyręczać człowieka od tzw. "brudnej roboty" zamieniając polecenia konsolowe na przyjemne dla oka okienka z opcjami dostosowania. Może wspierać ręczne programowanie, ale nie musi.

PRZYKŁADY SILNIKÓW GIER:

Silnik gry "Unity"

Silnik gry to "najpełniejsze" oprogramowanie do tworzenia gier charakteryzujące się zestawem wbudowanych narzędzi w stylu "all in one". Jednym z najbardziej rozpoznawalnych tytułów jest "Unity".

SILNIK GRY VS. "FRAMEWORK"

Drugim rodzajem narzędzia do tworzenia gier jest tzw. "framework". Definiowany jest jako "szkietet" przeznaczony do budowy aplikacji. Tym "szkietem" są klasy, metody i dane składowe napisane wcześniej przez twórcę. I to wszystko. Żadnych edytorów wizualnych, same kodowanie. Nawet po tym jednym zdaniu widać gołym okiem, że to już nie to samo, co oferuje silnik gry.

Jest to rodzaj pośredni w kwestii wbudowanych narzędzi ułatwiających proces tworzenia gry. W przypadku frameworka, on też oferuje możliwość łatwego eksportu na wszystkie wspierane przez niego platformy, aczkolwiek tutaj może być konieczne użycie wiersza poleceń, stąd użycie słowa "pośredni".

Kolejna ważna rzecz jest taka, iż framework może narzucać sposób programowania. Może działać jak zwykła pętla while, ale może też być podzielona na tzw. "state'y", czyli osobne sceny do których się "wrzuca" kilka metod służących do aktualizowania i rysowania obiektów. Jeszcze inny może być zaprogramowany pod wzorzec na dodawanie osobnych komponentów do obiektów tzw. "Entity-component-system". Silnik gry jest przeważnie programowany w taki sposób. Czy nadal sądzicie, że to jest to samo? Chyba nie...

PRZYKŁADY FRAMEWORK'ÓW:

Framework "Phaser"

Framework jest napisanym wcześniej zestawem metod i danych składowych (w dodatku klas, w zależności od paradygmatu). Nie jest sam w sobie zestawem kilkudziesięciu narzędzi jak silnik gier (jedynie ułatwia programowanie), a część czynności takich jak eksport może już wymagać użycia wiersza poleceń. "Phaser" jest jednym z przykładów.

SILNIK GRY VS. BIBLIOTEKA

Najbardziej "surowym" z tych trzech rodzajów narzędzia jest biblioteka. Biblioteka to też zestaw metod i danych składowych, natomiast nie narzuca w żaden sposób pisania programu. On posiada tylko zmienne i funkcje, ale nie "wtrąca się" do stylu pisania (być może są wyjątki o których nie wiem). Dlatego też pisze się w starym stylu, czyli pętla while i samodzielne konstruowanie przebiegu. Od sterowania, aż do przechodzenia z jednej sceny do drugiej.

Dodatkowo nie posiada żadnych narzędzi wbudowanych pozwalających na szybkie i przyjemne eksportowanie na wiele różnych platform. Jeśli chcemy coś takiego, co daje silnik gry, programujemy samodzielnie! Sorry, Winnetou!

PRZYKŁADY BIBLIOTEK:

Biblioteka "raylib"

Biblioteka dostarcza jedynie zestaw funkcji i zmiennych, aczkolwiek dbamy samodzielnie o eksport oraz programowanie wszystkiego ręcznie wewnątrz pętli while. Najczęściej dotyczą one programowania w językach C i C++, a jedną z nich jest "raylib".


Jeśli dotrwano do końca, serdecznie dziękuję i tym lepiej dla Was! Od tej pory mam nadzieję, że weszła do głowy świadomość, że silnik gry to nie to samo, co framework i biblioteka...

PODOBNE ARTYKUŁY