게임용 STL, 예 또는 아니오? [닫은]

모든 프로그래밍 언어에는 표준 컨테이너, 알고리즘 및 기타 유용한 라이브러리가 있습니다. C #, Java 및 Python과 같은 언어 에서는 표준 lib 없이 언어를 사용하는 것이 실제로 불가능 합니다.

그러나 내가 작업 한 많은 C ++ 게임에서 우리는 STL을 전혀 사용하지 않았거나 작은 부분을 사용하거나 자체 구현을 사용했습니다. 그것이 우리 게임에 대한 올바른 결정인지, 아니면 단순히 STL의 무지로 만들어진 것인지 결정하기는 어렵습니다.

STL이 적합합니까?

전문 게임 개발에 종사했을 때 STL은 너무 미숙하고 부풀어 올랐습니다. 그러나 그것은> 10 년 전이었습니다.

이제 프레임 워크 속도가 FPS 이하로 떨어지지 않는 것처럼 더욱 까다로운 성능 요구 사항이있는 군사 시뮬레이션 작업을하고 있습니다. 군사 시뮬레이션에서 STL은 모든 곳에서 사용됩니다.

STL을 사용하지 말라고 말하는 사람들 중 일부는 항상 문제에 대한 완벽한 해결책이 아니라는 주장을 사용합니다. 그러나 그것은 그 질문에 대한 답이 아닙니다. 질문은 : 게임에서 STL을 사용하는 데 본질적으로 잘못된 것이 있습니까? 아니오, STL은 대부분 사용자가 스스로 구현하는 것보다 더 나은 구현입니다.

STL 사용 방법을 알고 게임에서 사용하십시오. 일부 책을 읽고 사용중인 STL의 구현 코드를보십시오.

내 머리 꼭대기에서 STL을 사용하고 싶지 않은 이유를 정확히 알지 않는 한 STL을 사용하는 것이 좋습니다 .

다음은 STL에 관한 것입니다. STL은 당신보다 똑똑한 사람들에 의해 개발되었습니다. 그것은 불쾌감을 주거나 다른 것이 아닙니다. STL은 실제로 STL을 개발하는 사람들이 개발 한 것입니다. 플랫폼이 허용하는 속도만큼 실질적으로 빠르며 일반적으로 홈 롤링 솔루션보다 훨씬 강력합니다 (그리고 게임 속도 때문에 원시 속도에 대해 걱정 하지 않는 한 많은 관심사 가 필요합니다) 견고성은 속도가 필요한 것보다 훨씬 뛰어납니다. 후자는 전자가 없으면 의미가 없습니다).

STL이 "세계에 대한 좁은 시야"를 강요한다는 불만은 저를 조금 어리석게 만듭니다. 그들은 컨테이너입니다. 컨테이너에는 제한된 작업 세트가 있기 때문에 제한된 작업 세트가 있습니다. 이것으로 지브하지 않는 것은 무엇입니까?

게임에 STL을 사용하지 않는 이유는 거의 없습니다.

메모리 할당 문제의 경우 많은 사람들이 이것을 모르지만 STL 컨테이너 클래스에 대한 사용자 지정 할당자를 작성할 수 있습니다. 할당자는 기본적으로 할당 수행 방법을 결정하기 위해 템플릿에 전달하는 정책 클래스입니다. 이를 사용하면 일반적으로 선택한 플랫폼에서 문제가되는 메모리 문제를 해결할 수 있습니다.

물론 STL을 사용하고 포인터가 아닌 대형 유형에 대한 문자열 맵과 같은 멍청한 일을하는 경우 더 큰 문제가 있습니다.

기본 STL에는 특히 메모리 정렬과 관련하여 게임에 사용하기 어려운 많은 문제가 있습니다.

EA STL 과 같은 맞춤형 변형 은 게임용으로 특별히 설계되었으며 훨씬 더 나은 메모리 성능과 콘솔 사용성을 제공합니다. 2016 년 BSD-3 조항 에 따라 GitHub에 리포지토리 가있는 오픈 소스가되었습니다 .

