Jaka jest różnica między strukturą gry a silnikiem gry?

Jaka jest różnica między strukturą gry (na przykład XNA z C #, SDL dla c ++) a silnikiem gry?

Czy ramy gier używają silników? Czy silnik gry zawiera silniki podrzędne, takie jak silniki fizyki, silniki cząstek itp.? Czy powinny być używane razem, czy też wyłącznie wzajemnie?

Rozumiem, że istnieją oddzielne silniki dla 2D i 3D?

Naprawdę nie ma ścisłych definicji „silnika” ani „frameworka”.

Ogólnie mówiąc, uważa się, że silnik „robi więcej” lub ma więcej narzędzi i powiązanego wsparcia niż framework, który sam w sobie jest często tylko luźnym zbiorem powiązanych funkcji udostępnianych przez niektóre zunifikowane API.

W tym celu rzeczy, które twierdzą, że są silnikami, mogą wykorzystywać rzeczy, które twierdzą, że są szkieletami, aby osiągnąć funkcjonalność, ale nie zawsze tak musi być. Podobnie rzecz, która twierdzi, że jest silnikiem gry, może twierdzić, że jej części składowe (fizyka i rendering, itp.) Są implementowane za pomocą silnika fizyki lub środowiska fizyki. Rodzaje technologii, o których mowa w obu terminach, mogą być używane zamiennie lub nie.

Mogą istnieć „silniki” lub „ramy” do wszystkiego - fizyki, dźwięku i tak, nawet grafiki 2D lub 3D.

To naprawdę tylko kwestia terminologii i ogólnie nie ma większego znaczenia. Z perspektywy funkcjonalności, perspektywy skoncentrowanej na tworzeniu gry, ważne jest, czy dana technologia zapewnia to, czego potrzebujesz do stworzenia gry. To, czy nazywa się silnikiem, czy ramą, nie ma na to żadnego wpływu.

Prosta definicja, której używam: możesz zbudować silnik na platformie, ale nigdy nie zbudowałbyś platformy na silniku. Jednym z nich jest szkielet determinujący architekturę i przebieg programu, drugi to mięsień, który działa.

Na konkretny przykład Artemis to schludny mały szkielet do budowy systemów komponentów, ale nigdy nie nazwałbyś go silnikiem. Możesz zbudować Artemis Systems i standardowe komponenty, aby stworzyć z niego silnik.

Framework to zbiór (zwykle) bibliotek niższego poziomu i pomocników, których możesz używać do robienia wszystkiego, co chcesz (grafika, dźwięki itp.). Framework nie ma nic związanego z grami, z wyjątkiem tego, że są one zazwyczaj zoptymalizowane lub zaprojektowane do robienia rzeczy, które są wspólne w grach.

Przykład: silnik pozwala mieć listę podmiotów, z których każdy ma pozycję na mapie. Szkielet umożliwia renderowanie obiektu 3d w określonej pozycji.

Łączymy je więc, dając każdemu z twoich bytów obiekt 3d, i renderujemy w razie potrzeby.

I ta-da, masz grę.

Aby uzyskać naprawdę szczegółowe wyjaśnienie, polecam przeczytać jedyną biblijną architekturę Game Engine autorstwa Jasona Gregory'ego. Myślę, że jest to najbardziej kompletna praca na ten temat, odkąd została opublikowana. Obsługuje on nie tylko część C ++, ale także i jest ważny dla każdego programisty silnika gry, stojącego za teorią / architekturą. To dobry punkt wyjścia niezależnie od języka. Aby uzyskać przegląd, mówimy o tym obrazie z książki

Pozwól, że spróbuję odpowiedzieć na pytanie.

Cokolwiek napiszesz, będzie kodem :-) po latach doświadczenia napisz, czego potrzebujesz i jak potrzebujesz lub użyj tego, co zapewnia ci to, czego potrzebujesz.

Określenia silnika i ramy pochodzą z architektury oprogramowania wraz z innymi warunkami. Zacznijmy od podstawowych warunków i przejdźmy w górę.

Biblioteka

Typowe przykłady: biblioteka matematyczna zapewniająca wszystkie podstawowe typy i funkcje do obliczeń matematycznych (Vector, Matrix, ...) lub biblioteka obrazów (jpeg lub png) zapewniająca funkcjonalność do pisania obrazów jpeg lub png

W Unity 3D Math to biblioteka matematyczna.

Teoria: libray zapewnia dedykowane funkcje wokół tematu (np. Matematyki) ORAZ jest wywoływany przez programistę na żądanie .

Podgląd: mogą istnieć biblioteki przechowujące frameworki, czyli biblioteki frameworków.

Struktura

