산업 게임에서 C ++가 C #으로 대체됩니까?


23

산업 게임에서 나는 Quake, CoD 등을 의미합니다.


7
가장 적게 말하는 것은 매우 이상한 아이디어이기 때문에 아이디어를 준 것에 대해 간단히 설명하면 도움이 될 것입니다.
Konrad Rudolph

2
퀘이크를 고려하는 것은 C .. ;-)
공산주의 오리

나는이 질문을 스스로 궁금해했다!
Jeff

2
"산업용 게임"은 보통 "AAA 타이틀"을 의미합니다.
혼돈

답변:


53

어떤 의미에서 C ++은 실제로 C #뿐만 아니라 다른 언어로 대체되고 있습니다. 그러나 당신이 묻는다면, 그것은 완전히 교체되어 갈 것 입니까 ? 그러면 대답은 분명히 아니오 입니다.

C ++은 전통적으로 두 가지 용량으로 사용되기 때문입니다. 먼저 리소스를로드하는 저수준 구성 요소 인 게임 엔진 을 만들려면 물리 시뮬레이션에서 다각형을 화면에 띄우고 크런치 숫자로 만듭니다. 둘째, 게임 로직 을 코딩하는 것 : 게임 플레이를 만드는 실제 규칙.

이 두 번째 용량에는 C ++의 강점 (예 : 하위 수준 세부 사항에 대한 완전한 제어)이 필요하지 않지만 약점 (예 : 버그가 발생하기 쉬운 수동 코딩 메모리 관리)이 있습니다. 그리고이 두 번째 용량에서 C ++은 다른 스크립팅 언어로 대체되고 있습니다. 많은 개발자들이 Lua를 사용합니다. 일부는 파이썬을 사용합니다. 그러나 CLI 플랫폼을 .NET 또는 Mono 형식으로 사용할 수 있으면 훌륭한 스크립팅 호스트 후보가됩니다. 이 플랫폼은 매우 빠르고 안정적이며 널리 알려진 언어 (C #) 및 포괄적 인 기본 클래스 라이브러리를 제공합니다. 도구를 잊지 말자 : MS Visual studio 및 SharpDevelop / MonoDevelop는 세계에서 가장 좋은 IDE는 아니지만 아주 좋습니다.

즉, 게임 엔진 은 C # (또는 Lua 또는 Python)으로 작성되지 않습니다. 왜? 그들은 충분히 빠르지 않기 때문에.

많은 대중적 신념과는 달리 오늘날 가장 큰 성능 저하는 메모리 대기 시간 때문 입니다. 이것은 메모리에 액세스하는 것이 심각한 비즈니스임을 의미합니다. 그리고 관리되는 언어는 사용자가 메모리 액세스를 제어 할 수 없도록합니다. 이것이 바로 그들이 "관리"되는 이유입니다. 따라서 관리되는 언어로는 정말 빠른 게임 엔진을 작성할 수 없습니다. 실제로 내가 생각할 수있는 모든 "C #"엔진 (XNA, MOGRE, Unity)은 네이티브 C ++ 코드를 기반으로 합니다. C #으로 게임 로직을 작성할 수 있습니다.

요약하자면, C #은 C ++ 또는 다른 언어 대신 사용됩니다. 그러나 누군가가 대기 시간이없는 인스턴트 액세스 메모리를 발명 할 때까지 C ++을 대체하지는 않습니다.


16
+1 Visual Studio는 매우 훌륭한 IDE입니다. 그것은 어두운면 ...하더라도
마이클 콜맨

1
Bah, 내 경험상 C #은 시뮬레이션을하기에는 빠르지 않지만 사람들이 시도하는 것을 막지는 못합니다.
BigSandwich

@Nevermind "관리 언어"란 무엇입니까?
Quazi Irfan

3
@iamcreasy 넓은 의미에서 "관리되는 언어"는 가비지 수집 및 / 또는 메모리 관리 형식이 포함 된 가상 컴퓨터에서 실행되는 언어를 의미합니다. 더 엄격하게 말하면, 관리되는 언어는 공통 언어 런타임의 (일부 구현) 대상 언어이지만 내 대답은 이들 언어에만 적용되지 않습니다.
Nevermind

귀하의 의견으로는, 참조 카운트 된 GC 체계는이 범주에 속합니까?
weberc2

6

언어 선택은 플랫폼에 따라 크게 다릅니다. 현재 Microsoft 플랫폼 이외의 다른 구현에는 실제로 .NET이 필요할 것 같습니다.

기존의 지혜에 따르면 작은 플랫폼은 성능을 발휘하기 위해 금속에 가까워 야하지만 관리되는 플랫폼은 더 안전 합니다. 아마도 Windows Phone 7에서 .NET을 사용해야하는 이유 일 것입니다.

새로운 Xbox가 관리 형 플랫폼을 필요로한다면 흥미로울 것입니다. 휴대 전화의 하드웨어가 처리 할 수 ​​있다면 풀 사이즈 콘솔에서 사용할 수 있습니다. 모든 게임 코드를 스크립팅 언어로 작성하지 않고 플랫폼 간 게임을 작성하기가 더 어려워 콘솔 에코 시스템을 상당히 자극 할 것입니다. 이 경우 C #은 C ++을 대체 하지 않지만 실제로는 C ++을 대체 합니다.

지금 Mono를 스크립팅 백엔드로 사용할 있지만 (Unity와 비슷한) 대부분의 엔진 제작자가 자체 롤링을 원하거나 C #보다 Lua 또는 Python과 같은 더 컴팩트 한 것을 사용하려고한다고 생각합니다.

어느 쪽이든, 그것은 올바른 일을위한 올바른 도구에 관한 것입니다. C #을 사용하면 특정 도구 (도구 개발, 서버 개발 등)를보다 쉽게 ​​수행 할 수 있으므로 C ++ 이외의 다른 언어를 사용할 수 없기 때문에 두 언어를 모두 배워야합니다.


현재 3 년 후 게임 개발을위한 C # 상태가 훨씬 더 발전되었습니다. Mono-Project는 XNA Game Studio를 선택하여 MonoGame으로 이름을 바꿨습니다. SharpDX, SlimDX 및 OpenTK는 모두 매우 괜찮은 opengl / directx 래퍼입니다. C #의 일부 물리 엔진조차 등장했습니다. Mono / MonoGame을 사용하면 게임을 한 번 빌드하고 Android, linux, mac os, ios, xbox 360, ps3, ps4 및 wii로 자동 포트 할 수 있습니다.
Ryan Mann

3

가능성이 없습니다. C ++은 개발자가 실제로 가장 작은 디테일을 조정하여 가능한 최고의 성능을 얻을 수 있도록 낮은 수준의 이점을 제공합니다.

C # 및 .NET을 사용하면 가비지 수집 기능이 매우 유용하지만 메모리 및 리소스가 제한된 플랫폼 (휴대용 콘솔 및 홈 콘솔)을 사용하는 경우 최대한 활용하기 위해 최대한 많은 메모리를 제어해야합니다. 자원의. 관리되는 언어가 메모리를 할당하고 비우는 것을 허용하면 많은 문제가 발생할 수 있습니다.

속도도 문제입니다 (아마도 그렇지는 않지만). 시간이 지남에 따라 관리되는 언어가 C ++ 컴파일러와 비슷한 성능을 발휘할 수 있다고 확신합니다.

전반적으로 내 경험에 따르면 게임 개발자는 메모리, CPU 시간 및 리소스 (가능한 한 많은 성능을 짜기 위해)와 관련하여 괴물을 제어하는 ​​경향이 있으므로 C / C ++가 주로 사용되는 언어입니다.


2

AFAIK .NET GC는 여전히 월드 스타일 알고리즘 을 중지하는 데 어려움을 겪고 있습니다 . 이것은 다양한 응용 프로그램에 적합 할 수 있지만 게임과 같은 실시간 응용 프로그램에는 적합하지 않습니다.

실제로 GC에 돌파구가 생길 때까지 실시간 프로그램에 관리되는 언어를 효과적으로 사용하는 것은 매우 어렵습니다.


1

아니요. .NET에 따라 PS3와 같이 사용 가능한 프레임 워크가없는 플랫폼에 대한 대규모 재 작성을 의미하며 PC 나 라이브 아케이드 게임에서는 성능상의 단점을 완벽하게 수용 할 수 있지만 더 큰 게임에는 모든 스크랩이 필요합니다. 콘솔의 성능을 충분히 빠르게 실행할 수 있습니다. 또한 C ++에는 원하는 경우에도 업그레이드 할 수없는 거대한 기존 코드 기반이 있습니다. C ++은 게임 산업에 있으며 오랫동안 거기에 머무를 것입니다.


관성이 존재하지만 C ++ 코드베이스 자체는 그다지 오래되지는 않았으며 최대 10 년이 걸릴 수도 있습니다. 이 기간 동안 3D 가속기, 프로그래밍 가능한 파이프 라인, 데이터 기반 아키텍처 및 스크립팅 지원 등 거의 모든 코드가 교체되었습니다. AAA 개발자가 C #으로 전체 마이그레이션을 수행하려는 경우 아마도 세 게임 공간 내에서 최소 비용으로 달성 할 수 있습니다. 먼저 도구 및 스크립팅 호스트로 사용하고 두 번째로 게임 로직 레이어를 이동하고 세 번째 포트 관리 DX / GL 래퍼를 사용하는 렌더러

1
Mono에는 PS3 용 상용 .NET 솔루션이 있습니다.
Dan Olson

둘째, 모노 또는 모노 게임 (xna 교체)에 대해 C #으로 게임을 빌드하는 경우 ps3 / ps4, wii, xbox 360, android, max os 등으로 포팅 할 수 있습니다.
Ryan Mann

0

컴퓨터 전원이 부족한 경우 가비지 수집 언어가 프로그래머로부터 메모리 제어를 빼앗기 때문에 성능이 저하 될 수 있기 때문에 C 또는 C ++로 모든 프로그래밍이 필요했습니다.

오늘날 컴퓨터는 더 빠르지 만 Knuth가 말했듯이 짧게 말하면 최적화가 어려울 수 있습니다.

  • 3D 지오메트리, 물리, 충돌, 조명을 계산하면 사용 가능한 최상의 프로세서를 빠르게 부 풀릴 수 있기 때문에 낮은 수준의 핵심 기능을 최적화해야합니다. 컴퓨터에서 시각적 품질이 향상되면 거의 항상 성능이 크게 저하된다는 것을 쉽게 알 수 있습니다.

  • 이제 게임 상태, AI, 사운드, 입력, 네트워크와 같은 다른 기능이 여전히 게임에서 중요하지만 컴퓨터 리소스를 많이 차지하지는 않습니다. 이러한 기능은 대부분 최적화되지 않아도됩니다. 이것이 스크립팅 언어와 가비지 수집 언어의 목표입니다. 메모리 일관성과 응용 프로그램 조직에 대해 생각할 필요가 없습니다. 낮은 언어로 코딩하지 않는 경우 이러한 언어로 작성할 코드는 절대로 병목.

2 건의 예

  • 가구와 트럭 500kg을 운송하십시오.
  • 보트와 함께 30 톤의 자재를 배송하십시오.

둘 다 500km 거리에 있습니다.

두 경우 모두 CANT가 보트 나 트럭을 더 빨리 움직이게한다는 것을 알고 전체 운송 시간을 단축하기 위해 로딩 / 언 로딩 프로세스를 더 빠르게하는 것이 중요합니까?

대답은 트럭과 관련이 있지만 더 이상 보트와는 관련이 없습니다. 이미 보트와 함께 주식을 움직여 많은 일을했기 때문입니다.

나는 당신이이 은유를 이해하는지 모르겠지만, 어떤 식 으로든 답을 이해하는 것보다 더 중요한 수학 문제를 상상할 수 있습니다.

스크립팅 언어를 사용하면 이미 C / C ++로 프로그래밍 된 엔진이있는 경우 게임을 더 빠르게 만들 수 있습니다. 3D 엔진은 하위 수준의 문제를 해결하므로 이제 스크립트로 게임을 만들어야합니다.

그러나 저수준 컴파일 언어를 절대로 대체 할 수는 없습니다. 정적으로 유형이 정해지고 컴파일 된 언어는 성능의 핵심이며이를 배제 할 수 없으며 커널, 3D 엔진 또는 그래픽 카드 드라이버 일 것입니다.

그러나 게임이 그래픽으로 간단하고 많은 벡터 계산이 필요하지 않은 경우 게임 플레이에 집중하고 최적화를 잊어 버릴 수 있습니다.이 경우 기계가 실제로 빠르기 때문에 최적화를 처리 할 필요가 없기 때문에 그에 대한

DS에서 ir를 포팅하려는 경우를 제외하고. 그러나 나는 거기서 멈출 것이다.


1
"최적화는 악의적 일 수있다"는 필자가 읽은 그의 진술 중 가장 쓸모없는 변형 된 버전이다.

글쎄, 나는 그것을 설명하고 있습니다. 그래서 나는 그의 문장 전체를 인용하는 데 쓸모없는 것을 발견했습니다. Knuth가 말하고 싶은 광범위한 소프트웨어.
jokoon February

입력에 많은 컴퓨터 리소스가 거의 사용되지 않는다고 언급했습니다. 플레이어가 게임에 물리적으로 연결 될수록 사실은 줄어들 것입니다. 예를 들어, 키 넥트. 입력 형식이지만 사용하려면 많은 컴퓨팅 리소스가 필요합니다.
Ponkadoodle

0

봐, 나는 이것이 진창임을 알고 있지만 나는 머리카락을 나누는 것이 아닙니다. 나는 대부분의 프로그래머들이 실제로 이것을 합치 지 않는다고 생각합니다. 언어 자체는 실행 속도 / 성능과 관련이 없습니다. 컴파일러 / 프레임 워크입니다. cl (Microsoft prepre 2010) 또는 msbuild (2010의 현재 c ++ 컴파일러)에 대해 gcc를 더 잘 주장 할 수 있습니다. 모든 릴리스의 컴파일러는 더 나아 지므로 이전 버전과 비교해야합니다. 나는 .net에 매우 감명을 받았으며 잘 수행하지만 약간 더 나은 성능을 보여도 인수를 보지 못하는 이유는 다음과 같습니다.

AAA 게임은 Windows, Linux, Mac, XBox, PS3, Nintendo 등에 있어야합니다.


분명히 컴파일러 구현이 중요한 역할을하지만, 다른 언어는 컴파일러 중심의 최적화를위한 다른 능력과 프로그래머가 일반적인 언어 규칙을 우회하고 하드웨어와 직접 대화 할 수있는 다른 능력을 제공합니다. 언어와 목표 자체 는 성능과 관련이 있습니다.

구문과 표준 라이브러리는 다른 접근 방식을 선호하기 때문에 언어는 실행 속도 / 성능과 많은 관련이 있습니다. 예를 들어, 모든 객체가 포인터이기 때문에 연속 메모리 배열을 사용하기 어려운 언어는 배열이나 벡터를 효과적으로 사용할 수있는 것보다 캐시를 ​​많이 쓰러 뜨리는 경향이 있습니다.
Kylotan

멍청한 사람들을 모욕하지 않고 만들 수있는 아주 좋은 점 +1, 그들은 자신이 누구인지 모릅니다.
Fire Crow

오늘을 제외하고는 모노에 대해 빌드 할 수 있으며 거의 ​​모든 것에 포트됩니다. 예를 들어 이제 휴대 성이 뛰어납니다.
Ryan Mann
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.