2D 게임을위한지도를 만드는 가장 좋은 방법은?


16

주관적인 "최상의"키워드에 대해 사과드립니다.

내 친구와 나는 2D 어드벤처 게임을 만들기 시작했다. 그것은 포켓몬이나 젤다 스타일의 하향식입니다 (관점 그대로). 우리는 플레이어가 머신의 메모리 기능에 부담을주지 않으면 서 트래버스 할 수있는 대형 월드 맵을 만드는 방법에 대해 논의했습니다.

첫 번째 충동은 플레이어 주위에 큰지도와 원을 만들어서 콘텐츠를로드하는 것이 었습니다. 우리는 이것이 오랫동안 유지되지 않을 것이라고 생각하고 맵을 섹션으로 분할하기로 결정했습니다. 먼저 우리는 네 개의 큰 섹션을 가지고 있었지만 단순히 여러 개의 작은 섹션으로 나눌 수 있다는 것을 깨달았습니다.

나는 SNES에서 약간의 젤다를 연주했고,지도가 바뀌는 동안 내용이로드 될 수 있음을 보았습니다. 내 말은,로드 할 데이터의 직사각형 영역을 확인하는 대신 맵 부분에서 맵 부분으로 이동할 때 데이터를로드 및 언로드하는 많은 작은 덩어리로 맵을 간단히 나누는 것입니다.

오늘, 그는 게임의 모든 그리드에 대한 데이터를 포함하고 우리가 필요로하지 않는 데이터에 대한 지속적인 디스크 저장 작업 인 단순한 2D 어레이 맵 [WIDTH] [HEIGHT]을 만들고 싶다고 말했습니다.

나는 이러한 아이디어에 대해 확신하지 못하고 여기에서 생각할 수 있다고 생각했습니다. 주제에 대한 모든 링크, 리소스 또는 자습서는 효율적으로 수행하는 방법에 대한 우리의 질문에 대한 직접적인 답변뿐만 아니라 크게 감사하겠습니다.


어떤 기계를 사용하고 있습니까?
— David Titarenco 21

지금까지 SFML을 사용하는 C ++가있는 Windows (SFML은 변경 될 수 있으며 C ++은 변경되지 않음) 우리는 이식성 ATM을 목표로하지 않습니다.
— IAE

2
NES에서 Zelda의 구식 학교를 가려면 1 화면 전용지도를 사용하십시오. 작은지도는 플레이어가 의도의 범위에 초점을 맞추도록 도와줍니다 (예 : 던전에서는 방만 처리합니다. 디아블로에서는 몬스터가 위아래로 이동하지 않았습니다). FAllout3 및 Oblivion과 같은 오픈 스페이스 게임은 당신에게 제공하지 않습니다.
— Stephen Furlani

답변:


27

먼저,지도 크기를 추정하십시오. "큰 세계"가 메모리에 적합하지 않다고 가정하지 마십시오. 오늘날 메모리에서 10MB 이상을 차지하는 맵은 절대적으로 수용 가능하며 간단한 타일 기반 2D 세계에서 10MB로 LOT을 채울 수 있습니다.

세계 가 정말 큰 경우 가장 강력한 솔루션은 실제로 맵 청크를 사용하는 것입니다. 세계를 고정 크기 청크로 나눕니다 (예 : 64x64). 플레이어가 움직일 때 청크를 즉시로드하여 하나 이상의 청크가 모든 방향으로로드되도록 유지합니다 (즉, 플레이어가있는 청크와 모든 인접 항목을로드).

청크 언로드와 관련하여 여러 전략 중에서 선택할 수 있습니다. 열심히 언로드한다는 것은 플레이어가 충분히 멀리 이동하는 순간 모든 덩어리를 언로드하고 디스크에 저장한다는 것을 의미합니다. 그러나 언로드를 지연시켜 성능을 향상시킬 수 있습니다 (디스크 액세스는 비용이 많이 드는 작업이므로 청크를 저장하는 것이 좋습니다).


6
몇 가지 예시적인 수학 : 10MB의 Tile * s는 면당 1619 개의 타일이있는 정사각형을 제공합니다. 원래 Zelda의 맵은 긴 쪽의 256 타일과 짧은 쪽의 절반보다 작았습니다. 따라서 메모리 사용량이있는 첫 번째 Zelda보다 36 배 이상 클 수 있습니다. 정말 많은 콘텐츠 를 만들 준비가 되셨 습니까? (번호)

@ user744 그 의견은 매우 오해의 소지가 있습니다. 지도를 만들려면 타일에 대한 포인터 이상의 기능이 필요합니다. 타일에 포함 된 데이터도 저장해야합니다. 모든 2D 게임에 정해진 양의 미리 정의 된 고정 타일이있는 것은 아닙니다.
— Jeroen

5

개인적으로 TileEd 와 같은 지정된 타일 편집기를 사용하여 맵을 작성 합니다. 이 접근 방식은 몇 가지 이점을 제공합니다.

  • 적은 자원을 사용합니다. 끝없이 맵을 만들려면 인덱스가있는 타일 시트와 데이터 파일을로드하기 만하면됩니다.
  • 타일 ​​크기에 따라 맵을 아주 작은 덩어리로 나눌 수 있으므로 캐릭터가 세계를 이동하는 동안 행 / 열을 쉽게 추가 / 제거 할 수 있습니다.
  • 지도를 설명하는 데이터 파일이 있으면 지형 정보를 쉽게 추가 할 수 있습니다. 이것은 벽이나 호수와 같은 다른 타일 유형 (예 : 장애물) 또는 캐릭터의 움직임이 느려질 수있는 늪을 허용합니다 ...
  • 마지막으로, 타일 기반 맵은 편집하고 나중에 조정하기가 훨씬 쉽습니다. 에디터를 항상 실행하고 일부 내용을 변경하고 새로운 데이터 파일을 저장할 수 있기 때문입니다.

