Zauważyłem, że wielu dużych i znanych twórców gier często opracowuje własne silniki. Przykłady obejmują Valve, Crytek, Ubisoft, Epic Games i Square-Enix.
Czy może to być po prostu dlatego, że mogą, lub jest prawdopodobne, że istniejące silniki nie spełniają wystarczających wymagań, więc opracowalibyśmy własne? Nie mogę sobie wyobrazić gry, która wymaga określonego silnika. Takie jak Unity lub Unreal są po prostu wystarczające do stworzenia dowolnej gry; nawet jeśli nie, mają kod źródłowy, który można modyfikować, aby zaspokoić nawet niektóre nadzwyczajne potrzeby.
Dlaczego twórca gier napisałby własny silnik zamiast korzystać z istniejących?
game-industry
business
PaulD
źródło
źródło
Odpowiedzi:
Istnieje kilka powodów, dla których studio może zdecydować się na „budowę” zamiast „zakupu” swojej technologii:
Ogólnie rzecz biorąc, sensowne jest posiadanie i kontrolowanie rzeczy, które są kluczowe dla sukcesu Twojej firmy, i zlecanie na zewnątrz tych, które nie są.
W przypadku niektórych studiów aspekt projektowania lub opowiadania historii w ich grach może być kluczowym zasobem, którego osiągnięcia oczekują. W przypadku tych studiów sensowne jest po prostu zakupienie technologii, która pozwoli ich projektantom zrealizować odpowiednią wizję.
Dla innych technologia może być podstawą sukcesu. Na przykład wytwórnie, które budują MMO, będą musiały same zbudować tę infrastrukturę, ponieważ ma to decydujące znaczenie dla ich sukcesu (a istniejące oprogramowanie pośrednie jest ogólnie nieodpowiednie, przynajmniej w przypadku większych tytułów „AAA”).
Zauważ, że niektóre z wymienionych przez ciebie studiów (w szczególności Crytek i Epic) zasadniczo przestały próbować dominować bezpośrednio na rynku gier i prawie na pewno robią o wiele więcej jako dostawcy oprogramowania pośredniego niż jako twórcy gier.
źródło
jak powiedział Josh Petrie :
Piszę też własny silnik i przypuszczam, że powód będzie inny dla każdego programisty, ale tak naprawdę - generalnie nie lubię pracować w kodzie innych ludzi. Jestem kompulsywny w tym sensie, że jeśli czuję, że mógłbym sam go zbudować, nie ma sensu zadowalać się czymkolwiek innym .
Testowałem różne typy silników gier, renderowanie API i takie, w szczególności Ploobs, UNITY WaveEngine, XNAFinalEngine, Love, Ogre itp. Wiele innych ... Chciałem zacząć pisać gry - ściągnąłem dużo, szukając dobrego komfortu i dobrze udokumentowany punkt wejścia ...
Mój problem polegał jednak na tym, że nie miałem pojęcia, co dzieje się pod silnikiem. Chciałem dobrej kontroli i chciałem ramy, które znam jak tył mojej dłoni. Wpadłem na pomysł „HEJ! Myślę, że jedynym sposobem, aby dowiedzieć się, jak to działa i zrozumieć, jest próba zbudowania własnego silnika całkowicie i całkowicie od zera. Większość mojej historii programowania dotyczyła rozwiązań internetowych i przetwarzania - to była dla mnie zupełnie nowa gra w piłkę.
I tak właśnie skończyłem.
Zdecydowałem się więc skonfigurować XNA, ponieważ znałem już język C # i zacząłem myśleć o tym, jak i od czego powinienem zacząć. Potrzebowałem pomysłu.
Zdecydowałem, że bez względu na wszystko przejdę prosto do 3D .
Zrozumienie podstaw było fajne - wsadowe duszki, ale w miarę postępu odkryłem nowe bariery i przeszkody - moim pierwszym prawdziwym był limit wsadu . Moim celem było stworzenie gry, która w dowolnym momencie mogłaby renderować co najmniej 10000 podmiotów w widoku frustum.
Wyruszyłem w nową podróż do implementacji Instancji opartej na Shaderze (podczas gdy nauczyłem się HLSL), porzuciłem wbudowane w XNA obiekty Model i Efekt, aby zamiast tego napisać własne zamienniki. Na początku miałem problem ze zrozumieniem strumieni VBO; Zepsułem różne rzeczy - przeszedłem do sieci, zadając pytania na temat instancji, i trzymałem się tego, dopóki w końcu nie zrozumiałem, co robi GPU. Opłaciło się; teraz po kilku dniach debugowania mojego VBO z PIX (dxsdk) miałem ponad dwadzieścia tysięcy jednostek testowych powiększających się w moim obszarze wyświetlania.
Teraz miałem „jakieś” pojęcie o tym, jak działały potoki renderowania, ale jeszcze tego nie zrobiłem - ostatecznie stworzyłem własny stan gry, kamerę, efekty postu i obiekty bytu, odsuwając się od potoku treści XNA, budując własny moduły ładujące (osobista niechęć do rzeczy XNB), stworzyły skomplikowany, posortowany łańcuch geometrii i oddzielony stanem mieszania, a także miały instancje sprite'ów i tekstu wyświetlane na scenie gry.
Ciągle dodawałem, naprawiałem, zmieniałem i eksperymentowałem z tym przez prawie cały rok. W końcu wyszło całkiem nieźle. Teraz zrozumiałem, co dzieje się pod maską, bo to stworzyłem - moje dziecko.
Teraz mój silnik był w większości stabilny i prawie gotowy. To nie jest idealne: skrypty są uczciwe, a GUI wcale nie było świetne. Ale nadal mi się podobało. Tysiące wierszy kodu, zasobów i mediów - ukrytych w prywatnym repozytorium git 2 GB, i wszystkie problemy, z którymi musiałem się zmagać, próbując zrobić coś, czego nigdy wcześniej nie robiłem. Każda pokonana przeze mnie przeszkoda była wyciągniętą lekcją - i ulgą.
Wyciągnąłem prawie wszystko, co chciałem.
Ale w końcu - zdecydowałem, że czas ją położyć. O ile usatysfakcjonowałem się pisaniem tak ogromnego silnika samemu, z radą sieci i innych znajomych z gamedev, zdecydowałem, że zrobię to jeszcze raz - i zrobię to lepiej - ponieważ teraz tym razem głównie wiem co ja robię.
Ten projekt wciąż jest ukryty w moim repozytorium GIT.
Mój drugi krok przy pisaniu nowego silnika (tym razem na MonoGame) postępuje dobrze. Kiedy coś się psuje, łatwiej to naprawić. Mniej bałaganu Mam nadzieję, że w tym roku publicznie pokażę swoją grę, ponieważ jestem trochę „zbyt” przywiązany do mojego kodu.
Na koniec napisałem własny silnik, w jaki sposób nauczyłem się „jak” to robić, a jednocześnie móc powiedzieć, że wiem i rozumiem dokładnie, co robi każdy element i jak powinny działać. Nienawidzę czytać kodu innych ludzi, szczególnie w przypadku dużych nieudokumentowanych projektów. Chcę, aby wszystko, czego używam, zostało zbudowane przeze mnie.
Ale to tylko ja. Wątpię, czy kiedykolwiek użyję gotowego silnika, prawdopodobnie dlatego, że myślę, że pisanie własnych frameworków to dla mnie więcej zabawy niż siedzenie i zajmowanie się kodem innej osoby - pełna kontrola.
źródło
Absolutnym kluczowym powodem napisania własnego silnika (i zaskakuje mnie to, że nikt tego jeszcze nie wywołał) jest debugowanie .
Jeśli napisałeś dużą, skomplikowaną grę, w której występuje błąd awaryjny, a masz kod źródłowy (i dobrze go znasz dzięki temu, że go napisałeś), możesz po prostu podłączyć debugger do proces i znajdź przyczynę awarii. Gotowy.
Jeśli korzystasz z komercyjnie dostępnego silnika innej osoby i nie masz kodu źródłowego dla tego silnika (zwykle tego nie robisz), debugowanie wszelkich problemów, które się pojawią - nawet wewnątrz własnego kodu - będzie być monumentalnie trudniejszym. A jeśli napotkasz błąd w samym silniku, nie będziesz w stanie samodzielnie go rozwiązać. Jak chciałbyś spędzić tydzień przed datą premiery i pozwolić, aby ktoś odkrył błąd awarii w używanym silniku - błąd awarii, którego nie można naprawić, ponieważ jest to silnik zastrzeżony, do którego nie należy masz kod źródłowy? Widziałem, jak to się dzieje - nie masz innego wyjścia, jak wysłać pilną pomoc do sprzedawcy i mam nadzieję, że uda mu się (i jest zainteresowany) naprawienie problemu za Ciebie, podczas gdy będziesz się rozglądać,
Gra jest trudna, ale debugowanie jest trudniejsze o rząd wielkości. W mojej książce wszystko, co utrudnia tworzenie gier, ale ułatwia debugowanie, to ogromna wygrana netto.
źródło
Są tutaj bardzo dobre odpowiedzi, ale brakuje im jednego ważnego dodatkowego punktu.
Wiele dzisiejszych licencjonowanych silników zaczynało jako silniki dedykowane .
Weźmy za przykład Unreal, ponieważ jest tak wszechobecny.
Dzisiaj, gdy myślisz o Unreal, zwykle myślisz o silniku, na który masz licencję i którego możesz używać zamiast budowania własnego, ale nie zawsze tak było i kiedyś silnik Unreal nawet nie istniał jako oddzielny byt.
Dawno, dawno temu istniała gra o nazwie Unreal . Twórcy postanowili zbudować własny silnik, a nie licencjonować istniejący . Szybkie przewijanie do przodu przez kilka iteracji, a silnik ten staje się silnikiem Unreal, który znamy dzisiaj.
Chodzi o to, że jest to problem z kurczakiem i jajkami. Każda część oprogramowania pośredniego, na które można nabyć licencję, zaczynała się gdzieś i często nie zaczynała się jako oprogramowanie pośrednie (czasami nie było nawet napisane z zamiarem zostania oprogramowaniem pośrednim, a jego obecny stan jest w rzeczywistości wypadkiem ). Ludzie piszą własne silniki, ponieważ ostatecznie ktoś musi napisać silnik, a dzisiejszy dedykowany silnik może stać się jutro licencjonowanym oprogramowaniem pośrednim.
źródło
Istnieją inne powody, dla których studio może zdecydować się na „budowę” zamiast „zakupu” swojej technologii:
Zgadzam się również z konkretnymi prośbami / potrzebami, a ceny silników i wojny licencyjne zmuszają niektóre studia do uruchomienia niektórych silników.
Dobrymi motywami do „kupowania” lub „używania” innych silników są:
źródło
Powód historyczny (głównie).
Co jest związane z cenami.
Każda gra, którą widziałeś w Unreal lub CryEngine w ostatnich latach, musiała zapłacić ogromną sumę pieniędzy. Zwłaszcza jeśli chcesz uzyskać kod źródłowy (tzn .: chciałeś UE, a nie tylko UDK).
Ale to się zmieniło. Teraz każdy może sobie pozwolić na jeszcze większe silniki, gdy rozpoczął się wyścig cenowy.
Co to znaczy...
Nie będą to jednak gry AAA takie, jakie były.
Zobacz silnik Warhammer40k / COH w Relic lub ten, którego generałowie używali w EA.
Więc nawet jeśli kogoś stać na większe silniki, niekoniecznie oferują lepszy wybór.
Ludzie uwielbiają to za łatwość użycia, szybką wydajność i ogromny magazyn aktywów.
Oczywiście Unity może wdrożyć na prawie każdej platformie.
Więc tak. Potrzeby, ceny w przeszłości i tym podobne.
źródło
(ie.: you want UE, not UDK only.)?Co z organizacją zespołu?
Za materiałami do debugowania stoi dokumentacja i wsparcie, brak kodu, ponieważ na koniec nie chciałem, aby moja grupa budowlana dotknęła kodu mojego silnika. To może być bałagan.
Potrzebuję do tego grupy wsparcia. Ale to podnosi koszty: więcej ludzi, więcej miejsc, więcej telefonów stacjonarnych, więcej administracji ...
Jednym z rozwiązań może być outsourcing ... do firmy zajmującej się oprogramowaniem pośredniczącym, która udostępnia zasoby mojej firmie tworzenia gier, tj. Grupie twórczej i pisarzom.
Dla firmy rozpoczynającej działalność nie jest to zła opcja użycia i niebudowania. Po uzyskaniu masy krytycznej dochodów być może po prostu będziesz chciał zbudować własny silnik ...
źródło
dobrze. dla większości gier korzystających z własnego silnika stworzonego przez ich twórców. często. nie mogą robić rzeczy z silnikiem innej firmy. dlatego robią własne, aby ułatwić tworzenie własnej gry. lub przynajmniej możliwe.
i wiele gier, które używają własnego silnika po prostu ogólnie. Pracuj lepiej. ponieważ są bardziej niestandardowe i w 100% dopasowane do swoich zadań. a sama gra wygląda inaczej. bardzo łatwo jest grać w tę grę i powiedzieć, że została stworzona przez. nierealny silnik czy coś takiego. bardziej niestandardowy silnik, który powinien dać unikalną grę. wygląda wyjątkowo i działa wyjątkowo i powinien działać lepiej niż gra, która została stworzona na gotowym silniku.
źródło
Moja odpowiedź różni się od istniejących, więc dodaję ją, choć jest późno:
Jeśli weźmiesz przykład Valve z pytania lub serii Wiedźmin, proces był następujący:
To samo podejście jest stosowane przez prawie wszystkich rozsądnych finansowo programistów, którzy opracowują własny silnik. Modyfikując silnik, gromadzą wiedzę na temat działania silnika i napotykają ograniczenia projektowe wynikające z licencjonowanego silnika. Na koniec dysponują wiedzą wewnętrzną niezbędną do stworzenia silnika, środkami pieniężnymi na sfinansowanie stworzenia silnika oraz projektem, który skorzysta z dedykowanego silnika. W tym momencie powodem do zbudowania silnika jest: Ponieważ jest to mądra rzecz do zrobienia.
źródło
mój nauczyciel programowania powiedział nam, że używaj tylko API / metod / klas / funkcji, które wiesz jak zbudować
ponieważ jeśli nie wiesz, jak to zbudować i korzystasz z cudzej pracy, to nie wiesz, jak to działa, a kiedy nie wiesz, jak coś działa, to jesteś bardziej podatny na błędy i problemy i uderzasz w ściany zamieszania
uczenie się prostych rzeczy może, gdy złożone, powodują dziwne problemy, nie mówiąc już o czymś złożonym, takim jak silnik gry, zwłaszcza gdy masz używać tego silnika do uruchamiania gry, co może prowadzić do wielu nieoczekiwanych rezultatów i problemów
a silnik gry nie przestrzega kodu logicznego ani żadnej innej logiki po ich zbudowaniu, pewne rzeczy można się spodziewać, ale w rzeczywistości wszystko zostanie zbudowane na podstawie znajomości jakiegoś języka programowania lub działania systemu
na przykład, jeśli zdecyduję się napisać równanie matematyczne, mogę napisać je na tyle sposobów, że mogę je przedstawić za pomocą wielomianów, rachunku różniczkowego lub podstawowej geometrii lub algebry, lub czegokolwiek, co mi odpowiada, ale czasami napisałbym w pewnej formie / formacie, ponieważ chcę aby móc manipulować tym, co jest łatwo dostępne, na przykład gdybym planował wykonać wiele operacji na wierzchołkach, mógłbym napisać ten model matematyczny przy użyciu podstawowej geometrii, jednak jeśli chciałbym zmienić krzywą za pomocą gradientów, mógłbym skupić się na rachunku różniczkowym, aby móc aby łatwo manipulować gradientami itp. i to samo dotyczy wszystkiego, co planuję mieć łatwiejszy dostęp
a czasami obecny silnik gry może nie dać mi elastyczności w tym, co zamierzam zrobić, a może nawet daje tę opcję, ale jest to bardzo trudne, ponieważ silnik gry koncentruje się na siłach fizycznych jako głównym źródle ruchu i manipulacji obiekty w grze
w każdym razie mam nadzieję, że wyjaśniłem, na co próbowałem zwrócić uwagę
źródło