Ten artykuł ma na celu przybliżyć Ci 3 różne rodzaje narzędzi do tworzenia gier i pomóc Ci wybrać taki, który będzie dla Ciebie najwygodniejszy! Biblioteka, framework i silnik gry - oto 3 różne drogi tworzenia gry, które różnią się od siebie pod wieloma względami! Serdecznie Cię zapraszam do lektury 😁!
BIBLIOTEKA, FRAMEWORK I SILNIK GRY JAKO 3 SPOSOBY TWORZENIA GIER!
Przeglądając internet w poszukiwaniu informacji o tworzeniu gier, często będziesz natrafiać na 3 charakterystyczne pojęcia związane z narzędziami do tworzenia gier ⚠️. Możesz spotkać się z określeniami: "biblioteka", "framework" i "silnik gry" 3️⃣. Jeżeli planujesz rozpoczęcie projektu w sposób świadomy, to musisz wiedzieć czym te metody różnią się między sobą! Biblioteka to nie to samo, co "framework", a "framework" także nie daje tyle, co silnik gry 😳!
CZYM SIĘ CHARAKTERYZUJE BIBLIOTEKA, FRAMEWORK I SILNIK GRY?
Zacznijmy od tego, że wszystkie 3 pojęcia odnoszą się do sposobów czy podejść do tworzenia gry. Inaczej będzie przebiegać cały proces korzystając z biblioteki, inaczej przy użyciu "frameworka", a inaczej z użyciem silnika gry. Teraz wyjaśnię każde z tych pojęć 🔔.
CZYM JEST BIBLIOTEKA DO TWORZENIA GIER?
Biblioteka to uprzednio przygotowany zestaw funkcji umożliwiających stworzenie aplikacji na bazie wyłącznie operacji niskopoziomowych ℹ️. W przypadku gier, chodzi o następujące kwestie 👇:
- utworzenie okna o podanej rozdzielczości,
- konfiguracja nazwy okna i ewentualnych innych właściwości gry np. wygładzanie krawędzi (ang. antialiasing),
- obsługa sterowania poprzez wykrywanie klikania myszką, naciskania klawiszy na klawiaturze itd.,
- alokowanie i zwalnianie pamięci dla zasobów (mam na myśli zarządzanie pamięcią znane z języka C).
W większości przypadków to jest tyle 😲. Czyli chodzi o najbardziej podstawowe czynności, a całą resztę już programujemy sami ⚠️! Charakterystyczną cechą takiego podejścia jest fakt, iż to nie narzuca sposobu tworzenia gry ✅. Posługujemy się taką samą pętlą "while" i wewnątrz niej definiujemy wszystko to, co ma się dziać w oknie gry 🔁. A to, w jaki sposób zechcemy programować poziomy, grafikę czy przejścia pomiędzy scenami, to już nasza indywidualna sprawa 😄! Dodatkowo nie oferuje żadnych narzędzi pozwalających na szybkie i przyjemne eksportowanie na daną platformę ⛔. Wszystko kompilujemy ręcznie 😐.
Można powiedzieć, że jest to sposób "starodawny" z lat .90, gdy silniki gier były policzalne na palcach u jednej ręki i dostępne tylko dla bogatych ludzi 💸. Wtedy język C zaczął dominować w branży jako wygodna opcja do programowania gier i odejście od asemblera, lecz mimo wszystko trzeba było mieć głowę i cierpliwość do napisania wszystkiego samemu 🙂. Jeżeli chcesz wiedzieć "jak to się robiło kiedyś", to podejście najbardziej odzwierciedla tamte czasy 😉!
 |