Mike Acton (Insomniac Games of Spyro the Dragon, Ratchet & Clank 및 Resistance fame의 엔진 디렉터)이 여기에서 물었을 때 이에 대해 말한 내용 입니다. 그는 게임 개발에서의 사용과 관련하여 일반적으로 STL과 Boost 모두에 대해 질문 받았다.

STL / Boost, gamedev에 속합니까? 그것의 일부만 있다면 어느 것입니까?

여기에 다른 두 가지가 있습니다. STL과 Boost는 별도로 제공됩니다. 그러나 실제로 내 대답은 동일합니다. 하나 자체 에는 아무런 문제 가 없지만 사용을 권장하지 않습니다. 둘 중 하나를 사용하면 사람들 이 문제에 대한 해결책을 찾는 것이 아니라 문제에 대한 해결책을 찾 도록 권장 합니다. 이 솔루션은 항상 필요한 데이터와 하드웨어의 제약 조건에 적합해야합니다. STL과 Boost는 모두 "세계"에 대한보기가 매우 좁으며 적절한 사용이 제한됩니다. 실제로 프로그래머가 잘못된 방향으로 이끌 수 있기 때문에 실망하지 않습니다. 필자가 생각하는 문제 중 하나를 실제로 이해하지 못하는 경우가 종종 있습니다.

또한 대부분의 프로 게임 개발자는 C ++보다 C를 향해 더 많은 노력을 기울이고 있습니다.

어떤 이유로 든 STL에 이미 존재하는 것을 다시 작성하는 것을 발견하면 중지하십시오 . STL을 사용하십시오.

STL은 수년간의 분석과 시간에 걸쳐 최적화되었으며 더 효율적인 것을 작성하지 않을 것입니다. 그것은 더 간단한 해결책이 가능한 곳에서 STL을 사용해야한다고 말하는 것이 아닙니다 (예 : stl :: list가 아닌 알려진 수량이있을 때 배열을 사용하십시오). 게임 세계지도가 아닌 기본 데이터 구조), 잘못하고 있습니다.

STL이 게임에 적합합니까? 명확히. 게임은 복잡한 소프트웨어이므로 STL은 복잡성을 관리하는 데 도움이되는 기능을 제공하므로 좋습니다.

귀하의 플랫폼에 적합합니까? 반드시 그런 것은 아닙니다. 콘솔을 작성하는 경우 메모리 및 캐시 사용에 매우주의해야합니다. STL은 이것을 쉽게 만들지 않습니다.

"내장 하드웨어 나 맞춤형 하드웨어에서 실행되는 고성능 실시간 게임"으로 "게임"을 너무 자주 오해한다고 생각하지만, 구별하는 것이 중요합니다. 일정한 60fps로 전체 화면으로 실행하지 않는 Windows 게임을 작성하는 경우 표준 라이브러리가 제공하는 도구를 피할 이유가 없습니다.

나는 이것이 파티에 매우 늦다는 것을 알고 있지만 시간 변화와 대답은 계속 남아 있습니다. C ++ 11은 상당히 변화가 많으며 그 중 많은 부분이 C ++ 및 표준 라이브러리의 성능을 향상시킵니다. STL 또는 Boost를 사용하지 않는 사람들은 새로운 표준을 따르지 않는 경향이 있으며, 홈 스펀 솔루션에는 중요한 개선 사항이 부족하지만 물론 항상 그런 것은 아닙니다.

EA에서 짧은 시간을 제외하고 90 년대 중반부터 현재까지 모든 프로젝트에서 STL을 사용했습니다. 안티 STL 측은 그것을 사용하지 않을 근거가 거의 없다고 생각합니다. 그것들은 크게 사라졌습니다. 커스텀 할당자는 하나의 솔루션이며, 예약을 사용하는 것은 또 다른 방법이며, 가치에 따라 물건을 전달하지 않는 것은 세 번째이지만, 이것은 매우 간단하며 프로그래머는 이것을 알아야합니다. 더 중요한 것은 알고리즘 사용입니다. 컴파일러 작성자는 for_each ()의 기능을 정확히 알고 코드를 최적화 할 수 있습니다. 홈 롤 루프에서는 발생할 수 없습니다. const 객체의 for_each ()가 더 좋습니다. Microsoft는 직렬화를 포함하여 여러 가지 방법으로 for_each를 최적화합니다. 또한 parallel_for_each ()가있는 AMP 라이브러리도 있습니다. 기회가 생기면 컴파일러 엔지니어에게 문의하십시오. 콘솔 컴파일러는 사용되는 것을 최적화 할 것입니다. 약간의 닭고기와 계란 문제. 마이크로 소프트는 C ++ 11로 무거워지고 있으며 다음 XBox도 다르지 않을 것이다. 나는 PS4에 대해 전혀 모른다, 우리는 아직 하나도 얻지 못했다.

