Your SlideShare is downloading. ×
multi plaform Full3D MMO 만들기 "삼국지를 품다"의 테크니컬 아트
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

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

21,098
views

Published on


1 Comment
53 Likes
Statistics
Notes
No Downloads
Views
Total Views
21,098
On Slideshare
0
From Embeds
0
Number of Embeds
24
Actions
Shares
0
Downloads
196
Comments
1
Likes
53
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. 정종필Ndoors 개발1본부 기술지원팀부장/ Technical Art Director게 임 개 발 2 0 년 차임짂록/천년의싞화/거상/아틀란티카/삼국지를 품다NDC 강연 2회/KGC 강연 4회2010 / 2012 NDC 우수강연2 0 0 8 KG C S p e a ke r Aw a rd 대충 살아가는 게임개발자 http://chulin28ho.egloos.com 게임 개발 포에버 / 대마왕J http://gamedevforever.com
  • 2. 오늘의 이야기는 프로젝트의 시작 엔짂선택의 이유와 사용후기 웹 버젂에서의 테크니컬 아트 사례모바일 버젂에서의 테크니컬 아트 사례 결롞과 정리
  • 3. 당싞의 PC는 앆녕하십니까 아마도 그 누구 때문에제PC는 요새 일할때만 켜져 있습니다
  • 4. 시장은 혺란스러워요 다 아시겠지맊 PC 게임 시장의 위축그렇다고 모바일이나 소셜에 올인하기도 애매 이게 독이될지 약이될지 누가 알겠어요 우리가 한다고 성공한다는 보장도 없고 그래서 선택은
  • 5. 하이브리드형 게임의 선택 역사 / 턴제 온라인 게임에 강점 변화와 결정이 빨라서 빨리 맊드는게 특기 남들 앆하는 (하기 힘든) 싞기한 겂 잘함뭘 하건 자싞들의 장점을 버리는 겂은 바보 같은 짒입니다. 그래서 선택한 프로젝트가
  • 6. P C 게 임 이 기 도 하 면 서W E B 게 임 이 기 도 하 고MOBILE 게임이기도 한 게임
  • 7. 프 로 토 타 입
  • 8. 프 로 토 타 입
  • 9. 이 퀄리티로는 앆돼
  • 10. 그렇다면 풀3D 웹게임
  • 11. U N I T Y 3 D
  • 12. 솔직히 3년 젂에는 대앆이 없었음…그런데 이거 쓸맊하긴 한 거야?
  • 13. Engine Pre Test 결과멀티 플렛폼 지원 훌륭서드 파티 플러그인 기본장착엔짂 업데이트가 빠름생각보다 그래픽 퀄리티도 좋음 (3.0부터)우리 프로젝트 / 스튜디오 스타일에 잘 맞음 - 빠른 실시갂 피드백이 최대의 강점 - 우리에게 빠른 겂은 최고의 가치
  • 14. U N I T Y 3 D 사 용 후 기 개발이 빠른 건드릯 수 없는 게 맋은 엄청나게 쉬운 큰 프로젝트는 불편한 생각보다 그래픽도 괜찮은 결과물의 사양이 높은MiddleWare 가 맋이 들어갂 너무 쉽게 core에 접귺 가능한 가격이 매우 싼 부분 유료화인 가격 때문에 맋이 용서되는 엔짂 메모리 문제 해결이 키포인트
  • 15. 삼국지를 품다W E B Ve r s i o n ‟sTe c h n i c a l A r t
  • 16. 프로젝트의 가장 큰 불앆요소 “일단, 정말로 돌아가긴 하냐?”
  • 17. …그겂도 웹브라우저에서 이런게
  • 18. 그리고 또 짂짜 궁금했던 건“정말로 모바일과 PC 리소스가 같아도 되냐”그런걸 막 자동으로 이렇게 저렇게 요렇게 알아서 해주냐
  • 19. 결롞부터 얘기하면 당연하게도 “PC 버젂 수준을모바일에 맞추면 가능” 아니 이건 좀 … -_-;;
  • 20. “다른 웹게임과확연히 다른 수준을 맊들어” “아참, 모바일도당연히 그래야 하는거 알지”
  • 21. “귺데 무거우면 앆됨 ㅋ” 웹게임이잓아ㅋ 모바일도 물롞ㅋ
  • 22. 이런걸 원하는 거였냐
  • 23. 그래서“리소스는 모바일과 PC를 이원화한다” 이번 프로젝트에서 TA 파트는 최대한 업무 효율을 높이는데 올인한다 가이드라인의 빠른 확보로 삽질을 최소화 시킨다 게다가 사정상 모바일이 훨씬 늦게 시작…
  • 24. 가이드라인이 없으면 앆될 거야
  • 25. 가이드라인을 정하기 젂에혂재 상태를 점검하는 겂이 가장 필요했습니다.최악의 경우에 앆되면 빨리 포기하기 위해서라도…
  • 26. 초기 퍼포먼스 테스트프로파일러 깎는 노인
  • 27. 퍼포먼스 테스트Asset 제작 스타일 파악제작 개선점 분석“대충 이 정도면 되겠다”
  • 28. 본 격 적 인가이드라인 제작 제작하기 빠르고 편한풀 3D 게임을 맊들기 위한 가이드라인
  • 29. 1. 카메라 가이드라인모든 기준의 시작- FOV = 사양- 게임의 특성- 디자인 집중- 모바일도 고려
  • 30. 2. 렌더링 / 조명 가이드라인젂체 퍼포먼스와 배경에게 중요-Forward Rendering Only-1 Directional , Small Point Light-Pixel light 연산량에 주의-모바일 고려 앆함
  • 31. 3.배경 데이터 가이드라인DP Call은 그래픽팀에서 적극적으로 체크가상의 „보통‟ 옵션에서 400 이하폴리곢수는 더 밀도를 늘이지 않도록너무 복잡한 제약은 아티스트들을 주눅들게 한다.
  • 32. 4.캐릭터 데이터 가이드라인캐릭터는 30-40마리 출혂이 한계Dynamic Batch 가동하면 좀 더 가능할듯커스터마이짓 제약폴리곢은 4000 – 5000모바일과 완젂 이원화…
  • 33. 캐릭터 Shader 염색 / Rim Light 정도맊 요구 너무 고급 기술은 사용 않기로-Specular *2-Half Lambert-SSS-HemisphereAmbient-Rim-Dye
  • 34. 캐릭터 ShaderAD가 원한다면 -Lambert그게 정답입니다 -Rim -Dye
  • 35. 기타 헛된 시도들…아까워서 공개
  • 36. 세 부 최 적 화 &옵 션 결 정프로그램 최적화가 어느 정도 짂행된 후
  • 37. 그러려면또 데이터가 있어야 하지..?
  • 38. 5년동앆 차곡차곡 모은 저사양컴퓨터들
  • 39. 5년동앆 차곡차곡 모은 저사양컴퓨터들과VGA들이 쓸모있어지는 순갂
  • 40. 난 누굮가 또 여긴 어딘가
  • 41. 옵션결정 최저 낮음 보통 좋음 최상 Pixel light count 0 1 2 3 4 hard-낮은 사양쪽에 집중 shadow 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 Force anisotropic texture Enable-Fillrate로 자동설정 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
  • 42. 최상 옵션Realtime ShadowSSAOBloomContrast enhanceColor correctionFull Texture sizeAnisotropic FilteringTerrain error lowShader LOD 500
  • 43. 상 옵션Realtime ShadowSSAOBloomContrast enhanceColor correctionFull Texture sizeAnisotropic FilteringTerrain error lowShader LOD 500
  • 44. 보통 옵션Realtime ShadowSSAOBloomContrast enhanceColor correctionFull Texture sizeAnisotropic FilteringTerrain error midShader LOD 300
  • 45. 하 옵션Realtime ShadowSSAOBloomContrast enhanceColor correctionMiddle Texture sizeAnisotropic FilteringTerrain error midShader LOD 200
  • 46. 최하 옵션Realtime ShadowSSAOBloomContrast enhanceColor correctionLow Texture sizeAnisotropic FilteringTerrain error highShader LOD 150
  • 47. 삼국지를 품다Mobile Version‟sTe c h n i c a l A r t
  • 48. 프로젝트의 가장 큰 불앆요소 “일단, 정말로 돌아가긴 하냐?”
  • 49. 프로젝트의 가장 큰 불앆요소 “일단, 정말로 돌아가긴 하냐?”“아니, 그러니까 일단 뭐부터 해야 하는 거냐?”
  • 50. 이걸 웹버젂으로 겨우 맊들었더니…
  • 51. 모 바 일 로 이 렇 게 맊 들 래 요
  • 52. 가이드라인을 정할 수가 없다! 최악의 상태
  • 53. 웹은 그나마 PC와 큰 차이가 없었지맊 모바일은 맊들어 본 경험이 없다 예측이 불가능하다
  • 54. 그럼 테스트라도 해봐야 하는데프로그램이 돌아가는 상태가 아니다 내부사정으로 (그때는) 플레이 불가능
  • 55. 그럼 실험이라도 해봐야 하는데 시행착오할 시갂이 없다 너무 늦게 궤도에 올랐다 엎을 시갂이 없다 이제 가이드라인을 FIX 해야 할 시갂가이드라인 맊들면서 삽질까지 해야 한다
  • 56. 일단 돌아갂다 쳐도테스트할 장비도 없다아직 장비도 완젂히 준비되지 않았다. 앆드로이드 기기의 파편화는 …?일단 맋이 팔릮 기기를 목표로(겔S2) 타블렛 등의 특수기기는 포기
  • 57. 장비가 있다 해도퍼포먼스 테스트가 너무 어렵다 세부 퍼포먼스 체크는 불가능 젂체 메모리 체크외엔 앆됨 (싞 버젂에서는 해결) 하드웨어도 너무 다양 기기에 넘겨보기도 어렵다 시갂과 홖경이 없다 빌어먹을 ADB Shell 도와줘요 QA 팀
  • 58. 참고를 하고 싶어도 참고할 외부 프로젝트가 없다 비슷한 건 좀 있긴 하지맊오더&카오스 세븐 스워드 포켓 레젂드
  • 59. 가능한 제대로 된 참고 자료는 매뉴얼과 감 뿐 혹은 GDC에서의 강연들 드로우콜은 최대로 줄여라 알파 테스팅은 사용하면 더 느린(?) 라이팅과 셰이더 가볍게 쓰세요 텍스쳐 포맷에 매우 주의할겂-앆드로이드는 호홖성을 위해 표준 포맷 (ETC1 , RGBA16) 을 사용 -IOS는 PVRTC 4bit / 2bit 사용
  • 60. 어쨌건 짂행해야 하는 타이밍그래픽 리소스 제작가 이 드 라 인 을 잡기 위한 삽질들로 알 게 된꼼수와 트러블 슈팅
  • 61. 1. 카메라 가이드라인모든 기준의 시작- 고정- 각도 조젃 앆됨- 의도적 줌도 앆됨- 미리 정해 놔서 편하네요
  • 62. *싱글코어에서 렌더타겟은 무리모바일용 Bloom & Vignetting 후처리 제작, 적용- 싱글코어에서는 심각한 프레임 저하 발생 보고- 후처리는 사용 불가. 삭제. 듀얼코어는 쓸맊하던데…
  • 63. 2 . 조 명 가 이 드 라 인라이팅 테스트-1 Vertex light-아예 앆쓰고 싶었지맊…
  • 64. *Batch를 주의하세요- Dynamic batch 는 scale과 조합시 라이팅 버그 (있었음)- Static batch는 vertex 용량을 급격히 증가시킴- Batch를 모두 꺼서 해결
  • 65. 3. 배경 데이터 가이드라인터레인 기능 사용 불가FOG / 후처리 사용 불가PC와 동일한 구조 제작 필요Call 수의 최소화 – 약 30 이하 좀더 귺본적인 혁싞 필요
  • 66. -라이트맵 사용 곢란. 퀄리티도 생각보다 별로. 제작 효율도 낮음-Terrain 사용 불가. Texture splatting 사용 불가-이젂에 제작한 웹 데이터를 최대한 사용할 순 없을까?
  • 67. 라이트맵 사용 곢란-퀄리티도 생각보다 별로-제작 효율도 매우 낮음-이젂에 제작한 웹 데이터를 사용할 순 없을까?
  • 68. 라이트맵 사용 곢란-퀄리티도 생각보다 별로-제작 효율도 매우 낮음-이젂에 제작한 웹 데이터를 사용할 순 없을까?
  • 69. Diffuse Map – Lightmap baked
  • 70.
  • 71. 배경팀의 아이디어 – Diffuse Map – Lightmap baked with Post Effects“아트팀이 기술을 이해하기 시작하면놀라운 일이 일어납니다.”
  • 72. 배경팀의 아이디어 – Diffuse baked Lightmap with Post Effects WEB Mobile
  • 73. 배경팀의 제앆2
  • 74. 배경팀의 제앆2 : Atlas TextureETC1 4bit RGB ETC1 4bit RGB 16bit RGBA ETC1 4bit RGB1024*1024 256*256 128*128 128*128
  • 75. 웹과 모바일이 동일한 느낌, 동일한 구조 , 젂혀 다른 데이터 Dpcall 575 Texture 73 – 11.1M VBO 503 – 14.9M Vert 776,500
  • 76. 웹과 모바일이 동일한 느낌, 동일한 구조 , 젂혀 다른 데이터 Dpcall 575 Dpcall 23 Texture 73 – 11.1M Texture 6 – 2.3M VBO 503 – 14.9M VBO 130 – 0.9M Vert 776,500 Vert 5,600
  • 77. *Data를 „쪼잒하게 더‟ 줄이기-(꼭 필요하지 않으면) Hard Edge 사용 금지-(카메라 각도가 저러니) mipmap도 앆씀-UV를 단순하게 펴세요*뻔한 내용인데 모바일에서는 엄청난 효과 Normal 최적화 UV까지 최적화 시킴. Hard Edge Normal 약 30% 젃약
  • 78. 4. 캐릭터 데이터 가이드라인- Zoom in 되지 않으니 최대한 줄이는 겂이 가능해짐 512*512 2418 vert 128*128 555 vert
  • 79. 모바일 캐릭터 shader-Unlit-염색 지원
  • 80. 4. 모바일 UI 가이드라인-32bit RGBA 사용 가능!-단, 메인 화면UI 텍스쳐는 모두 1장에 구혂
  • 81. *폰트 문제이미지 폰트 용량의 문제…몇…맊자라고요?
  • 82. *4 channel image- Font 와 Minimap 데이터가 맋음-용량이 맋아져 파일 분리하면 call수의 급격한 증가 유발- 4 channel로 구혂. 1장으로 4배의 효과- 1장으로 중국어 / 일본어 한자 표혂 가능
  • 83. *4 channel image- Font 와 Minimap 데이터가 맋음-용량이 맋아져 파일 분리하면 call수의 급격한 증가 유발- 4 channel로 구혂. 1장으로 4배의 효과- 1장으로 중국어 / 일본어 한자 표혂 가능한글은 참 몇 자없는 거였굮요
  • 84. *4 channel image- Font 와 Minimap 데이터가 맋음-용량이 맋아져 파일 분리하면 call수의 급격한 증가 유발- 4 channel로 구혂. 1장으로 4배의 효과- 1장으로 중국어 / 일본어 한자 표혂 가능 미니맵도 편리하게 사용 가능
  • 85. 그래서 이런 게 맊들어 졌습니다 모바일 웹
  • 86. 그래서 이런 게 맊들어 졌습니다 모바일 웹
  • 87. 결 롞 과 정 리
  • 88. 아티스트들을 위한 그 래 픽 리 소 스 가 이 드 라 인 원 칙1. 아티스트들은 느슨하게 묶어주세요2. 큰 겂을 줄이는 겂은 쉽지맊 줄인 겂을 늘이는 겂은 불가능합니다3. 그래픽 세부 최적화보다 프로그램 최적화가 먼저입니다.
  • 89. 1. 아티스트들은 느슨하게 묶어주세요 ♥ 아잉 ♥아티스트들에게제약이 없는 건 더 무섭습니다.묶기는 묶어주세요 …살살하지맊 아티스트들은 그 제약을최대한 사용할 겂입니다.
  • 90. 2. 큰 겂을 줄이는 겂은 쉽지맊 줄인 겂을 늘이는 겂은 불가능합니다처음에는차라리 약갂 무겁게 맊드는 게유리합니다. …그렇다고 아무거나 그러면 앆돼요 Ex) Bone / Animation은 초반에 빨리 최적화 하는게 좋습니다. 그래도 무거우면 Dpcall과 vertex를 „더‟ 줄입니다 . 그래도 무거우면 Texture size 를 줄입시다. 그래도 무거우면 Post Effects를 줄입시다. 쉽고, Dependency 가 작은 겂을 나중에 줄이는 겂이 좋습니다.
  • 91. 사실 모바일 데이터도이걸 믿고 이원화 했다능 모바일 데이터도 이렇게 맊들면 쉽겠지?
  • 92. 3. 그래픽 세부 최적화보다 프로그램 최적화가 먼저입니다.프로그램 최적화는 눆에 보이지 않지맊그래픽 데이터 최적화는 눆에 보이니까요갂편하다고 그래픽 데이터부터 최적화하면 위험합니다. -프로그램에서 한계까지 최적화를 시켰는지 잘 보는 겂이 중요합니다. -프로파일러를 적극 이용하세요 -그래픽에 할당된 m/s를 늘 체크하세요
  • 93. 프로젝트에서 얻은 겂 좋았던 점 난생 처음 시도하는 프로젝트를 완수했다!정보가 적은 상태에서 Technical Control 하는 방법을 알았다! 삽질이 상대적으로 적었다! 아트 팀의 레벨이 한 단계 상승했다! 모바일에서도 괜찮은 퀄리티를 낼 수 있다는 걸 알았다! 다시 맊든다면 2-3배 이상의 퀄리티를 낼 수 있을 듯. 아쉬웠던 점 고급 기술을 폴리싱 할 시갂이 맋지 않았다! 더 자동화 시켰으면 좋았을 겂 같다! UI는 더 다듬을 시갂이 필요했다!
  • 94. 감사합니다 정종필Ndoors 개발1본부 기술지원팀부장/ Technical Art Director@Jpcorpsjpcorp@hanmail.net대충 살아가는 게임개발자http://chulin28ho.egloos.com게임개발 포에버 / 대마왕Jhttp://gamedevforever.com 참고자료 http://www.sampoom.com http://chulin28ho.egloos.com http://www.unity3dkorea.com/

×