Biblioteka to "najsurowszy" sposób tworzenia gry, która jedynie udostępnia zestaw funkcji umożliwiających wykonywanie operacji niskopoziomowych. To podejście zapewnia największą "liberalność" co do sposobu programowania całej gry. Jedną z przykładowych bibliotek jest "SDL", czyli "Simple DirectMedia Layer".
Źródło: Wikimedia
To może dziwić, jednak nawet po wielu latach od końca XX wieku tworzenie gier za pomocą biblioteki nadal jest popularne i widoczne wśród wielu znanych tytułów 🌟. Choćby "World of Goo" (2008) jest przykładem gry, która skorzystała z "SDL" (w skrócie "Simple DirectMedia Layer") - jednej z najpopularniejszych bibliotek do tworzenia gier ❤️!
KIEDY NAJLEPIEJ SKORZYSTAĆ Z BIBLIOTEKI DO TWORZENIA GIER?
W obecnych czasach, w dobie dzisiejszych możliwości i pełnego dostępu do silników gry, tworzenie gier za pomocą biblioteki najlepiej zastosować tylko przy 3 okolicznościach 👇:
- dla celów edukacyjnych, aby poznać cały proces programowania niskopoziomowego,
- do portfolio do prezentacji w formie publicznego repozytorium (pokazujesz, że radzisz sobie z niskopoziomowym programowaniem i jesteś przygotowany(-a) na "hardkorowe" samodzielne implementacje reszty niezbędnych funkcjonalności),
- do gier, w których jest potrzeba zapewnienia architektury dającej najwięcej swobody (jak najmniej zależności od innych bibliotek, możliwość elastycznego modyfikowania na wiele różnych sposobów, portowanie na największą liczbę platform itp.).
Jeżeli jednak zależy Ci po prostu na stworzeniu gry, to dużo lepiej skorzystać z gotowych rozwiązań w postaci "framework'ów" i silników gry, które zostały już dawno opracowane przez inne osoby i to kilkanaście lat temu 😉! Nie wynajduj koła na nowo - tylko stracisz czas 🚫!
JAKIE SĄ BIBLIOTEKI DO TWORZENIA GIER?
Poniżej są wypisane biblioteki do tworzenia gier, dzięki którym można tworzyć gry "w najsurowszej" formie 👇:
Porównując do pozostałych pojęć wymienionych w artykule, biblioteka "stoi" najbliżej systemu operacyjnego i zapewnia najmniej abstrakcji 1️⃣. Następny jest "framework"!
CZYM JEST FRAMEWORK DO TWORZENIA GIER?
"Framework" to już nieco inna konstrukcja. To również zestaw uprzednio zdefiniowanych funkcji do stosowania przez nas, natomiast w przeciwieństwie do biblioteki on już narzuca nam strukturę pisania kodu 😲. Innymi słowy, może wymagać jakiejś specyficznej konstrukcji w kodzie źródłowym, aby narzędzie zadziałało w sposób oczekiwany.
Częstą postać jaką dostrzeżesz we "frameworkach", to zdefiniowanie funkcji o sztywno ustalonych nazwach i listach parametrów, na które narzędzie "reaguje" ℹ️. Na przykład będziesz musiał(a) napisać funkcję o nazwie "update" z jednym parametrem "dt", co sprawi że wszystkie instrukcje znajdujące się w środku tej funkcji, będą wykonywać się co klatkę 🔥.
To jest przykład "narzucenia" metodyki pracy ⚠️. Zamiast pętli "while" masz podział na funkcje działające jak wywołania zwrotne (ang. callback), czyli "framework" oczekuje, że one się znajdą w Twoim kodzie i będzie w ten sposób nawiązywał z nimi łączność ⚡. Mogą być inne rodzaje narzucania postaci kodu, natomiast to jest najpopularniejsze ℹ️.
Drugą cechą "framework'ów" jest wbudowana możliwość eksportowania gry na daną platformę 💛. Zazwyczaj robi się to poprzez jakieś polecenie wpisywane tak jak w wierszu poleceń np. "export" 👍. Nie zawsze tak musi być, jednak zazwyczaj występuje 😉.
 |
