[📚정보] 겜메는 도트아니래도 문젠 없음 + 겜메 렌더링 특징

[익명(121.173)]

아래 링크는 게임메이커로 9년전에 HD 모바일 게임으로 나온거

https://gall.dcinside.com/game_dev/137624

보통 게임메이커 하면 2D HD 아트시 아래의 문제를 제시하는데 설명해주겠음.

1. 충돌 방식이 픽셀 기반이라 벡터랑 다르게 픽셀 루프도니 무겁다.

이 충돌 방식이 btree + aabb로 1차 처리후 처리되고있음. 게임메이커도 엔진이기때문에 이런건 자기네들도 문제가 있다고 판단해서 다 해결함.

그리고 이제 느리다 불릴만한건 충돌 마스크중 precise 를 체크했을때임. 이게 문제의 '픽셀 충돌'임 이건 aabb후 충돌이 확인되면 그때부터 내부적으로 픽셀 충돌까지 루프를 돌림. 거기서 충돌되면? 루프가 멈추기때문에 얕은 탐색때는 성능 저하가 크게 없음.

그리고 그 루프조차도 타일 사이즈 128x128을 대각선 삼각형급에서도 성능은 잡아먹지만 게임에 지장이 올정돈 아님. 지장이오면 그건 설계에서 뭔가 잘못된거임.

유니티에서도 종종 픽셀 퍼펙트한 충돌을 하려고 이걸 일부로 구현하는 케이스들도 있는걸 감안하면 C++ 런타임에서 루프도는거라 성능적으로 훨씬 쾌적하겠지.

요약 : precise 아니면 문제없다, 그런데 precise도 웬만해선 남발하는거 아니면 문제 없다

2. 텍스쳐가 너무 크면 모바일에 문제가 생긴다.

게임메이커를 옜날에 좀 해본 사람들이면 이 문제에 대해 들어본 사람도 있을거임.

이건 게임메이커 스튜디오 1 시절때부터 바뀌지않는 진리인데, 텍스쳐 그룹을 안나눠서그럼. 유니티에서는 이걸 텍스쳐 아틀라스 형태로 분리를 거치고 그럴건데 당연히 게임메이커도 해야한다.

HD게임쯤되면 당연히 텍스쳐 그룹 분리를 안하면 개판이되겠지. 그리고 게임메이커는 텍스쳐 분리를 정말 편하고 쉽게할 수 있음.

요약 : 텍스쳐 그룹 나누고 vram 플러시랑 unload, load 관리 잘 하면 문제가 없다.

아래의 게임이 FHD게임으로 볼 예시 게임인데 게임메이커로 만들어졌음.

https://www.youtube.com/watch?v=tYKu7XVoThI

The Swords of Ditto: Mormo's Curse - Launch Trailer

이 게임은 텍스쳐랑 직접적으로 들이받아야하는 닌텐도 스위치나 모바일 플랫폼에서 정상적으로 출시했음.

게임메이커 렌더링에 대한 특징

게임메이커는 일반적인 엔진이랑 크게 차이가 있는 부분이 하나있음. 이거덕에도 2D 게임으로서 이것저것 복잡한 묘사를 맘대로 할 수 있게되는데

보통의 타 엔진들이랑 다르게 Draw 구간에 내가 원하는 코드를 다 쑤셔박을수있음.

그렇다보니 게임의 메인 로직이랑 드로우 구간이 하나로 묶여있어서 여러 이상한 표현이 가능함.

예로 들자면 아래와 같은 방식의 코드 예시를 보여줄건데, 이런식으로 게임메이커의 draw는 처리되고 가장 쓰이는 draw_sprite_ext함수로 예시를 들어봄.

draw event내에서

draw_sprite_ext(sprite_asset_name, frame, x, y, xscale, yscale, angle, color, alpha);

draw_text(x, y, string("Hello {0}", "World"));

이러면 내가 지정한 x, y 좌표에 정해진 설정의 스프라이트가 그려지고, 그다음 그 스프라이트 위에 Hello World가 그려짐.

