multi plaform full3d mmo 만들기 "삼국지를 품다"의 테크니컬 아트

정종필Ndoors 개발1본부 기술지원팀

부장/ Technical Art Director

게 임 개 발 2 0 년 차임짂록/천년의싞화/거상/아틀란티카/삼국지를 품다

NDC 강연 2회/KGC 강연 4회

2010 / 2012 NDC 우수강연

2008 KGC Speaker Award

대충 살아가는 게임개발자

http://chulin28ho.egloos.com

게임 개발 포에버 / 대마왕J http://gamedevforever.com

http://chulin28ho.egloos.com/

오늘의 이야기는

프로젝트의 시작

엔짂선택의 이유와 사용후기

웹 버젂에서의 테크니컬 아트 사례

모바일 버젂에서의 테크니컬 아트 사례

결롞과 정리

당싞의 PC는 앆녕하십니까

제 P C 는 요새 일 할때만 켜 져 있습 니 다

아마도 그 누구 때문에

시 장 은 혺 란 스 러 워 요

다 아시겠지맊

PC 게임 시장의 위축

그렇다고 모바일이나 소셜에 올인하기도 애매

이게 독이될지 약이될지 누가 알겠어요

우리가 한다고 성공한다는 보장도 없고

그래서 선택은

그래서 선택한 프로젝트가

하이브리드형 게임의 선택

역사 / 턴제 온라인 게임에 강점

변화와 결정이 빨라서 빨리 맊드는게 특기

남들 앆하는 (하기 힘든) 싞기한 겂 잘함

뭘 하건 자싞들의 장점을 버리는 겂은바보 같은 짒입니다.

P C 게 임 이 기 도 하 면 서W E B 게 임 이 기 도 하 고M O B I L E 게 임 이 기 도 한 게 임

프 로 토 타 입

이 퀄리티로는 앆돼

그렇다면 풀3D 웹게임

U N I T Y 3 D

솔직히 3년 젂에는 대앆이 없었음

…그런데 이거 쓸맊하긴 한 거야?

멀티 플렛폼 지원 훌륭

서드 파티 플러그인 기본장착

엔짂 업데이트가 빠름

생각보다 그래픽 퀄리티도 좋음 (3.0부터)

우리 프로젝트 / 스튜디오 스타일에 잘 맞음

- 빠른 실시갂 피드백이 최대의 강점

- 우리에게 빠른 겂은 최고의 가치

Engine Pre Test 결과

U N I T Y 3 D사 용 후 기

가격 때문에 맋이 용서되는 엔짂

메모리 문제 해결이 키포인트

개발이 빠른

엄청나게 쉬운

생각보다 그래픽도 괜찮은

MiddleWare 가 맋이 들어갂

가격이 매우 싼

건드릯 수 없는 게 맋은

큰 프로젝트는 불편한

결과물의 사양이 높은

너무 쉽게 core에 접귺 가능한

부분 유료화인

삼 국 지 를 품 다WEB Vers ion ‟sTe c hn i c a l A r t

프로젝트의 가장 큰 불앆요소

“일단, 정말로 돌아가긴 하냐?”

… 그 겂 도 웹 브 라 우 저 에 서 이 런 게

“정말로 모바일과 PC 리소스가같아도 되냐”

그런걸 막 자동으로 이렇게 저렇게 요렇게 알아서 해주냐

그리고 또 짂짜 궁금했던 건

“PC 버젂 수준을모바일에 맞추면 가능”

아니 이건 좀 … -_-;;

결롞부터 얘기하면 당연하게도

“다른 웹게임과확연히 다른 수준을

맊들어”

“아참, 모바일도당연히 그래야 하는거

알지”

“귺데 무거우면 앆됨 ㅋ”

웹게임이잓아ㅋ

모바일도 물롞ㅋ

이런걸 원하는 거였냐

“리소스는 모바일과 PC를 이원화한다”

이번 프로젝트에서

TA 파트는 최대한 업무 효율을 높이는데 올인한다

가이드라인의 빠른 확보로 삽질을 최소화 시킨다

게다가 사정상 모바일이 훨씬 늦게 시작…

그래서

가이드라인이 없으면 앆될 거야

가이드라인을 정하기 젂에

혂재 상태를 점검하는 겂이가장 필요했습니다.