"Framework" to druga metoda tworzenia gry, która poza zestawem uprzednio przygotowanych funkcji, narzuca nam sposób pisania kodu i ogranicza nam swobodę w jego konstruowaniu. "LÖVE" jest przykładem znanego "frameworka" do tworzenia gier.
Źródło: Löve Logo Graphics
"Frameworki" także są popularnym podejściem do tworzenia gier i są to na "dowody" w postaci popularnych produkcji 🏆! Przykładem jest "Kingdom Rush" (2011), które zostało stworzone w "LÖVE", jednym z najpopularniejszych "framework'ów" do tworzenia gier (co ciekawe, także korzysta z "SDL" 🙂) 💥!
KIEDY NAJLEPIEJ SKORZYSTAĆ Z FRAMEWORKA DO TWORZENIA GIER?
"Framework" do tworzenia gier będzie najlepszym wyborem, jeśli interesuje Cię tworzenie gier wyłącznie przy pomocy kodu, a jednocześnie nie masz ochoty na operowanie na niskich warstwach systemu i nie planujesz tworzenia skomplikowanej technicznie gry 👍. Tutaj te funkcje występują na nieco wyższym poziomie abstrakcji (np. nie trzeba samemu dbać o alokowanie i zwalnianie pamięci ✔️) i ta wygoda z korzystania z funkcji jest odrobinę bardziej odczuwalna, niż przy samej bibliotece ℹ️.
Granica zaczyna się zacierać w momencie, gdy czujesz, że będziesz chciał(a) mieć dodatkowe edytory WYSIWYG (ang. What Is You See Is What You Get), czyli np. okna do podglądu sceny na żywo bądź skorzystać z gotowych rozbudowanych rozwiązań do obsługi sterowania, fizyki, wtyczek dodawanych do edytora itd. (choć mogą być wyjątki przy niektórych narzędziach np. "PICO-8" - posiada edytory, natomiast wciąż sam(a) dbasz o obsługę sterowania!) ❌.
Wtedy "framework" odpada i powinieneś/powinnaś sięgnąć po silnik gry, bo to jedyny rodzaj narzędzia do tworzenia gier dający użytkownikowi pełnię możliwości tak, abyś mógł/mogła "przeskoczyć" całą konstrukcję podstawowych funkcjonalności gry, jak np. sterowanie czy rysowanie tekstu 🔔!
JAKIE SĄ FRAMEWORKI DO TWORZENIA GIER?
Oto lista znanych "framework'ów" do tworzenia gier 👇:
- Kha,
- LÖVE,
- MEG-4,
- KorGE,
- nCine,
- pyxel,
- Usagi,
- Ebiten,
- PICO-8,
- libGDX,
- Phaser,
- PixiJS,
- pygame,
- TIC-80,
- WASM-4,
- Ceramic,
- Gideros,
- Solar2D,
- Heaps.io,
- MonoGame,
- Picotron,
- HaxeFlixel,
- Bitty Engine.
"Framework" jest rozwiązaniem "stojącym" pomiędzy niską warstwą systemu, a poziomem abstrakcji. Tutaj ta abstrakcja jest wyższa, stąd mamy nieco więcej luzu, lecz "płacimy" za to mniejszą swobodą w podejściu do programowania ℹ️. Musisz zdecydować co jest dla Ciebie ważniejsze 🫵!
CZYM JEST SILNIK GRY?
Silnik gry to najbardziej rozbudowany wariant spośród wszystkich 3 sposobów tworzenia gier (obok biblioteki i "frameworka") 💪. Narzędzie zapewniające największe możliwości po stronie deweloperskiej, które składa się z następujących cech 👇:
- wsparcie wielu okien do pracy nad grą w stylu WYSIWYG (podgląd sceny na żywo, edycja modeli, podgląd wyglądu materiału itp.),
- wsparcie programowania gry bez pisania kodu (programowanie wizualne poprzez tworzenie i łączenie ze sobą bloków),
- obsługa wtyczek lub pakietów rozbudowujących podstawowe możliwości edytorów silnika (przykładem są pakiety silnika "Unity"),
- uprzednio przygotowane i zaawansowane moduły do obsługi podstawowych technicznych aspektów gry (wygładzanie krawędzi, automatyczne dopasowywanie elementów interfejsu użytkownika do rozdzielczości, obsługa sterowania dla wielu różnych urządzeń naraz, fizyka itp.).
Można go określić podejściem "all-in-one" 😉. Kluczowym określeniem jest wyjście poza edytor kodu 🎯. W zależności od rodzaju narzędzia tutaj również możemy pisać kod, natomiast cały proces tworzenia gry jest poszerzony o dodatkowe okna do edycji. Modyfikacje już nie pochodzą od samego edytora kodu, lecz dotyczą również o wiele szerszego zakresu 👇:
- budowanie sceny,
- rozstawianie obiektów,
- nakładanie materiałów na obiekty,
- animowanie i modelowanie (o ile silnik gry wspiera taką możliwość),
- konfigurowanie projektu poprzez okno ustawień.
To są rzeczy, których nie znajdziesz ani w bibliotece, ani we "frameworku" 😄. Tu jest najwyższy poziom abstrakcji i "wyręczania" od żmudnej pracy 🚀!
 |