지연을 방지하기 위해 게임 플레이 중에 맵의 비트를로드하지 않는 것이 좋습니다. 앞에서 언급했듯이 타일 시트를 메모리에 보관할 수 있으므로 필요하지 않습니다. 캐릭터가 "세계"의 다른 부분에 들어가면 타일 시트를 다른 타일로 교체 할 수 있습니다 (예 : 사막 타일로 대체 된 스노우 타일).

타일을 화면에 비벼주 는 것이지도를 렌더링하는 가장 빠른 방법 일 것입니다. SFML을 모르지만 사이트의 문서에서 Sprite클래스를 살펴 보거나 클래스의 Copy기능을 사용해야합니다 Image.

업데이트 : SFML 문서 중 일부를 읽었으므로 성능을 위해 이미지를 조작 Drawable하거나 Sprite대신 사용해야 합니다. 분명히 Tiled SFML 로더 가 있습니다. 아마도 무언가를 빨리 시작하고 실행하는 좋은 방법 일 것입니다.


1

게임에서 이야기하고 싶은 이야기를하기 위해 필요한 크기의지도를 만들어 시작하십시오. 사람들이 게임을하는 데 필요한 최소 사양으로 컴퓨터에서 테스트하십시오. 너무 느리면 프로파일 링하고 최적화하십시오.


0

제 생각에는 개별 타일의 2D 배열을 사용하는 것이 가장 좋습니다. 전체 큰지도를 하나의 2D 배열로 가질 수 있으며 주어진 시간에 표시해야하는 부분 만 그립니다. 다음은 tabageos (tbgs.js) HTML5 게임 라이브러리와 함께 2D 맵 배열을 사용하는 예입니다. http://actiontad.com/tabageosHTML5/Examples/BlitMathCameraAndTravelers/


-3

ultima-online (Fallout 3 또는 Oblivion)을 재 구축 할 계획이 아니라면 세상이 완벽해야하는 이유는 없습니다. Baldur 's Gate와 Icewind Dale은 게임 플레이를 방해하지 않는 효과적인 맵을 구현하는 두 가지 게임입니다.

물론, 당신은 그들이하는 것보다 훨씬 더 많은 컴퓨팅 마력을 가지고 있기 때문에 로딩 화면은 최소화되어야하지만 Fallout과 Oblivion조차도 어떤 것들에 대한 로딩 화면을 가지고 있습니다.

내가 말할 수있는 것은 32x32 타일 세트를 가져 와서 NSImage에 그리는 iPhone 용 작은 Obj-C 라이브러리를 작성하고 있다는 것입니다. 나는이 방법으로 약 10fps를 얻었고 아마도 OpenGL을 사용해야 할 것입니다. 그러나 캐릭터가 rect에서 벗어나면 다시 그려야합니다.

맵을 9 개의 화면 크기 (나에게는 960x640 블록)로 분할해야합니다. 따라서 캐릭터가 중앙 블록을 벗어나면 9 개의 화면을 큰 이미지 (약 1.2MB)로 다시 그립니다. iPhone 3G에서 20MB 제한 이하의 공간). 상당히 느리게 (10fps보다 훨씬 느리게) 재생 중에 다시 그리기가 눈에 띄지 않습니다.

언젠가 OpenGL ES로 옮길 가능성이 있지만 지금은 잘 작동합니다.


[편집하다]

내가 명확히 할 수있게하십시오.

9 화면 배경의 드로잉 알고리즘은 0.1 초 (10fps 플랫 아웃)가 걸립니다. 플레이어가 1 분의 1 초 이내에 전체 화면을 가로 지르지 않는 한 재생 중에는 다시 그릴 수 없습니다.


게임에 10fps가 허용된다고해서 특히 iPhone과 같은 전력 제한이있는 기기에서는 좋은 생각이되지 않습니다. 다시 그리기를 수행하지 않고 GPU 측에서 래스터 화를 처리하고 실제로 프로그램이 잠을 자도록 할 수 있으므로 휴대 전화가 뜨거워 지거나 배터리 수명이 다하지 않습니다.

@Joe Wreschnig ... ??? 플레이어가 화면을 움직일 때 필요에 따라 그려집니다. 그렇지 않으면 UIImageView의 배경 이미지 가 다시 그려지지 않으므로 처리 능력이 절약됩니다. 귀하의 의견이 이해가되지 않습니다.
— Stephen Furlani

게임에 필요한 fps에 대해서는 주장하지 않습니다. 나는 OpenGL이 사소한 일에 60fps를 제공 할 수 있다고 말합니다 (실제로 정적 장면과 OpenGL로 "다시 그리기"에 대해 이야기조차하지 않습니다)-10fps 만 필요하면 OpenGL을 사용하면 배터리 전력을 낭비하지 않아도됩니다. 다른 "50 프레임". GPU 가속을 사용하는 세상에서는 그리기 방법이 낭비됩니다. PC에서는 문제가 없지만 배터리를 소모 할 때는 그렇지 않습니다.

@ 조, 나는 아직도 당신이 무슨 말을하는지 모르겠습니다. 이미지를 그립니다. 그런 다음 플레이어가 경계에 도달 할 때까지 이미지가 그대로 남은 다음 새 이미지를 다시 그립니다. 배터리 수명을 어떻게 낭비합니까? 요청시 "그리기"만하고 나머지 시간은 UIImageView의 기본 그리기 알고리즘을 사용하여 그려집니다.
— Stephen Furlani
당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.