Dlaczego twórca gier napisałby własny silnik zamiast korzystać z istniejących?


41

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?



1
Nie chcą licencjonować silników gier innych firm i płacić im.
János Turánszki

Myślę, że to właśnie robisz, gdy masz wokół siebie pracowników 9K + ...
glampert

3
Istnieje kilka kontrprzykładów dużych studiów nagraniowych, które tworzą tytuły AAA przy użyciu zewnętrznych silników, takich jak Unreal lub CryEngine .
Philipp

3
Valve zaczęło od silnika Quake, a potem napisało własne do późniejszych gier. Często trzeba nauczyć się korzystać z tego, co jest dostępne, a następnie chcieć osiągnąć coś więcej niż to, co oferuje istniejący silnik. W tym momencie musisz dokonać ciężkich modyfikacji lub rzucić własne.
Nairou

Odpowiedzi:


53

Istnieje kilka powodów, dla których studio może zdecydować się na „budowę” zamiast „zakupu” swojej technologii:

  • Starsza technologia; studio mogło zacząć budować swój własny zestaw narzędzi, zanim istniało dla niego realne oprogramowanie pośrednie.
  • Specyficzne wymagania; studio może mieć określoną kolekcję wymagań, która nie jest dobrze dopasowana do istniejącego oprogramowania pośredniego lub
  • Problemy budżetowe; studio może nie być w stanie pokryć kosztów lub zobowiązań umownych związanych z istniejącym oprogramowaniem pośrednim.
  • „Syndrom tu nie zbudowany;” kierownictwo techniczne studia może być ostrożne (w sposób uzasadniony lub nieuzasadniony) w zakresie technologii, której nie zbudowali, a zatem nie do końca rozumieją.

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.


20
Dodałbym, że czasami technologie są „budowane tutaj”. Jednym z przykładów jest to, w jaki sposób Unity3D zmienia swoje umowy EULA dla każdej wersji i dodaje dziwne ograniczenia, takie jak brak „gier hazardowych”. Gdy licencjonujesz technologię, jesteś na łasce licencjodawcy, aby nie zawracać i nie cofać licencji bez żadnego konkretnego powodu (dzieje się tak z prawami własności intelektualnej do tworzenia licencjonowanych gier) lub decydować się na obciążenie Cię za naprawienie ich błędów.
Skrylar

poważnie, Unity mówi „nie ma gier hazardowych”? Mieli nawet specjalną stronę dotyczącą hazardu w sekcji Społeczność na swojej stronie internetowej!
jhocking

Strona Unity tutaj unity3d.com/industries/gambling mówi, że możesz kupić „licencję Unity Gambling”. Nie znalazłem za to ceny, ale wydaje się, że nadal pozwalają ci tworzyć gry hazardowe, pod warunkiem, że płacisz za specjalne licencje.
Alex

1
Ponadto łatwiej jest zacząć od tego, co już wiesz, i ostatecznie zbudować silnik, nawet nie wiedząc, co to jest silnik. Silnik to nic innego jak zbiór przypadków użycia; jeśli próbujesz zmniejszyć nadmiarowość, kończysz pisanie silnika, a jeśli próbujesz po prostu zbudować grę, kończysz na monolitycznym systemie. Bardzo trudno jest uzyskać silnik gry i nauczyć się, jak wyświetlać piksel, a następnie uświadomić sobie, że nie może tego zrobić, ponieważ widzi wszystko jako teksturę. Nie musisz sobie z tym poradzić, pisząc własne.
Dmitry

18

jak powiedział Josh Petrie :

Nie zbudowano tutaj syndromu ”;

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.


13
To brzmi bardziej jak rozpaczliwa anegdota osobista; prawdopodobnie możesz to edytować, aby uczynić go bardziej zwięzłym i byłby lepszą odpowiedzią.
Josh

2
To wszystko z pewnością świetnie nadaje się do nauki, a także do tworzenia gry, gdy masz czas na wszystko. Kiedy to naprawdę tylko ty. Ale co jeśli kiedykolwiek będziesz chciał z kimś współpracować? A może pracujesz w firmie z innymi programistami? Jeśli ktoś chciałby dołączyć do twojego projektu, czy to nie jest dziwne, że miałby wtedy czytać Twój kod - dla nich kod innej osoby… to jest to, czego NIENAWIDZI. Uważam, że czytanie kodu jest również bardzo ważną umiejętnością. Bez obrazy, jestem pewien, że wiele się nauczyłeś i napisałeś fajny silnik - wystarczy pamiętać, że to nie wszystko.
antont

Zdaję sobie sprawę z tego, że każda praca, którą wykonywałem przy użyciu dowolnego kodu w dowolnym języku, zawsze była dla mnie solo;
Codie Morgan

