콘텐츠를 하드 코딩하는 것이 왜 나쁜가요?

나는 대부분의 게임이 대화 텍스트를 파일로 저장한다는 것을 알고 있지만 텍스트 기반 게임 중 일부는 실제로 콘텐츠 (맵, 선택, 가능한 플레이어 명령, 스토리 텍스트)를 게임 코드에 프로그래밍하는 것을 보았습니다.

몇 가지 이유를 생각할 수 있지만 텍스트 게임조차도 프로그램 외부의 모든 파일을 파일에 보관하는 주요 이유는 무엇입니까?

구현 세부 사항은 널리 사용되는 XML 형식과 같은 내용으로 컨텐츠를 보유하고 구문 분석 한 다음 XML 파일에서 작성된 변수를 기반으로 맵을 렌더링하거나 텍스트를 표시하는 것과 XML 파일을 완전히 포기하는 것 사이에는 거의 차이가 없습니다. 둘 다 문자열로 화면에 출력됩니다. 차이점은 단순한 표기법이 아닙니까?

일부 게임은 심지어 코드 안에 그래픽 (ASCII 아트?)을 가지고 있습니다. 나는 이것이 옳지 않다는 것을 알고 있으며 그것이 왜 나쁜지 몇 가지 이유를 추측 할 수 있지만 그 주요 이유를 모른다.

대부분의 콘텐츠를 프로그램 외부에 두는 것이 매우 인기가 있습니다. Dwarf Fortress 조차도 실제 ASCII 문자를 사용하지 않고 ASCII 문자 이미지를 메모리에로드합니다.

XML 파일을 작성, 구문 분석 및 작업하는 것은 약간의 PITA이기 때문에 주로 묻습니다. 모든 고유 한 던전 (콘텐츠)을 자체 클래스로 만드는 게으른 대안과 비교하면 알 수 있습니다.

몇 가지 이유가 있습니다. 몇 가지만 살펴 보겠습니다.

1. 소스 코드를 혼란스럽게 만듭니다. 대화 상자 (트리)가 많은 경우 코드베이스의 상당 부분은 실제 게임 코드와 관련이없는 텍스트 일뿐입니다.
2. 단일 문자로 변경할 때마다 다시 컴파일해야합니다.
3. 대화 상자 자체를 탐색하기가 어렵습니다. 소스 내부에 완전히 대화 상자 트리를 구현하려고하면 스파게티와 중첩 된 ifs, switches 등이 엉망이 될 것입니다. 그러면 오류가 발생하기 쉽고, 읽기 어렵고 디버그하기 어려운 코드가 생성됩니다.
4. 사람들이 게임을 수정하거나 확장 할 수있게하려면 소스 코드를 처리 할 필요가없는 것이 훨씬 쉽습니다.
5. 팀에서 일한다면 위의 요점이 훨씬 더 중요합니다. 작가가 대화 상자에 들어가기 위해 코드를 망칠 필요는 없습니다.
6. 기존 라이브러리를 사용하는 경우 XML 또는 기타 표준 파일 형식을 구문 분석하는 것은 매우 쉽습니다. 따라서 이러한 방식으로 구현하는 데 드는 비용은 매우 낮지 만 위에서 언급 한 문제를 피하면서 많은 이점을 얻을 수 있습니다.
7. @MiloPrice가 아래에 지적했듯이 텍스트가 외부 파일에 있으면 게임을 현지화하는 것이 훨씬 쉽습니다. 파일을 추가하여 언어를 추가 할 수 있으며, 팀은 소스를 건드리지 않고 번역을 처리 할 수 ​​있습니다 (특히 사람들이 모든 코드를 보지 말아야하는 사람을 번역하도록 허용하는 경우 특히 중요합니다. 팀에 속하지 않은 커뮤니티 등).

게임 컨텐츠 데이터를 코드에 넣는 것은 해당 게임 컨텐츠 데이터의 잠재적 인 변경 또는 반복을 보려면 게임 자체를 다시 컴파일해야한다는 것을 의미합니다. 이것은 두 가지 이유로 나쁘다 :

• 게임이 작성된 많은 언어는 컴파일 시간이 길다. C ++은 특히이 점에서 매우 나쁠 수 있으며 C ++은 대형 상용 게임에서 매우 일반적인 언어입니다. C # 및 Java와 같은 언어에서는 문제가 아니지만 게임 데이터가 실제로 실행되는 동안 외부 파일에 게임 데이터를 저장하여 변경 사항을 확인하는 것만 큼 빠르지는 않습니다.

• 많은 게임은 종종 컨텐츠를 제작하는 비 기술적 개발자 (디자이너 및 아티스트)로 구성된 팀이 개발합니다. 비 기술적 인 사람들이 게임을 다시 컴파일하거나 "거대한 프로그래머 도구"를 다루지 않고 콘텐츠를 반복 할 필요가 없을뿐만 아니라 프로그래머에게만 소스 코드 노출을 최소화하는 것이 바람직 할 수 있습니다. 소스 코드에 액세스 할 수 있으며 실수로 유출 할 수있는 사람이 적습니다.

