비디오 게임은 정보를 어떻게 화면에 저장합니까?

비디오 게임을 처음부터 만들려고 노력하고 있지만 실제로는 새로운 것이 아니며 기본 문제가 계속 발생합니다. 가장 중요한 것은 비디오 게임이 오프 스크린 정보를 어떻게 저장 하는가? 내 말은 프로그램이 화면에 다음에 무엇을 표시할지 어떻게 알 수 있습니까? 또는 플레이어가 환경을 변경하더라도 다음에 화면에로드 될 때이 변경이 어떻게 유지됩니까?

예를 들어 New Super Mario Bros에서? 차단 한 다음 화면에서 나오고 다시 나오더라도 여전히 적중 상태입니다. 다음에 플레이어가 블록을로드 할 때이 정보는 어떻게 유지되고 실행됩니까? 왜 그냥 재설정되지 않습니까?

일반적으로 게임 환경의 논리적 상태를 시각적 표현과 분리해야합니다.

플레이어는 화면에서 작은 부분 만 볼 수 있지만 여전히 전체 레벨의 상태를 메모리에 유지하고 일반적으로 전체 레벨의 게임 메커니즘을 계산합니다. 세계가 너무 커서 램 및 / 또는 CPU가 너무 많이 필요할 경우 하드 드라이브에 더 멀리 영역을 일시 중단 할 수 있습니다.

렌더링 서브 루틴은 레벨의 어떤 부분이 현재 화면에 있는지 확인한 다음 그 부분 만 그립니다. 화면에 표시되지 않은 것이 그려지지는 않지만 업데이트되지 않았다는 의미는 아닙니다.

당신은 거꾸로 가고 있습니다.

당신은 게임의 논리적 상태에서 시작하여 그것을 모델링합니다. 전 세계의 전체 논리적 상태는 거의 확실하게 메모리에 한 번에 저장하기에 너무 많아서 독립적으로로드하고 저장할 수있는 더 작은 부분으로 분해 할 수 있습니다. 이러한 부분은 종종 청크 로 불립니다 . 이러한 덩어리는 연속적인 세계를 형성 할 수 있지만 별도의 레벨 / 인스턴스 일 수도 있습니다. 용어는 장르와 사용하려는 기술에 따라 크게 다릅니다.

그런 다음 관심있는 부분, 즉 플레이어 근처에있는 덩어리를로드합니다. 너무 멀리 떨어진 청크는 디스크 / 영구 스토리지에 저장되고 메모리에서 언로드됩니다.

그런 다음 마지막 단계로 실제로 보이는 것을 결정 하고 현재 게임 상태를 시각적으로 표현 하여 화면에 렌더링합니다.

물론 전체 시각적 표현을 매번 다시 작성하지 말고 이미 구성한 부분이 있지만 이것이 기본 원리 인 경우이를 캐시하고 재사용하십시오.

출력되는 모든 프로그램에 적용됩니다. 텍스트 편집기와 같은 일반 GUI로 프로그램을 작성하는 경우 문서를 모델링 한 다음 GUI가 문서의 상태 및 표시되는 부분을 결정하여 화면에 렌더링합니다. 또는 양식 필드를 적절하게 채우십시오.

주요 요점은 다음과 같습니다. 데이터를 저장하는 방법과 함께 데이터를 어디에 어떻게 저장해야하는지 생각해보십시오. 거의 모든 프로그램은 데이터 스토리지를 처리해야합니다. 데이터를 저장하지 않는 경우는 거의 없습니다.

다른 사람들이 말했듯이지도 (예 : 배열)를 유지하고지도의 보이는 부분을 화면에 그리고 화면에서 다시 읽지 마십시오.

그러나 일부 구형 시스템에서는 문자 그대로 데이터를 화면에 표시하지 않습니다. 예를 들어 320x200 디스플레이에 400x300 픽셀의 비디오 메모리가 있으며 뷰포트를 정의합니다 ( "X = 10 Y = 30에서 시작"). 레지스터를 조정하여 화면을 스크롤 할 수 있습니다. 바이트를 이동하는 데 필요한 수십만 사이클을 소비 할 필요가 없으며 비디오 하드웨어가 읽기 시작하는 위치 만 변경하면됩니다.