Muszę powiedzieć, że wiem dokładnie, z jakich powodów ktoś uruchamia własny silnik / narzędzie / cokolwiek innego. Ale ma swoją cenę (jak wszystkie rzeczy) ... Mam wrażenie, że wszyscy szefowie po prostu nienawidzą tego, gdy nie możesz odczytać / zrozumieć najbardziej okropnego kodu na świecie, więc idź dalej i wrzuć się jako ** * ton źle napisanego źle utrzymanego kodu bez dokumentacji, po prostu poczuj go („prawdziwy” świat). Bez urazy.
Quonux

Dlatego my, programiści, nie możemy mieć miłych rzeczy. Ponieważ zawsze chcemy robić wszystko sami zamiast korzystać z działających i zaufanych metod. Mam kompulsywną potrzebę napisania wszystkiego samemu, ale powoli uczę się ufać innym i jak dotąd robi mi to więcej niż źle :)
Maurycy

15

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.


3
Jest to jedna wielka zaleta, której doświadczyliśmy przy użyciu silnika open source (cocos2d-iphone). Możemy debugować go dokładnie tak samo, jak napisany przez nas kod. Uważam, że sposobem myślenia o otwartym kodzie źródłowym jest to, że jest to twój kod. Jeśli są jakieś błędy, będziemy musieli je naprawić, jak w każdej innej części naszego kodu ..
Antont

1
Można to powiedzieć o dowolnym oprogramowaniu pośrednim. Kod debugowania stanowi 80% pracy programisty, a obsługa oprogramowania pośredniego jest częstym problemem w technologii, na której dzisiaj siedzimy, z większą ilością oprogramowania pośredniego niż możemy zliczyć. Nauka przezwyciężania tego to tylko część pracy. Jeśli silnik się nie zepsuje, dzieje się coś, nad czym nie masz kontroli. Mniej ruchomych części jest dobrym pomysłem, ale kiedy komplikuje się jak twórca gry, będziesz musiał poradzić sobie z wieloma z nich.
Tim

@ Tymczasem zdecydowanie się nie zgadzam - że jedna rzecz zewnętrzna może źle się zachowywać w sposób trudny do debugowania, nie oznacza, że ​​powinniśmy tylko wzruszyć ramionami i pogodzić się z tym, że wszystko źle się zachowuje w sposób trudny do debugowania. Oczywiście trzeba brać sprawy indywidualnie, ale silnik to duży system, w którym często czają się trudne błędy . Dlaczego nie chcesz tego mieć pod kontrolą, skoro możesz sobie na to pozwolić?
Trevor Powell

@TrevorPowell oczywiście pochodzi ona w dół do złożoności projektu i jak mówisz, indywidualnie dla każdego przypadku, ale po prostu wymyślania koła (szczególnie jeśli jest to duże koła) musi być poważnie brana pod uwagę w odniesieniu do czasu zapisanego przez nie robi to. Oprogramowanie pośrednie ułatwia rzeczy. Jako programiści wierzymy, że zawsze możemy wynaleźć rozwiązanie, aby było ono lepsze bez zastanowienia się, jak dobrze to rozwiązanie jest połączone. Kilka nierówności> ponowne wymyślenie> Całkowicie złe rozwiązanie
Tim

2
@Tim RE: „Oprogramowanie pośrednie ułatwia”, najwyraźniej miałem inne doświadczenia niż ty.
Trevor Powell,

9

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.


2
Warto zauważyć, że w czasach, gdy gry takie jak Unreal były budowane po raz pierwszy, po prostu nie było innego wyjścia, jak pisać wszystko od zera. To tylko kilka ostatnich lat, kiedy mamy wybór silników N ...
joltmode,

3

Istnieją inne powody, dla których studio może zdecydować się na „budowę” zamiast „zakupu” swojej technologii:

  • Nowe platformy : nowy mobilny system operacyjny, konsola lub kontrolery. Pomyśl o leapmotion, Google Glass itp. Obsługa wielu platform jest trudna
  • Nowa mechanika gry i / lub edytory w grze : Pomyśl o WSE kilka lat temu (2D vs 3D)
  • Brak dobrych darmowych edytorów gier typu open source . Brak dobrej dokumentacji dotyczącej istniejącego źródła starych gier
  • Ewolucja narzędzi w łańcuchu narzędzi studia (lub dodaj nowe)
  • Ceny silników i wojny licencyjne

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ą:

  • Ponowne użycie kodu : silnik już używany w innych grach jest bardziej testowany, bardziej stabilny i może mieć większość potrzebnych funkcji, począwszy od pierwszego dnia.
  • Rozszerz : możesz rozszerzyć niektóre silniki open source.
  • Bezpłatnie : lub prawie za darmo, ponieważ nawet darmowe silniki open source potrzebują trochę czasu dla programistów, aby się uczyć.