텍스트 또는 XML 파일에서 데이터를로드하는 복잡성을 과대 평가하고 있다고 생각합니다. 대부분의 경우 라이브러리를 사용하여이를 수행해야하므로 XML / JSON / 구문 분석 프로세스가 훨씬 쉬워집니다. 예, 데이터 중심의 레벨 로딩 시스템을 작성하는 데 약간의 초기 비용이 있지만, 일반적으로 각 레벨을 나타내는 고유 클래스 수 톤에 비해 장기적 으로 많은 시간을 절약 할 수 있습니다.

더 작거나 간단한 게임은 데이터 기반 접근 방식의 장기 투자를 통해 얻을 수있는 이익이 많지 않을 수 있으므로 개발자가 지원하는 기존 프레임 워크 / 엔진을 사용하지 않는 한 단순히 데이터를 인코딩하는 것이 더 효율적일 수 있습니다 게임 코드.

물론 특정 게임에서 데이터를 외부 파일에 넣거나 선택하지 않는 데는 여러 가지 이유가 있습니다. 그것들을 모두 나열하는 것은 불가능합니다. 어떤 수준에서는 일반적으로 게임을 재구성하지 않아도 제공 할 수있는 추가 반복 속도 또는 유연성으로 모두 축소됩니다.

항상 그렇듯이 항상 그렇습니다. 그러나 먼저 하드 코딩 자체가 나쁘지는 않다고 주장하고 싶습니다.

간단한 게임에서 하드 코딩 된 콘텐츠, 특히 대화 상자 텍스트를 사용하여 세상이 끝나지 않았습니다. 우리 프로그래머들은 추상화하는 것을 좋아하지만 추상화의 각 레이어는 프로그램을 더 복잡하고 이해하기 어렵게 만듭니다.

게임이 충분히 단순해서 일부 내용을 하드 코딩 할 수 있다면 간단하게하기 위해 확실히 고려할 것입니다.

그러나 이것은 실제로 너무 많이 확장되지는 않습니다. 콘텐츠를 외부 리소스에 넣는 가장 일반적인 이유는 한 사람 또는 팀이 게임 작성에 집중할 수있는 반면 다른 사람은 콘텐츠 작성 및 연마에 집중할 수 있기 때문에 팀워크를 단순화하는 것입니다.

그러나 프로그램과 콘텐츠 사이의 선을 그리는 것이 항상 사소한 것은 아닙니다. 텍스처는 100 % 함량이라고 말할 수 있습니다. 그러나 절차 적으로 생성 된 텍스처는 어떻습니까? 대화 상자 텍스트는 100 % 내용으로 간주 될 수 있습니다. 그러나 이전 작업에 따라 대화 상자가 변경되는 경우는 어떻습니까? 스크립트 또는 셰이더와 같이 프로그램의 100 % 부분으로 간주 될 수있는 다른 요소도 게임 내용의 일부로 간주 될 수 있습니다. 하드 코딩해야합니까? 외부 리소스로로드해야합니까?

게임에서 지원하는 각 유형의 컨텐츠에는로드 및 해석과 관련된 코드가 있어야하므로 일반적으로 확실하지 않은 경우 컨텐츠를 하드 코딩하는 것이 좋습니다. 실제로 유연성이 필요합니다 (생각할 때가 아니라 실제로 필요할 때).

마지막으로, 리소스 파일에 데이터를 저장하는 것의 한 가지 장점은 필요할 때만 (따라서 게임로드 시간을 단축시킬 수 있음) 데이터를 더 이상 필요하지 않을 때 언로드 할 수 있다는 것입니다. 메모리에 들어갈 수있는 것보다). (Nitpickers의 코너 : 리소스 DLL은 외부 리소스로 간주 될 수 있음)

텍스트 파일에 저장해야하는 큰 이유는 재사용 성입니다. 텍스트 파일에서 맵, 대화 상자 및 기타 리소스를 읽는 텍스트 게임 프레임 워크를 만들면 다른 게임에 프레임 워크를 재사용 할 수 있습니다. 텍스트 게임 외에도 콜 오브 듀티 (Call of Duty)와 같은 대규모 예산 타이틀이 매년 새로운 게임을 출시하는 방식입니다.

또 다른 이유는 이식성입니다. 웹, PC, Mac, Android 등에서 동일한 파일을 사용할 수 있습니다.이 다른 플랫폼에 대한 프레임 워크를 모의하기 만하면 게임 데이터의 대부분이 변경되지 않습니다.

텍스트 기반 게임을 넘어 서면 파일에 저장된 스크립트와 데이터가 있으면 재 컴파일 시간이 줄어들고 데이터를보다 쉽게 ​​조작 할 수있는 인터페이스를 만들 수 있습니다.

보다 빠른 변경을 위해 대량 생산으로 톤을 빠르게 개발할 수 있습니다.