사용자 지정 할당자는 메모리 문제를 처리하는 한 가지 방법이지만 간과되는 또 다른 옵션은 클래스 기반 new 및 delete를 사용하는 것입니다. 이렇게하면 성능이 크게 향상 될 수 있습니다.

Boost와 STL이 문제 해결에 대한 좁은 견해를 가지고 있다는 개념은 순수한 광기입니다. STL과 Boost의 특성과 정책을 통해 사용자 정의 할 수있는 항목 수에 놀랐습니다. 예를 들어 대소 문자 구분 문자열 비교를 찾으십시오.

긴 링크 시간 및 코드 팽창과 관련하여 새로운 extern 템플릿 이이를 지원해야합니다. 일반적으로 컴파일 시간이 길어지면 과도한 커플 링과 pch의 오용이 발생합니다.

STL을 사용하는 가장 강력한 이유는 STL에 도움을 줄 수있는 수백만의 사람들이 있기 때문입니다. 항상 그렇듯이 조기에 최적화하고 테스트, 테스트, 테스트하지 마십시오.

이것은 게임 개발에서 뜨거운 주제입니다. 위에서 언급 한 EASTL을 제외하고는 개인적으로 권장하지 않습니다. 게임에서 STL (기술적으로 STL은 더 이상 이름이 아니므로 "C ++ 표준 라이브러리")과 관련하여 두 가지 주요 문제가 있습니다. 1) 동적 메모리 할당은 종종 STL을 사용할 때 게임에서 많은 런타임을 낭비합니다. 2) STL을 사용하면 게임 구조에 대한 배열 접근 방식이 권장되는 반면 배열 배열 접근 방식은 캐시에 훨씬 친숙합니다.

따라 다릅니다. 프로젝트 규모, 플랫폼 및 타임 라인은 무엇입니까?

대규모 프로젝트, 제한된 자원과 플랫폼, 상당한 타임 라인 및 예산으로 작업하는 경우 50 만 라인 코드 기반을 보는 불가피한 지옥을 피함으로써 많은 문제를 해결할 수 있습니다 STL로 쓰레기를 처리하고 프레임 속도를 30 이상으로 유지할 수 없으며 몇 개의 자산에 더 적합한 RAM을 사용하며 빌드하는 데 2 ​​시간이 걸립니다.

그러나 다른 상황에서는 STL 및 Boost조차도 적절하게 적용하면 매우 유용 할 수 있습니다. 나는 STL / Boost를 사용하여 타이틀을 작업했으며, 버그 / 누수를 줄이고 코드를 쉽게 관리 할 수 ​​있다는 것은 새로운 기능을 코딩하는 데 더 많은 시간이 걸리는 것을 의미합니다. 특히 취미 프로젝트의 경우 동기 부서에서 큰 승리입니다.

편의를 위해 성능 거래시기를 알아야합니다!

IMHO STL은 이미 잘 작동하고 있으며 작업에 최적화되어 있기 때문에 적합하다고 말하고 싶습니다. 게다가, 당신은 게임을하고 있기 때문에, 당신의 삶을 더 편하게하고 코드가 버그에 덜 취약하게 만드는 도구를 사용하십시오.

게임의 AI, 사용자 경험 또는 더 나은 것과 같은 다른 작업을 할 수있을 때 바퀴를 재발 명하는 이유는 무엇입니까? 테스트 및 디버깅?

STL은 잘 이해하는 한 게임에서 사용하기에 절대적으로 좋습니다. 우리의 엔진은 그것을 광범위하게 사용하며 결코 문제가되지 않았습니다. 콘솔 개발에 대한 경험이 없지만 완전히 다른 이야기 일 수는 있지만 모든 PC 플랫폼 (Windows / Mac / Linux)에서 잘 지원됩니다.

