[NDC17] Protocol:hyperspace Diver 개발 포스트모템

넥스트플로어 지하연구소
김영수
- 엔진 개발부터 시작하는 모바일 인디 리듬게임 개발
<Protocol:hyperspace Diver>
개발 포스트모템
Rev. 2
NDC17 발표: 2017년 4월 25일
최종 자료 수정: 2017년 5월 11일

Protocol:hyperspace Diver
넥스트플로어 지하연구소의 모바일 리듬게임
2017년 4월 19일 Google Play 및 iOS AppStore 출시
https://itunes.apple.com/kr/app/id1124788464?mt=8 https://play.google.com/store/apps/details?id=com.NextFloor.phdiver
이하, P:h Diver로 표기

• iOS & Android 동시 지원
• 대부분의 코드는 C++ 기반
▪ 양 플랫폼 간 공유되는 코드
• OpenGL ES 2.0, OpenAL 등을 이용
▪ Low-Level 라이브러리리 위에 작성됨
NEW GAME! Vol. 4 - 芳文社
개발 환경 및 특징
즉, 자체 개발 엔진 사용

하는 것이 본 발표의 내용
• 엔진 레벨부터 개발을 하게 된 의사결정 과정 소개
• 엔진을 포함한 개발 과정의 경험 공유
엔진을 위주로 P:h Diver의 개발 내용을 포스트모템
특히,
두 가지에 중점을 두고 내용을 전개

• 엔진 개발 여부를 결정할 때, 참고할 수 있는 경험
▪ P:h Diver는 어떤 상황에서, 왜 엔진 레벨부터의 개발을 결정했는가?
▪ 어떤 과정을 거쳐 개발이 이루어지게 되며, 비용은 어느 정도인지
• 저수준의 모바일 게임 개발 노하우
▪ 모바일 플랫폼에서의 호환성 있는 엔진 구조 설계
▪ P:h Diver에서 엔진에서 제공하는 저수준 기능들을 개발한 방식
▪ 저수준 기능 개발에 있어 참고할 만한 점이나 주의해야 할 점 = 삽질 간접경험
전달하고자 하는 것

저수준부터의 모바일 게임 개발에 관심이 있는 분
▪ 게임 프로그래머
모바일 게임 프로젝트 초기,
기술 스택에 대한 의사결정을 하게 될 분
▪ 클라이언트 리드 프로그래머 혹은 테크니컬 디렉터
이런 분들께 청강을 추천
난이도는 초~중급 정도
기초적인, 어떻게 보면 당연한 기술적 내용을 포함
그러나, 실제 삽질경험의 전달이 주된 목적

목차
I. 어째서 엔진을 만들게 되었나?
II. 엔진 개발의 지향점과 전체 구조 설계
III. 개발 과정에서의 경험 공유
IV. 개발 비용 추산 및 평가
V. 결론

현재, 넥스트플로어 지하연구소 미공개 신작 디렉터
<데스티니 차일드> 프로그래머
<마비노기 2: 아레나> 프로그래머
<MapleStory Village> 프로그래머
<MapleStory Adventures> 프로그래머

다른 엔진을 사용하지 않고,
엔진 레벨부터 구현을 시작한다는 의사결정을 하게 된 과정 공유
V. 결론

Protocol:hyperspace Diver
https://youtu.be/CX6YHf1iKPg
백문이 불여일견, 어떤 게임인지 영상으로 확인해 보세요!
Protocol:hyperspace Diver 게임 플레이 영상

넥스트플로어 지하연구소 프로젝트
여기서 잠깐, 어떤 환경에서 개발을 하게 되었는지를 짚고 넘어가자면
• 사내 독립 개발 스튜디오
▪ 상업적 성공 가능성이 크지 않은
프로젝트들을 시도해 볼 수 있는 기회
• 디렉터 중심의 개발 환경
• 몇 가지 제약 사항이 존재
▪ 1년의 개발 기간 제한
▪ 라이브 서비스는 기본적으로 고려 X디스이즈게임, NextFloor

• 1인 개발 프로젝트로 시작
▪ 프로그래밍까진 어찌어찌 가능하니
• 쌈마이하게 만들어서 빠르게 출시하는게
초기 목표
▪ 핵심 게임플레이 기획 프로토타입이 있었음
• 나중에 규모가 좀 커졌지만…
P:h Diver의 개발 자원
김영수
노세노세팀
Director,
Programmer
A
Art Director
B
Planner,
Programmer
C
Artist
2015년 11월 O
12월 O
2016년 1월 △
2월 △
3월 O
4월 O
5월 O ▽
6월 O O
7월 △
8월 △ △
9월 O △
10월 O O
11월 △
12월 △
2017년 1월 O
2월 O △ ▽ ▽
3월 O △ O O
4월 △ △ △
△: 타 프로젝트 병행
▽: 중도 참여
P:h Diver 프로젝트 구성원 맨먼스 도표
개발 수행
타 프로젝트 진행
및
런칭 준비

P:h Diver의 코어 게임 기획
모바일 터치 – 3D 리듬게임
3차원 공간 상에 선과 노트가 존재하고,
음악의 플레이를 따라 공간을 진행하며
터치를 통해 2차원 스크린 상의 노트를 처리하는 게임

• 3D 그래픽 출력/연출이 가능
• 터치 입력을 처리 가능
▪ 낮은 input lag을 가졌으면 좋겠음
• 사운드 출력이 가능
▪ 재생 위치 – 게임 시간 싱크를 맞춰 출력할 수 있어야
▪ Latency가 낮았으면 좋겠음
P:h Diver의 핵심 요구사항
코어 게임플레이를 구현하려면 갖춰야 할, 최소한의 요구사항들
3차원 공간 상에 선과 노트가 존재하고,
음악의 플레이를 따라 공간을 진행하며
터치를 통해 2차원 스크린 상의 노트를 처리하는 게임
어떻게 보면 게임 엔진의 당연한 기능들이라 할 수 있기도 한데…

• 프로젝트 킥오프 얼마 전, 리듬게임이 출시
▪ THE iDOLMASTER CINDERELLA GIRLS
STARLIGHT STAGE (이하 데레스테)
• 리듬게임으로서의 요구사항에 참고
▪ 동세대, 동종 기기를 타겟으로 한 메이저 게임
▪ 좋은 방향으로든 나쁜 방향으로든 기준이 됨
➢ 나쁜 방향에 대한 참고를 더 많이 한 것 같지만
요구사항 참고: 데레스테
아무래도 비슷한 장르의 게임은 개발자에게도, 유저에게도 기준이 될 수 밖에 없다
https://itunes.apple.com/jp/app/the-idolmaster-cinderella-girls-starlight-stage/id1016318735?mt=8
© 2015 BANDAI NAMCO Entertainment Inc.

• 프레임 드랍으로 인한 입력 누락이 없어야 한다
▪ 데레스테 초기에 자주 발생하던 현상
➢ Unity의 GC로 인한 렉으로 추정
▪ 프레임 드랍이 없으면 좋고, 최소한 큐잉된 입력 처리는 되어야 한다
• 사운드 latency는 낮을 수록 좋다
▪ 터치음은 모바일 터치 디바이스에서 줄 수 있는 강력한 피드백 중 하나
P:h Diver의 목표: 1. 높은 성능의 리듬게임
데레스테를 플레이하며 유저로서도 느낀 부분이지만, 게임 경험에 가장 크게 영향을 미치는 부분

• UI가 뛰어난 반응성과 조작 경험을 가지게 하고 싶음
▪ 멀티터치 환경에서 터치 등의 조작에 적절하게 반응해야 함
▪ UI에서 쫀득한 조작함을 느낄 수 있게 커스터마이즈 하고 싶음
➢ 예: iOS의 rubber band scrolling
• 네이티브 해상도 / Responsive Design 지원
▪ 스마트폰/태블릿을 동시에 지향하는 게임으로선 필수적인 부분
P:h Diver의 목표: 2. 좋은 UI/UX 체감
게임의 UI/UX는 디렉터로서 가장 중요하게 생각하는 부분

어떻게 개발할 것인가?
Unity Moderato Cocos2d-x
기존에 존재하던 모바일 게임 엔진들의 사용을 고려

• 무겁고 크고 느리다
▪ 특히 GC에 의한 랙은 실시간성을 요구하는 게임에서 치명적
• UI 도구들이 미묘
▪ NGUI, UGUI 등등이 있긴 하지만, 크게 좋은 평은 아님
➢ 최근에 듣기에도 썩 좋은 UI 프레임워크는 아니란 이야기가
• 개인적으로 선호하지 않는 개발 스타일
▪ FPS/TPS 등의 게임에 맞춰진 엔진 설계
기존 엔진 검토: Unity
요즘 가장 널리 쓰이는 엔진. 데레스테도 Unity로 만들어짐

• NextFloor에서 사용하는 인하우스 엔진
▪ 드래곤 플라이트, 데스티니 차일드 등에서 사용되어 검증된 엔진
▪ 사내에 전문가들이 계셔서 문제가 생기면 지원 요청 가능
• C++ native 코드가 기반 / Lua로 로직을 올려 연동
• 약간의 애니메이션과 상호작용 지원이 있는 UI 시스템
• 개인적으로도 사용 경험 있음
기존 엔진 검토: Moderato
NF에서 개발했기 때문에 고려 가능했던 선택지