NES는 이것을 타일 기반 시스템과 결합하여 가지고 있습니다 : http://wiki.nesdev.com/w/index.php/PPU_scrolling

RAM이 충분하지 않기 때문에 NES는 전체 이미지를 메모리에 구성하지 않습니다. 대신 2 화면 너비의 타일 세트를 정의하는 RAM 배열이 있습니다. 타일 ​​종류 당 1 바이트 비디오 하드웨어는 타일 및 X / Y 오프셋 좌표를 조회하여 어느 지점에서 어떤 픽셀을 표시할지 결정합니다.

이런 종류의 질문을한다면 게임을 할 수있는 시점에 도달 할 수있는 길이 멀 것입니다. 그러나 질문의 ​​핵심에 도달하면 프로그램은 프로그램의 백엔드에있는 변수에 여러 가지 다양한 상태를 저장할 수 있습니다. 몇 가지 예를 살펴 보겠습니다.

마리오 브라더스 (또는 비슷한)는 현재 레벨의 상태를 저장합니다. 여기에는 블록이 맞았는지 여부에 따라 사망하기 전의 거리가 포함될 수 있습니다. 좀 더 객체 지향적 인 의미에서, 게임은 단지 "여기에 블록이된다"라고 말하고 블록이 존재합니다. 그런 다음 블록을 치면 블록이 내부 상태를 변경하여 "I hited"라고 말합니다. 이와 같은 데이터는 다양한 방식으로 저장 될 수 있습니다.

워드 프로세서는 데이터 구조로 데이터를 저장합니다. 이제 구현할 수있는 방법과 방법이 많이 있지만 아마도 어떤 형태의 트리를 사용합니다. 트리에는 하나 이상의 노드가 있습니다. 왼쪽으로 가기 전에 추가 된 것 그 후에 추가 된 것은 오른쪽으로갑니다. 세 개의 노드를 추가하면 두 개의 노드가 중간 노드에 매달려 있습니다. 그리고 나무는 어디서나 추가되는 새로운 조각으로 더 커질 수 있으며 나무는 스스로 재건 될 것입니다. 또는 적이 돌아 다니는 사수 게임을 생각해보십시오. 각각에는 위치, 생명 등을 추적하는 변수가 있으므로 상처를 입었을 때 상처를 입 었음을 기억할 것입니다.

이 모든 것은 데이터 구조에 대한 지식이 필요합니다. 화면에 보이는 것 이상으로 진행됩니다. 배열, 목록, 해시 (때로는 사전 또는 맵이라고 함)에 대해 읽고 다시 문제를 제기하는 것이 좋습니다.

다음은 좋은 출발 자료입니다.

• http://visualgo.net/

어느 정도까지 이것은 3D 렌더링 방법의 함수입니다. 예를 들어 OpenGL은 XY 화면 공간에서 -1.0, +1.0 범위를 벗어난 형상을 자동으로 제거합니다 (Z는 더 복잡하지만 유사 함). 컬링 된 지오메트리는 프래그먼트 (약 픽셀)를 생성하지 않으므로 렌더링하기 위해 시스템으로 보내지더라도 실제 이미지로 변환되지 않습니다. 어쨌든 렌더 윈도우 외부의 공간에 쓸 수는 없습니다 (모든 것이 제대로 작동하는 경우).

일부 상황에서는이 동작을 최적화로 사용하기에 충분합니다. 그러나 비디오 카드가 표시되는 내용을 알기 전에 모든 게임 데이터를 하나 이상의 렌더링 단계 (정점 셰이더)를 통해 전달해야합니다. 예를 들어, Skyrim과 같이 그것은 비현실적입니다. 렌더링 파이프 라인을 통해 세계의 모든 정점을 보내야 할뿐만 아니라 모든 정점을 시스템 / 비디오 메모리 에 로드 해야합니다 . 가능하다면 비효율적입니다.

