4. 코끼리를 냉장고에 넣는법
코끼리 – PC
냉장고 – 모바일
PC 개발에서 Unity를 이용한 모바일 개발로 넘어가면서 경험했던
문제점들과 해결방안, 팁
5. 코끼리를 냉장고에 넣는법
Unity Update - 업데이트 주기가 짧은 편이다.
멀티플랫폼 엔진
- 각 플랫폼 업데이트
- Unity 자체적
3.x 버전은 업데이트마다 Asset Bundle을 다시 빌드해야 한다.
그리고 유저가 패치를 받아야 한다.
4.x 부터는 해결되었으니 4.x를 사용하라.
6. 코끼리를 냉장고에 넣는법
많은 모바일 API 제공
세심한 컨트롤은 힘들게 되어있다.
ex) 진동 – On / Off 정도 지원
별도의 Plug-in을 제작 해야 한다.
즉, 해당 플랫폼에 대한 지식이 꼭 필요하다.
7. 코끼리를 냉장고에 넣는법
Wifi - PC에 비해 매우 불안정하다.
패치 후 안 켜진다는 유저를 찾아가 확인
특정 통신사 Wifi 망에 접속하면 Wifi 자체는 접속이 된거지만 인증
을 하지 않으면 통신이 되지 않는 경우가 있다.
(Web Error 코드가 적혀있고 데이터가 비정상적)
CRC등 무결성 검사가 필수적이다.
8. 코끼리를 냉장고에 넣는법
배터리 문제
배터리를 닳게 하는 3가지 요소
1. 디스플레이
2. 데이터 통신 모듈
3. AP 연산(AP 연산에 대해서만 최적화 시도)
PC FPS를 따르지 않고 특정 FPS로 고정시켜 AP 연산을 줄인다.
배터리 소모 속도와 발열이 줄어들었다.
끊기는 느낌이 나지만 AP 연산 최적화가 도움이 되는것은 증명.
9. 코끼리를 냉장고에 넣는법
메모리 관리
Object를 추가하면 메모리 블록을 할당한다.
여분을 남기고 메모리 블록이 꽉 차면 확장된 사이즈로 할당한다.
Object들이 해제하더라도 확장된 사이즈는 그대로 유지한다.
최대치에 도달하게 되면 Crash를 낸다.
재활용 리소스를 잘 관리하고 Memory Pool이 필수다.
10. 코끼리를 냉장고에 넣는법
심의, 반려
모바일은 Update 때마다 심의를 받는다.
1. Google – Update 후 심사
2. 이통 3사 – 하루 정도 심사
3. Apple – 2주 정도 심사, 반려가 나면 다시 재 심사.
심사도 사람이 하는거라 기준이 다르다.
기존에 통과된 부분도 반려 될 수 있다는 생각을 가지는게 좋다.
11. 코끼리를 냉장고에 넣는법
심의, 반려
다른 플랫폼과 Apple 버전을 맞추기 힘들 때가 있다.
패킷에 버전을 두어서 기능은 안되더라도 실행은 되게끔 처리했다.
현재 플랫폼에서 구입한 아이템을 다른 플랫폼으로 선물을 금지하
기 때문에 해당 기능은 제거하였다.
플랫폼당 서버로 분리할까도 고려중이다.
12. 셰이더 리소스 빌드 자동화
할 수 없나요?
시스템 구현 및 최적화 사례 소개
넥슨 – 정화석
13. 셰이더 리소스 빌드 자동화
할 수 없나요?
쉐이더 코드 조합
1. Micro Shader (#include)
2. Uber Shader (#if ~ #endif)
3. Shader Editor (GUI)
#include와 #if ~ #endif로 처리하기로 결정
14. 셰이더 리소스 빌드 자동화
할 수 없나요?
ShaderSetting 파일
옵션 메타 데이터
상속 구조
LOD 시스템
C++ 전처리와 메타 데이터를 이용하여 처리하려고 만들기 시작
15. 셰이더 리소스 빌드 자동화
할 수 없나요?
컴파일 시간, 메모리 최적화
컴파일된 바이너리를 바로 사용하자.
VS와 PS를 따로 컴파일한다.
Technique는 자체 포맷으로 만들었다. (DX11 대응 겸)
16. 셰이더 리소스 빌드 자동화
할 수 없나요?
컴파일 시간, 메모리 최적화
다양한 시도를 하다가 결정된 포맷
Version
옵션 Hash 1
옵션 Hash 2
함수 이름 1
함수 이름 2
Version
바이너리 1
바이너리 2
쉐이더 갯수 1개
17. 셰이더 리소스 빌드 자동화
할 수 없나요?
자동화 빌드
CruiseControl.NET의 Daily Build로 등록한다.
셰이더 수정이 일어나면 재 빌드가 필요하다.
셰이더 코드가 체크인 되면 빌드 서버에서 셰이더를 포함해서 빌드
하겠다는 설정을 걸고 빌드를 한다. 새벽엔 Daily Build로 돌아가
게끔 설정. (Config On / Off)
19. 마영전의 구세대 엔진으로
차세대 비주얼 게임 만들기
HL2 소스엔진에서 L4D 소스 엔진으로 마이그레이션 시도
많은 수정과 자체적인 포맷들로 인해 마이그레이션은 포기
L4D 소스 엔진에 작업 중.
라이브를 위해서 HL2 소스엔진을 통해서 컨텐츠 만들때 사용한 팁
20. 마영전의 구세대 엔진으로
차세대 비주얼 게임 만들기
Z-Pre Pass 라이팅
엔진이 Deffered나 Light Pre Pass를 적용하기는 힘든 구조
32F 텍스쳐에 View-Space 기준으로 Z-Pre Pass 라이팅 적용
Forward 렌더링을 유지하면서 Sun Shaft, DOF등 적용 가능.
렌더링을 2번 해야 하므로 비용은 비싼편이다.
21. 마영전의 구세대 엔진으로
차세대 비주얼 게임 만들기
Sun Shaft, DOF
Sun Shaft
태양을 중심으로 Radial Blur를 적용하였다.
Z값을 Occlusion 정보로 활용하였다.
DOF
초점이 멀수록 블러를 적용
Z값을 초점 거리를 계산할 때 활용
22. 마영전의 구세대 엔진으로
차세대 비주얼 게임 만들기
Sun Shaft, DOF
Sun Shaft
플레이어, 보스, 월드만 중요
DOF
플레이어, 타겟, 월드만 중요
플레이어, 타겟(보스), 월드만 렌더링 나머지는 Clear!
23. 마영전의 구세대 엔진으로
차세대 비주얼 게임 만들기
강조효과
수풀을 많이 심어 밀림처럼 보이게 만들었다.
시야를 많이 가리게 되어 카메라를 기준으로 반투명 처리를 했다.
일부러 나무 틈 사이에 태양을 배치하여 SunShaft를 강조
보스전 컷신때 보스 뒤에 태양을 배치하여 역광을 주어 강조
24. 마영전의 구세대 엔진으로
차세대 비주얼 게임 만들기
빗물 효과
카메라에 묻는 빗물
카메라를 기준으로 파티클을 뿌린다.
노멀맵, 굴절도 적용
바닥의 빗물
텍스쳐 애니메이션을 이용
25. 마영전의 구세대 엔진으로
차세대 비주얼 게임 만들기
배의 흔들림
월드를 그대로 두고 카메라를 흔든다.
스카이 박스는 역방향으로 흔들어 하늘은 고정되어 보이게 한다.
수평선등도 기울어 지겠지만 포그로 가려서 문제가 없었다.
26. 마영전의 구세대 엔진으로
차세대 비주얼 게임 만들기
빨판 (크라켄)
빨판에 본을 심는건 너무 낭비로 판단
텍스쳐 스페이스 기준으로 구 기반 버텍스 노이즈를 적용하기로 함.
빨판 정면을 기준으로 (0, 0) ~ (1, 1) 텍스쳐를 잡는다.
(0, 0)을 (-1, 1)로 변경하는 루틴을 넣어 구에 대응되게 계산
노이즈 함수의 결과값을 이용해 Displacement 해준다.
27. 마영전의 구세대 엔진으로
차세대 비주얼 게임 만들기
사슬 무기
무기에 20개정도 본을 넣었다. 듀얼이므로 40개정도 사용했음.
휘두를때는 본 애니로 처리하고 그 후에는 물리 시뮬레이션 처리.
캐릭터의 프레임과 무기의프레임을 강제적으로 동기화 한다.
사슬은 본에 대해서 스플라인을 계산해 스프라이트를 적용한다.
28. 마영전의 구세대 엔진으로
차세대 비주얼 게임 만들기
Trail
Trail을 줄때는 Plane의 2차원 배열을 만들고 그려주었다.
가장자리 부분은 얇고 길게 처리하여 날카로움을 강조.
29. 마영전의 구세대 엔진으로
차세대 비주얼 게임 만들기
충돌처리
벽이나 몬스터를 관통하지 못하도록 처리해야 한다.
손을 기준으로 무기 끝과 벽사이의 거리를 이용하여 비율 적용.
해당 비율로 본 스케일링을 해준다.
충돌 점에 대해서 캐시를 두어 비용을 절약했다.
30. 마영전의 구세대 엔진으로
차세대 비주얼 게임 만들기
발사하기
본 애니메이션은 일정 길이로 발사하도록 잡아놓는다.
XY쪽은 스케일을 조정해주고 Z쪽은 상체 각도를 회전한다.
(상하좌우로 던지기 위해서)
일단 클라이언트에서 체크후 사슬을 건다.
이후 서버에서 계산하고 위치를 보정해준다.
보스등에 많이 사용되므로 보정이 티가 나지 않는다.
31. 마영전의 구세대 엔진으로
차세대 비주얼 게임 만들기
제압하기
리액션에 대한 애니메이션 추가 없이 처리
기존의 플린치 모션을 랜덤 롤백(초 중반 부분)한다.
기존보다 재생 부분이 더 빨라야 한다.
피니쉬때는 전체 재생을 한번 해주면 관성의 느낌도 줄 수 있다.
32. 마영전의 구세대 엔진으로
차세대 비주얼 게임 만들기
Y축 플리핑
좌우 미러링 처리를 한다. (실루엣, 공격판정)
로컬을 기준으로 Y축 플리핑 처리를 해준다. (CCW -> CW)
튀는 부분은 중간 변경 모션을 추가하면 해결 될 것이다.
33. 마영전의 구세대 엔진으로
차세대 비주얼 게임 만들기
Z축 플리핑
천장에 매달리는 연출을 위함.
로컬 스페이스를 기준으로 Z축 플리핑
천장과 충돌 체크 후 위치를 잡아줌.
인공지능은 지상에 있는 걸로 처리 (대칭 구조라 상관 없었음)
35. 광택 재질 표현
현재 스포2에서 물리 기반 쉐이딩을 적용
조명, 거칠기, 반사도 설정으로 알아서 조명 계산이 되길 원함.
특히나 Glossy Reflection 강조를 원함.
관련된 내용중 Voxel Cone Tracing을 구현해 보기 위해서 Voxel
Ray Tracing을 먼저 해보게 되었다.
36. 광택 재질 표현
Voxelization
Open Source 중 Voxelizer를 이용함. (CUDA 베이스)
(Obj파일을 Voxel화 시켜주는 코드가 포함되어 있음)
Unreal3에 맞게 Emissive, Lightmap등을 추가해줌
Obj 파일에는 Texture 좌표들을 추가해 주도록 수정
균일한 그리드로 Export 시키도록 수정 (DX9에서 렌더링을 위함)
HDR 계산된 부분은 Voxel의 Color 값으로 Voxel 데이터에 추가.
37. 광택 재질 표현
3D – DDA 알고리즘
X축 뿐만 아니라 Y축까지 고려하는 DDA 알고리즘
해당 알고리즘을 이용하여 Ray Tracing을 하면 된다.
38. 광택 재질 표현
Compositing
그냥 렌더링 하면 복셀의 모양이 보이거나 투박해 보인다.
1을 기준으로 불투명도를 누적해 가면서 색상을 적용하고 프레넬
항을 적용하여 부드럽게 만들어 준다.
GPG Gems3 참조.
39. 광택 재질 표현
Memory 이슈
64 해상도 -> 1MB인데 512 이상 해상도는 되야 퀄리티가 좋다.
존재하는 복셀만 3D Texture에 담아서 사용한다.
존재하는 복셀을 검사할 때는 64 해상도등 낮은 해상도로 먼저 계
산하고 512 해상도로 처리한다.
40. 광택 재질 표현
한계
DX9를 기반으로 두고 있어 정적인 데이터로 뽑아서 사용해야 한다.
아직 게임에 사용하기에는 힘들것 같다.
Unreal4 엔진 등에서 실시간으로 Voxel Octree를 구축해주는 알
고리즘이 나오고 있다.
48. WEBGL+NODE.JS+CUDA
를 이용한 서버사이드 렌더링
흐름 구조
Worker 쪽에서는 V8 쪽에 접근할 수 없게 구조가 되어 있다.
V8쪽에서 Worker에 요청을 하고 바로 끝내면 Worker쪽에서 따로
스레드를 돌아 처리하고 Callback을 해주는 형태로 진행
49. WEBGL+NODE.JS+CUDA
를 이용한 서버사이드 렌더링
디버깅
Chrome Developer Tool을 이용한다.
변수, 함수에 대해서 추가, 변경 가능
Node용 디버깅 툴도 따로 있다. (WebStorm)
C++ 모듈은 DLL로 빼기 때문에 VS에 연결해서 디버깅
51. WEBGL+NODE.JS+CUDA
를 이용한 서버사이드 렌더링
실제 활용 케이스
지형 생성툴 (C#)
코어는 유지하고 Form 부분만 Web으로 포팅
결과는 HTML5 Canvas를 이용해서 본다. (2D 이미지)
실제 하이트 맵은 WebGL과 연동은 아직 못해봄.
52. WEBGL+NODE.JS+CUDA
를 이용한 서버사이드 렌더링
Web 기반 툴 장, 단점
장점
1. Download, Patch 불필요
2. 서버에 따로 데이터를 올리지 않아도 됨
3. UI 만들기가 비교적 편함(익숙하다는 전제)
단점
1. 동시접속 등 네트워크 이슈가 발생할 수 있음.
2. 데이터를 연결하는 과정이 복잡할 수 있다.
55. MMO와 SNG의 컨버전스
node.js
실제 게임에서 사용할 수 있을까?
libvr - 윈도우에서 node.js를 이용하여 iocp가 가능하도록 해주는 라
이브러리
javascript 기반이라 결과적으로는 느리다.
(ASIO보다 약간느리고, 메모리는 2.5배정도 더 든다.)
채팅 정도는 가능
56. MMO와 SNG의 컨버전스
Socket IO
node.js를 이용하여 webbrowser에서 실시간 네트워킹을 한다.
Win32에서 tcp에 연결하려면 쉽지 않다.
HTTP로 일단 연결하고 HTTP 1.1로 연결을 유지시켜야 한다.
발표자 블로그에 가면 소스 공유 되어 있음.
57. MMO와 SNG의 컨버전스
Redis
메모리 캐싱을 제공해준다.
서로 다른 서버에 접속한 유저끼리 통신을 하게끔 연결해 준다.
아직 개발중인 부분으로 Clustering이 불가능
Master/Slave 복제는 가능
58. MMO와 SNG의 컨버전스
PC에서 채팅을 보내면 모바일의 Push로 넘어오거나 모바일상에
채팅으로 서로 연동되는 부분까지는 만들어 봤음.
다음에는 Shading 등을 고려해서 만들어볼 생각….
63. 유연한 해외 서비스하기
Technical Writing
1. 상대방이 원하는 정보를 우선적으로 적는다.
2. KISS(Keep It Simple and Short)
3. 가능한 능동태로 직관적으로 적는다.
4. 한 물체를 한 단어로 표현하도록 노력한다.
64. 유연한 해외 서비스하기
외국의 엔지니어와 소통하려면 하루 이틀은 금방 간다.
개발자와 PM의 사고 방식이 다르다는 것도 기억해라.
현지 엔지니어의 레벨은 신입이라 가정하고 간단하게 적도록 노력.
글보다는 그림, 다이어그램으로 만드는게 더 효과적일 수 있다.
스크린샷을 뜨고 박스로 강조하는 것도 좋다.
65. 유연한 해외 서비스하기
SVN 관리하기
1. 단일 저장소를 이용한다.
2. 브랜치를 이용한다.
3. 다른 버전으로 만든다.
66. 유연한 해외 서비스하기
단일 저장소 사용
각 나라 패치마다 최신의 내용이 적용된다.
로컬별로 서로 영향을 받을 가능성이 있다.
패치날이 겹치면 힘들 것이다.
로컬 스위칭이 편하도록 구축해 놓아야 한다. (#if def도 쓸만하다.)
67. 유연한 해외 서비스하기
브랜치를 이용한다.
브랜치별로 언제 나눴는지 파악이 쉽다.
비교적 안정된 버전이라 생각할 수 있다.
로컬끼리 서로 영향을 주지 않는다.
다른 로컬에서 해결된 문제가 다시 발생할 수 있다.
브랜치 관리가 따로 필요하다.
68. 유연한 해외 서비스하기
다른 버전으로 만든다.
Merge를 바로 바로 해주지 않으면 나중에 피곤해진다.
Merge
1. 구간 (선택해서 Merge 가능(범위나 Rev 기준))
2. 재통합(개발이 완료되고 주 저장소로 통째로 Merge 가능)
3. 다른 트리(두개의 다른 트리끼리 Merge도 가능)
69. 유연한 해외 서비스하기
충돌
2명 이상의 개발자가 겹치면서 발생하는 현상
1. File (작업 부분이 겹침) (따로 머지툴을 설치하면 더 좋다.)
2. Tree (파일 삭제, 추가가 겹침)
3. Property
70. 유연한 해외 서비스하기
머지 주기는 가능한 짧게 잡는게 좋다.
피쳐별 분리가 쉽게 만드는 것이 좋다.
하나의 저장소에 통합하는 것도 꾸준히 해야한다.
여유로운 마음을 가져야 한다.
72. 서버를 위한 디자인 패턴
스레드 모델
1. Single Thread
2. Input Thread
3. Custom Thread Pool
4. Object Bound Thread Pool
공통적으로 Input -> Excute -> Logic 의 흐름으로 진행된다.
73. 서버를 위한 디자인 패턴
Single Thread
폴링으로 받아서 처리한다.
Input
Excute
(Poll)
Logic
74. 서버를 위한 디자인 패턴
Input Thread
해석후 처리한다.
Input
Excute
(해석)
Logic
75. 서버를 위한 디자인 패턴
Custom Thread Pool
해석후에 Queue에 담아 Logic에 보내준다.
Input Excute
(해석/Queue)
Logic
76. 서버를 위한 디자인 패턴
Object Bound Thread Pool
해석 후에 Logic에서 각 로직에 맞게 알아서 Queue에 담는다.
Input
Excute
(해석)
Logic
(Queue)
77. 서버를 위한 디자인 패턴
중간에 스레드 모델을 교체하기는 쉽지 않은 작업이다.
일단 Single로 만들고 나중에 모델을 결정해서 변경하는게 그나마
편한 선택이다.
78. 서버를 위한 디자인 패턴
Game World
나를 중심으로 범위안으로 들어온 객체들을 생성해서 유지하고 나
가면 제거해주면서 처리한다. (그룹핑)
공간 분할 알고리즘이 필요하다.
간단한 알고리즘으로는 타일 분할이 있다.
(빠르지도 느리지도 않은 것이 특징)
79. 서버를 위한 디자인 패턴
심리스 월드
눈에 보이는 객체들은 한 서버에 같이 있는것이 좋다.
서버에 숫자 제한이 생기게 된다.
경험상 Player 100명에 NPC는 5000~10000 정도
80. 서버를 위한 디자인 패턴
동기 / 비동기
DB에 쿼리나 Dead Lock, Sleep 등으로 공회전되는 시간이 많다.
비동기로 처리하면 이런 부분은 막을 수 있다.
동기로 처리하면 개발이 쉽지만 느릴때가 있다. (하지만 추천)
비동기를 되도록 안쓰려고 한다고 함.
81. 서버를 위한 디자인 패턴
조각 내기
안 할 수 있는 부분은 안 하는게 좋다.
바다를 건너는 등 불 필요한 월드 갱신 부분은 워프등으로 막자.
초보용 마을
편지등 여러 기능을 막고 유저를 조금이라도 더 받는 쪽으로 하자.
메모리, CPU를 늘려라.
돈으로 해결할 수 있는건 돈으로 해결하는게 좋다.
82. 서버를 위한 디자인 패턴
현재는 C#을 사용하고 있다.
Thread Model은 Input Thread Model을 이용중이다.
100개 정도 돌린다.
84. REDIS 소스로부터 살펴보
는 REDIS 쓸 때 주의할 점
위험한 명령어 (데이터가 많을 수록 느리다.)
1. Keys * (On 알고리즘) List나 SortSet을 이용해라.
2. Flash All (On 알고리즘) 전체 삭제
Single Thread
짧은 시간이 걸리는 명령어, 작은 데이터일 수록 좋다.
85. REDIS 소스로부터 살펴보
는 REDIS 쓸 때 주의할 점
메모리 정책
LRU등 다양한 정책이 존재한다.
32비트는 기본적으로 4GB 제한이 걸려있다.
64비트는 제한은 없고 현재 메모리를 넘어가면 디스크에 쓴다.
86. REDIS 소스로부터 살펴보
는 REDIS 쓸 때 주의할 점
Master / Slave
Master에서 어떤 부분을 제거하면 Slave쪽에도 삭제가 된다.
Slave쪽에 어떤 부분을 제거하는건 Master에 영향을 주지 않는다.
Slave는 Master와 비교하여 다르면 Slave를 지우고 Master로 갱
신한다. (slaveof no one으로 slave를 master로 변경할 수는 있
다.)