• 조금은 올드한 엔진
▪ 드래곤 플라이트 이전 시절부터 이어 내려오는 역사 깊은 엔진
➢ 그만큼 검증되었단 얘기일 수도 있지만…
➢ 의존성 깊은 레거시 코드가 많이 쌓여 있고, 일부 신뢰성 낮은 블록도
▪ 구 문법의 C++을 사용하고, 기본적으로 싱글스레드 기반
▪ OpenGL ES 1.1을 사용 – 쉐이더 이용이 어려움
• Lua로 로직을 짜는 구조에 최적화된 부분이 많음
기존 엔진 검토: Moderato
장점도 많지만…

• 한창 발전하고 있던 엔진
▪ 빠른 C++11 지원
▪ 3D 지원도 꽤 빠른 속도로 구현되고 있었음
▪ 오픈소스/C++이라, 어쨌든 문제가 생기면 손댈 수 있긴 함
• 이리저리 마음에 드는 구석이 많고 쓸만한 엔진
▪ Native C++ 기반이라 괜찮은 속도를 보여줌
▪ 엔진 구조도 꽤 단순하면서 개인 취향에 맞는 처리 흐름
➢ 취향입니다 존중해 주시죠
기존 엔진 검토: Cocos2d-x
가장 유력했던 후보

• 신뢰성에 약간의 문제가 있었음
▪ 3.0 alpha 버전부터 써 봤는데, 조금 안 좋은 기억이 있음
➢ 물론 알파 버전이라 당연한 것이지만, 여전히 완벽히 믿고 쓰기는 조금 어려움
▪ 3D 지원도 아직은 구현을 시작한 단계 (당시 기준)
• 라이브러리에 다소 만족스럽지 못한 부분이 있었음
▪ 역시 괜찮은 UI/UX 프레임워크가 부재
▪ 사운드 라이브가 생각하던 것 만큼 강력하지 않았음
기존 엔진 검토: Cocos2d-x
다 좋았다면, 발표의 제목부터 달라졌겠죠?

• 최신 C++로 편안한 개발 환경에서 개발
▪ 그 전 프로젝트가 Lua(Client) / PHP(Server) 였는데… 후샏
▪ 런타임 디버깅 등의 개발 환경 지원이 훌륭했으면
• 최대한 많은 플랫폼을 단일 코드로 지원
▪ iOS/Android(+@), 국가나 기종에 관계 없이 단일 코드베이스로 지원
▪ 주 개발자가 1인인 상황에서, 출시 및 출시 후 대응을 고려하면 필수적
• 성능이나 UI/UX 등의 요구사항을 높은 퀄리티로 맞추고 싶었음
프로그래머로서는 이렇게 개발하고 싶었음
나는 단수가 아니다

• Win32 네이티브 환경에서 게임 개발을 학습
▪ 당시 엔진은 너무 컸고, WinAPI + DX / OpenGL로 게임을 만들기 시작
• 실무 프로젝트에서 자체/인하우스 엔진을 사용
▪ ‘발표자 소개’ 페이지에 있는 프로젝트 중 상용 엔진 사용 X
➢ 데스티니 차일드: 조금 전 살펴본 Moderato
▪ 특히, MapleStory Village와 데스티니 차일드가 모바일 + 자체엔진 기반
내가 예전에는 어떻게 했더라..?
경험해 본 방향으로의 개발 진행은 여러가지 측면에서 무시 못할 정도의 고려 요소
그러고보니 오히려 Unity라거나 기타 상용 엔진 써서 만들어본 경험이 더 없네요;;
(옛날)언리얼, Ogre, Crystal Space 같은게 있던 시절

그런다고 막 개발하면 되나요?
프로그래머로서의 자신 이전에 개발 디렉터로서의 자신이 거는 태클
NDC12 게임 잼 운영과 게이미피케이션
프로로서 회사의 업무에 대해 결정하고 책임을 져야 하는 것
들어가는 비용과 얻을 수 있는 리턴을 고려해서 개발 진행에 대한 의사결정을 해야 한다

