Jakie technologie są obecnie wykorzystywane do tworzenia gier? [Zamknięte]

Ilekroć zadaję pytanie dotyczące rozwoju gry na forum online, zawsze otrzymuję sugestie, takie jak nauka algorytmów rysowania linii, manipulowanie obrazem na poziomie bitowym i dekompresja wideo itp.

Jednak patrząc na gry takie jak God of War 3, trudno mi uwierzyć, że można je opracować przy użyciu tak niskich technik.

Niesamowita gra tego typu sprzeciwia się jakiejkolwiek zrozumiałej (jak dla mnie) metodologii programowania.

Poza tym sprzęt do gier jest teraz naprawdę potworem. Jest więc oczywiste, że programiści będą pracować na wyższym poziomie abstrakcji.

Jaka jest najnowsza metodologia rozwoju w branży gier? Jak to się dzieje, że zespół 30-35 programistów (z których większość to puch zarządzania i marketingu) jest w stanie tworzyć takie zadziwiające gry?

Jeśli pytanie wydaje się zbyt ogólne, czy mógłbyś wyjaśnić architekturę gry God of War 3? Albo jak poszedłbyś na produkcję klona? Myślę, że powinien być obiektywnie odpowiedzialny.

Zastrzeżenie: Jestem nie deweloper gier wideo. Ale interesuje mnie „hobbysta”.

Większość gier AAA, które widzisz, powstają przy użyciu silników. Nie są napisane od podstaw. Pomyśl o silniku jak o ramie. Masz platformę .NET, Java SDK, zestaw narzędzi Cocoa.

Wszystkie rzeczy, które ułatwiają tworzenie oprogramowania i usuwanie kodu zlewu kuchennego. Jest to konieczne, ale pisanie go za każdym razem jest bardzo bezproduktywne.

Korzystając z tych silników, deweloper może budować swoją grę i nie martwić się o część bazowego kodu. ( Nie pomyl się, tworzenie gier jest jedną z najtrudniejszych gałęzi inżynierii oprogramowania. )

Na przykład Unreal Engine 4 ma zestaw deweloperski i studio dla zabójców:

http://www.youtube.com/watch?v=MOvfn1p92_8

Istnieje wiele różnych silników. Niektóre są płatne, inne bezpłatne, niektóre bardziej do metalu, inne oferują większą abstrakcję.

Na przykład:

• OGR
• Unreal Engine
• Jedność
• Źródło
• i wiele więcej...

W nawiązaniu do komentarza gbjbaanb, niektóre z rzeczy, które sprawiają, że programowanie gier jest zabawne, to ograniczona żywotność podstawy kodu i brak wymagających precyzji. Na przykład, jeśli projektujesz grę FPS, a algorytm ruchu czasami umieszcza twoją postać w grze o kilka pikseli dalej, to nic wielkiego i nie ma szans, że nikt tego nie zauważy. Jeśli projektujesz oprogramowanie biznesowe i od czasu do czasu funkcja sumowania kosztuje kilka dolarów, jest to o wiele poważniejszy błąd. Dlatego podczas projektowania gier niektóre aspekty mogą być znacznie mniej precyzyjne (i muszą przejść tylko testy na ludziach, a nie zautomatyzowany zestaw testów, który sprawdza, czy odpowiedzi są poprawne).

Z mojego doświadczenia wynika, że ​​programowanie gier, szczególnie dla gier w czasie rzeczywistym, jest czymś zupełnie innym niż ... prawie każde inne oprogramowanie, które zrobiłem, może poza pracą z graficznym interfejsem użytkownika. Musisz spróbować!

Odpowiedź brzmi „silniki”. Wiele gier jest zbudowanych na różnych silnikach graficznych i gameplay, które są w zasadzie dużymi bibliotekami lub frameworkami.

W świecie OSS spójrz na przykład na Ogre , na komercyjne gry, które lubisz Source.