여기서 이제 이런식으로 바꿔보겠음.

x += 64;

draw_sprite_ext(sprite_asset_name, frame, x, y, xscale, yscale, angle, color, alpha);

x -= 64;

draw_text(x, y, string("Hello {0}", "World"));

이러면? x가 우측으로 64 좌표 이동후 스프라이트를 그린 다음 되돌아와서 Hello World를 그리는데, 실제 화면에선 좌우로 이동하는게 아닌 스프라이트가 hello world 우측에 그려져있음.

왜냐면 이건 모두 드로우 영역에서 단 한번에 처리되고 최종 결과물만 보여주기 때문임.

이런식으로

gpu_set_blendmode(bm_add); // 가산 혼합 시작

draw_sprite_ext(sprite_asset_name, frame, x, y, xscale, yscale, angle, color, alpha);

gpu_set_blendmode(bm_normal); // 원상 복구

라든지

gpu_get_texfilter(true); // 텍스쳐 인터폴레이션 실행, 세부적인 인터폴레이션 유무는 다른 함수로 처리함

draw_sprite_ext(sprite_asset_name, frame, x, y, xscale, yscale, angle, color, alpha);

gpu_get_texfilter(false); // 복구

이런식으로 내가 원하는 대상 한정으로 그래픽 설정을 끼워넣을수있음.

그리고 이게 심화되면 '서피스(Surface)' 같은 개념이 들어가는데 이건 포토샵의 레이어를 생각하면 쉬운 개념임.

Create 이벤트에서

test_surface = surface_create(100, 100);

surface_set_target(test_surface);

draw_clear_alpha(c_black, 1);

draw_sprite_ext(sprite_asset_name, frame, x, y, xscale, yscale, angle, color, alpha);

surface_reset_target();

Draw 이벤트에서

draw_surface_ext(test_surface, x, y, xscale, yscale, angle, color, alpha);

이러면 create에서 vram에 임시로 100x100 사이즈의 텍스쳐를 만든후, 검은색의 알파 100%로 청소후 draw_sprite_ext를 그림.

그걸 draw이벤트에서 그리면 실제로 상단 4줄에 해당하는 코드는 1회만 호출되어 vram에 저장되고, 게임안에서는 그 텍스쳐만 그려주는거임.

이런식으로 드로우콜을 줄이거나, 다양한 응용 방법에 쓰이게됨.

위에 서피스가 100x100인데 스프라이트가 서피스보다 크면? 그러면 서피스의 사이즈 만큼 잘려서 나오게될거고, 이런식으로 스프라이트 마스크 효과를 만들수도있음. 물론 쉐이더로 이렇게 자를수도있긴함.

그리고 draw_surface_ext를 보면 알다싶이 서피스 조차도 스프라이트처럼 scale이나 색상 속성을 다 입힐수있음. 즉 서피스에 한번에 일괄로 그린 결과물을 원하는 형태로 늘리고 줄이고 투명하게만들고 할 수 있음.

여기에 쉐이더같은걸 쓴다치면

shader_set(sha_outline);

draw_surface_ext(test_surface, x, y, xscale, yscale, angle, color, alpha);

shader_reset();

이런식으로 쉐이더를 적용시킬수도있거나, 해당 서피스를 텍스쳐 샘플로 써서 쉐이더로 넘겨서 연산시킬수도있음.

이런 구조를 내가 직접적으로 하나하나 제어하기 쉽다는게 게임메이커의 특징이라 봄.

대신 이런 구조는 성능 저하라는 문제를 가짐.

게임메이커의 draw_sprite 같은 함수는 있는 그대로 그리는 수준으로 단순해서 defold의 그 가벼운 2d 드로우보다 가벼움 모습을 보임 (실제 과거에 테스트해본적이 있었는데, 현재 defold는 어떨지 모르겠음)

문제는 드로우에 올려지는 로직들임.

유니티나 언리얼, 디폴드등의 엔진에서 보통들 볼수있는 무거운 3D 환경을 위해 최적화된 드로우 파이프라인과 멀티쓰레드 렌더링은 게임메이커의 드로우 방식상 구조적으로 하기 힘듬

