Czym jest engine?

 

autor: Kaytek


 

   W definicji używanej ogólnie, jest to zbiór programów umożliwiających wykonywanie danej czynności (np. obsługi bazy danych). Idąc dalej: silnik gry jest główną częścią jej (gry) kodu odpowiadającą za wyświetlanie grafiki, obsługę fizyki itd. Inaczej zestaw narzędzi umożliwiających stworzenie gry. W rozumieniu klikowym definicja jest ta nieco inna. Według tej "właściwej" silnikiem Waszych gier (klikowych) jest dany klik (TGF, MMF) – w końcu to on umożliwia Wam stworzenie gry - jest narzędziem. Przyjmiemy jednak definicję, że silnik gry klikowej to zestaw zdarzeń ją obsługujący. Może teraz brzmi to trochę niejasno, ale mam nadzieję, że zrozumiesz o co mi chodzi po przeczytaniu dalszej części tego artykułu.

   Korzyści ze stworzenia silnika są bardzo wymierne: tworzenie gry "na sucho" może spowodować, że bardzo szybko zaczniesz gubić się w zdarzeniach, dodanie jednej wartości (nowego surowca itd.) może wymagać przebudowy znacznej części zdarzeń, co jest monotonne i męczące. A właśnie przez monotonne, męczące i nudne czynności upada większość projektów. Tutaj drobna uwaga: tworząc silnik musi być on na tyle "elastyczny", aby dodawanie nowych wartości w ogóle było możliwe. Co jeszcze daje stworzenie silnika? Dzięki temu można zrobić kilka gier tego samego gatunku znacznie skracając sobie czas tworzenia. Jednak, żeby nie było zbyt różowo, takie rozwiązanie ma klika wad. Wyklikanie sobie takiego enginu wymaga już pewnych umiejętności – w końcu chodzi o to, żeby silnik był dobry, a nie tylko o to, żeby był. Kolejną wadą jest czas trwania samego procesu tworzenia. W końcu im potężniejsze, łatwiejsze w obsłudze i bardziej modyfikowalne narzędzie planujesz stworzyć – tym więcej czasu stracisz. Czasu, który mógłbyś wykorzystać na tworzenie samej gry.

   Jak powinien więc taki engine wyglądać, co powinien umożliwiać? Pierwszą, bardzo ważną sprawą jest jak najmniejsza ingerencja człowieka tworzącego grę w zdarzenia samego silnika. Powinien być on tak zbudowany, że edycja zdarzeń w ogóle nie powinna być wymagana (albo w jakimś minimalnym stopniu). Najlepiej zrób sobie jakieś zewnętrzne edytory (map, surowców, czy czego tam chcesz). Gwarantuje Ci to, że jak coś raz zadziała – nie rozwalisz tego "jednym kliknięciem za daleko". Gwarantuje to też sporą wygodę – w końcu używanie wbudowanego Edytora Etapu zbyt wygodne nie jest, jeśli mapa jest specyficzna (dużo nieregularnych obiektów tła; w końcu można sobie to "narysować" własnym edytorem). Takie rozwiązanie ma jednak swoje wady – zrobienie jakiegoś specyficznego kodu (innego niż cały obsługujący plansze – skryptu, mówiąc krótko) może być trudne (ale zawsze jest to wykonalne).

   Co więc wybrać? Ja jestem zdecydowanym zwolennikiem rozbudowanych silników z zewnętrznymi edytorami, otwartych na stworzenie dowolnej gry danego gatunku. Jest to jednak bardzo trudne i (jak już pisałem na początku) wymaga pewnych umiejętności. Należy też pamiętać, że kliki nie są niezawodne – łatwo można zaprzepaścić miesiące pracy tylko dlatego, że TGF/MMF nie "lubi" danego typu zdarzeń – i już. Przy okazji: nie wspomniałem o najważniejszym – każda gra ma silnik. Są zdarzenia, które powtarzają się w danym etapie i są one raczej niemodyfikowalne – obsługują grę, czyli (co można przeczytać we wstępie do tekstu) – są silnikiem.


Przekonać się jak to wszystko wygląda możecie czytając artykuł Kamila "Skręć Se Silnik" z numeru #3 (2/2006 r.)

   Cóż więc począć? Zmierz "kaliber" swojej gry – do tetrisa nie musisz wyposażać silnika w system precyzyjnej detekcji kolizji czy symulacje fizyki – engine "skrój na miarę", bo najważniejszym jest, żeby zachować w tym wszystkim zdrowy rozsądek.

 

 

 

by pepe9donkey