따라서 많은 게임에서 CPU 기반 컬링을 사용합니다. 그들은 일반적으로 어떤 종류의 LOD (Level of Detail) 시스템을 구현할 것이며, 여기서 자산의 품질과 존재가 주어진 맥락에서 얼마나 중요하게 평가되는지에 의해 영향을받습니다. 피라미드 메쉬는 산에서 50 마일 떨어져 있으면 산에 대한 근사치 일 수 있습니다. 전혀 볼 수 없다면 (다른 산에 의해 막힌 것처럼)로드 할 필요도 없습니다. 이 작업을 수행하는 데 더 복잡한 방법이 많이 있습니다.이 질문에서 요청한 깊이와 직접 관련이 없다고 생각되는 주제이지만 가장 일반적인 예 중 하나에 대한 테셀레이션 을 살펴보십시오 .

이것의 진짜 요지는 비주얼이 게임의 산물이라는 것입니다. 실제 데이터는 대부분보고 있거나 보지 않는 것과 직접적으로 관련이 없으며 그림이 화면에 쓰여지는 지점에 도달하기 전에 외부 정보를 제거하기 위해 다양한 단계로 데이터를 필터링합니다. 엔진 디자인에 따라, 같은 게임에 2D 및 3D 인터페이스를 갖는 것과 같은 것이 가능한 한, 비주얼은 실제 게임 로직에서 크게 분리 될 수 있습니다. 많은 게임 엔진이 출력없이 실행되는 것도 가능합니다. 때때로 이것은 게임 AI를 테스트하는 데 사용됩니다.

그래도 상황이 복잡해질 수 있습니다. 마리오 게임과 같은 간단한 것에서는 레벨에있는 모든 적의 움직임을 눈에 띄지 않더라도 계산하는 것은 너무 금지되지 않습니다. 현대적인 맥락에서 화면 밖에서 일어나는 일은 진지한 고려의 실제 문제입니다. 도시 전체에 NPC가 여러 개있는 경우 플레이어가 다른 도시에있을 때처럼 완전히 추려 질 때 어떻게 행동하는지 어떻게 처리합니까? 지도 전체에 걸쳐 수백 개의 NPC 결정을 계산하고 싶습니까? 대답은 보통은 아니지만 그렇게하지 않는 정확한 방법은 다양 할 수 있으며 게임에 영향을 줄 수 있습니다.

이것이 지금 작동하는 방식이라는 점에 유의해야합니다 . 구식 Mario 게임 자체는 당시의 하드웨어 제한이 극도로 다르기 때문에 매우 다른 방식으로 프로그래밍되었을 가능성이 높습니다 (정확한 방법으로 말할 수는 없습니다). 당시 3D의 개념은 존재하지 않았습니다. 그러나 오늘날 거의 모든 게임, 심지어 완전히 2D 게임이라도 모르는 경우에도 어떤 형태로든 3D 렌더링을 사용합니다. 최신 비디오 하드웨어는 먼저 3D이며 2D 렌더링 (적어도 하드웨어를 올바르게 사용하는 경우)은 3 차원을 무시합니다.

귀하의 질문에 대답하기 위해 : 비디오 게임은 게임 세계의 상태를 화면과 관련이없는 추상적 인 데이터 구조로 유지합니다. 그런 다음 필요에 따라 (예 : 플레이어의 위치에 따라) 화면에 렌더링됩니다.

상태 목적으로 비디오 RAM을 직접 사용하는 게임은 8 비트 80 년대, 심지어 16 비트 시대에도 있었지만, 해당 플랫폼 용으로 개발하거나 RAM을 KB 단위로 제한하는 µC를 제외하고는 GB를 잊어 버리십시오.

즉, 프로그래밍과 관련된 모든 것에 익숙하지 않은 것 같습니다. 그렇지 않으면 질문이 나오지 않을 것입니다. 아주 쉬운 것을 먼저 프로그래밍하는 것이 좋습니다. 텍스트 입력 / 출력 (단순 프롬프트 및 모든 것) 만있는 것입니다. 솔직히 말해서, 내가 그 일을했던 시간은 약 30 년이 지났기 때문에 정말 좋은 자료는 없지만, 지역 도서관 은 인터넷보다 나아서 프로그래밍을 시작하기에 좋습니다.