• 기존 엔진을 사용할 때의 추가 비용
▪ 엔진을 배워서 사용하는 비용 (특히 Moderato 이외의 엔진을 사용할 때)
➢ 엔진에 대한 충분한 이해가 부족한 시절에 만들 수 있는 기술 부채도 비용
▪ 최적화에 드는 비용도 무시할 수 없음
➢ Unity의 경우, NDC에서 그것만 주제로 하는 별도의 세션들이 열릴 정도
비용 추산에 추가로 고려한 요소: 기존 엔진
기존 엔진 쓴다고 슉~ 하고 게임이 나오는게 아니까요
NDC Replay (http://ndcreplay.nexon.com)

• 결코 낮지 않은 요구사항
▪ Low-latency의 사운드는 기술적으로도 도전적인 과제
▪ UI/UX의 경우, 일반적인 게임에서 보통 사용하는 수준보다 높은 요구사항
비용 추산에 추가로 고려한 요소: 요구사항
실제 구현 가능 여부는 결국 구체적 문제 해결에 들어가 봐야 알 수 있겠지만
8 Mile - Imagine Entertainment

• 자체 엔진 사용 프로젝트 종사 경험
▪ 직접 엔진을 시작부터 만들진 않았지만
▪ 꽤 깊은 곳까지 건드리며 다뤄본 경험
• 비슷한 모바일 프로젝트 경험이 있음
➢ 데스티니 차일드와 MapleStory Village
▪ 엔진 구성 및 기술적 노하우를 참고 가능
▪ 일어날 수 있는 문제도 어느 정도 파악
비용 추산에 추가로 고려한 요소: 개발 경험
내가 해 봐서 아는데…
오마이뉴스
http://m.ohmynews.com/NWS_Web/Mobile/at_pg.aspx?CNTN_CD=A0001516557&CMPT_CD=TAG_M#cb

선택지 비교
Unity Moderato Cocos2d-x 자체개발
성능 낮음 보통 높음 높음
제공하는 기능 보통 보통 보통
없음 →
원하는 모든 기능
개발 비용 보통 보통 보통 보통
개발 편의성 낮음 보통 높음 높음
두 가지 선택지 사이에서 많은 갈등을 했었음

결론은 자체 엔진개발
비용-효용적인 측면에선 (리스크를 고려해도) Cocos2d-x와 자체개발이 비슷할 것 같았으나
기술을 끝까지 이해하고, 만일의 경우 좀 더 원하는 방향으로 커스텀 할 수 있을 것 같아 선택

• 개발팀의 인력 구성이 달랐다면 다른 선택을 했을 수도 있음
▪ 프로그래머 전원이 동일한 경험 배경을 가지고 있음
▪ 프로그래밍적 기능을 구현하는데 의사소통 비용 거의 0 (1명이라서!)
• 특히 타 직군과의 협업을 고려할 경우, 큰 차이가 발생 가능
▪ 아티스트 등의 직군이 사용할 수 있는 툴의 개발 비용 문제를 반드시 고려!
➢ P:h Diver에서도 마지막에 터져 나온 문제
주의사항: 개발팀의 구성
앞서의 선택은 P:h Diver 개발팀 기준에서의 비용 추산에 의거한 것
Don't Try This At Home - COMEDY CENTRAL

어떤 목표를 가지고 있었고, 그것을 엔진의 구조에 어떻게 적용시켰는지
엔진의 설계에 대한 경험 공유
V. 결론
THE IDOLM@STER CINDERELLA GIRLS - A-1 Pictures

왜 엔진을 직접 개발하려고 했었죠?
위의 목표를 정제해서 기술적으로 달성해야 할 지향점을 추출

P:h Diver 엔진 개발의 지향점
개발 시작하면서 개발실 화이트보드에 적어 놓았었음
+ 멀티스레드 호환 너무 당연한 거라 적을 때 까먹고 빠뜨림ㅠ
1~3
2
4
5
6
3

1. 플랫폼 중립
N-Screen 대응이 목표
• 스마트폰 / 태블릿
• iOS / Android
▪ 수많은 제조사
▪ 수많은 제품군
▪ …

어떻게 대응할 것인가?
1. 플랫폼 중립
한 땀 한 땀, 장인의 손길로 기기에 맞춰서 포팅한다
iOS에서는 Swift, Android에서는 Java를 써야겠죠?
Patek Philippe 5175R Grandmaster Chime Watch
https://youtu.be/SGPjFFMD3c0

이말년 시리즈 - 이말년

어떻게 대응할 것인가?
1. 플랫폼 중립
이건 절대 할 수 없음
그렇다면 어떻게…?

소프트웨어 공학의 가장 강력한 도구 중 하나
객체지향 프로그래밍 시간에 다들 들어보셨죠?
스타크래프트 - 김성모
1. 플랫폼 중립

Platform별 로직의 추상화
Platform별 구동 로직을 밑에 깔고, 그 위에서 플랫폼 중립적인 게임을 만들자!
넘을 수 없는 추상화의 벽
게임 로직 구현
플랫폼 로직
1. 플랫폼 중립
DIP:
one should “depend upon abstractions,
[not] concretions.”
Robert C. Martin (“Uncle Bob”) (2000),
Design Principles and Design Patterns

• 사실 당연한 소리
▪ 관심사를 분리하여 묶을 수 있는 부분은 묶는게 CS의 전통(?)
• 당장 모든 엔진들이 취하는 접근 방식
▪ 특히 데스티니 차일드와 MapleStory Village의 사례가 있음
➢ 로직 코드는 공용으로 쓰고, iOS 및 Android를 지원하는 기반 코드 존재
▪ 효과가 굉장했다!
➢ 플랫폼 의존 신기능 개발 시 외에는 로직 코드만 짜면 양 플랫폼 빌드가 뙇!
기존 구현 사례
당연히 제가 발명한 방법은 아니고…
1. 플랫폼 중립

2. 플랫폼 중립적 도구
그래서 그렇게 쓸 수 있는 도구들이 뭐냐면…
• 우선, 프로그래밍 언어의 문제
▪ 각 플랫폼에서 지원하는 first-class 프로그래밍 언어는..
Ojbective-C
Swift
Java
iOS Android

그래서 그렇게 쓸 수 있는 도구들이 뭐냐면…
• 우선, 프로그래밍 언어의 문제
▪ 각 플랫폼에서 지원하는 first-class 프로그래밍 언어는..
Ojbective-C
Swift
Java
iOS Android
++
C++ via NDK
C++

• C++ 밖에 없다
▪ 양 플랫폼에서 모두 Native로 지원하는 프로그래밍 언어
➢ LLVM Clang / Android NDK
• C++11로 가자!
▪ C++11 버전에서 언어적으로 꽤 많은 발전이 있었음
➢ 특히 std::shared_ptr이나 std::function 등은 혁신적인 편의성을 제공
▪ Xcode 지원 LLVM clang이나 NDK용 gcc 등이 표준을 지원
플랫폼 중립적인 C++로 짠다!
생각보다 로직 짜기 편하고 좋은 언어예요… 적어도 Lua나 PHP보단ㅠ

기타 플랫폼 중립적 도구들
얘네들
플랫폼에 의존해야 하는 기능들은
C++에서 사용 가능한 플랫폼 중립적 라이브러리들을 사용
POSIX

• 그래픽 라이브러리로 OpenGL을 사용
▪ 모바일에서는 거의 표준처럼 사용되고 있음
• OpenGL ES 2.0을 사용
▪ 모바일에서 지원하는 건 ES 계열
▪ 2.0은 현재 대부분의 디바이스에서 지원
➢ Programmable Pipeline 사용이 가능
OpenGL: 그래픽 라이브러리

• 사운드 출력을 위한 라이브러리로 OpenAL을 사용
▪ 양 플랫폼 모두를 지원하는 최소한의 선택지
• 꽤나 저수준의 라이브러리
▪ 3D 사운드를 지원하나, 입력은 PCM으로만
▪ 오디오 포맷 디코딩 등은 사용자의 몫
OpenAL: 사운드 라이브러리

• Pthread
▪ POSIX Thread
▪ 플랫폼 독립적인 공용 멀티스레드 프로그래밍을 위해 이용
• 기타 파일 관련 API 등
▪ OS 기능은 표준 라이브러리에 없으면 POSIX 표준을 이용
▪ (후술하겠지만) Windows 지원 이슈로 제한적으로 사용함
POSIX

• 암호화 라이브러리로 OpenSSL을 사용
OpenSSL: 암호 및 통신

• 암호화 라이브러리로 OpenSSL을 사용
▪ 하려고 했으나, 빌드 호환이 생각보다 비용이 많이 들었음
▪ 여튼 Android 및 Windows PC에서는 OpenSSL을 이용
• iOS에서는 CoreCrypto + NSURLSession
▪ 해당 도구가 지원하는 기능의 상위 수준에서 엔진 기능 추상화
▪ 암호화쪽은 OpenSSL과 거의 비슷하게 생김: 거의 래퍼 수준
OpenSSL: 암호 및 통신

• 게임 엔진은 표준 C/C++을 이용
▪ 표준 C/C++ 라이브러리, STL 등을
이용 가능
➢ Boost는 사용하지 않음
▪ C/C++용으로 작성된 대부분의
라이브러리 호환 가능
기타 C/C++ 라이브러리

3. 각각의 플랫폼 대응
IDE 상에서의 런타임 디버깅 가능 여부는 가장 먼저 챙긴 부분 중 하나
XCode
iOS
NSight Tegra
Android

• Per-frame Update를 기반으로
▪ iOS/Android 모두 OpenGL App은
Frame 단위 Update를 기반으로 삼음
• 앱 생명 주기에 따라 게임 객체 관리
▪ App이 생성될 때, 게임 객체를 생성
▪ 생성-초기화 후, 매 프레임
Update/Render
플랫폼 추상화 수준
게임 루프로 돌아가자!

• Objective-C++은 C++의 super set
▪ .mm 파일 만들어 두고 C++로 코딩해도 잘 컴파일이 됨
▪ Obj-C의 id는 C++의 pointer로 사용하면 거의 무리 없이 호환됨
• 하지만 iOS 라이브러리는 Objective-C(++)만을 지원
▪ iOS 플랫폼 의존 라이브러리를 이용하는 코드는 Obj-C에서
➢ 게임 제어에 필요한 C++ 코드가 있다면 섞어서 작성해도 무방
▪ 게임 → 플랫폼이나 플랫폼 → 게임 로직은 C++ 인터페이스를 이용
iOS C++ 호환
날로 먹을 수 있는 iOS C++ 호환

• GLKView를 디자이너에서 생성해 이용
▪ GLKViewController Delegate와
AppDelegate에 최소한의 로직을 구현
▪ Delegate로 전달되는 이벤트를 게임 객체로
전달해 처리
➢ Objective-C로 처리되는 델리게이트 코드에서
C++ 게임 인터페이스를 직접 호출할 수 있어 편리!
iOS 플랫폼 호환
GLKViewController
Obj-C++
GLKView
AppDelegate
Obj-C++
Game
C++
Delegate Events
Call via C++
Frame Update,
Graphic Prepare, … App Pause, Background, …

• Android 플랫폼의 1종 언어는 Java
▪ C++과의 호환을 위해선 JNI(Java Native Interface)를 사용
➢ 엄밀히는 C와 호환이 되는 것이므로, 작성 시 주의 필요(extern “C” 사용 등)
• NDK에서 Native Activity를 생성할 수도 있지만… 추천하지 않음
▪ 대부분의 안드로이드 라이브러리는 Java를 기준으로 작성/제공
➢ 문서나 예제도 대부분 Java 기준으로 제공됨
▪ 라이브러리 상호 호환을 위해 Activity나 기본 앱 구동은 Java를 이용함
Android Java 호환
안드로이드 – C++ 로직 간 호환은 조금 더 번거롭다

• Activity 생성 후, GLSurfaceView를 만들어 이용
▪ 앱의 생명 주기 관련 처리는 Activity 로직을 통해 수행
▪ 게임의 Update/Render는 GLSurfaceView의 Renderer 이벤트 이용
➢ onDrawFrame에서 호출하면 됨
• C++ 게임 객체에 대한 통신은 JNI를 통해
▪ Activity/Renderer는 JNI로 노출된 C 코드를 호출
▪ 게임 객체를 전역으로 올려두고 JNI C 코드에서 이를 초기화 - 사용
Android 플랫폼 호환
플랫폼 호환은 Android OpenGL ES 앱의 흐름을 따라

Android 플랫폼 호환
GLSurfaceView.Renderer
Java
GLSurfaceView
FragmentActivity
Java
Game
C API in C++
Call via JNI
Frame Update,
Graphic Prepare, … App Pause, Background, …
Logic Side Platform Library Calls
Activity owns
GLSurfaceView

• 빠른 이터레이션과 디버깅은 다시 강조해도 모자람이 없음
▪ 게임의 완성과 생산성에 메우메우 중요
• Windows PC 환경에 대해서도 플랫폼 로직을 지원하자!
▪ 보통 대부분의 작업은 Windows PC에서 수행하게 됨
➢ 작업하던 PC에서 바로 게임을 돌려볼 수 있다는 것은 엄청난 효율을 선사해줌
▪ Visual Studio는 아주 훌륭한 IDE
➢ VS에서의 런타임 디버깅이 되면 공용 로직의 디버깅은 천국에서
Windows PC 플랫폼 지원
혹시라도 저희랑 비슷하게 엔진부터 만드시게 되면, 이건 반드시 구현해서 쓰세요!

• WinAPI로 Window를 생성해서 사용
▪ 하나의 Window를 가진, 메시지 루프가 돌아가는 단순한 프로그램
▪ 메시지 루프가 메인 게임 루프가 된다.
➢ 메시지 루프 안에서 이벤트를 처리 후, 프레임 Update/Render 함수를 호출
• 지원해야 할 플랫폼 기능은 많지 않음
▪ 개발 시작 시점에서는 터치(= 마우스 클릭) 이벤트만 전달해 주면 됨
➢ Windows Touch 이벤트들을 처리하면 멀티터치까지도 지원 가능
✓ 생각보다 쉬워요... 저도 이거 구현해서 서피스 프로에서 게임 테스트 해봄
Windows PC 플랫폼 구현
WinAPI 쓰던 시절 기억을 되살려보자구요

• 생성된 Window에 OpenGL을 붙여서 사용
• OpenGL이 아닌 OpenGL ES를 지원!
▪ 비슷하게 쓸 수 있지만 은근히 세부적인 부분에서 차이가 있음
➢ 모바일이 목표 플랫폼, PC에서의 구동은 개발/디버깅 목적으로 할 것이므로
▪ PC를 first-class로 지원하는 엔진에서는 OpenGL을 사용하는 경우도
➢ 앞에서 예시로 든 Moderato 엔진
▪ P:h Diver에서는 OpenGL ES 에뮬레이션을 위해 EGL 구현을 사용
Windows PC 플랫폼 그래픽 시스템
OpenGL 대신 OpenGL ES를 사용하자!

4. 멀티스레드 지원
• 멀티스레드 프로그래밍을 지원하는 것이 목표
▪ 엔진 설계 시점부터 고려하여 코드를 작성하는 것이 좋음
▪ 차후에 멀티스레드 지원을 추가하는 것은 작업량이 꽤 많을 수 있음
• 프로그래밍이 편해질 수도 있다
▪ 비동기 IO 작업과 백그라운드 작업 등을 관리하는 비용이 줄어듬

• 비동기 작업을 지원
▪ 사실 성능 문제는 그렇게 까지 크지
않은 경우가 많다
▪ 단, 프레임을 잡아먹어 게임 자체를
버벅거리게 하는 일을 줄일 수 있음
➢ 데스티니 차일드 로직이 싱글 스레드라
로딩 때 ‘끊김’을 아무리 해도 못 잡음ㅠ
멀티스레드 지원의 필요성
https://youtu.be/PoaK1vnlD7c
Destiny Child 로딩 영상
애니메이션 끊김을 포함한 프레임 드랍에 주목

• 문제가 될 만한 부분들을 잘 챙겨가며 코딩 당연한 소리지만
▪ 스레드 간 공유될 수 있는 객체/자원의 경우 동기화 메커니즘 적용
▪ 데드락 등, 동기화 문제가 생기지 않도록 주의
• 특히, 라이브러리 등에 접근할 때 주의
▪ STL 객체를 여러 스레드에서 사용할 경우
➢ const 멤버 함수만 스레드 안전하다는 점을 기억
➢ 적절한 동기화 메커니즘 없이 동시에 막 사용하면 쉽게 깨짐
▪ 라이브러리 내부가 스레드 안전하지 않은 경우가 종종 있으니 주의
설계 및 구현 시, 고려해야 할 부분
OS 시간에 배운 대로만 짜면 됩니다

• 표준 라이브러리를 통해 스레드 지원
▪ <thread>, <mutex>, <condition_variable> 헤더 사용
▪ 꽤나 사용하기 편한 객체 기반 스레드/동기화 도구 제공
• 이외에도 유용한 도구들
▪ <atomic>, <future> 등
C++11의 멀티스레드 프로그래밍 지원

• Pthread쪽이 조금 더 많은 도구들을 지원
▪ 상세한 스레드 속성 지정, 세마포어, Read-Write Lock 등을 추가 지원
➢ 특히 Read-Write Lock은 실제로 사용할 일이 굉장히 많음
• Pthread 역시 플랫폼 호환
▪ iOS/Android에서 참조 추가 만으로 사용 가능
▪ Windows 포팅이 존재
• std::thread와 pthread를 섞어 쓰지는 않는 것을 권장
C++ thread vs. pthread
P:h Diver에서 pthread를 쓴 이유

5. 가벼운 엔진을 지향
• 유니티가 마음에 들지 않았던 이유
▪ 지나치게 강제되는 구조가 많음
➢ 모든 것이 Object… 그럼 흐름은 어디다 담지?
➢ 그럭저럭 괜찮은 컨트롤러, 그런데 이걸 쓰려면 물리 객체를 붙여야 한다고?
▪ 큰 구조에서의 제어 흐름을 건드릴 수 없음
➢ 업데이트 구조, 객체-컴퍼넌트 구조 등을 건드릴 수 없음
➢ 특히 Scene에 코드를 담은 객체들을 담아놓고 작업하는 상황이란

게임 로직에서 맵 초기화를 위해서,
빈 Object를 씬에 배치하고 스크립트를 붙인다고?
그냥 아이소메트릭 뷰의 단순한 2D 게임인데…
빌보드 띄우기 위해 이상한 각도로 올리는 거야 그렇다 쳐도
컨트롤러랑 연동하려면 타일 기반 통행 가능성 체크가 안 되고
콜라이더를 붙여야 한다고???
개인적인 Unity 게임 개발 경험

쓰지 않는 제너럴함은 몸을 무겁게 만들 뿐
너희는 객체를 잡혔을 때 얼마만큼 힘을 쓸 수 있는가? 이 팬티의 무게는 무려 20kg가 넘는단다.
• 리듬 게임 P:h Diver는 코어 로직이 간단
▪ 실제로 처리해야 하는 단계는:
➢ 프레임 간에 입력된 터치를 받아와서
➢ 현재의 노트 위치를 계산해, 판정
➢ 그린다. 끝.
▪ 노트 등이 각각 객체의 그 수많은 기능을 필요로 하는게 아님
➢ GoF의 라이트웨이트 패턴까지 갈 것도 없지 않나요?
• 기능이 필요 없을 때도 특정 구조를 강제하는 것이 문제란 것

예전엔 어떻게 개발했더라..? (2)
대전공대 버거킹 있던 시절.. 아니 조금 더 옛날인가?
• GLUT가 불러주는 게임 루프 위에서 프레임 처리를 수행
▪ 결국 OpenGL 가지고 게임을 짰던 것

C++로 작성하는 게임 코드
다들 옛날에는 이렇게 하셨잖아요?
• C++(11)은 나름 게임 로직 짜기 좋은 언어
▪ 스크립트 언어가 뜨기 전엔 다들 C++로 게임 로직을 작성
▪ 정적-강타입이라 디버깅이 (상대적으로) 편하고 꽤나 파워풀
➢ 특히, 속도가 빨라서 조금 막 짜도 그럭저럭 돌아감
▪ C++11 등의 최신 표준 하에선 훨씬 사정이 나아짐
➢ 제일 귀찮던 메모리 관리가 std::shared_ptr의 도움을 받을 수 있게 됨
➢ <functional> 기능들도 로직 작성에 큰 도움이 됨

그래서 우리 엔진은..?
넘을 수 없는 추상화의 벽
게임 로직 구현
플랫폼 로직
OpenGL
최대한 얇은 레어어로 추상화
Portability를 중심으로
호환성을 확보한 후,
C++과 OpenGL로 원하는 대로
프로그래밍 가능하게!

Low-level 프로그래밍 가능
• 원한다면 OpenGL ES에 바로 접근
▪ 각종 랜더링 테크닉도 직접 사용 가능
• 물론 상위 레벨의 기능은 제공
▪ OpenGL ES도 ‘쓸 수 있다’는 것
▪ 매번 Per-Vertex를 건드리는 건 아님
▪ 레이어링을 통해 상위 기능을 제공

따지고 보면 엔진이라기보단 프레임워크
GLUT나 GLFW과 비슷한 수준의 레벨까지의 접근을 제공
• 매우 얇은 하부 레이어
▪ 적어도 Unity나 cocos2d-x보다는
훨씬 얇은 레이어 위에서 시작
• 프레임워크 vs. 엔진
▪ 루프나 프레임 제어구조를 내가 짜면
프레임워크, 아니면 엔진이란 말이 있음
What's the difference between an “engine” and a “framework”? [closed] - Stack overflow
http://stackoverflow.com/questions/5068992/whats-the-difference-between-an-engine-and-a-framework

6. 모듈 구조
숟가락으로 밥도 먹고, 참호도 파고, 연못도 만들고…???????
군용 식판 (New Generation) - K-ration
http://k-ration.co.kr/product/%EA%B5%B0%EC%9A%A9-%EC%8B%9D%ED%8C%90-new-generation/171/
그래도 개발하다 보면
이것저것 필요하기 마련
그림 한 장 뿌리자고 매번 libpng 불러와서
텍스처 로딩하는건 좀 아니잖;;;

골라먹는 모듈
필요한 기능들만 쏙쏙, 모듈도 골라먹는 객체지향의 시대!
• 레이어링을 통해 상위 계층 기능 제공
▪ 하위 계층 기능들을 이용해 상위 계층의
기능을 제공하는 계층화된 모듈 구조
▪ 그래픽 자원관리, 추상화된 파일 시스템,
등등…
• 필요에 따라 모듈을 구성해서,
게임에 필요한 기능에 맞춰 엔진 구성!
6. 모듈 구조
한국맥도날드(유)
http://www.mcdonalds.co.kr/event/kor/pc/create_your_taste.jsp

다른 엔진들도 다 그렇잖아요?
에이, 모듈이야 다들 쓰는건데… Unity는 더 객체지향적인 엔티티-컴퍼넌트라구요?
• 아뇨
▪ 생각보다 이거 관리가 쉽지 않음
▪ Moderato의 사례:
➢ 의존성 추상화를 위해 만든 중앙집중적 InterfaceLib이 모듈 간
상호 의존성을 감춰 제공, 전체적으론 의존성이 꽤 복잡하게
꼬여버림
6. 모듈 구조
InterfaceLib
PackLib VisualLibRendererLib SoundLib …
Game
Lua
Game Script Manager
& Common Lib
+ Unity도 따지고 보면
파편화된 ‘기능’단의 선택을 제공하는 것

모듈
6. 모듈 구조
module – Merriam-Webster Dictionary
https://www.merriam-webster.com/dictionary/module
모듈의 정의로 돌아가 다시 보면…

모듈의 정의로 돌아가 다시 보면…
모듈
6. 모듈 구조
module – Merriam-Webster Dictionary
https://www.merriam-webster.com/dictionary/module

엔진을 명확하게 모듈로 구조화
모듈의 구성요건을 명확하게 정의하고 향후 구성이나 확장, 상호호환을 위한 규칙을 정리
6. 모듈 구조
• 독립적으로 구성 가능한 엔진의 기능 단위 요소
▪ 형태와 구성 방식을 표준화시켜 정의
▪ 의존성을 명확하게 정리
▪ 인터페이스의 명료화-표준화
• 모듈을 구성하여 원하는 기능을 가진 게임 엔진을 만들 수 있도록
▪ 필요한 모듈만을 넣을 수 있게
▪ 그리고 추가로 기능이 필요하면 모듈의 형태로 추가 가능하게

레이어링과 모듈 간 의존성 관리 체계
순환 참조 의존성이 생기는 순간, 독립성은 되돌아올 수 없는 강을 건너게 된다
6. 모듈 구조
• 모듈의 참조는 위에서 아래로만
▪ 상위 모듈은 하위 모듈을 참조할 수 있음
▪ 하위 모듈은 상위 모듈 참조 금지!
➢ 계층을 도입하면 자연스럽게 의존성이 Tree로 정리
Application
Graphic
File SystemInput
Sound
Sound Data
Graphic Resource
Manager
1. Base System

레이어링을 통한 의존성 관리의 장점
왜 굳이 저런 불편한 짓을?
6. 모듈 구조
• 모듈간 커플링의 감소 기대
▪ 순환 의존성을 금지시키는 것으로, 강한 커플링은 줄일 수 있다.
• 모듈의 추가 및 제거가 쉬워진다
▪ 어떤 기능을 개발하면 어떤 모듈에 의존하는지를 쉽게 파악 가능
▪ 제거 시, 해당 Sub-Tree만 걷어내는 것으로 의존성 관리 가능
• 모듈의 초기화 순서가 명확해진다
▪ 엔진 구성에서 꽤 중요한 문제가 될 수 있음

모듈의 형태 표준화
모듈은 엔진 컴퍼넌트와 모듈 라이브러리라는 형식을 통해 표준화
6. 모듈 구조
엔진 컴퍼넌트
엔진을 구성하는 컴퍼넌트
내부 상태를 가질 수 있다
게임 초기화 시, 객체 생성
모듈 라이브러리
전역 함수 형태의 라이브러리 API
내부 상태를 가질 수 없다
게임 초기화 시, 초기화 함수 호출
Entity
초기화의 절차와 엑세스 형식을 표준화
상태의 유무는 엔진 모듈 작성 시의 가이드라인

엔진 컴퍼넌트?
그것도 무스비… 그것도 객체…
6. 모듈 구조
• 게임 그 자체, 혹은 엔진의 인스턴스도 결국은 객체!
▪ 엔진의 구성요소를 컴퍼넌트의 형태로 접근하게 할 수 있다.
➢ 특히, 내부 상태를 가지는 부분 기능을 추상화하기 좋은 모델
• 의존성 정리가 편리
▪ 엔진 초기화 시, 의존성에 따라 순서대로 초기화를 수행할 수 있음
➢ 다른 컴퍼넌트에 명확하게 의존하는 컴퍼넌트는 해당 컴퍼넌트 참조 가능
• S 모 엔진의 ‘월드 컴퍼넌트’ 에서 배워온 설계

엔진 컴퍼넌트 vs. 서비스 로케이터
6. 모듈 구조
• 서비스 로케이트 패턴: 중개자를 통해 추상적인 서비스를 제공
• 비슷하지만 다르다
▪ 엔진 컴퍼넌트는 ‘구성’이라는 원리를 기반으로 한 마인드 모델
[1] 로버트 나이스트롬, 게임 프로그래밍 패턴, 박일 역 (한빛미디어, 서울, 2016), p. 308.
[1]

모듈 라이브러리 관리
전역 함수 API의 집합이더라도 표준 형식을 제공해서 관리
6. 모듈 구조
• 싱글턴 모듈 인터페이스 객체
▪ 일부 전역 상태 초기화/정리
➢ 상태라고 보긴 미묘하지만,
글로벌 초기화가 필요한
라이브러리가 은근히 있음
▪ 모듈 간의 의존성을 데이터의
형태로 제공

GAME
7. 엔진 아키텍처
Platform
iOS
Android
Windows
PC
Application Graphic File System Input …
Graphic Resource
Manager
OpenGL
ES
엔
진
모
듈
플
랫
폼
구
현
엔
진
기
반
구
조
외부 라이브러리
외부 라이브러리
어
플
리
케
이
션
빌
드
게임 구현
실제 프로젝트 구성

게임 객체의 생성 및 초기화
게임을 구성하는 방법
• 게임 코드 레이어에 게임 객체의 생성을 위임
▪ 엔진에는 생성 함수의 인터페이스만 존재
▪ 게임에서 이용할 기능에 맞게 모듈 및 컴퍼넌트 초기화

현재의 상태
지금의 엔진 모습은?
• 아직 모든 기능을 완성하지는 않음
▪ 게임 개발에 필요한 기능만 우선 구현
➢ 목적은 어디까지나 게임 개발 기술 덕질을 했으면 내가 엔진이 아니라 스크립트 언어를 만들고 있었겠지
▪ 일부 기능은 충분한 퀄리티로 정리되지는 못함
• 정리가 덜 된 기능은 게임 코드 내에 위치
▪ 표준화되지 않은 구현은 엔진 레벨로 끌어들이기 위험
▪ 재사용을 억제한 게임 코드로 격리! Secure Contain Protection

엔진의 기능들을 개발하면서 겪었던 경험을 각론적으로 소개
V. 결론
Note:
원래 이 파트도 꽤 중요하게 가져가서 많은 경험을 소개하고 싶었는데,
발표 분량 및 준비 시간 문제로ㅠ 주요한 몇 가지 부분적 Tip 위주로 간략하게 소개하게 되었습니다.
나중에 기회가 된다면, 추가적인 경험을 공유할 수 있는 자료를 만들어서 배포해 볼게요!

1. 텍스처 관리
여기까진 금방인데…
일단 그림 파일을 읽을 수 있어야 하고(File IO)
png 포맷 파일을 디코딩 할 수 있어야 하고,
OpenGL 텍스처에 올려서…
헉, 이거 어떻게 하지?

PNG 텍스처 로드
엔진 만들기로 했으니까 해야죠
• PNG Only!
▪ 투명도, 32비트 색상, 기타 압축 등 게임에 필요한 기능은 거의 갖춤
➢ JPEG도 잠깐 리서치 해 봤는데, 퀄리티가 높으면 용량 차이가 별로 안 남
➢ 텍스처 생성을 추상화 해 두면, 디코더만 붙이면 되니 필요할 때 붙이면 됨
• 어떻게 로드할까? : 단순무식!
▪ libpng로 디코드해서
➢ 빌드할 때 neon 설정 같은거 잘 해 주면 조금 더 빨라짐
▪ 비트맵으로 메모리에 뽑은 다음, OpenGL ES 텍스처에 업로드

텍스처 복구
• 텍스처가 날아가는 경우가 있음
▪ 앱이 Background로 가거나 OS가 필요하다고 생각하는 경우
➢ Android의 경우, setPreserveEGLContextOnPause를 설정해서 막을 수 있음
• 대처 방법은? : 체크하고 복구
▪ 앱이 Background에서 돌아올 때, 기존 텍스처를 체크할 필요 있음
➢ glIsTexture 함수를 이용해서 텍스처가 날아갔는지 여부를 검사
▪ 날아간 텍스처를 복구하기 위해서는 적절한 메커니즘 구현 필요

Texture Atlas
• 여러 스프라이트를 하나의 이미지에 모은 것
▪ 저장 공간의 효율적 사용 및 성능 향상 등이 목적
➢ Draw Call을 줄일 수 있음. GL에선 텍스처가 상태라;;
• 정적 Texture Atlas
▪ 아티스트와의 협업 과정에서 많이 사용
▪ 툴의 출력을 읽어 사용할 수 있게 구현하는걸 추천
➢ TexturePackerhttps://www.codeandweb.com/texturepacker

동적 Texture Atlas
• 런타임에도 텍스처 아틀라스를 구성할 수 있음
▪ glTexSubImage2D를 이용해 텍스처 부분 업로드 가능
▪ 텍스트 랜더링 등에서 사용됨
• 이미지들을 주면 영역을 확보해 아틀라스를 구성할 수 있어야 함
▪ 2차원 냅색 문제
➢ …지만, 글로벌 최적해 찾지 않고 적당히 greedy로 푸는 방법은 꽤 존재
• 텍스처 복구 매커니즘에 주의
▪ 텍스처를 받을 때, 복구 함수를 함께 받아 저장한다거나

추가로 구현하면 좋은 것
• RTT - Render Target Texture
▪ GL이 랜더링하는 타깃(Framebuffer)를 텍스처로 설정
➢ glFramebufferTexture2D
• Frame Buffer → Texture Copy
▪ 프레임 버퍼의 내용을 텍스처로 카피 가능
➢ glCopyTexSubImage2D
▪ 스크린 효과 등, 여러가지 랜더링 효과를 이용할 수 있음
➢ 게임에 들어간 blur 효과가 이걸 이용

2. 텍스트 랜더링
Hello, World!
콘솔 응용 프로그램의 기본은 Hello, World!
모바일 게임에선 어떻게 하지?

텍스트 랜더링
기본에 충실할 수 밖에 없다
• OpenGL 화면에 텍스트를 그려야 한다!
▪ 일반적으로 텍스트를 텍스처로 만든 다음, 텍스처를 그리는 방식 채택
▪ 문자열이 주어지면 한 자 씩 글자 텍스처를 얻어내 그릴 수 있음
• 폰트의 사용
▪ 각 문자를 어떻게 그릴지에 대한 정보를 담고 있는 것이 폰트
▪ 일반적으로 우리가 사용하는 TrueType 등의 폰트는 벡터 방식
➢ 사용자 화면 크기에 상관없이 깨끗한 폰트를 얻을 수 있다

FreeType
• 폰트 정보에서 개개 글씨의 비트맵 이미지를 얻을 수 있다
▪ 레퍼런스가 많고 적당히 쓰기 편한 라이브러리
• FreeType을 통해 문자 이미지 텍스처 생성
▪ 문자를 이미지로 변경한 다음, 텍스처 아틀라스에 구워두는 것이 표준적
▪ FreeType은 설정과 함께 문자를 주면 비트맵 이미지를 반환한다.
➢ 이 이미지를 텍스처 아틀라스에 올려 쓰면 되는 것
• GSUB 미지원: 태국어 등의 언어 지원 시 주의할 것

폰트 선택
FreeType을 무사히 올렸으면, 대부분의 폰트를 사용 가능하다
• 폰트의 종류에 따라서 서로 다른 글자의 모양을 가짐
▪ 아트 직군에서 결정하는 것이 바람직
▪ 라이선스나 용량 등을 고려하여 선택한다
• 구글/어도비의 Noto(본) 계열 폰트를 추천
▪ 여러 언어에 대해 무난한 수준의 글리프를 제공
▪ 대부분의 문자는 커버된다

문자열 조판
우리는 *NIX 콘솔을 만드는 것이 아니니, 읽을 법하게 & 읽기 편하게 & 예쁘게!
• 커닝: 내용에 따라 문자 간의 간격을 조정하는 것
▪ FreeType에서 지원하므로, 가능하면 맞춰 쓸 수 있도록 하면 좋다.
• 텍스트 블록 구성: 여러 줄 텍스트로 블록을 구성하게 될 경우
▪ 정렬 방식을 잘 선택해야 예쁘다: 특히 배분정렬을 고려한다
▪ 개행에 주의: 영어권 언어에는 하이픈 삽입, CJK는 단어 단위 개행
• 다국어 폰트 지원
▪ 한 문장에서 다국어 문자를 조판할 때는, Baseline과 크기 세팅을!

3. UI 시스템
엔진을 만든다면 아마도 다시 한 번 발명해야 할 바퀴
• UI는 시스템화 시켜서 사용하는 것이 좋다
▪ 공통적인 동작과 상호작용 로직을 가지는 부분이 많음
• 쓸 만한 기존 라이브러리가 존재하지 않음
▪ OpenGL 게임과 연동해 쓸 만한 추상적 UI 라이브러리를 찾기가 어려움
• 신경 써야 할 부분
▪ 터치 이벤트의 처리 방식: WPF의 체이닝/버블링이 참고할 만한 사례
▪ 레이아웃: 특히 Responsive를 지원한다면 반드시 고민해서 설계해야

UI 시스템의 데이터화
• 빠른 이터레이션을 위해선 가능한 많은 부분을 데이터화 해야 함
▪ 특히, 아티스트 분들이 조금씩 손대며 개선할 필요성이 큰 부분
• Mark Up Language 정도는 만들어서 사용하는 것을 추천
▪ Responsive가 지원되는 HTML의 예시에서 볼 수 있듯, 마크업 언어로
기술하는 방식이 꽤나 잘 맞는 도메인
▪ HTML처럼 tree 구조를 가지는 XML의 사용도 고려해볼만 함
▪ P:h Diver에서도 XML 기반 Description이라는 마크업 언어를 만들어 사용
➢ 이것도 재미있는 주제지만, 발표하자면 도메인 특화 언어 개발로 작은 세션 급이라ㅠ

4. 다국어 대응
• 게임 데이터 문자열로는 UTF-8 인코딩의 사용을 추천
▪ 여러 플랫폼 상호운용성이 뛰어나고, 큰 고민 없이 다국어 지원이 가능
▪ 성능 문제는 보통은 신경 쓰지 않아도 될 수준
▪ 플랫폼 상호 변환도 간편한 편
➢ Android의 jstring이나 iOS의 NSString도 UTF-8 문자열에서의 변환이 용이
➢ Windows에서는 UTF-16으로 변환해야 하는 경우가 종종 있다.
• 유저에게 출력되는 문자열은 테이블 – 키 구조로 관리
▪ 코드에 하드코딩 되는 문자열이 없어야 한다

5. 파일 시스템의 이용
• 번들 리소스의 이해
▪ iOS의 번들은 파일, Android의 번들은 압축된 어떤 데이터
➢ std::stream 등을 이용해 일관된 인터페이스를 제공할 수 있도록 하면 편하다
▪ 빌드 시, iOS 번들 리소스 – Android Asset은 파일 시스템 상 하나의
폴더에서 연동되게 하는게 편하다
• 저장소 클래스의 구분 사용
▪ 내부/외부 저장소, 임시/영구적 저장소, 클라우드 백업 여부를 고려

6. 몇 가지 소소한 팁
미리 챙겨 두면 코딩이 편해지는 팁!
• 공용 로그 함수부터 만들자!
▪ 로그는 디버깅의 기본
▪ 하나의 함수로 NSLog와 안드로이드 Log 등으로 출력되게 하는게 좋다
➢ Windows의 경우 OutputDebugString 함수의 이용을 고려
• 유틸리티 라이브러리 이용
▪ C/C++이므로 많은 라이브러리와 호환성을 가짐
▪ String Format, sqlite, JSON/XML 파서 등을 연동시켜 두면 편하다

게임이 출시된 시점에서 되돌아보는 엔진 및 게임 개발 총평
V. 결론

개발 일정 되돌아보기 (1)
3개 플랫폼 호환 OpenGL 어플리케이션 만들어서 Cube 띄우는데 까지 1개월 반
2015년 11월개발 시작
장비 세팅에 1주일, VS 올때까지 1주일, …
이런 식으로 좀 시간을 낭비하며 설계를 고민
2015년 12월 말Windows, Android 최초 빌드
2016년 1월 초iOS 최초 빌드
중간에 2주 정도 컨텐츠 툴 작업(C#)
OpenGL에서 Cube를 띄우는데 성공

중간에 타 프로젝트 지원이 있었지만, 어쨌든 4개월 내로 프로토타입 완성
2016년 1월 말PNG 텍스처 구현
ogg까지를 포함한 사운드 구현
2016년 2월 하순Primitive를 이용한 프로토타입

3월에 여러가지 개발을 통해, 게임 로직 및 UI 등이 모두 포함된 개발 빌드를 뽑아냄
2016년 3월 하순리소스를 적용시킨 개발 빌드
2016년 4월 중순텍스트 랜더링 기능 구현
Thanatos 빌드

비주얼은 좀 떨어져도(텍스처 등으로 연출 가능하므로) 기능적으로는 모두 동작하는 UI 시스템 구현
2016년 5월 2일UI 시스템이 들어간 개발 빌드
Elysion 빌드
UI 시스템 구현
AD님 합류
‘그래도 어느정도 비주얼적 구색은 갖추자’로 개발 방향 조정

하드코어한 UI 프레임워크 작업을 중간에 멈춰 둔 상태로 타 프로젝트 지원 이슈로 개발이 거의 홀딩
2016년 6월 3일신 비주얼의 게임 빌드
Roman 빌드
UI 시스템 구현

신 UI 시스템 구현 후 1개월, 게임 클라이언트 기능은 어느 정도 마무리 (2016년 10월 말)
2016년 10월 20일클라이언트 빌드
2016년 9월 중순Description 기반 신 UI 시스템 구현
2016년 10월 27일네트워크 및 비동기 기능 구현
이후, 타 부서 협업을 통한 서버 및 인프라 세팅,
로컬라이제이션, 스토어 및 결제 최적화, QA 등의
출시 준비 작업 수행

핵심 기능 구현까지 걸린 시간
이정도면 그래도 용인할 만한 수준?
작업 시간 기준 2달 반 조금 덜 걸렸음
이후 한 달 이내로 리소스를 적용시킨 핵심 구현 빌드가 나옴

엔진부터 개발해서 가능했던 것들
어떻게 보면 cocos2d-x 정도를 썼다면 (역시 삽질을 거쳐) 구현 가능했을지도 모르겠네요
• 비동기 처리
▪ 데이터 로딩, 네트워크 통신 등을 비동기 처리
➢ 데스티니 차일드 등에서와 같은 피할 수 없는 프레임 저하는 없음
▪ 단, Transition 애니메이션을 구현하지 못해 크게 표시가 나지는 않음
• UI 다듬기 및 텍스트 랜더링
▪ 단일 UI 리소스로 Responsive 하게 전 해상도 기기에 대응
▪ 스크롤 가능한 구성요소에 대한 최적화 등을 성공적으로 수행
▪ 대부분의 기기에서 텍스트는 깔끔하게 출력

빠른 기능 추가 가능: 탭틱 엔진
엔진을 만들었기에 가능했던 새로운 실험
• 탭틱 효과를 실험적으로 지원
▪ 10월, iPhone 7 구매 후 삘 받아 구현
➢ 토요일에 새 핸드폰 구매회사 앞 프리즈비
➢ 주말 간, 탭틱 기능을 체험하고
➢ 월요일에 출근하자 마자 하루만에 구현
• 이렇게 빠르게 구현할 수 있다니?
▪ 플랫폼단 코드를 바로 만질 수 있었기
때문

성능적 목표는?
엔진 개발을 결심했던 핵심 이유 중 하나
• 대강 달성한 것 같은데…
▪ iOS의 경우에는 어느 정도 달성한 것 같음
➢ 거의 눌렀을 때, ‘타격음‘이라 인식할 정도의 지연으로 효과음이 출력
▪ Android는 흐흠..?
➢ 성능이 좋은 최신 디바이스에서는 낮은 레이턴시 달성
➢ 일부 디바이스에서 싱크 밀림이나 랙 현상 보고
▪ 이게 다 개밥을 덜 먹어서…
➢ 제 폰이 아이폰에, 아이패드 소지자라 iOS로만 게임함ㅠ

만약 다른 엔진을 썼다면?
• Unity의 경우
▪ 최적화 여부를 장담할 수 없긴 함
• Moderato
▪ 사운드 시스템 지원이 사실 애매했던 상황…
➢ 아마도 지금이랑 비슷한 느낌으로 새로 구현하지 않았을까?
• Cocos2d-x
▪ 이쪽도 사운드 시스템은 조금 미묘했던 것으로 기억
역시 그렇게 잘 되었을 것 같지는 않음

사운드가 문제라면, 미들웨어를 썼다면
• CRI ADX2 for Smartphone
▪ 조금 가격이 있긴 해도, Android 기종별 지연을 맞춰줄 수 있는 부분은,
사실 소수 팀으로서는 달성하기 어려운 강점
개발 중간에 다소 고민했던 부분
「CRI ADX2」 for Smartphone - CRI Middleware Co., Ltd.
http://www.cri-mw.co.jp/product/smartphone/adx2/index.html

개발한 코드의 규모
아무래도 개발 경험의 공유라는 측면에서 가장 중요할지도 모르는 정보
LocMetrics
http://locmetrics.com/
LocMetrics이란 툴을 사용해 LoC 측정
LoC(Lines of Code)가 절대적인 정보는 아니지만,
어느 정도 프로젝트 규모에 대한 감을 전달하기에는 좋은 자료

개발한 코드의 규모
아무래도 개발 경험의 공유라는 측면에서 가장 중요할지도 모르는 정보
LocMetrics
http://locmetrics.com/
LocMetrics이란 툴을 사용해 LoC 측정
LoC(Lines of Code)가 절대적인 정보는 아니지만,
어느 정도 프로젝트 규모에 대한 감을 전달하기에는 좋은 자료
깜짝 놀랐는데, 라이브러리 코드가 상당수인 걸로 판명

개발한 코드의 LoC 규모
세부적으로 정리한 LoC 정보
• 엔진: 33,673
▪ 공용: 6,751
▪ 플랫폼: 9,661
▪ 모듈 구현: 17,261
• 게임: 138,230
▪ 사운드 시스템: 4,516
▪ UI 시스템: 37,950
▪ 태스크 시스템: 1,634
▪ 네트워크: 1,959
• 엔진성 코드: 총 79,732 Lines
• 프로젝트 코드: 총 171,903 Lines
충분한 완성도로 정리하지 않아
게임 레이어에 격리시켜 둔
엔진성 코드

개발 인력 규모
• 메인 프로그래머 1인 중심
▪ 지원 조직 및 차기 프로젝트 프로그래머로부터
플랫폼 특화 구현 관련 기술 지원을 받음
▪ 프로그래머 맨먼스는 14 정도로 표기
➢ 런칭 준비를 위한 엔지니어링 코스트 포함
➢ 타 프로젝트 지원으로 인한 손실이 생각보다 컸음
➢ 디렉터 겸업이라 이로 인한 작업 로스도 컸음
• 실질적으로는 프로그래머 1명, 10개월 정도?
역시 절대적인 기준이라기엔 애매하지만 맨먼스를…
김영수
노세노세팀
Director,
Programmer
A
Art Director
B
Planner,
Programmer
C
Artist
2015년 11월 O
12월 O
2016년 1월 △
2월 △
3월 O
4월 O
5월 O ▽
6월 O O
7월 △
8월 △ △
9월 O △
10월 O O
11월 △
12월 △
2017년 1월 O
2월 O △ ▽ ▽
3월 O △ O O
4월 △ △ △
△: 타 프로젝트 병행
▽: 중도 참여
P:h Diver 프로젝트 구성원 맨먼스 도표
개발 수행
타 프로젝트 진행
및
런칭 준비
게임 로직 개발을 포함해 이 정도 비용이면 소규모 팀이라도 투자를 고려해 볼 만한 비용?
직접적인 시간 투자도 그렇지만, 다른 일 하다가 돌아오는 모드 체인지 비용도orz

엔진 개발부터 시작해서 생긴 문제점
• 엔진 기능 구현은 무조건 병목이 된다
▪ 이게 구현되지 않으면 게임 기능이 나오질 않으니…
➢ 특히, 적은 프로그래머 등으로 인력적 병목이 겹치면 끔찍한 상황
• 예상보다는 늦어지게 되기 마련
▪ 어지간한 경지에 이르기까진 무조건 예상보다 오래 걸림
➢ 특히 플랫폼 문제 해결, 설계 이슈 등이 섞이면 더더욱
▪ 초보 관리자로서, 어쩌면 당연히 피해가지 못했을 실수
성적을 매기자면 A를 주긴 힘든 레벨

해결하기 어려운 호환성/최적화 문제
• 최종 사용자들에게 빌드가 나가면 별의 별 일이;;
▪ 다른 엔진들 또한 숱하게 겪었던 일…이지만
➢ 우리는 새로 시행착오를 겪고 고쳐야 할 부분이란 걸 각오
• 정석적인 방법으로 부딪힐 수 밖에 없음
▪ 충분한 테스트와 꼼꼼한 QA
▪ 언어/라이브러리 표준, 플랫폼에서 요구하는 규약을 지켜 코딩
➢ 문서 꼼꼼히 읽고 하라는 대로 하면 꽤 많은 지뢰를 피할 수 있음
➢ 가끔은 플랫폼 문서에도 지뢰가 있다는게 문제지만
Android의 지옥에 오신 것을 환영합니다

가장 고통스러웠던 문제점은
• 엔진 개발 이외의 작업이 함께 주어지면, 퍼포먼스 저하
▪ 엔진 레벨 개발은 꽤나 높은 집중도를 요하는 코어한 업무
➢ 다른 일을 처리하기 위한 컨텍스트 체인지 비용이 어마어마
➢ 심지어, 로직/비주얼 코드와도 성격이 다른 부분이 많음
• 작업에 집중할 수 있을 인력적 여유가 될 때 진행을 고려
▪ 시간적으로라도 엔진 개발 단계를 분리하는게 좋음
• 개발 디렉터/매니저랑은 겸업해서는 안 되는 업무

총평: '엔진 개발부터 시작한 모바일 인디 리듬게임 개발'
• 게임은 나옴
▪ iOS에서는 적절히 잘 돌아가고, Android도 돌아가게 만든 수준
➢ 개발 자원도 스펙 변경과 로스를 고려하면 낫아웃 후 출루 정도는 되는듯
▪ UI쪽 구현 퀄리티는 개인적으로는 만족스러운 수준
• 다시 선택하라면…?
▪ 역시 cocos2d-x와의 사이에서 고민하겠지만
▪ 같은 결과를 내놓을 가능성이 더 큰 것 같음
어쨌든 완성해서 출시는 했습니다
…정도?
http://www.dmm.com/netgame/social/-/gadgets/=/app_id=854854/

V. 결론
암호는 빅토리의 V
V. 결론

P:h Diver는 왜 자체 엔진 개발을 선택했는가?
개발 전, 이와 같은 개발 목표가 있었고

개발 진행에 필요한 조건과

다른 엔진을 사용할 때의 비용과 효과를 고려하여,
최종적으로 엔진 레벨 부터의 자체 개발을 선택

자체 엔진 개발의 장점
• 기술적인 요구사항을 원하는 수준까지 맞출 수 있음
▪ 새로운 플랫폼 기술(예: 탭틱 기능 등)도 즉시 적용 가능
• 자신/팀에게 맞는 개발 환경을 선택 가능
▪ IDE나 기술 스택을 필요에 맞춰 고를 수 있음
▪ 구조 및 개념 설계 등을 최적화할 수 있음
• 생각보다 구현 비용이 크지는 않음

자체 엔진 개발의 단점
• 파편화된 기기 최적화가 어려움
▪ 특히 통제가 약한 Android 환경에서, 최종 사용자에 맞춰 최적화가 힘듦
▪ 각 개발 도메인의 기술을 파고드는 최적화는 어려움
➢ 안되는 건 아닌데, 그만큼의 시간을 추가로 할당해야 함
• 개발 병목이 될 수 있음
▪ 게임 구현에 필요한 기능이 늦은 시점에 나오게 될 위험 존재
▪ 엔진 개발자는 컨텍스트 체인지 비용이 크다
• 팀 환경에 따라 툴이나 (타 직군)개발 환경의 부재가 아쉬울 수도

• 엔진 개발 케이스에 대한 간접 경험
▪ 어떤 과정을 거쳐 개발이 이루어졌으며, 비용은 어느 정도였는지
▪ 만약, 엔진 개발을 수행하게 된다면 어떤 것들을 준비하고 구현해야 하는지
• 저수준의 모바일 게임 개발에 대한 일종의 팁
▪ 모바일 플랫폼에서의 호환성 있는 구조를 설계할 때, 참고할 만한 지식
▪ 저수준의 모바일 개발에 있어서 피해야 할 삽질 케이스 정보
공유하고 싶었던 것들

Q&A
발표 중, Symflow를 통해 들어왔으나 시간 관계로 답변하지 못했던 질문을
NDC 사무국에서 전달받아 답변과 함께 수록
https://ndc.nexon.com

• Q. NextFloor는 "드래곤 플라이트"나 "데스티니 차일드" 같이 대중적으로 인하여 대중적으로 인지도가 있는 회사라고 생각합니다. 허나
P:h Diver를 강연의 제목과 같이 "인디 게임" 이라고 칭하였습니다만 흔히 알고 있는 "인디 게임"과의 정의와는 다르다고 생각합니다만,
"인디 게임"으로 칭한 이유를 알고 싶습니다.
• A. 이 부분에 대해 답변 드리려면, 먼저 ‘인디 게임’의 정의에 대한 논의가 필요할 것 같습니다.
가령 한국어 위키백과의 "인디 게임" 항목에서도https://ko.wikipedia.org/wiki/%EC%9D%B8%EB%94%94_%EA%B2%8C%EC%9E%84,
개략적으로 정의를 서술하면서 구체적 정의는 아직 없다는 점을 이야기하고 있습니다(2017년 5월 11일 현재, “어떤 게임이 인디 게임인지에 대한 구체적 정의는 아직 내려진 바가 없다.”).
사람에 따라 서로 다른 정의를 가지고 인디 게임에 대해 논하는 경우가 많지만,
• Flow를 제작하고 퍼블리셔 SCE에서 꽤나 큰 규모의 직접적인 투자를 받은 상태였던 thatgamecompany의 Journey도,
• 다른 사업 분야로 매출을 올리며 어느 정도 규모가 있던 회사인 Ustwo에서 제작된 Monument Valley도,
인디 게임이라 칭하는 경우가 있고(2017년 5월 11일 현재)
• 바람의나라 등의 게임을 이미 제작해 서비스하고 있었던 넥슨도 택티컬 커맨더스로 IGF에서 수상을 했던 경력이 있습니다.
이런 관점들에서 채택하고 있는, 광의의 인디 게임의 정의 하에서는 P:h Diver도 충분히 인디 게임으로 분류할 수 있다고 생각합니다.
Monument Valley (video game) - Wikipedia
https://en.wikipedia.org/wiki/Monument_Valley_(video_game)
Journey (2012 video game) - Wikipedia
thttps://en.wikipedia.org/wiki/Journey_(2012_video_game)

• (앞 페이지에서 이어짐)
NC소프트 문화재단의 지원을 받아 발간된 "게임 사전"에 있는 인디 게임에 대한 내용에는 기본적으로 인디 게임이 8가지의 특성을 지닌다고 서술되어 있습니다.
해당 특성들에 견주어 봐도 P:h Diver는 그 거의 대부분을 만족한다고 할 수 있으며, 이와 같이 보통 ‘인디 게임’이라 부르는 게임들이 지향하는 목표를 따라가며 개발-운영
중인 게임이라 디렉터로서 P:h Diver를 인디 게임으로 정체화하고 있습니다.
게임의 디렉터로서 개인적인 의견을 조금 더 첨부하자면,
저는 ‘인디 게임’이냐의 여부를, 자본의 지원을 받아 – 자본의 중요한 속성인 자기 증식을 목적으로 한다는 방향에 종사하기 위한 것을 주요한 목적으로 두고 제작되었는지의
여부로 판단하고자 하는 입장입니다.
앞서 페이지에서나 언론 매체를 통해서도 소개된 적 있는 바와 같이 넥스트플로어의 지하연구소는 매출보다는 도전을 통해 새로운 재미를 찾아가기 위해 설립된 브랜드이고,
P:h Diver 또한 회사의 매출에 기여하기보다는 무언가 다른 시도를 해볼 수 있는 게임이라는 목적을 갖고 제작되었습니다.
그래서 자본의, 자본적 속성으로부터 독립적일 수 있는 게임이라 생각하여, P:h Diver를 인디 게임이라 판단하게 된 것입니다.

• Q. 리듬게임은 아무래도 다양한 곡 (작곡가)이 필요한데 프로그래머로서 1인 개발을 시작했을 때의 애로사항이 있었나요?
• A. 곡에 대해서는 기본적으로 최대한 다양한 곡에 대해 수록의 가능성을 열어 두는 게임을 만들고 싶다는 생각을 가지고 있었고,
여러 작곡가 분들께의 의뢰 또한 함께 고려하고 있었습니다. 이전에 언급한 바와 같이 외주 관리 등의 업무를 진행하면서 엔진 코어
개발작업을 동시에 하는 부분에서 작업 컨텍스트 체인지가 조금 힘들기는 했지만, 이 외의 큰 문제는 없었던 것 같습니다.
• Q.리듬게임을 1인 개발함으로써 많은 어려움이 있을테고 또한 이 소규모 인원으로서 QA가 어려웠을텐데 레벨 테스트나 싱크
등등의 리듬게임에 대한 테스트는 어떻게 해결하였는가요?
• A.풀타임 작업자 1인 규모의 팀으로 개발을 시작하기는 했지만, 순수 1인 개발 체제로 굳이 개발을 진행할 생각은 없었고 가능하면 많은 분들의 도움을
받으려고 했습니다. 게임 내 크레딧에도 표기하였듯, 채보 레벨 디자인은 외주 제작자 분들의 도움을 얻어 진행하였고, 이에 대한 테스트나 싱크 등은 함께
열심히, 꾸준히 플레이하면서(개밥먹기로도 불리는 과정이죠) 개선을 할 수 있도록 노력했습니다.

• Q. 최근 많은 리듬게임들이 동인계 서브컬처에 활동하는 작곡가나 보컬분들을 많이 라인업으로 사용하는 경우가 많습니다. 또 P:h
Diver로 동인계 서브컬처 기업인 "스퀘어뮤직"과 같이 협력을 한 것으로도 알려져 있습니다. 이와 같이 국내 리듬게임에선 서브컬처
문화가 중요하다고 생각합니다만 NextFloor가 생각하는 서브컬처의 중요성은 어느 정도인지 궁금합니다.
• A. NextFloor의 공식 입장을 이 자리에서 발표자 개인이 말씀드릴 수는 없지만, P:h Diver의 개발팀에서는 개발 및 컨텐츠 구성에
있어 서브컬처로 흔히 분류되는 계열의 문화와 컨텐츠 또한 상당히 중요하게 인식하고 있으며, 언급하신 SQUARE MUSIQ 역시 중요한
협력 관계를 맺고 있는 분들이라 생각하고 있습니다.
• Q.Cocos를 사용하고 사운드는 외부라이브러리를 썼으면 좀 더 빨리 개발하지 않았을까요
• A.개발에 시간을 많이 들인 부분이 주로 cocos에서 제공하지 않았던 기능들(UI, 3D 기반의 게임 구성 등)이라 시간 상 큰 차이는 없었을 것이라 판단하고
있습니다. 차이가 난다면 2~3주 정도? 사운드 외부 라이브러리의 사용도 오히려 시간적인 측면에서 보다는 (특히 안드로이드에서의) 완성도 측면에서
고려해볼 만 했다고 생각하고 있습니다. 사운드 라이브러리는 cocos2d-x 뿐 아니라 저희 엔진에도 적용할 수 있는 부분이라, 엔진 사용에서의 차이에
해당하는 부분은 아닐 것 같네요.

• 아마 동시간대 다른 세션에 대한 질문으로 추정됩니다
▪ 저도 듣고 싶은 세션들 많았는데, 흑흑ㅠ
➢ 특히 Kailua 공개되었다던 내가 만든 언어의 개발환경 세션orz
And two more questions…
https://ndc.nexon.com

[NDC17] Protocol:hyperspace Diver 개발 포스트모템

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a [NDC17] Protocol:hyperspace Diver 개발 포스트모템

Similar a [NDC17] Protocol:hyperspace Diver 개발 포스트모템 (20)

[NDC17] Protocol:hyperspace Diver 개발 포스트모템