Teoria: Framework wprowadza odwrócenie kontroli . Oznacza to, że programista przez większość czasu nie wywołuje metod frameworka, ale framework wywołuje kod programisty. Wyjątkiem są sytuacje, gdy trzeba zintegrować bibliotekę frameworka z kodem i uruchomić frameworka. Biblioteka frameworka udostępnia wszystkie metody i funkcje oraz interfejsy dla frameworka o przeznaczeniu dedykowanym. Tak więc frameworki mogą znajdować się w bibliotece.

Typowy przykład: Unity 3D MonoBehaviour zapewnia metody takie jak Przebudź, Start, OnUpdate. Deweloper wdraża te metody, a następnie metody te są wywoływane przez środowisko (zarządzanie obiektami gry) (jest to odwrócenie kontroli) . To samo z metodami OnCollisionEnter, OnCollisionExit. Są w tym samym Monobehaviour, ale założę się, że są nazywani przez ramy fizyki.

Podgląd: silnik, środowisko wykonawcze, edytor, zestaw SDK

Ponieważ termin silnik zawsze był niejasny i nadal jest (i nie staje się lepszy wraz z dalszym rozwojem technologicznym), niektóre wyjaśnienia podglądu.

Termin silnik jest używany do wielu rzeczy i nie można jednoznacznie stwierdzić, która z nich jest poprawna. W 2004 roku, kiedy po raz pierwszy zetknąłem się z pisaniem silników do gier, było to również niejasne. Miałeś silnik gry w rozumieniu kodu ładującego predefiniowane dane i pozwalającego na grę. Ponieważ ładuje predefiniowane dane, nazwano je silnikami opartymi na danych. Kompilujesz je raz, a dane zewnętrzne mogły być różnymi grami bez ich ponownej kompilacji. W pewnym momencie było to tak samo jak środowisko uruchomieniowe.

Edytor jest przejrzysty. Pozwala zdefiniować predefiniowane dane ładowane przez silnik / środowisko wykonawcze.

Silnik z edytorem nazwano SDK (np. Hammer SDK).

Potem były / są dedykowane silniki. Silnik phyiscs, silnik renderowania, silnik dźwięku, silnik zarządzania obiektami, silnik sieci ...

Moim osobistym zdaniem nie są to silniki (szczególnie silnik renderujący NIE JEST silnikiem gry, ponieważ tylko renderuje). Kiedy używam silnika gry Google, wyniki zawierają 90% czystych silników renderowania, które nie są silnikami gier. Nazwałbym je wszystkimi bibliotekami, ale ponieważ mogą ładować predefiniowane dane, pasują do terminu silnik sterowany danymi.

Ostatnia krótka uwaga, zanim przejdziemy do szczegółów: z sukcesem ukończyłem studia informatyczne. Moja praca magisterska zajmowała się tematem „jak opracować rdzeń silnika gry”. Oznacza to część kodu, która łączy wszystkie inne silniki, czy zarządzanie obiektami gry, pętla gry itp.

Swoją pracę magisterską opublikowałem jako (krótką) książkę. Jedyny komentarz kupującego / czytelnika na temat Amazon to (po kilku latach): nie chodzi o silnik gry. Ponieważ ukończyłem z sukcesem studia i dlatego obroniłem moją tezę przed 3 doświadczonymi programistami (2 z nich zajmujących się grami i aplikacjami interaktywnymi), chyba napisałem silnik gry.

Redaktor

Łatwe: pozwala zdefiniować dane w formacie, którego wymagają inne części, a zatem eliminuje potrzebę ręcznego zapisywania tych plików lub korzystania z zewnętrznych narzędzi do ich tworzenia.

Tak właśnie działa edytor Unity 3D.

Środowisko wykonawcze

Termin ten jest często używany w równym stopniu z silnikiem (który może być poprawny lub niepoprawny).

Środowisko wykonawcze wykonuje wygenerowane dane i robi to, co ma z nimi wspólnego. Np. Pokaż grę i pozwól jej zagrać. Nie tworzy żadnych danych (oprócz zapisywania gier) w tym sensie, że nie można modyfikować samej gry.

Unity Web Player to / było środowiskiem uruchomieniowym, które pozwala grać w gry Unity w przeglądarce internetowej.

Możesz ładować i uruchamiać wiele różnych gier w tym samym środowisku uruchomieniowym.

W przypadku interfejsu API skryptów Unity 3D istnieje rozróżnienie między funkcjonalnością, która będzie działać w grze, a funkcjonalnością, która będzie działać tylko w edytorze.

SDK

Termin ten często nazywany jest również „ramowym” .

Wówczas SDK był pakietem narzędzi takich jak edytor, IDE (zintegrowane środowisko programistyczne) dla programistów, eksporterów formatów danych oraz środowiska uruchomieniowego / silnika.

