Byłoby pomocne, gdybyś krótko wyjaśnił, co dało ci ten pomysł, ponieważ jest to bardzo dziwny pomysł, mówiąc co najmniej.
Konrad Rudolph
2
Biorąc pod uwagę, że Quake odbywa się w C .. ;-)
Kaczka komunistyczna
Zastanawiałem się tylko nad tym pytaniem!
Jeff
2
To brzmi jak „gry branżowe”, to znaczy tak zwane „tytuły AAA”.
chaos
Odpowiedzi:
53
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.
+1 Visual Studio to bardzo dobre IDE. Nawet jeśli jest to ciemna strona ...
Michael Coleman
1
Bah, z mojego doświadczenia, że C # nie jest wystarczająco szybki do symulacji, ale to nie powstrzymuje ludzi przed próbowaniem.
BigSandwich
@Nevermind Co to jest „języki zarządzane”?
Quazi Irfan
3
@iamcreasy W szerokim znaczeniu słowa „języki zarządzane” mam na myśli języki działające na maszynie wirtualnej, które zawierają pewne formy usuwania śmieci i / lub zarządzania pamięcią. Mówiąc ściślej, języki zarządzane to języki, które są ukierunkowane na (niektóre implementacje) środowiska uruchomieniowego języka wspólnego, ale moja odpowiedź dotyczy nie tylko tych języków.
Nevermind
Czy Twoim zdaniem programy GC liczone według referencji należą do tej kategorii a la Vala?
weberc2
6
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 ++.
Obecnie 3 lata później stan C # w rozwoju gier jest znacznie bardziej rozwinięty. Mono-Project wybrał XNA Game Studio i zmienił nazwę na MonoGame. SharpDX, SlimDX i OpenTK są bardzo przyzwoitymi opakowaniami opengl / directx. Pojawiło się nawet kilka silników fizyki w języku c #. Mono / MonoGame pozwala zbudować grę raz i automatycznie przenieść ją na Androida, Linux, Mac OS, iOS, Xbox 360, PS3, PS4 i Wii.
Ryan Mann
3
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.
Chociaż istnieje bezwładność, podstawy kodu C ++ nie są tak stare - może najwyżej 10 lat. Prawie cały kod w nich został w tym czasie zastąpiony - dla akceleratorów 3D, programowalnych potoków, architektur opartych na danych i obsługi skryptów. Jeśli deweloper AAA chciałby przeprowadzić pełną migrację do C #, prawdopodobnie mógłby to zrobić przy minimalnym koszcie w obrębie trzech gier - najpierw użyj go jako narzędzia i hosta skryptów, po drugie przenieś warstwy logiki gry do niego i trzeci port moduł renderujący do korzystania z zarządzanego opakowania DX / GL.
1
Mono ma komercyjne rozwiązanie .NET dla PS3.
Dan Olson
Oddelegowany, jeśli budować swoją grę w c # przeciwko mono lub monogame (wymiana XNA), można przenieść go do PS3 / PS4, Wii, Xbox 360, android, max OS, etc zbudowany w.
Ryan Mann
0
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.
„optymalizacja może być zła” jest zdecydowanie najbardziej bezużyteczną, zmutowaną wersją jego wypowiedzi, którą przeczytałem.
cóż, tłumaczę to, dlatego bezcelowe jest cytowanie całego jego oświadczenia, które jest dość długim zdaniem i nie jest tak naprawdę wyjaśnione ... Poza tym mówimy o grach, które nie są takie same szersze oprogramowanie, o którym chciał opowiedzieć Knuth.
Jokoon
Wspominasz, że dane wejściowe prawie nigdy nie zajmują wielu zasobów komputerowych. Chciałbym zauważyć, że gdy gracz staje się bardziej fizycznie związany z grą, staje się to mniej prawdziwe. Na przykład kinect. Jest to forma wprowadzania danych, ale wymaga dużej ilości zasobów obliczeniowych.
Ponkadoodle
0
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.
Z pewnością istotną rolę odgrywa implementacja kompilatora, ale różne języki zapewniają różne możliwości optymalizacji sterowanej przez kompilator oraz różne możliwości dla programistów w celu obejścia zwykłych reguł językowych i bezpośredniej rozmowy ze sprzętem. Język i cel same w sobie mają wiele wspólnego z wydajnością.
Język może mieć wiele wspólnego z prędkością działania / wydajnością, ponieważ składnia i biblioteki standardowe będą sprzyjać różnym podejściom. Na przykład język, w którym trudno jest używać tablic ciągłej pamięci, ponieważ wszystkie ich obiekty będące wskaźnikami będą miały tendencję do przebijania pamięci podręcznej o wiele więcej niż jednego, w którym można efektywnie korzystać z tablic lub wektorów.
Kylotan
+1 bardzo dobry punkt, który mogłeś zrobić bez obrażania głupich ludzi, którzy nie wiedzą kim są.
Fire Crow
Z wyjątkiem tego, że na dzień dzisiejszy możesz budować przeciwko mono, a to prawie wszystko. Np. Jest teraz bardzo przenośny.
Odpowiedzi:
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.
źródło
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 ++.
źródło
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.
źródło
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.
źródło
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.
źródło
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
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.
źródło
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.
źródło