가장 중요한 것은 각 컨테이너 유형의 강점과 약점이 무엇인지 이해하고 작업에 적합한 컨테이너를 선택하는 것입니다.

이전 고용주는 강력한 사용자 정의 컨테이너 클래스 사용에서 STL로 전환했습니다. 빌드 시간이 길어지고 디버깅이 쉬워졌습니다. 우리가 처음부터 시작했다면 STL (아마도 더 잘 사용됨)이 의미가 있었을 것입니다. 그러나 STL로 전환하여 작동하고 빠르고 디버깅 가능한 코드를 버리는 것을 정당화 할 수있는 것은 아무것도 없었습니다.

내 개인 프로젝트의 경우 STL이 맞는지 여부는 프로젝트에 따라 다릅니다. Mike Acton 스타일의 데이터 중심의 메모리 및 캐시 액세스 최적화 작업을 수행하려는 경우 적어도 내 자신의 사용자 지정 데이터 구조를 롤링하는 것에 대해 생각할 것입니다. 일부 알고리즘 또는 게임 플레이를 프로토 타이핑하고 성능, 확장 성, 대상 플랫폼 등에 신경 쓰지 않으면 STL을 자동으로 가져옵니다.

이것에 대한 나의 2 센트는 STL이 잘 작동한다는 것입니다. 나는 PC를 위해 3D 게임 엔진 (AAA 품질이 아니라, 충분히 고급-스크립트 된 엔티티 유형, 지연된 렌더러, 통합 된 총알 물리학)을 개발하고 있으며 컨테이너가 주요 병목 현상이되는 것을 아직 보지 못했습니다. 내가 들어가서 약간 더 많은 성능을 발휘하려고 시도 할 때마다 잘못된 3D API 사용과 열악한 알고리즘이 최고의 목표였습니다 (프로파일 링으로 결정!).

나는 STL을 사용하여 게임을 만들었고 그것을 좋아하며 성능이 좋아 보입니다.

좋은 질문! 보다 구체적인 질문은 게임이 STL 및 Boost로 충족 할 수없는 일반적인 요구 사항입니다.

필자의 경험에 따르면 콘솔 하드웨어의 메모리 제한으로 인해 사용자 지정 할당자가 얼마나 영리한 지에 관계없이 모든 종류의 동적 크기 컨테이너를 나쁜 생각으로 만들 수 있습니다. 의도적 인 범위가없는 컨테이너는 프로그래머가 데이터 세트의 범위를 제한하지 않는 코드를 작성하도록 권장합니다. 추적하기 어려운 수많은 변수에 따라 메모리 제한을 초과 할 수 있습니다. 나는 이것이 현대 게임에서 불안정의 주요 원인 중 하나라는 직감을 가지고 있습니다.

또한 템플릿을 과도하게 사용하면 큰 코드 기반에서 컴파일 시간이 매우 길어질 수 있으며 실행 파일 크기가 더 커져서 ps3의 보조 코어 캐시에 더 이상 맞지 않게됩니다.

그러나 PC 전용 개발의 경우 STL과 Boost가 매우 좋습니다. 일반적인 솔루션이 항상 이상적인 것은 아니지만 종종 충분합니다. 문제에 대한 첫 번째 해결책은 거의 이상적인 것이 아니며, 충분할 때까지 부족 성을 개선하거나 대체합니다.

STL이 게임에 적합하면 STL이 게임에 적합합니다.

개발 중에 선택한 모든 기술과 마찬가지로 장단점을 고려해야합니다. 내 라이브러리를 롤링하면 STL을 사용하는 것보다 더 유용한 메모리 사용, 성능 및 생산성을 얻을 수 있습니까? 혹시; vector더 많은 메모리를 사용하고 느리며 이미 존재하는 것과 비교하여 기능을 유지하기 위해 많은 유지 보수가 필요한 구현 을 작성하는 것이 쉽지만 .

다른 사람들은 게임에서 STL을 사용하지 않기 때문에 사람들은 게임에서 STL을 사용하지 않아야합니다. 그들은 모든 옵션의 무게를 if다면 사용을 피해야합니다. 다른 구현이 제품의 품질을 향상시킬 것이라고 진정으로 믿는 .