2

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

  • Zobaczysz znacznie więcej gier korzystających zarówno z UE4, jak i CryEngine.
    Nie będą to jednak gry AAA takie, jakie były.
  • Niestandardowe wymagania i potrzeby dla każdego projektu nie znikną.
    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.
  • Istnieją inne na rynku. Jak Jedność.
    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.


1
Nie nazwałbym Havoka „mocno zmodyfikowanym”.
Josh

Czy Havok nie jest tylko silnikiem fizyki?
Philipp

Tak jest, a GW2 nie zrobiło z tego wiele uwagi, którą pamiętam.
Josh

Nie masz na myśli (ie.: you want UE, not UDK only.)?
Keavon

#JoshPetrie: Przepraszam, szczerze mówiąc, nie mam doświadczenia w Havok / nigdy z nim nie grałem. Natknąłem się więc na plik LICENCJI GW2, a kilka dni temu odwiedziłem stronę wiki i zobaczyłem Havoka. Potem miałem trochę starych wspomnień o zobaczeniu „Havoka” na początku gry, gdzie myślałem, że to silnik. Ale wtedy też spojrzałem na Havoka i wiedziałem, że to silnik fizyki. tl; dr: Mieszałem różne rzeczy na temat Havoka. || #Philipp: To coś więcej, ale w rzeczywistości nie jest to silnik gry, mój zły. || #Keavon: Racja, naprawione. Dzięki!
Apache

0

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


0

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.


0

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:

  • Licencjonuj silnik
  • Zmodyfikuj / dostosuj silnik do swoich potrzeb
  • Wypuść grę i wygeneruj pieniądze
  • Utwórz własny silnik do następnej gry

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.


-2

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ę


6
-1 Jeśli pracujesz nad jakimkolwiek projektem o odpowiednich rozmiarach, w rzeczywistości oczekuje się, że użyjesz funkcji / klas, których nie znasz, jak zostały napisane, i możesz nie być w stanie napisać jednego bez konieczności studiowania liczby książek na temat. Nie mówię o tym, co każdy programista powinien wiedzieć, ale silnik gry to ogromny projekt, i oczekuje się, że specjalistyczny temat X programisty X nie ma wiedzy w temacie Y i dlatego muszę korzystać z tej funkcji, ja też nie jestem sugerując, że nie powinieneś wiedzieć, jak korzystać z interfejsu API, powinieneś, ale możesz nie mieć wystarczającej wiedzy, aby go napisać.
concept3d

2
Czy twój nauczyciel wie, jak zbudować od podstaw kompletny samochód z pierwiastków chemicznych? Czy kieruje nim, zakładając, że to po prostu działa ;-)
Kromster mówi o wsparciu Moniki

1
@ concept3d istnieje różnica między pracą nad projektem, w którym ktoś inny projektuje te funkcje / klasy, których używasz, ponieważ zwykle, jeśli czegoś nie rozumiesz, można to łatwo wyjaśnić, programista, który korzysta z klas / funkcji / bibliotek kodu / nie wie, że to głupia osoba, nawet klasy i interfejsy API, które są dostępne publicznie, zawierają podręczniki i wiki wyjaśniające, co robią te interfejsy API lub funkcje, aby po prostu oczekiwać, że go użyje się, nie wiedząc, jak to działa głębokie wody, nie wiedząc, jak pływać, i naprawdę nieświadomy i podatny na błędy
thingybingytie

@ hopjoppe5 Jeśli sprawdzisz zaakceptowaną odpowiedź, są to jedyne powody, dla których ludzie budują własną technologię. Wiele bibliotek / kodu pochodzi z outsourcingu w prawdziwym świecie i trzeba z niego korzystać. Czytanie instrukcji różni się od znajomości implementacji, w przypadku niektórych algorytmów nawet odradza się jej samodzielną implementację i powinny zostać zaimplementowane przez ekspertów w tej dziedzinie, jeśli masz doświadczenie w świecie rzeczywistym, zrozumiesz to. Wiedza o wszystkim jest niemożliwa.
concept3d

Jednym z głównych powodów abstrakcji jest pisanie kodu, aby ludzie, którzy nie wiedzą, jak to działa, mogli go nadal używać. Podczas pracy nad grą większą niż pong nie jest prawdopodobne, że znasz każdy fragment kodu. I w większości przypadków jest to dobra rzecz, ponieważ oznacza, że ​​możesz skoncentrować się na tym, nad czym teraz pracujesz, zamiast martwić się, jak system wejściowy może obsłużyć twoją prośbę o zdarzenie „Przy naciśnięciu klawisza działania”.
Aidiakapi
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.