Czy C ++ jest zastępowane przez C # w grach branżowych?

W grach branżowych mam na myśli Quake, CoD itp.

W pewnym sensie C ++ jest naprawdę zastępowany - nie tylko przez C #, ale przez mnóstwo innych języków. Ale jeśli zapytasz, czy zastąpi to całkowicie - wtedy odpowiedź jest zdecydowanie przecząca .

To dlatego, że C ++ jest tradycyjnie używany w dwóch wersjach. Po pierwsze, aby stworzyć silnik gry : komponenty niskiego poziomu, które ładują zasoby, przesuwają wielokąty do ekranu i chrupią liczby w symulacjach fizycznych. Po drugie, aby zakodować logikę gry : rzeczywiste zasady gry.

Ta druga pojemność nie wymaga mocnych stron C ++ (takich jak pełna kontrola nad szczegółami niskiego poziomu), ale ma swoje słabości (takie jak podatne na błędy ręczne zarządzanie pamięcią). W tej drugiej pojemności C ++ jest zastępowany przez różne języki skryptowe. Wielu programistów używa Lua; niektórzy używają Pythona. Ale jeśli dostępna jest platforma CLI w formie .NET lub Mono, jest to świetny kandydat na gospodarza skryptów. Platformy te są dość szybkie, niezawodne, oferują powszechnie znany język (C #) i obszerną bibliotekę klas podstawowych. Nie zapominajmy o narzędziach: MS Visual studio i SharpDevelop / MonoDevelop mogą nie być najlepszymi IDE na świecie, ale są całkiem dobre.

To powiedziawszy, silnik gry nie będzie napisany w C # (ani Lua, ani Python, jeśli o to chodzi). Czemu? Ponieważ nie są wystarczająco szybkie.

W przeciwieństwie do wielu popularnych przekonań, największy obecnie hit wydajności wynika z opóźnienia pamięci . Oznacza to, że dostęp do pamięci to poważna sprawa. Języki zarządzane nie pozwalają użytkownikowi kontrolować dostępu do pamięci - właśnie dlatego są „zarządzane” w pierwszej kolejności. Tak więc żaden zarządzany język nie pozwoli napisać naprawdę szybkiego silnika gry. Właściwie wszystkie duże silniki „C #”, o których mogę myśleć - XNA, MOGRE, Unity - są oparte na natywnym kodzie C ++; ale pozwól napisać logikę gry w C #.

Podsumowując : C # będzie używany zamiast C ++ lub innych języków. Ale nigdy nie zastąpi C ++, przynajmniej dopóki ktoś nie wymyśli wolnej od opóźnień pamięci o natychmiastowym dostępie.

Wybór języka w dużej mierze zależy od platformy. W tej chwili wydaje się bardzo mało prawdopodobne, aby cokolwiek innego niż platforma Microsoft wymagała .NET jako implementacji.

Konwencjonalna mądrość mówi, że mała platforma musiałaby być blisko metalu, aby była wydajna, ale z drugiej strony zarządzane platformy są bezpieczniejsze . To prawdopodobnie powód, dla którego Windows Phone 7 zmusza cię do korzystania z .NET.

Z pewnością byłoby interesujące, gdyby nowy Xbox wymagał platformy zarządzanej. Jeśli sprzęt telefonu może to obsłużyć (i tak się dzieje), z pewnością widziałbym, jak używają go na pełnowymiarowej konsoli. Podniosłoby to ekosystem konsoli dość mocno, ponieważ trudniej byłoby pisać gry międzyplatformowe bez pisania całego kodu gry w języku skryptowym. W takim przypadku C # nie zastąpiłby C ++, ale szedłby w parze.

Teraz ty mógł używać Mono jako koniec skryptowy tyłu (podobny do tego, co robi Unity), ale wyobrażam sobie, że większość producentów silników będzie albo chcą toczyć własną rękę, lub użyć czegoś bardziej zwarty jak Lua lub Python niż C #.

Tak czy inaczej, chodzi o właściwe narzędzie do właściwej pracy. Naprawdę powinieneś nauczyć się obu języków, ponieważ C # ułatwia robienie pewnych rzeczy (rozwój narzędzi, prawdopodobnie rozwój serwerów itp.), Aw niektórych przypadkach nie możesz używać niczego oprócz C ++.

To mało prawdopodobne. Zaletą C ++ jest niski poziom, dzięki czemu programiści mogą dopracować najdrobniejsze szczegóły, aby uzyskać najlepszą możliwą wydajność.

W C # i .NET masz bardzo przydatne, ale przy pracy z platformami z ograniczoną pamięcią i zasobami (konsole przenośne i do pewnego stopnia konsole domowe) musisz mieć jak największą kontrolę nad pamięcią, aby jak najlepiej wykorzystać zasobów. Umożliwienie zarządzanym językom przydzielania i zwalniania pamięci najprawdopodobniej spowodowałoby wiele problemów.

Szybkość jest również problemem (choć prawdopodobnie mniejszym). Z biegiem czasu jestem pewien, że języki zarządzane mogłyby sprawić, by działały porównywalnie z kompilatorami C ++.

Ogólnie rzecz biorąc, z mojego doświadczenia wynika, że ​​twórcy gier są maniakami kontroli, jeśli chodzi o pamięć, czas procesora i zasoby (aby wycisnąć jak najwięcej wydajności), dlatego właśnie C / C ++ są najczęściej używanymi językami.

AFAIK .NET GC wciąż cierpi na zatrzymanie algorytmu stylu światowego . Chociaż może to być odpowiednie dla wielu różnych aplikacji - jest niedopuszczalne w przypadku aplikacji w czasie rzeczywistym, takich jak gry.

W rzeczywistości bardzo trudno jest skutecznie używać języków zarządzanych w programach czasu rzeczywistego, dopóki nie osiągniemy przełomu w GC.

Nie. W zależności od platformy .NET oznaczałoby to konieczność wielokrotnego zapisu na platformach bez dostępnych ram, takich jak PS3, a wady wydajności mogą być całkowicie akceptowalne na PC lub w grach Live Arcade, ale większe gry będą wymagać każdego kawałka wydajność z ich konsol, aby działać wystarczająco szybko. Co więcej, w C ++ istnieją ogromne bazy kodu, których nikt nie mógłby sobie pozwolić na aktualizację, nawet gdyby chcieli. C ++ jest w branży gier i pozostanie tam przez długi czas.

W czasach, gdy brakowało mocy komputera, wszystko musiało być programowane w C lub C ++, po prostu dlatego, że śmieciowe języki odbierają kontrolę pamięci od programisty, a zatem wydajność może spaść.

W dzisiejszych czasach komputery są szybsze, ale jak mówi Knuth i krótko mówiąc, optymalizacja może być zła:

• oczywiste jest, że podstawowe funkcje niskiego poziomu muszą zostać zoptymalizowane, ponieważ obliczenia geometrii 3D, fizyki, kolizji, oświetlenia mogą szybko rozproszyć najlepszy dostępny procesor. Łatwo można stwierdzić, że rosnąca jakość obrazu na maszynie prawie zawsze znacząco obniża wydajność.

• Teraz istnieją inne funkcje, takie jak stany gry, sztuczna inteligencja, dźwięk, wejście, sieć, które są nadal ważne w grze, ale które prawie nigdy nie zajmą tak dużej ilości zasobów komputerowych. Te funkcje w większości przypadków nie muszą być optymalizowane. Taki jest cel języka skryptowego i języków odśmiecanych: nie musisz myśleć o spójności pamięci i organizacji aplikacji, ponieważ kod, który napiszesz w tych językach, jeśli nie kodujesz rzeczy niskiego poziomu, nigdy nie będzie szyjka.

Przykład z 2 przypadkami

• Wyślij 500 kg mebli ciężarówką.
• Wyślij 30 ton materiału łodzią.

oba są w odległości 500 km.

Czy w obu przypadkach ważne jest, aby przyspieszyć proces załadunku / rozładunku, aby skrócić cały czas transportu, wiedząc, że NIE MOŻESZ przyspieszyć łodzi ani ciężarówki?

Odpowiedź brzmi: to miało znaczenie dla ciężarówki, ale już nie dla łodzi, ponieważ już wiele zrobiłeś, przenosząc kolbę z łodzią.

Nie wiem, czy rozumiesz tę metaforę, ale w pewnym sensie może ona wyobrazić sobie matematyczny problem, który jest ważniejszy niż zrozumienie odpowiedzi.

Języki skryptowe pozwalają szybciej tworzyć gry, jeśli masz już silnik zaprogramowany w C / C ++: silnik 3D rozwiązuje problemy niskiego poziomu, teraz musisz tworzyć grę za pomocą skryptów.

Pamiętaj jednak: absolutnie nigdy nie będziesz w stanie zastąpić skompilowanego języka niskiego poziomu, KIEDYKOLWIEK. Kompilowane języki o statycznym typie są rdzeniem wydajności i NIE MOŻESZ ich wykluczyć, czy będzie to jądro, silnik 3D czy sterownik karty graficznej.

Ale oczywiście, jeśli twoja gra jest prosta graficznie i nie wymaga dużo obliczeń wektorowych, możesz skupić się na rozgrywce i zapomnieć o optymalizacji, ponieważ w tym przypadku nigdy nie będziesz musiał radzić sobie z optymalizacją, ponieważ twoja maszyna jest naprawdę szybka za to

Z wyjątkiem sytuacji, gdy planujesz przenieść port na DS. Ale zatrzymam się tam.

Słuchaj, wiem, że to rant, ale nie tylko dzielę włosy. Wydaje mi się, że większość programistów tak naprawdę tego nie łączy. Sam język nie ma nic wspólnego z szybkością / wydajnością biegu. To kompilator / framework. Lepiej argumentuj gcc przeciwko cl (kompilator Microsoft przed 2010) lub msbuild (obecny kompilator c ++ na 2010). Z każdym wydaniem te kompilatory stają się coraz lepsze, więc musisz także porównać je z poprzednimi wersjami. Jestem pod wrażeniem .net i działa on dobrze, ale nawet jeśli był nieco lepszy, nie widzę, aby przejął go, z jednego powodu: przenośności.

Gry AAA chcą być na systemach Windows, Linux, Mac, XBox, PS3, Nintendo itp.