Silnik gry to najbardziej zaawansowane podejście do tworzenia gry, które ma zapewnić maksimum swobody przy jednoczesnym "wyręczeniu" użytkownika od tworzenia najbardziej podstawowych elementów technicznych. Przykładem znanego silnika gry jest "Unity".
Źródło: Guidelines for Using Unity Trademarks
Jak można się domyślić, silniki gry także doczekały się wielu hitów 🌟. "Cuphead" (2017) jako popularna platformówka z graficznym stylem kreskówek z lat .30, została stworzona w silniku "Unity" będącym jednym z dwóch najczęściej wykorzystywanych silników w produkcji komercyjnej (zaraz obok "Unreal Engine") 🔥!
KIEDY NAJLEPIEJ SKORZYSTAĆ Z SILNIKA GRY DO TWORZENIA GIER?
Wtedy, gdy wiesz, że potrzebujesz narzędzia o potężnych możliwościach, który od razu zapewni Ci w pełni działającą aplikację na miejscu, a duża zajętość pamięci na dysku Twoich gier i silnika, nie gra roli 💾. Musisz liczyć się z tym, że duża liczba wbudowanych funkcji będzie Cię słono "kosztować" w gigabajtach 😬. "Unity" na przykład potrzebuje "na dzień dobry" ok. 20 GB całej przestrzeni na jedną wersję, a "Unreal Engine", ok. 40 GB 😱.
Podobna sytuacja jest z rozmiarem pliku skończonej gry. Nawet "pusta" gra we "frameworku" może zajmować poniżej 1 MB (zależy od narzędzia) ✔️. Ta sama "pusta" gra wykonana w silniku gry, już może zajmować 20 MB 😨! Dużym minusem silników gry jest wymagalność dużej ilości wolnej przestrzeni na dysku i niestety to dotyczyć będzie również eksportów Twoich gier ⚠️!
Drugim punktem mogącym odpowiedzieć sobie na pytanie, jest spojrzeć na swoją grę i samemu ocenić czy rzeczywiście jest potrzebne tak duże narzędzie na taki projekt, jaki chcesz stworzyć 💡. Jeżeli chcesz tylko sobie poćwiczyć korzystanie z silnika gry, to nie będzie to robiło różnicy, natomiast warto o tym pomyśleć, gdy planujesz wydać swój produkt, bo silnik gry może okazać się niewłaściwym wyborem ❌. Skorzystasz z narzędzia, które zapewnia jakieś ogromne możliwości, natomiast nie skorzystasz z samych tych możliwości 🙂.
Gdy zależeć Ci będzie na stworzeniu "chudej" gry, która nie będzie korzystać z "shader'ów" i innych ekskluzywnych bajerów XXI wieku, warto wtedy rozważyć przejście na "framework", jeśli dalej chcesz mieć wygodniejsze tworzenie bez pisania wszystkiego od nowa lub bibliotekę, gdy chcesz poznać smak programowania z lat .90, gdy nie było niczego gotowego 💪!
JAKIE SĄ SILNIKI GRY DO TWORZENIA GIER?
Oto lista występujących silników gry do tworzenia gier 👇:
- Godot,
- Unity,
- ct.js,
- Defold,
- Solarus,
- GameGuru,
- GDevelop,
- NESMaker,
- CRYENGINE,
- GameMaker,
- RPG Maker (seria),
- CopperCube,
- Construct 3,
- SRPG Studio,
- Falco Engine,
- GameGuru MAX,
- RPG in a Box,
- Unreal Engine,
- Easy FPS Editor,
- RPG Paper Maker,
- 001 Game Creator,
- AppGameKit Studio,
- Castle Game Engine,
- Stride Game Engine,
- SMILE Game Builder,
- Pixel Game Maker MV,
- Clickteam Fusion 2.5,
- Leadwerks Game Engine.
Skończyłem 😊. Wyłożyłem cały temat najlepiej, jak byłem w stanie 😅. Od tej pory mam nadzieję, że będziesz już w stanie samemu/samej określić czym jest biblioteka, "framework" i silnik gry ✅. Często widać w sieci, że wszystkie pojęcia, choć dotyczą tej samej tematyki, są często ze sobą utożsamiane i traktowane jak synonimy 🙂.