대부분의 질문에서와 같이 대답은 결코 "예나 냐", 검은 색 또는 흰색입니다. STL은 일부 문제에 적합하며 해당 문제에 사용하면 좋습니다. 쓸모가 없다고 생각하는 것은 실수이지만 모든 상황에서 사용하는 것이 적절하다고 가정하는 것은 실수입니다.

게임 개발에서 STL을 사용할 때주의해야 할 가장 큰 문제는 메모리 할당입니다. STL의 기본 할당자는 게임 개발을위한 선호 할당 전략에 잘 맞지 않는 것 같습니다. 물론 사용자 지정 할당자를 사용할 수 있지만 STL을 비 STL 코드베이스에 추가할지 여부를 고려할 경우 전체 아이디어가 덜 매력적입니다.

또한 코드베이스가 STL이 아닌 경우 사용자 지정 할당자를 올바르게 구현하기 위해 STL 또는 템플릿 개념에 익숙한 사람이 없을 수도 있습니다.

이 논의는 다음과 같이 요약 될 수 있다고 생각합니다.

평범하게 작성된 응용 프로그램 특정 코드 <잘 작성된 범용 코드 <잘 작성된 응용 프로그램 특정 코드

자체 개발 솔루션이 카테고리 3에 해당되는 사람은 특정 문제에 대한 원래 질문에 대한 답변을 반드시 알고 있습니다. STL은 카테고리 2에 속합니다. 따라서 " STL을 사용해야 합니까? "라는 질문을해야하는 사람에게는 대답이 그렇습니다.

STL은 고급 가상 메모리 시스템으로 인해 메모리 할당에 대한 필요성이 덜 중요하기 때문에 (PC는 여전히 매우 신중해야하지만) PC에서 사용할 수 있습니다. 가상 메모리 기능이 제한적이거나 전혀없고 캐시 손실 비용이 큰 콘솔에서는 예측 가능하거나 제한된 메모리 할당 패턴을 가진 사용자 지정 데이터 구조를 작성하는 것이 더 나을 것입니다. (그리고 PC 게임 프로젝트에서도 똑같이 잘못하지 않을 것입니다.)

이 질문은 실제로 더 큰 질문이 아니라고 생각합니다. Y에 X 를 사용해야 합니까? 그리고 실제로 대답 할 수있는 유일한 방법은 직접 해보는 것입니다. X가 훌륭하게 작동한다고 말하는 모든 사람에게 끔찍하다고 말하는 사람이 있습니다. 그리고 둘 다 프로젝트에 적합합니다.

대부분의 다른 분야와 달리 소프트웨어의 가장 큰 장점은 원하는 방식으로 작동하지 않는 경우 언제든지 나중에 변경할 수 있다는 것입니다. 나중에이 프로젝트에서 STL이 작동하지 않는다는 것을 알고 있습니까? 그것을 빼내고, 그 자리에 다른 것을 넣으십시오. 임무를 어떻게 사물간에 나누는 것이 마음에 들지 않습니까? 리 팩터 당신이 객체를 사용하는 것을 좋아하지 않습니까? 직선 C 방법으로 교체하십시오. 구조체와 메소드에 저장된 모든 것을 조작하는 것을 좋아하지 않습니까? 그것들을 C ++ 객체로 교체하십시오.

나는 STL에 대해 말합니다. 내 이유는 매우 간단합니다.

1. 게임을 작성하기 위해 STL이 필요하지 않습니다. 큰 것도 아닙니다.
2. STL은 컴파일 시간을 크게 증가시킵니다.
3. 컴파일 시간이 길면 개발 과정에서 반복 횟수가 줄어 듭니다.

반복 횟수를 가장 중요하게 생각하므로 STL 및 반복을 늦추는 다른 개발 기술 (그것을 위해 설계 또는 컴파일 해야하는 스크립트 언어)을 피하십시오.

비용이 많이 드는 반복은 실제로 거의 일어나지 않는 작업을 수행하려는 대규모 개발 팀으로 이어집니다. 나는 그것을보고 들었고, 범인 중 하나는 템플릿 라이브러리의 컴파일 시간 인 것 같습니다.