|
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.
|