Rywalizacja z C ++ w zakresie programowania gier

Jestem ciekawy, dlaczego C ++ jest tak popularny do tworzenia gier, a nie innych języków. Wiem, że możesz stworzyć z niego bardzo szybki kod, ale co dokładnie sprawia, że ​​jest popularny?

Czy to tylko dlatego, że jest szybki? Czy jest to jakaś inna funkcja w języku, taka jak paradygmat OO lub przenośność? Czy to z powodu wszystkich bibliotek, które powstały z czasem? Czy jakaś kombinacja tych (i innych) powodów?

Gdyby ktoś mógł mi to powiedzieć, byłbym bardzo szczęśliwy. :-)

Liczne powody:

• Duży, który przegapiłeś: jest przenośny, upraszczając porty silnika gry na iOS, XBOX, PS3, cokolwiek
• To jest szybkie
• Wszystkie zestawy SDK obsługują go natywnie
• Wiele dostępnych bibliotek
• Każdy, kto pisze gry, wie o tym, więc łatwo jest zatrudnić doświadczonych twórców gier dla swojego zespołu
• Osadzanie języka skryptowego silnika gry, takiego jak Lua, jest banalne

Jest kilka powodów, o których chciałbym wspomnieć oprócz tego, co poruszał @Graham.

• Legacy Code - wiele studiów ma dużo kodu C ++, wspomina o bibliotekach.
• C ++ jest naprawdę asemblerem wysokiego poziomu i ma bezpośredni dostęp do sprzętu (przynajmniej tak bezpośredni, jak można uruchomić na systemie operacyjnym) i jest dość szybki. Jeśli chcesz, w C ++ możesz przejść bezpośrednio do języka asemblera do kontroli poziomu instrukcji (nie to, że zawsze jest to mądre, po prostu nie jest możliwe w Javie, C #, Python itp.)
• DirectX i OpenGL natywnie obsługują C ++, większość innych języków ma „powiązania” z podstawowymi bibliotekami poprzez warstwy pośrednie, co nie znaczy, że nie są szybkie lub nie mogą zrobić wielu takich samych rzeczy, ale dodaje warstwę oprogramowania pomiędzy Twoja gra i sprzęt.
• Jak wspomina @Graham, wielu programistów wie o tym, więc łatwo jest znaleźć doświadczonych programistów, a także jest dość przenośny, w porównaniu do C #, który utknął w .NET Framework (istnieje Mono, ale generalnie opóźnia się o pokolenie za implementacją Microsoftu .)

Szybkość pierwotna jest głównym powodem, ale tak naprawdę nie jest to decyzja ani, więc wiele firm produkujących gry zaczyna używać innych języków w niektórych częściach gry. Niektóre zadania wymagają, aby komputer działał tak szybko, jak to możliwe (np. Podstawowe funkcje renderowania), ale wiele zadań w kodzie gry nie musi działać tak szybko (np. Otwieranie drzwi, gdy gracz je kliknie), co oznacza, że jest mądry w użyciu dla tych części znacznie prostszego (a przez to szybszego do pisania programów) języka. Dlatego wiele silników gier jest napisanych w C ++, ale zawierają język skryptowy, taki jak Lua, do pisania kodu gry.

Trudną rzeczą do zrozumienia jest to, że przy wyborze języków programowania istnieje ogólny kompromis między wydajnością komputera i wydajnością programisty. To znaczy, co jest dla Ciebie ważniejsze, jak szybko komputer uruchamia kod lub jak szybko programista pisze kod?

W C ++ można przydzielić zmienne lokalne, które znikają po zakończeniu funkcji. Zazwyczaj są one przydzielane na stosie.

Zmienne stosu nie przyczyniają się do problemów związanych z dynamiczną alokacją pamięci związaną z fragmentacją i narzutem. Przydzielanie pokoju na stosie jest szybkie i łatwe (wystarczy dopasować wskaźnik). Dynamiczny przydział pamięci zwykle polega na przeszukaniu kontenera pod kątem odpowiedniego bloku pamięci, oznaczeniu pamięci, a następnie oznaczeniu jej jako zajętej. Dealokacja obejmuje dodanie bloku pamięci do kontenera i ewentualnie połączenie go z istniejącymi blokami. O wiele więcej narzutów niż tylko zmiana wskaźnika.

Java i C # przydzielają pamięć dynamicznie, z wyjątkiem typów pierwotnych. Języki te zależą od środowiska wykonawczego, które oznaczy zmienną do usunięcia, a następnie uruchom moduł wyrzucający elementy bezużyteczne w losowych (niezaplanowanych) odstępach czasu, aby odzyskać pamięć. Zasadniczo programista nie ma kontroli nad tym, kiedy zmienna zostanie oznaczona do usunięcia, ani kiedy zostanie odzyskana (odzyskiwanie zużytej pamięci jest zaawansowanym tematem, którego nie doświadcza większość programistów C ++ i Java).

Szybkość C ++ wynika przede wszystkim z jego bezpośredniego tłumaczenia na kod wykonywalny. Java i C # są kompilowane do kodu pośredniego, który jest następnie interpretowany przez maszynę wirtualną. Zasadniczo języki interpretacyjne działają wolniej niż języki tłumaczone bezpośrednio.

Gry były kiedyś pisane w języku maszynowym, ponieważ miały egzotyczny sprzęt, dla którego nie było kompilatora. Sprzętowi brakowało również funkcji, które programiści C biorą za pewnik, takich jak wydajna matematyka na 16-bitowych liczbach całkowitych.

Gdy gry osiadły na znanym sprzęcie, kompilatory C stały się dostępne iw krótkim czasie wszystkie gry zostały napisane w C.

C ++ wydawało się kiedyś dobrym pomysłem, a większość gier jest dzisiaj C ++, ale inżynierowie mamroczą o powrocie do C, a to może się zdarzyć. Chciałbym pracować nad grą w C, podobnie jak wielu współpracowników. W C ++ nie ma żadnej nowej funkcji, która moim zdaniem poprawia gry.

Wydawałoby się teraz, że komputery są 1000 razy szybsze niż kilka lat temu, język wysokiego poziomu skróciłby czas programowania ($), czyniąc C przestarzałym.

Tak się nie stało, ponieważ kupujący gry wiedzą, że sprzęt jest 1000 razy lepszy, i chcą wymienić swoje pieniądze na grę, która wygląda i brzmi 1000 razy lepiej. Usuwa to z systemu luz, który zużywałby język wysokiego poziomu.

Wymagania dotyczące wydajności w grach są brutalne. Nowa ramka grafiki musi zostać zrenderowana w czasie poniżej 33ms (lub 16ms!). Należy uwzględnić wszystko, co robi sprzęt, aby ten budżet mógł zostać zrealizowany. Każdy język, który zadziała i robi coś ze sprzętem, którego programista nie rozumie lub nie spodziewa się, bardzo utrudni realizację tego budżetu. Jest to automatyczny minus w stosunku do czegokolwiek wysokiego poziomu.

Programiści gier nie tylko pracują w języku niskiego poziomu, ale także unikają struktur danych i algorytmów wysokiego poziomu. Gry zazwyczaj nie mają połączonych list i rzadko mają drzewa. W miarę możliwości występuje ruch w kierunku unikania wskaźników *. Każdy algorytm z czasem większym niż O (N) lub przestrzenią O (1) zwykle nie znajduje szerokiego zastosowania.

* Jeśli wskaźnik nie powoduje braku pamięci podręcznej, to po co wydawać 32 bity, aby go zapisać? Jeśli wskaźnik powoduje brak pamięci podręcznej, najlepiej się go pozbyć.

Każdy język programowania ma swoje mocne i słabe strony w wielu różnych czynnikach. Przykładami tych czynników są:

• Prędkość na konkretnej platformie
• Zużycie pamięci na konkretnej platformie
• Jaką funkcjonalność udostępnia łatwiej
• Na jakich platformach istnieje
• Jakie uwagi musi wziąć programista na pokład

Jednym z najważniejszych czynników, na których dba programista, jest wydajność. Chcą stworzyć interaktywne doświadczenie, co oznacza, że ​​musi być reaktywny i być w stanie wygenerować jak najwięcej użytecznych (lub interesujących) danych, jak to możliwe. Chcesz wiedzieć, ile masz zdrowia w dowolnym momencie i nie chcesz na to czekać. A jeśli klikniesz przycisk, oczekujesz, że wystrzeli broń lub Twoja postać podskoczy, kiedy to powiesz. Niewielkie opóźnienie może zakłócać tę interaktywność, dlatego potrzebujesz wydajności.

Innym ważnym czynnikiem jest preferowanie programowania w języku problemu, a nie w języku implementacji. Programista gier chce zajmować się ludźmi, orkami i samochodami wyścigowymi, a nie rejestrem pamięci ED0. Nadal chcą opcji nurkowania w szczegółach implementacji, jeśli potrzebują wydajności, ale byłoby świetnie, gdyby w przeważającej części potrafili radzić sobie na poziomie bytów w swoim świecie gry. Mają dość zmartwień o symulowanie świata gry bez konieczności dbania o to, jak działa połączona lista.

C ++ bardzo dobrze pasuje do tych dwóch głównych czynników. Możesz zyskać na wydajności wynikającej z asemblera lub kodu C z wyrazistością obiektów. Aby zobaczyć, dlaczego jest to naturalne dopasowanie do gier, porównaj z innymi opcjami językowymi:

• Montaż: To jest surowa moc. To, co piszesz, jest w zasadzie tym, co robi procesor. Ale na każdym etapie musisz wiedzieć, co się dzieje z rejestrami i ich skutkami, i nigdy nie wygląda to na byty w twoim świecie gry. Programista musi dokonać mentalnej zgodności tego, co robi ich kod, z tym, co dzieje się w grze. To może być dość mentalne obciążenie.
• C: Tutaj mamy dobrą wydajność, ale możemy wykorzystać doświadczenie guru, aby wykonać standardowe rzeczy (takie jak przydzielanie pamięci, operowanie na ciągach znaków i używanie standardowych funkcji matematycznych). Zbliżamy się tutaj do ekspresji, ale język mniej więcej zmusza cię do skupienia się na implementacji, ponieważ tak naprawdę możesz operować tylko na normalnych typach danych. Wszystko jest naprawdę char, int lub tym podobne. Struktury, wskaźniki i tablice mogą trzymać wszystko razem, ale nadal muszą myśleć o elementach wewnętrznych.
• Java: Przeskakujemy przez C ++ i przechodzimy do Java. Java odsuwa się od szczegółów implementacji. W rzeczywistości przez większość czasu nie masz dostępu do niższych poziomów. Java wyodrębnia wiele szczegółów implementacji (np. Jakiego procesora lub systemu operacyjnego używasz) z tego powodu, że chce być wieloplatformowy. Nie możesz uzyskać dostępu do szczegółów, ponieważ ich tam nie ma. Nie programujesz na komputer, programujesz na platformę (platformę Java, która tak naprawdę istnieje na większości komputerów). Co więcej, Java ma prawdopodobnie lepszy język do radzenia sobie w języku problemu niż C ++. Kompromis polega na tym, że nie można zoptymalizować dla konkretnego komputera. To, czy stanowi to praktyczną różnicę, sprowadza się do specyfiki programu i komputera.
• Język skryptowy gry: mam na myśli coś takiego jak UnrealScript lub niestandardowe języki skryptowe powiązane z silnikiem gry. W nich nie masz dostępu do silnika bazowego. Przekazujesz względy wydajności silnikowi, pozostawiając sobie swobodę martwienia się tworzeniem gry. Łatwiej jest napisać grę, trudniej samemu zoptymalizować jej wydajność.
• Haskell (lub twój ulubiony niejasny język): każdy język programowania Turing-zupełny jest równoważny każdemu innemu. Tak więc, podczas gdy można napisać dowolny program w dowolnym języku, zrobić kompromisów, jakiś cel, niektóre subiektywne. Język taki jak Haskell jest bardziej skoncentrowany na pracy w duchu matematycznym. Problemy, do których jest przeznaczony, są nieco inne niż problemy w grach. Nie oznacza to, że nie może lub nie powinien być używany do gier, po prostu nie jest łatwo do niego przystosowany.

Ostatnią kwestią jest to, że niektóre z nich mają charakter historyczny i polityczny. Wiele wojen płomiennych toczyło się między różnymi językami programowania. Na przykład C # może być równie odpowiedni do tworzenia gier, ale pojawił się po C ++. Lub ludziom się to nie podoba. Niektóre osoby przeprowadziły się do C #, niektóre nie. Niektóre osoby nadal programują gry w języku BASIC, Pascal i C. Bez względu na to, z czego programiści czują się komfortowo, będą się trzymać. Programiści gier byli w większości zadowoleni z C ++, być może dlatego, że dorastali z C i C ++ i spełnił ich potrzeby. Jeśli przemysł komputerowy znajduje się w stanie, w którym wydajność i upodobanie Javy satysfakcjonuje wystarczającą liczbę osób, być może Java byłaby de facto standardowym językiem programowania gier.

Dziedzictwo i pęd.

Dawno, dawno temu został napisany kod w asemblerze dla najwyższej wydajności. Wraz ze wzrostem mocy obliczeniowej, języki kompilowane stały się bardziej opłacalne, a C oferował najlepszy kompromis między mocą a produktywnością, na bardzo podstawowym poziomie niewiele więcej niż makro asembler.

C ++ był naturalnym następcą C. Nie wyrzucasz wcześniejszego kodu ani wiedzy, ale masz potencjał, by rozwinąć się w nowe metodologie. C ++ jest ostatecznie bardzo elastyczny i jeszcze nie widziałem paradygmatu projektowania, którego nie można przynajmniej symulować w C ++, a jednocześnie być w stanie utrzymać prawie całkowitą kontrolę nad wydajnością.

Jeśli tworzysz konsole, nie masz wyboru: profesjonalne zestawy SDK są dostępne tylko w wersjach C ++. Zwykle mają również dostęp do C dla większości rzeczy.

Ponieważ wielu programistów to konsole + PC, sensowne jest, aby cała ich praca na PC odbywała się w tym samym języku i bezpośrednio współdzieliła technologię.

Ponieważ tam mieszka profesjonalna branża i większość z nich chce być tego częścią, większość programistów gier to programiści C ++.

Ponieważ wszystko to się dzieje, większość programistów silników jest również programistami C ++, więc podczas oceny silników klasy profesjonalnej prawie wszystkie wybory to C ++.

To wszystko duży samopodtrzymujący się silnik. Zakłócenie tego wymagałoby więcej niż tylko postępu technicznego.

FWIW: C # zyskuje na popularności w tworzeniu gier. Zobacz post na blogu Miguela de Icazy . Bardzo ciekawa lektura, IMHO.

Chociaż jestem dość mocno przeciwny C, C i C ++, jedyną rzeczą, jaką mają, że niewiele innych języków ma, jest pełna kontrola nad platformą, na której działa, możesz być pewien, co dokładnie będzie się działo przez cały czas, nie GC, żadnych błędów.

W dzisiejszych czasach nie jest to tak ważne, ale może być w przypadku słabych platform.

Na PC / Mac / Linux jest to prawdopodobnie najmniej przenośny język, z którym się obecnie spotkasz, a premia do prędkości nie jest już tak istotną różnicą - Minecraft (Java) jest płynny i działa na dość minimalnych platformach (i dowolnym systemie operacyjnym) z jednym plikiem wykonywalnym - jeszcze nie widziałem aplikacji C / C ++ indi o niskiej sile roboczej z taką samą funkcjonalnością i tak małą liczbą błędów, nie mówiąc już o pracy na trzech platformach.

W tym momencie powiedziałbym, że większość z nich to bezwładność i koncepcja, że ​​prawdziwe gry są zawsze wykonywane w C / C ++, chociaż zdolność do „portowania” na iPhone'a i konsole jest znacząca (chociaż jestem całkiem pewny, że większość interfejsu użytkownika gier wymaga dużo wysiłku, aby przenieść je z wyjątkiem Windowsa i XBoxa.