Niech ten artykuł zdementuje raz na zawsze pojęcia związane z narzędziami do tworzenia gier! "Framework" to NIE to samo, co silnik gry. 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.
| Tweet |
TYP NARZĘDZIA "SILNIK GRY"
Przeglądając Internet, 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 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".
Źródło: Wikimedia
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" 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.
Źródło: GitHub
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 wbudowanych narzędzi 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 :D!
PRZYKŁADY BIBLIOTEK
 |
Biblioteka dostarcza jedynie zestaw funkcji i zmiennych, aczkolwiek dbamy samodzielnie o eksport oraz programowanie wszystkiego ręcznie wewnątrz pętli "while". Przykładem takiej biblioteki jest "raylib".
Źródło: Wikimedia
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 ;).