Witam, mam takie pytanko - czy dominacja C++ w tworzeniu gier na dużą skalę (nie chodzi mi o małe gierki mobilne etc., tylko takie na PC/Konsole) będzie się utrzymywać (czy nie ma alternatyw?) i żeby pracować jako game developer koniecznie muszę znać C++ (lub C)?
0
0
Języki inerpretowane raczej marnie nadają się do bardziej skomplikowanych gier (patrz minecraft tworzony w javie), więc na chwilę obecną nie widzę alternatywy dla wymienionych przez ciebie jako "język główny". Aczkolwiek możesz np "postawić" na rozwijającą się obecnie kategorię gier przeglądarkowych, a co za tym idzie HTML5 lub podobne. Pewne elementy gry "instalowanej" mogą być też tworzone np w LUA.
0
Kolejny temat typu "kto mi wywróży".
Można podyskutować jaka jest aktualna sytuacja i dlaczego, ale przyszłość - kto to wie?
Quake II był napisany w C. Źródła: http://quakepc.webs.com/codeandscripting.htm
Nie chcesz C/C++ - użyj gotowego engine'a:
- Unity 3D: C#, JavaScript, Boo - http://unity3d.com/unity/workflow/scripting
- CryEngine: C#, Lua - http://www.packtpub.com/cryengine-game-programming-with-c-plus-plus-c-sharp-and-lua/book
- Unreal Engine: UnrealScript - http://udn.epicgames.com/Three/DevelopmentKitProgramming.html
Koszt UDK: $19/mc+5% - https://www.unrealengine.com/register
Unity to $75/mc: https://store.unity3d.com/
CryEngine: $10/mc: http://www.cryengine.com/get-cryengine/
Możesz też pewnie to taniej zogranizować, ale te enginy akurat znam (osobiście poruszam się w całkiem innych dziedzinach).
0
Wizzie napisał(a):
Witam, mam takie pytanko - czy dominacja C++ w tworzeniu gier na dużą skalę (nie chodzi mi o małe gierki mobilne etc., tylko takie na PC/Konsole) będzie się utrzymywać (czy nie ma alternatyw?) i żeby pracować jako game developer
patrząc praktycznie (marzenia odkładając na bok) wydaje mi się, że osoba startująca ma większe szanse znalezienia zatrudnienia w mniejszych firmach robiących gierki mobilne, bo chyba od razu z ulicy bez doswiadczenia, do produkcji Wiedźmina go nie wezmą...
Chociaż mogę się mylić.
0
To zależy włącznie od NAS.
Napisz kilka prostych gier - w C++ i twoim języku -, ale wymagających pod pewnymi względami, jak:
- grafika (np. dokładne, ruchome modele)
- złożoność obliczeń
- ilość obliczeń (np. pełno stworków, które coś ze sobą robią)
Następnie sprawdź benchmarki.
Jeśli twój język nie wypadł paskudnie, możesz się go trzymać.
Oczywiście na C++ warto zerknąć, jak i na każdy inny język.
0
CryEngine: C#, Lua
To znaczy, że CryEngine jest napisany w C#? O to mi się właśnie rozchodzi, bo googlowałem trochę angielskie fora i dowiedziałem się tylko tyle, że wszystkie silniki gier są pisane w C/C++ bo są najbardziej wydajne. Czyli to nie jest prawda? Jak to jest z tą wydajnością w porównaniu do np. C# (w którym osobiście piszę)?
Edit: Czy takie testy mają duże odniesienie do gier? Ogólnie C++ w większości testów sprawuje się lepiej od C#, ale niektóre zadania C# wykonuje szybciej, a w części mniej więcej w takim samym czasie. Czy ta różnica jest zauważalna przy tworzeniu dużych gier? http://www.codeproject.com/Articles/212856/Head-to-head-benchmark-Csharp-vs-NET
2
Edit: Czy takie testy mają duże odniesienie do gier? Ogólnie C++ w większości testów sprawuje się lepiej od C#, ale niektóre zadania C# wykonuje szybciej, a w części mniej więcej w takim samym czasie. Czy ta różnica jest zauważalna przy tworzeniu dużych gier?
Problemem może być nie tyle surowa wydajność przy obliczeniach numerycznych, bo ta jest naprawdę w wielu sytuacjach bardzo zbliżona pomiędzy C++, Javą i .NETem, ale zarządzanie pamięcią. Gry wymagają bardzo przewidywalnej wydajności, a języki z GC są dość trudne do optymalizacji pod tym względem, mimo olbrzymiego postępu w tej dziedzinie. W C++ masz większą kontrolę nad tym jak rozmieszczasz obiekty w pamięci, kiedy pamięc alokujesz, jak wykorzystujesz cache, kiedy zwalniasz itp. W .NET/Java, wiele z tych rzeczy dzieje się automatycznie. I teraz w zależności od gry albo możesz mieć szczęście i automat poradzi sobie dobrze z zadaniem, albo masz pecha i będziesz się babrał w optymalizację kilka lat jak się bawią z Minecraftem.
Drugą przyczyną zapewne jest wrodzony konserwatyzm branży gamedev. W gamedev pisało się w asmie, kiedy wszyscy inni pisali już w C, później przestawili się na C, gdy większość innego softu masowo pisało się w C++. Teraz piszą w C++, gdy reszta pisze w Javach, .NETach itp. - widzisz regułę?
P.S. Eksperymentalnie przepisano Quake II na Javę i okazało się, że po przepisaniu był praktycznie tak samo szybki jak oryginał, a nawet w niektórych testach nieco szybszy.
http://en.wikipedia.org/wiki/Jake2
The performance of Jake2 is on par with the original C version. In some hardware configurations, it is even better.
Tak czy siak, niezależnie od tego w czym piszesz, musisz mieć dużą wiedzę na temat tego, co się dzieje pod spodem. Inaczej czy napiszesz to w C++ czy w C#, będzie chodziło kijowo i żarło tony RAMu. Jak jesteś początkującym to zapewne lepsze efekty osiągniesz pisząc w C# z jakimś znanym silnikiem gier (unity, cryengine itp), niż klepiąc wszystko od zera samemu.
0
Eksperymentalnie przepisano Quake II na Javę i okazało się, że po przepisaniu był praktycznie tak samo szybki jak oryginał, a nawet w niektórych testach nieco szybszy.
A to nie jest tak, że gdyby teraz przepisano całego Quake II znowu w tym samym języku, to byłby szybszy? Wiesz, rozwój technik programowania itd.
albo masz pecha i będziesz się babrał w optymalizację kilka lat jak się bawią z Minecraftem.
Miałem kiedyś serwer tej gry i potrafił jednego dnia wpierdzielać 90% procesora bez powodu, a po restarcie śmigać normalnie. Ogólnie to był tworzony chwilę projekt przepisania serwera na C++ i jego wersja alpha jadła według twórców kilka razy mniej zasobów niż vanilla (sam nie sprawdzałem), projekt został porzucony z tego co pamiętam.
Jak jesteś początkującym to zapewne lepsze efekty osiągniesz pisząc w C# z jakimś znanym silnikiem gier (unity, cryengine itp), niż klepiąc wszystko od zera samemu.
Ale i tak nie będąc programistą C++ nie wbije się do tworzenia np. Wiedźmina czy Dead Island? Chodzi mi głównie o odpowiedź na pytanie: jak dużą część programistów w gamedevie stanowią programiści C++, a jaki innych języków (oczywiście mniej więcej ;p)?
0
Ale i tak nie będąc programistą C++ nie wbije się do tworzenia np. Wiedźmina czy Dead Island? Chodzi mi głównie o odpowiedź na pytanie: jak dużą część programistów w gamedevie stanowią programiści C++, a jaki innych języków (oczywiście mniej więcej ;p)?
a co za problem się tego rzeczonego C++ nauczyć? Zrobił ci coś ten język? Nie rozumiem. Przecież możesz znać kilka języków programowania.
1
Miałem kiedyś serwer tej gry i potrafił jednego dnia wpierdzielać 90% procesora bez powodu, a po restarcie śmigać normalnie. Ogólnie to był tworzony chwilę projekt przepisania serwera na C++ i jego wersja alpha jadła według twórców kilka razy mniej zasobów niż vanilla (sam nie sprawdzałem), projekt został porzucony z tego co pamiętam
To nie jest zasługa C++, tylko tego że poprawili zapewne parę bugów. Prób przepisania minecrafta na C++ było kilka i żadna się nie powiodła. Przepisywanie oprogramowania na C++ tylko ze względu na wydajność na ogół kończy się źle - z innych przykładów przychodzi mi do głowy HyperTable (ok, wiem, że to nie gamedev), którego twórcy otwarcie twierdzili, że będzie wielokrotnie szybszy niż inne NoSQLe typu BigTable, bo napisany w C++. Tymczasem minęło parę lat i co? Raz, że ostatnią stabilną wersję wydali w połowie 2013 roku, czyli z punktu widzenia klienta projekt jest martwy, dwa, że obecne ich własne benchmarki pokazują, że są szybsi od HBase'a raptem jakieś 20%-2x, więc z dumnych zapowiedzi marketingowców niewiele zostało. Komercyjnie, pod względem zdobycia rynku, prawie nie istnieją.
Ale i tak nie będąc programistą C++ nie wbije się do tworzenia np. Wiedźmina czy Dead Island?
Raczej się nie wbije. Przynajmniej nie teraz, kiedy klasyczny gamedev (nie-mobilny) nie chce patrzeć na nic innego oprócz C++. Inna rzecz, że w gamedevie płacą relatywnie mało w stosunku do innych branż w IT i warunki pracy (przynajmniej w Polsce) są takie sobie, więc trzeba gry naprawdę lubić aby w to się pakować - inaczej nie ma sensu.
0
Dzięki wielkie za odpowiedzi :)
0
Tak sobie właśnie poczytałem o .NET Native - myślicie, że to krok w stronę .NET w gamedevie? Microsoft zapowiada ogromny skok wydajności.
http://blogs.msdn.com/b/dotnet/archive/2014/04/02/announcing-net-native-preview.aspx
0
Z tego co na szybko przeczytałem i zrozumiałem to jest to coś porównywalne z kompilacją AOT. Tyle, że w .NETu to już było. A w Javie też jest, ale za grube pieniądze: http://www.excelsiorjet.com/
Wątpię, by .NET zdominował gamedev. .NET jest praktycznie przyspawany do Windowsa. Mono można olać, bo nie ma wsparcia od MS, tylko od Xamarina z 170 pracownikami (a nie wszyscy z nich to koderzy). C++ jest przenośny i jak już napisał Królik - daje dużo większą kontrolę nad pamięcią (RAM) niż języki zarządzane (wyjątek być może C# z unsafe dodatkami, no ale to unsafe w końcu).
0
Mono można olać, bo nie ma wsparcia od MS, tylko od Xamarina z 170 pracownikami (a nie wszyscy z nich to koderzy).
Na tym polu dzieje się obecnie dużo i IMO będzie się dziać jeszcze więcej. Xamarin i Mono mają coraz większe wsparcie od Microsoftu i codebase'y Mono i .NET mają coraz więcej wspólnego kodu (ostatnio uwolnione zostały BCL oraz kompilator). Nowy kod Microsoftu ma pokrycie Mono w swoich testach (nowe wersje ASP.NET, Entity Framework). Subscriberzy MSDN mają dostęp do Xamarina na iOS i Androida na preferencyjnych warunkach. Skończy się to za kilka lat tym, że Microsoft ich pewnie wykupi.
Wątpię, by .NET zdominował gamedev. .NET jest praktycznie przyspawany do Windowsa.
A Mono nie jest tak mało znaczące jak ci się wydaje. Unity jest coraz popularniejsze i dopiero zaczęło zwracać uwagę większych developerów. Blizzard swojego Hearthstone'a napisał w Unity/Mono/C# na PC, Maki oraz iOS i nie są chyba z tego powodu bardzo nieszczęśliwi.
0
Przede wszystkim należy rozgraniczyć pisanie core (silnik gry) od implementacji samej gry. W tym pierwszym przypadku (na którym się skupię) dominować będą języki z ręcznym zarządzaniem pamięci (głównie C/C++). Samą grę pisze się już raczej w językach o wyższym poziomie abstrakcji (podkreślam słowo raczej).
Dlaczego ręczne zarządzanie pamięcią jest takie ważne w obszarze gier? Bo dostęp do pamięci zawsze jest kosztowny (dostęp do sterty). "Dąży" się do jak największej alokacji statycznej. Z tego płynie interesujący wniosek - STL nie nadaje się do pisania gier ;) Wynika to głównie z implementacji std::allocator (http://en.cppreference.com/w/cpp/memory/allocator). Programiści silników gier (klasy AAA) przeważnie implementują swoją wersję STL, bazując (przeważnie) na Scope Stack Allocation (http://dice.se/wp-content/uploads/scopestacks_public.pdf). Inną opcją jest użycie przystosowanej wersji STL - np. EASTL (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html). Dodam, że miałem przyjemność porozmawiać z głównym programistą silnika CD Projektu (RED Engine) - oni także bazują na własnej implementacji STLa.
Warto wspomnieć o innych problemach z jakimi muszą borykać się programiści silników gier klasy AAA. Kilka przykładów:
- unikanie metod wirtualnych,
- przenośność kodu,
- problemy z CPU cache np. false sharing.
Jak widać pisanie kodu na poziomie silnika gry nie ogranicza się do znajomości samego języka programowania. Taka praca wymaga sporej wiedzy nt CPU & GPU. Taka wiedza przeważnie nie jest domeną programistów języków o wyższym poziomie abstrakcji.