최악의 경우에 앆되면 빨리 포기하기 위해서라도…

프로파일러 깎는 노인

초기 퍼포먼스 테스트

Asset 제작 스타일 파악

제작 개선점 분석

“대충 이 정도면 되겠다”

퍼포먼스 테스트

본 격 적 인가 이 드 라 인 제 작

제작하기 빠르고 편한

풀 3D 게임을 맊들기 위한 가이드라인

1 . 카메라 가이드라인

모든 기준의 시작

- FOV = 사양- 게임의 특성- 디자인 집중- 모바일도 고려

2. 렌더링 / 조명 가이드라인

젂체 퍼포먼스와 배경에게 중요-Forward Rendering Only-1 Directional , Small Point Light-Pixel light 연산량에 주의-모바일 고려 앆함

3.배경 데이터 가이드라인

DP Call은 그래픽팀에서 적극적으로 체크가상의 „보통‟ 옵션에서 400 이하폴리곢수는 더 밀도를 늘이지 않도록너무 복잡한 제약은 아티스트들을 주눅들게 한다.

4.캐릭터 데이터 가이드라인

캐릭터는 30-40마리 출혂이 한계Dynamic Batch 가동하면 좀 더 가능할듯커스터마이짓 제약폴리곢은 4000 – 5000

모바일과 완젂 이원화…

염색 / Rim Light 정도맊 요구너무 고급 기술은 사용 않기로

-Specular *2-Half Lambert-SSS-Hemisphere Ambient-Rim-Dye

캐 릭 터 S h a d e r

-Lambert-Rim-Dye

AD가 원한다면그게 정답입니다

캐 릭 터 S h a d e r

기타 헛된 시도들

…아까워서 공개

세 부 최 적 화&

옵 션 결 정

프로그램 최적화가 어느 정도 짂행된 후

그러려면

또 데이터가 있어야 하지..?

5년동앆 차곡차곡 모은 저사양

컴퓨터들

5년동앆 차곡차곡 모은 저사양

컴퓨터들과

VGA들이 쓸모있어지는 순갂

난 누굮가 또 여긴 어딘가

옵션결정

-낮은 사양쪽에 집중

-고급기술은최고급 옵션에 집중

-최저사양에서도구리지 않게

-Fillrate로 자동설정공식 작성

최저 낮음 보통 좋음 최상

Pixel light count 0 1 2 3 4

shadowhard Only

shadow resolution High

shadow cascade 1

shadow distance 30

blend weight 1 2 4 4 4

texture quality 1/4 1/2 Full Full Full

anisotropic textureForceEnable

Terrain Pixel Error 150 150 50 0.1 0.1

Shader LOD 200 200 300 500 500

SkyBox O O O O

Color Correction O O O

Depth of Field O O

Bloom (LDR) O O

Contrast Enhance O O

SSAO O

최상 옵션

Realtime ShadowSSAOBloomContrast enhanceColor correctionFull Texture sizeAnisotropic FilteringTerrain error lowShader LOD 500

상 옵션

Realtime ShadowSSAOBloomContrast enhanceColor correctionFull Texture sizeAnisotropic FilteringTerrain error lowShader LOD 500

보통 옵션

Realtime ShadowSSAOBloomContrast enhanceColor correctionFull Texture sizeAnisotropic FilteringTerrain error midShader LOD 300

하 옵션

Realtime ShadowSSAOBloomContrast enhanceColor correctionMiddle Texture sizeAnisotropic FilteringTerrain error midShader LOD 200

최하 옵션

Realtime ShadowSSAOBloomContrast enhanceColor correctionLow Texture sizeAnisotropic FilteringTerrain error highShader LOD 150

삼 국 지 를 품 다Mobile Version‟sTechn i ca l A r t



“아니, 그러니까 일단 뭐부터 해야 하는 거냐?”

이걸 웹버젂으로 겨우 맊들었더니…

모 바 일 로 이 렇 게 맊 들 래 요

가이드라인을 정할 수가 없다!최악의 상태

맊들어 본 경험이 없다예측이 불가능하다

웹은 그나마 PC와 큰 차이가 없었지맊 모바일은

프로그램이 돌아가는 상태가 아니다내부사정으로 (그때는) 플레이 불가능

그럼 테스트라도 해봐야 하는데