Tak więc zestaw SDK / framework zapewnia wstępnie zdefiniowany przepływ pracy i narzędzia oraz pokazuje (dobrze zaprojektowany) sposób (łatwego) tworzenia gry.

Zasadniczo silnik Unity 3D byłby niewłaściwy, ponieważ bardziej pasowałby do kierunku SDK. Ale ponieważ Unity jest jeszcze bardziej potrzebne, nowe słowo / definicja musi pasować do tego, czym jest.

W każdym razie, aby wprowadzić inny termin, SDK / framework zapewnia wstępnie zdefiniowany potok rozwoju gry (nie tylko potok zasobów, ale może, podobnie jak Unity, potok zasobów, logiki, kompilacji, wdrożeń, ...)

Silnik

sarkazm na Używany do wszystkiego, ponieważ każdy chce być fajny, pisząc nie tylko bibliotekę, framework lub grę, ale lepiej pisząc kompletny silnik. sarkazm

Spuśćmy to:

Silnik

1. jest kawałkiem kodu / oprogramowania
2. jest przeznaczony do ponownego wykorzystania w wielu projektach (możesz także napisać silnik gry tylko dla jednej gry)
3. za ponowne użycie silnik gry oddziela część wielokrotnego użytku od części specyficznej dla gry
4. do wielokrotnego użytku (w zależności od tego, w jaki sposób mają być ponownie użyte) istnieją różne smaki, takie jak silnik sterowany danymi ładujący dane zewnętrzne

Silnik może składać się z wielu innych silników (ponieważ obecnie wszystko nazywa się silnikiem). Silnik gry może obejmować

• silnik renderujący renderujący (PONOWNIE: cholera, cholera, piekło: kod tylko renderujący NIE JEST silnikiem gry)
• silnik fizyki wykonujący fizykę (to silnik fizyki, a nie silnik gry)
• silnik AI obsługujący sztuczną inteligencję (to silnik AI, a nie silnik gry)
• silnik sieciowy (np. RakNet) wykonujący zadania sieciowe (to silnik sieciowy, a nie silnik gry)
• silnik audio wykonujący dźwięk (to silnik audio, a nie silnik gry)

Przykład aplikacji opartej na silniku rdzeniowym zapewniającej strukturę opartą na wtyczkach do łączenia wszystkiego razem w opartym na komponentach modelu zarządzania obiektami gry. Każdy pod silnik (renderowanie dźwięku) to moduł dodawany do silnika gry jako wtyczka. Każdy element może być częścią pod silnika / modułu. A (oparte na komponentach) zarządzanie obiektami gry jest łącznikiem pomiędzy oddzielnymi modułami.

Najbliższa definicja Game Engine

Silnik gry jest częścią kodu źródłowego swojej grze, która zapewnia wszystkie funkcje , które są przeznaczone do ponownego wykorzystania po drugiej stronie wielu gier i niech Ci kod i uruchomić grę. Dlatego łączy wszystkie pozostałe części kodu (renderowanie, audio, fizyka, zarządzanie obiektami w grze, tworzenie sieci), które są bibliotekami, frameworkami lub dedykowanymi silnikami (renderowanie, fizyka, ...).

Silnik gry to bałagan na środku.

Jak już stwierdził @Josh, nie ma ścisłej definicji frameworku lub silnika, ale w sensie koncepcyjnym oba są bardzo różnymi narzędziami.

Framework zawiera podstawową funkcję API do pracy, co daje użytkownikowi narzędzia na wyższym poziomie do interakcji z platformą lub funkcjonalnością, bez (ogólnie) martwienia się o wydajność, kompatybilność itp. W podanych przez ciebie przykładach SDL to framework, który daje zachwycasz się platformą i możesz budować oprogramowanie za tą warstwą, nie martwiąc się o zarządzanie oknami, rzeczy specyficzne dla systemu operacyjnego itp. Jeśli chcesz zbudować całe oprogramowanie, będziesz potrzebować różnych platform, np. SDL do zarządzania mediami i rzeczy platformy, Box2D do zarządzania fizyką itp.

Silnik jest inny, w tym przypadku narzędzie dostarcza wszystko, co potrzebne do rozwoju, silnik fizyki zapewni ci wszystko, co potrzebne do zarządzania fizyką i dostarczy łatwy w użyciu interfejs API, więc jeśli chcesz zbudować symulację fizyki, nie będzie potrzebować żadnej innej biblioteki strony trzeciej. Silniki to nic innego jak zbiór frameworków, innych silników, interfejsów, fragmentów i ogólnego kodu, który zapewnia wszystko, co jest potrzebne do ukończenia projektu bez potrzeby korzystania z usług innych podmiotów zewnętrznych ani martwienia się o rzeczy niższego poziomu.