게임메이커의 draw는 일반 step (유니티로 치면 update) 이벤트와 무조껀 동기화되서 순차 연산되어야 위에 언급한 디테일한 로직의 처리가 가능하기 때문임.

이러한 환경은 2D 게임이 3D보다 단순한 파이프라인과 vram 사용 구조를 가지기때문에 가능한 방법이라 생각함.

다르게 보자면 유니티, 언리얼, 고도등은 정석적인 모던 3D 구성위에 2D를 사용하게끔 제공하기 때문에, 결국 거대한 3D 파이프라인이 기반에서 동작되고있어서 이걸로 성능을 잡아먹는게 있음.

그래서도 게임메이커에서 3D 구현이 문제가 되는 이유중 하나임. 3D에 대한 기초 파이프라인이 전혀 없어서. 모든걸 직접 구현해야하기때문임.

그리고 위에서 예시로 든 서피스의 경우 마구잡이로 사용시 vram 소모가 극심해지기 때문에, 내장 메모리를 vram으로 끌어다쓰는 모바일 환경에서 제한적일 수 있음.

한때 과거에 서피스를 모바일에 쓰면 무조껀 느리다 라는 인식이 그래서 생겼는데, 지금은 남발하는거 아니면 문제없음.

그리고 2D로서 쓸모없는 3D 뎁스를 줄여서 vram 사용량을 줄이는 기능도 제공하고 있어서 정말 많이 해결됨

그리고 하단 게임들 보면 그런 해괴한 게임메이커만의 렌더링 방식을 통해 만들어진 게임들임

언급한 서피스를 이용한 색칠 메커니즘을 활용한 게임

https://www.youtube.com/watch?v=zcg1uzgVtXY

Chicory: A Colorful Tale ~ Official Reveal Trailer!!!

로우한 게임메이커 3D를 통해 구현한 슈팅 게임

https://www.youtube.com/watch?v=dzVDAOjKQoA

Jet Lancer | Available now on Steam and Nintendo Switch

마찬가지로 게임메이커 3D의 로우한 환경을 통해 구현된 1인칭 그리드 기반 이동 액션 게임

https://www.youtube.com/watch?v=MVi_WHWCMR8

FIGHT KNIGHT Release Date Announcement Trailer!!

겜메 draw를 잘 활용한 게임

https://www.youtube.com/watch?v=M6YconSNx2k

Wally and the FANTASTIC PREDATORS! OFFICIAL TRAILER!

유명한 니드호그 2, 스파인이아니고 다 직접 게임메이커에서 만든 무엇인가로 알고있음.

https://www.youtube.com/watch?v=5h3lW5JOjD0

Nidhogg 2 - Launch Trailer

당시 발표했을때 2D 소울라이크류로 기대하는 사람들이 많았으나 개망한 데스갬빗 이거도 그 시절엔 스파인이 아니였을건데 지금은 모르겠음.

https://www.youtube.com/watch?v=_hXlYTFcSVg

Death's Gambit: Afterlife - Launch | PS4

[익명(119.207)]

이런글은 개추야

[에뚜(ssss4610)]

[00(124.58)]

데스겜빗 좋아보이는데 왜 망했지

[글쓴 ㅇㅇ(121.173)]

게임이 UX + 레벨 디자인적으로 문제가 많았다고 들었음. 지금은 확장팩 내면서 문제들을 개선했는지 매우 긍정적으로 뜨는듯함.

[00(124.58)]

에이 그럼 뜬거네 뭐

[글쓴 ㅇㅇ(121.173)]

망했을때 환불 터지고 난리나는거 보고 관심끊었는데, 결과적으로 성공한게 맞는듯.

[익명(indgmb2304)]

꾸미기같은 리소스양 많은겜도 감당되나?

[글쓴 ㅇㅇ(121.173)]

텍스쳐 그룹 단위로 메모리에서 load unload 관리되서 문제 없음.

[익명(indgmb2304)]