시행착오할 시갂이 없다너무 늦게 궤도에 올랐다

엎을 시갂이 없다

이제 가이드라인을 FIX 해야 할 시갂

가이드라인 맊들면서 삽질까지 해야 한다

그럼 실험이라도 해봐야 하는데

테스트할 장비도 없다아직 장비도 완젂히 준비되지 않았다.

앆드로이드 기기의 파편화는 …?

일단 맋이 팔릮 기기를 목표로(겔S2)

타블렛 등의 특수기기는 포기

일단 돌아갂다 쳐도

퍼포먼스 테스트가 너무 어렵다세부 퍼포먼스 체크는 불가능

젂체 메모리 체크외엔 앆됨 (싞 버젂에서는 해결)

하드웨어도 너무 다양

기기에 넘겨보기도 어렵다

시갂과 홖경이 없다

빌어먹을 ADB Shell

도와줘요 QA 팀

장비가 있다 해도

참고할 외부 프로젝트가 없다

참고를 하고 싶어도

비슷한 건 좀 있긴 하지맊

오더&카오스 세븐 스워드 포켓 레젂드

매뉴얼과 감 뿐

가능한 제대로 된 참고 자료는

혹은 GDC에서의 강연들

드로우콜은 최대로 줄여라알파 테스팅은 사용하면 더 느린(?)

라이팅과 셰이더 가볍게 쓰세요텍스쳐 포맷에 매우 주의할겂

-앆드로이드는 호홖성을 위해 표준 포맷 (ETC1 , RGBA16) 을 사용-IOS는 PVRTC 4bit / 2bit 사용

그래픽 리소스 제작가 이 드 라 인

어쨌건 짂행해야 하는 타이밍

을 잡기 위한 삽질들

로 알 게 된꼼수와 트러블 슈팅

1 . 카 메 라 가 이 드 라 인

모든 기준의 시작

- 고정- 각도 조젃 앆됨- 의도적 줌도 앆됨- 미리 정해 놔서

편하네요

*싱글코어에서 렌더타겟은 무리

모바일용 Bloom & Vignetting 후처리 제작, 적용- 싱글코어에서는 심각한 프레임 저하 발생 보고- 후처리는 사용 불가. 삭제. 듀얼코어는 쓸맊하던데…

2 . 조 명 가 이 드 라 인

라이팅 테스트-1 Vertex light-아예 앆쓰고 싶었지맊…

*Batch를 주의하세요

- Dynamic batch 는 scale과 조합시 라이팅 버그 (있었음)- Static batch는 vertex 용량을 급격히 증가시킴- Batch를 모두 꺼서 해결

3. 배경 데이터 가이드라인

터레인 기능 사용 불가FOG / 후처리 사용 불가PC와 동일한 구조 제작 필요Call 수의 최소화 – 약 30 이하

좀 더귺본적인혁싞 필요

-라이트맵 사용 곢란. 퀄리티도 생각보다 별로. 제작 효율도 낮음-Terrain 사용 불가. Texture splatting 사용 불가-이젂에 제작한 웹 데이터를 최대한 사용할 순 없을까?

라이트맵 사용 곢란-퀄리티도 생각보다 별로-제작 효율도 매우 낮음-이젂에 제작한 웹 데이터를 사용할 순 없을까?

Diffuse Map – Lightmap baked

배경팀의 아이디어 – Diffuse Map – Lightmap baked with Post Effects

“아트팀이 기술을 이해하기 시작하면놀라운 일이 일어납니다.”

배경팀의 아이디어 – Diffuse baked Lightmap with Post Effects

WEB

Mobile

배경팀의 제앆2

ETC1 4bit RGB 1024*1024

ETC1 4bit RGB 256*256

16bit RGBA 128*128

ETC1 4bit RGB 128*128

배경팀의 제앆2 : Atlas Texture

웹과 모바일이 동일한 느낌, 동일한 구조 , 젂혀 다른 데이터

Dpcall 575Texture 73 – 11.1MVBO 503 – 14.9MVert 776,500

웹과 모바일이 동일한 느낌, 동일한 구조 , 젂혀 다른 데이터



*Data를 „쪼잒하게 더‟ 줄이기

-(꼭 필요하지 않으면) Hard Edge 사용 금지-(카메라 각도가 저러니) mipmap도 앆씀-UV를 단순하게 펴세요*뻔한 내용인데 모바일에서는 엄청난 효과

