Jaka jest różnica między frameworkiem gry (na przykład XNA z C #, SDL dla c ++) a silnikiem gry?
Czy frameworki gier używają silników? Czy silnik gry zawiera silniki podrzędne, takie jak silniki fizyczne, silniki cząsteczkowe itp.? Czy powinny być używane razem, czy tylko wzajemnie?
Rozumiem, że istnieją oddzielne silniki dla 2D i 3D?
Komentarze
Odpowiedź
Tak naprawdę nie ma ścisłych definicji „silnika” lub „frameworka”.
Ogólnie rzecz biorąc, silnik jest uważany za „robiącego więcej” lub mają więcej narzędzi i powiązanego wsparcia niż framework, który sam w sobie jest po prostu luźnym zbiorem pokrewnych funkcji udostępnianych przez jakiś ujednolicony interfejs API.
W tym celu rzeczy, które twierdzą, że są silnikami, mogą używać rzeczy, twierdzą, że są frameworkami do osiągnięcia funkcjonalności, 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 renderowanie itp.) są implementowane za pomocą silnik fizyczny lub framework fizyki. Rodzaje technologii, do których odnoszą się oba terminy, mogą być używane zamiennie lub nie.
Mogą istnieć „silniki” lub „ramy” dla prawie wszystkiego – fizyki, dźwięku i tak, nawet grafiki 2D lub 3D.
To naprawdę tylko terminologia problem i generalnie nie ma to większego znaczenia. Z punktu widzenia funkcjonalności, perspektywy skupionej na tworzeniu gry, ważne jest, czy dana technologia zapewnia to, czego potrzebujesz, aby stworzyć grę. To, czy nazywa się silnikiem, czy frameworkiem, nie ma na to żadnego wpływu.
Odpowiedź
Prosta definicja, której używam : możesz zbudować silnik na frameworku, ale nigdy nie zbudowałbyś frameworku na silniku. Jeden to szkielet, który określa architekturę i przepływ programu, a drugi to mięśnie, które wykonują pracę.
W przypadku konkretnego Na przykład Artemis to zgrabny, mały framework do budowania systemów składowych, ale nigdy nie nazwałbyś tego silnikiem. Możesz zbudować Artemis Systems i standardowe komponenty, aby stworzyć z niego silnik.
Komentarze
- W mojej firmie ktoś zaprojektował framework na silniku. ten framework służy jako zbiór brakujących części, których silnik nie ' dostarcza, ujednolica rzeczy, które poza tym są nieco nieporządne w naszym (starym) silniku. I zapewnia pomocników ułatwiających tworzenie.
Odpowiedź
Framework to zbiór (zwykle) bibliotek niższego poziomu i rzeczy pomocnicze, których możesz użyć, aby zrobić, co chcesz (grafika, dźwięki itp.). Framework nie ma nic związanego z grami poza tym, że są one zwykle zoptymalizowane lub zaprojektowane do robienia rzeczy, które są typowe w grach.
Przykład: silnik umożliwia utworzenie listy jednostek, z których każda ma określoną pozycję na mapie. Framework pozwala renderować obiekt 3D w określonej pozycji.
Więc łączysz je, dając każdemu z twoich obiektów obiekt 3D i renderując je w razie potrzeby.
Ta-da, masz grę.
Odpowiedź
Aby uzyskać naprawdę szczegółowe wyjaśnienie, polecam przeczytanie jednego i tylko biblia Architektura silnika gry Jason Gregory. Wydaje mi się, że jest to najbardziej kompletna praca na ten temat od czasu jej opublikowania. Nie tylko zajmuje się częścią C ++, ale także i dla każdego programisty silnika gier, za którą stoi teoria / architektura. To dobry punkt wyjścia, niezależny od języka. Aby uzyskać ogólny zarys, mówimy o tej ilustracji z książki
Spróbuję odpowiedzieć na pytanie.
Cokolwiek napiszesz, będzie to kod 🙂 po latach doświadczeń napisz, czego potrzebujesz i jak tego potrzebujesz lub użyj tego, co zapewnia Ci to, czego potrzebujesz.
Warunki silnik i framework przyjdź z architektury oprogramowania wraz z innymi warunkami. Zacznijmy więc od podstawowych terminów i przejdźmy wyżej.
Biblioteka
Typowe przykłady: biblioteka matematyczna zawierająca wszystkie podstawowe typy i funkcje do obliczeń matematycznych (wektor, macierz, …) lub biblioteka obrazów (jpeg lub png) zapewniająca funkcjonalność do pisania obrazów jpeg lub png
W Unity 3D Matematyka to biblioteka matematyczna.
Teoria: biblioteka zapewnia funkcje związane z danym tematem (np. matematyka ) AND jest wywoływane przez programistę na żądanie .
Część poglądowa: mogą istnieć biblioteki przechowujące frameworki, czyli będące biblioteką frameworków.
Framework
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ątki dotyczą sytuacji, gdy musisz zintegrować bibliotekę frameworka w swoim kodzie i musisz uruchomić framework. Biblioteka frameworka zawiera wszystkie metody i funkcje oraz interfejsy dla frameworka z przeznaczeniem do dedykowanego użycia. Dlatego frameworki mogą znajdować się w bibliotece.
Typowy przykład: Unity 3D MonoBehaviour udostępnia metody takie jak Awake, Start, OnUpdate. Programista implementuje te metody, a następnie metody te są wywoływane przez strukturę (zarządzania obiektami gry) (jest to odwrócenie kontroli) . To samo z metodami OnCollisionEnter, OnCollisionExit. Działają w tym samym Monobehaviour, ale założę się, że są wywoływane przez framework fizyki.
Podgląd: silnik, środowisko wykonawcze, edytor, SDK
Ponieważ termin silnik był zawsze niejasny i nadal jest (i nie poprawia się wraz z dalszym rozwojem technologii) jakimś wstępnym wyjaśnieniem.
Termin silnik jest używany do wielu rzeczy i nie można jednoznacznie stwierdzić, która z nich jest właściwa. W 2004 roku, kiedy po raz pierwszy zetknąłem się z pisaniem silników gier, było to również niejasne. Miałeś silnik gry w znaczeniu pewnego rodzaju kodu ładującego predefiniowane dane i pozwalającego ci grać. Ponieważ ładuje predefiniowane dane, nazywano je silnikami opartymi na danych. Skompilowałeś je raz, a dane zewnętrzne mogły być różnymi grami bez ich ponownej kompilacji. W pewnym momencie było to to samo, co środowisko wykonawcze.
Edytor jest przejrzysty. Pozwala zdefiniować predefiniowane dane ładowane przez silnik / środowisko wykonawcze.
Silnik z edytorem został nazwany SDK (np. Hammer SDK).
Wtedy były / są dedykowane silniki. Silnik phyiscs, silnik renderujący, silnik dźwięku, silnik zarządzania obiektami gry, silnik sieciowy, ….
Moim zdaniem to nie są silniki (zwłaszcza silnik renderujący NIE JEST silnikiem gry, ponieważ wykonanie). Kiedy wyszukuję silnik gier Google, wyniki zawierają 90% czystych silników renderujących, które nie są silnikami gier. Nazwałbym wszystkie z nich bibliotekami, ale ponieważ mogą ładować predefiniowane dane, pasowałyby do terminu silnik oparty na danych.
Ostatnia krótka uwaga dodatkowa, zanim przejdziemy do szczegółów: pomyślnie ukończyłem studia magisterskie z Informatyka. Moja praca magisterska dotyczyła tematu „jak rozwinąć rdzeń silnika gry”. To znaczy część kodu, która podpowiada wszystkie inne silniki, czy zarządza obiektami gry, pętla gry itp.
Pracę magisterską opublikowałem jako (krótką) książkę. Jedyny komentarz kupującego / czytelnika na temat Amazon brzmi (po kilku latach): nie chodzi o silnik gry. Ponieważ ukończyłem pomyślnie studia i obroniłem pracę przed 3 doświadczonymi programistami (2 z nich zajmujących się grami i aplikacjami interaktywnymi), chyba napisałem silnik gry.
Edytor
Łatwe: pozwala zdefiniować dane w formacie, którego wymagają inne części, a tym samym eliminuje konieczność zapisywania tych plików ręcznie lub za pomocą narzędzi zewnętrznych, aby je utworzyć.
To właśnie robi edytor Unity 3D.
Środowisko wykonawcze
Ten termin jest często używany na równi z silnikiem (co może być poprawne lub niepoprawne).
Środowisko wykonawcze wykonuje wygenerowane dane i robi z nimi to, co ma do czynienia. Np. Pokażę ci grę i pozwól ci grać. Nie tworzy żadnych danych (z wyjątkiem zapisów gier) w tym sensie, że nie można za jego pomocą modyfikować samej gry.
Unity Web Player jest / był środowiskiem wykonawczym umożliwiającym granie w gry Unity w przeglądarce internetowej.
Możesz ładować i uruchamiać wiele różnych gier w tym samym środowisku wykonawczym.
W przypadku interfejsu API skryptów Unity 3D istnieje różnica 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 jest często nazywany także frameworkiem .
W tamtych czasach SDK był pakietem narzędzi takich jak edytor, IDE (zintegrowane środowisko programistyczne) dla programistów, eksporterów formatów danych i środowiska wykonawczego / silnika.
Zatem SDK / framework zapewnia wstępnie zdefiniowany przepływ pracy i narzędzia oraz pokazuje (dobrze zaprojektowany) sposób jak (łatwo) stworzyć grę.
Zasadniczo silnik Unity 3D byłby zły, ponieważ pasowałby bardziej do kierunku SDK. Ale ponieważ Unity jest jeszcze bardziej potrzebne, aby dopasować to, czym jest, potrzebne jest nowe słowo / definicja.
W każdym razie, aby wprowadzić inny termin, SDK / framework zapewnia predefiniowany proces tworzenia gier (nie tylko zasób potok, ale może, tak jak Unity, potok dla zasobów, logiki, kompilacji, wdrożeń itp.)
Silnik
sarkazm na Używany do wszystkiego, ponieważ każdy chce być fajny pisząc nie tylko bibliotekę, framework lub grę, ale lepiej napisać kompletny silnik. sarkazm z
Uruchommy to:
Silnik
- to fragment kodu / oprogramowania
- ma być ponownie użyty w wielu projekty (możesz także napisać silnik gry tylko dla jednej gry)
- za ponowne użycie silnik gry oddziela część wielokrotnego użytku od części specyficznej dla gry
- w celu ponownego użycia (w zależności od tego, jak to jest przeznaczone do ponownego wykorzystania) istnieją różne smaki, takie jak silnik oparty na danych ładowanie danych zewnętrznych
Silnik może składać się z wielu innych silników (ponieważ obecnie wszystko nazywa się silnikiem). Silnik gry może zawierać
- silnik renderujący wykonujący renderowanie (ZNOWU: Boże, cholera: kod wykonujący tylko renderowanie NIE JEST silnikiem gry)
- silnik fizyki zajmowanie się fizyką (to silnik fizyki, a nie silnik gry)
- silnik AI obsługujący rzeczy AI (to silnik AI, a nie silnik gry)
- a silnik sieciowy (np. RakNet) zajmujący się siecią (jest to silnik sieciowy, a nie silnik gry)
- silnik audio zajmujący się dźwiękiem (to silnik audio, a nie silnik gry)
Przykład aplikacji opartej na silniku rdzeniowym zapewniającym platformę opartą na wtyczkach do łączenia wszystkiego razem w modelu zarządzania obiektami gry opartym na komponentach. Każdy silnik podrzędny (renderujący dźwięk) to moduł dodawany do silnika gry jako wtyczka. Każdy komponent może być częścią silnika podrzędnego / modułu. Zarządzanie obiektami gry (oparte na komponentach) jest łącznikiem między oddzielnymi modułami.
Najbliższa definicja silnika gier
silnik gry jest częścią kodu źródłowego Twojej gry, która zapewnia wszystkie funkcje , czyli przeznaczony do ponownego użycia w wielu grach i umożliwiający kod i wykonanie Twoja gra. Dlatego wskazówki razem wszystkie inne części kodu (renderowanie, dźwięk, fizyka, zarządzanie obiektami gry, sieć), które są biblioteki, frameworki lub dedykowane silniki (renderowanie, fizyka, …).
Silnik gry to bałagan w środku.
Odpowiedź
Jak już powiedział @Josh, nie ma ścisłej definicji frameworka lub silnika, ale w sensie koncepcyjnym oba są bardzo różnymi narzędziami.
Framework zawiera podstawową funkcję API do pracy, dając użytkownikowi narzędzia wyższego poziomu do interakcji z platformą lub funkcjonalnością bez (ogólnie) martwienia się o wydajność, kompatybilność itp. W podanych przez Ciebie przykładach SDL jest frameworkiem, daje rezygnujesz z platformy i możesz tworzyć oprogramowanie za tą warstwą bez martwienia się o zarządzanie oknami, rzeczy specyficzne dla systemu operacyjnego itp. Jeśli chcesz zbudować całe oprogramowanie, będziesz potrzebować innego frameworki, np. SDL do zarządzania mediami i platformą, Box2D do zarządzania fizyką itp.
Silnik jest inny, w tym przypadku narzędzie dostarcza wszystko, co jest potrzebne do rozwoju, silnik fizyki zapewni ci ze wszystkim, co potrzebne do zarządzania fizyką, i będzie dostarczać łatwe w użyciu API, więc jeśli chcesz zbudować symulację fizyki, nie potrzebujesz żadnej innej biblioteki innej firmy. Silniki to nic innego jak zbiór frameworków, innych silników, interfejsów, fragmentów kodu i ogólnego kodu, który zapewnia wszystko, co jest potrzebne do ukończenia projektu, bez potrzeby innych stron trzecich ani martwienia się o rzeczy niższego poziomu.