간단한 변경을 위해 소스를 입력하고 편집하는 방법을 배우도록 모든 사람을 가르 칠 필요는 없습니다. 실제 코드에서 코드를 끌어다 놓으면 더 많은 사람들이 속일 수 있습니다. 어떤 옵션을 사용할 수 있는지 쉽게 알 수 있으며 게임의 여러 부분을 미세 조정하는 전체 프로세스가 훨씬 덜 걸립니다. Q & A도 도움이 될 수 있습니다.

아직 아무도 이것을 언급하지 않았지만 큰 이유는 현지화를 훨씬 쉽게 만드는 것입니다. 영어, 프랑스어, 독일어, 스페인어, 포르투갈어, 이탈리아어, 러시아어, 중국어 및 기타 다른 언어를 지원해야하는 경우 하드 코딩하려면 모든 언어에 대해 별도의 코드 숨김이 필요합니다. 또한 특정 컨텐츠 (읽기 : 검열)를 제거해야하는 경우, "이 항문 프로빙 미니 게임을 수동적 공격적 배너로 대체하여 진행 상황을 그래픽으로 설명하는 대신 코드 자체를 변경하여이를 피해야합니다" ". 다른 라이브러리를로드해야하기 때문에 언어를 변경하기 위해 게임을 다시 시작해야 할 가능성이 높기 때문에 소비자에게는 다소 친숙하지 않습니다. 드디어,

반면에 외부 리소스를 사용하는 경우 다른 언어를 지원한다는 것은 다른 리소스 파일을로드하는 것을 의미합니다. 게임이 실행되는 동안 쉽게 수행 할 수 있습니다. 즉, 단일 코드베이스를 사용하여 개발을 대폭 간소화 할 수 있습니다. 또한 다른 언어에 대한 출시 후 지원을 쉽게 추가 할 수 있습니다. 마지막으로, 디스크 공간과 대역폭을 절약하기 위해 사용자가 특정 언어 (게임에서 자주 발생하지는 않지만 여전히 가능한 언어)를 설치하지 않도록 선택할 수 있습니다.

핵심 구절은 우려의 분리 라고 생각합니다 .

코드에 텍스트가 포함되어 있지 않으면 코드가 덜 복잡해집니다. 코드를 작성하는 프로그래머는 특정 텍스트에 대해 생각할 필요가 없으며 코드에 집중할 수 있습니다.

그는 현지화에 대해 생각할 필요가 없습니다. 현지화를하는 사람은 코드에 대해 걱정할 필요가 없습니다.

나는 '백인보다 백인'사람이되기가 너무 쉽고 외부 텍스트 리소스 파일을 따뜻하게 사용하는 것이 좋습니다.

왜? 여기에는 각 솔루션의 비용 / 문제 / 장점의 균형을 맞추는 선택이 있습니다.

외부 파일을 사용할 때 ... 음, 다른 답변은 이점을 충분히 설명한다고 생각합니다. 그러나 비용은 어떻습니까? 유효한 형식을 정의하고, 인터프리터를 작성하고, 파일 형식에 동의하고, 다른 응용 프로그램 인 편집기를 작성해야합니다. 대규모 프로젝트를 구축하는 50 명의 코더 팀 구성원 인 경우 0.00 % 문제입니다. 그러나 당신이 혼자라면 : 당신은 멈췄습니다.

다시 말하지만, 외부 리소스의 큰 유연성 이점을 과소 평가하지는 않습니다. 데이터 기반 프로그래밍은 비디오 게임을위한 길입니다. 그러나 비용을 잊지 마십시오.

반면에, 코드 안에 텍스트가 있으면 프로토 타입을 빠르게 만들 수 있으므로 처음에 선호해야합니다. 그런 다음 프로젝트가 성숙함에 따라 대화를 모델링하는 데 필요한 데이터 종류 (분위기 / 역사 / 상태 / ...)를 분석하는 것이 좋습니다. 그런 다음 어떤 클래스 / 규칙 / 파일 형식을 결정하고 실제로 다른 사람들이 코드를 내용에서 편집 / 분리 할 수있게합니다. 또는 간단한 대화 상자 (Mario ...)가있는 게임의 경우 비용이 너무 높고 문자열 / 동작을 하드 코딩 된 상태로 유지하십시오.
당신의 전화.

현지화에 대한 설명 : 해시 테이블 일 뿐이므로 독립적이고 쉽게 해결할 수있는 문제입니다.

라이센스 가 코드에 내용을 포함시키지 않는 이유 일 수도 있다고 생각 합니다.

예를 들어

• 귀하의 코드는 FLOSS 일 수 있지만 콘텐츠 라이센스를 전혀 원하지 않습니다 (게임 코드를 게시하여 다른 사람들이 다른 콘텐츠로 유사한 게임을 만드는 데 사용할 수 있음)
• 코드가 FLOSS 일 수 있지만 콘텐츠에 Creative Commons 라이선스를 사용하려는 경우 (소프트웨어 라이선스 는 콘텐츠에 적합 하지 않으며 그 반대도 마찬가지입니다)
• 코드는 독점적 이지만 무료 콘텐츠를 재사용하고 있습니다.
• 코드는 독점적이지만 무료 / 자유 라이센스로 자신의 콘텐츠를 게시하려고합니다.