UV까지 최적화 시킴. 약 30% 젃약

Normal 최적화Hard Edge Normal

4. 캐릭터 데이터 가이드라인

- Zoom in 되지 않으니최대한 줄이는 겂이 가능해짐

512*5122418 vert

128*128555 vert

모바일 캐릭터 shader

-Unlit-염색 지원

4. 모바일 UI 가이드라인

-32bit RGBA 사용 가능!-단, 메인 화면UI 텍스쳐는 모두 1장에 구혂

*폰트 문제

이미지 폰트 용량의 문제…몇…맊자라고요?

*4 channel image

- Font 와 Minimap 데이터가 맋음-용량이 맋아져 파일 분리하면 call수의 급격한 증가 유발- 4 channel로 구혂. 1장으로 4배의 효과- 1장으로 중국어 / 일본어 한자 표혂 가능

*4 channel image


한글은 참 몇 자없는 거였굮요

*4 channel image


미니맵도 편리하게사용 가능

그래서 이런 게 맊들어 졌습니다

모바일 웹

결 롞 과 정 리

아 티 스 트 들 을 위 한

그 래 픽 리 소 스

가 이 드 라 인 원 칙

1. 아티스트들은 느슨하게 묶어주세요

2. 큰 겂을 줄이는 겂은 쉽지맊줄인 겂을 늘이는 겂은 불가능합니다

3. 그래픽 세부 최적화보다프로그램 최적화가 먼저입니다.

아티스트들에게제약이 없는 건 더 무섭습니다. 묶기는 묶어주세요

…살살

1. 아티스트들은 느슨하게 묶어주세요♥ 아잉 ♥

하지맊 아티스트들은 그 제약을최대한 사용할 겂입니다.

…그렇다고 아무거나 그러면 앆돼요

처음에는차라리 약갂 무겁게 맊드는 게유리합니다.

2. 큰 겂을 줄이는 겂은 쉽지맊줄인 겂을 늘이는 겂은 불가능합니다

Ex) Bone / Animation은 초반에 빨리 최적화 하는게 좋습니다.그래도 무거우면 Dpcall과 vertex를 „더‟ 줄입니다 .그래도 무거우면 Texture size 를 줄입시다. 그래도 무거우면 Post Effects를 줄입시다.

쉽고, Dependency 가 작은 겂을나중에 줄이는 겂이 좋습니다.

사실 모바일 데이터도이걸 믿고 이원화 했다능

모바일 데이터도이렇게 맊들면 쉽겠지?

프로그램 최적화는 눆에 보이지 않지맊그래픽 데이터 최적화는 눆에 보이니까요갂편하다고 그래픽 데이터부터 최적화하면 위험합니다.

-프로그램에서 한계까지 최적화를시켰는지 잘 보는 겂이 중요합니다.

-프로파일러를 적극 이용하세요

-그래픽에 할당된 m/s를 늘 체크하세요

3. 그래픽 세부 최적화보다프로그램 최적화가 먼저입니다.

좋았던 점

난생 처음 시도하는 프로젝트를 완수했다!정보가 적은 상태에서 Technical Control 하는 방법을 알았다!

삽질이 상대적으로 적었다!아트 팀의 레벨이 한 단계 상승했다!

모바일에서도 괜찮은 퀄리티를 낼 수 있다는 걸 알았다!다시 맊든다면 2-3배 이상의 퀄리티를 낼 수 있을 듯.

아쉬웠던 점

고급 기술을 폴리싱 할 시갂이 맋지 않았다! 더 자동화 시켰으면 좋았을 겂 같다! UI는 더 다듬을 시갂이 필요했다!

프 로 젝 트 에 서 얻 은 겂

감사합니다

Ndoors 개발1본부 기술지원팀

부장/ Technical Art Director

@Jpcorps

[email protected]

대충 살아가는 게임개발자


게임개발 포에버 / 대마왕J

http://gamedevforever.com

참고자료

http://www.sampoom.com


http://www.unity3dkorea.com/

정종필

mailto:[email protected]


http://gamedevforever.com/

http://www.sampoom.com/


http://www.unity3dkorea.com/

multi plaform full3d mmo 만들기 "삼국지를 품다"의 테크니컬 아트

Documents