W grę wchodzą inne czynniki, takie jak duża część kodu, która jest jednorazowa i nie przejdzie w środowisku biznesowym - ale to dlatego, że ograniczona żywotność gry i przyspieszone ramy czasowe programowania oznaczają, że kod jest (prawie) zaprojektowany tylko do pracy, a nie do utrzymania.

Unity3D jest naprawdę fajny. Oto kilka punktów, które mi się podobają:

• pozwala budować gry w sposób niezależny od platformy, a następnie automatycznie tworzy wdrożenia dla systemów Windows, Mac OS X, Android i IOS. Dotyczy to bieżącej wersji (3.x). Najwyraźniej wersja 4 pozwala również na wdrożenie w systemie Linux:

http://en.wikipedia.org/wiki/Unity_(game_engine)#Major_features

• Nawet jeśli potrzebujesz płatnej licencji, aby móc z niej faktycznie korzystać (komercyjnie), możesz załadować bezpłatną wersję, w której możesz korzystać z większości funkcji (tj. Nie możesz na przykład udostępniać wdrożeń na platformach mobilnych). To świetny sposób na podgląd rzeczy, zanim zdecydujesz się ją kupić lub nie:

http://unity3d.com/unity/licenses

• Działa z większością programów do modelowania 3D (wolę 3d Studio Max, ale obsługuje również inne):

http://unity3d.com/unity/editor/importing (przewiń nieco w dół)

• Kodowanie (skryptowanie) można wykonać w języku C #, który jest przyjemnym językiem, z dobrym interfejsem API i kontrolą czasu kompilacji. Pochodzi z dobrym środowiskiem programistycznym (IDE i wszystko). Jeśli chcesz czegoś innego, obsługuje również Javascript.

• Ma bardzo dobre wsparcie fizyki (zderzenia, grawitacja, siły itp.):

http://docs.unity3d.com/Documentation/Manual/Physics.html

• Ma sklep z zasobami, który pozwala kupować różne modele, skrypty, animacje itp. W zależności od twoich umiejętności (i portfela) możesz je zdobyć / zmodyfikować, aby szybko uzyskać przyzwoite zasoby do gry.

• Last but not least, jest przyzwoicie szybki. Sprawdź dema urządzeń mobilnych, IMHO poruszają się całkiem dobrze i mają bardzo przyzwoitą grafikę:

http://unity3d.com/gallery/made-with-unity/game-list

Oto jeden fajny projekt Unity, na który obecnie czekam:

Pustkowie Briana Fargo 2

Mają fajny wpis na blogu o tym, dlaczego wybrali Unity , a także inne dyskusje na temat tego, jak przebiega współpraca .

ID Software jest jednym z dostawców, który zazwyczaj publikuje najnowsze gry. Kilka lat później często publikują je jako open source. Na stronie http://fabiensanglard.net/quake3/index.php można znaleźć analizę kodu źródłowego Quake3. Jest to dość szczegółowy opis i chociaż Quake3 jest dość stary, tymczasem koncepcje nadal powinny być istotne dla współczesnych gier.

I tak, jeśli chcesz zbudować najnowocześniejszy, szybki, konkurencyjny silnik do gry, musisz znać wszystkie te elementy niskiego poziomu. Jeśli nie chcesz się tym przejmować: Dostępne są różne silniki (silnik quake3 lub te z innych odpowiedzi), ale dobrze, to nie tworzysz nowej rewolucyjnej gry ;-)

Jak wspomina wiele odpowiedzi, dużą rolę odgrywają silniki gier i biblioteki. Należy jednak pamiętać, że dotyczy to średnich gier komercyjnych bardziej niż małych gier niezależnych.

Na przykład na platformach mobilnych większość gier jest pisana przy użyciu jedynie zestawu stosunkowo prymitywnych bibliotek, zamiast polegać na pełnych mechanizmach gier i ramach. Istnieją, ale w przeważającej części chodzi o ponowne użycie własnego kodu z wcześniejszych projektów.