[NDC 2014] 유저 수만큼 다양한 섬을 만들자
<야생의>의 절차적인 섬 생성 기법
발표장에서 시간이 없어서 답변드리지 못했던 Q&A 내용들을 뒷 부분에 추가하였습니다.
GIF 가 포함된 부분은 잘 나오지 않으므로 궁금하시면 직접 다운로드 받아서 보시기 바랍니다. - http://goo.gl/UUKmjL
NDC 2015. 한 그루 한 그루 심지 않아도 돼요. 생태학에 기반한 [야생의 땅: 듀랑고]의 절차적 생성 생태계Imseong KangNDC 2015. 한 그루 한 그루 심지 않아도 돼요. 생태학에 기반한 [야생의 땅: 듀랑고]의 절차적 생성 생태계.
빌드별로 PDF를 만들었더니 300장 넘게 나오지만 실제 슬라이드는 130여 장입니다.
NDC 2014 Beyond Code: <야생의 땅:듀랑고>의 좌충우돌 개발 과정 - 프로그래머가 챙겨주는 또 다른 개발자 사용 설명서영준 박(과거 NDC 2014에서 했던 강연 자료입니다. 발표 당시엔 공유에 힘든 부분이 있어 게임 출시 이후에 공개되는 점 양해를 드립니다.)
프로그래머의 시각에서 게임 개발 프로세스를 보면, 여러 에이전트 들이 특정한 목적을 가지고 동시에 정보를 처리하는 일련의 로직 조합이라고 생각해볼 수 있습니다. 테크니컬 하게 정보 처리 로직을 작성하고 그 효율을 탐구하는 업무가 바로 프로그래머의 주요 업무 중 하나입니다. 그렇다면 프로그래머의 시각으로 개발 프로세스를 접근해 보면 새로운 인사이트를 얻는 부분이 있지 않을까요?
<야생의 땅:듀랑고>에는 새로움이 가득한 도전이 많이 있습니다. 이러한 새로움을 향한 도전은, 비단 게임 피처 뿐만 아니라 개발 프로세스에서도 마찬가지로 녹아 있습니다. 실제로 개발 프로세스 관리에 수많은 시도들이 있었고 지금도 계속 되고 있습니다.
그간 시도했던 여러 개발 프로세스에 대한 소개를 하고, 그것을 활용한 피처 개발, 프로토타이핑 사례 등을 공유하고자 합니다.
NDC 2017 하재승 NEXON ZERO (넥슨 제로) 점검없이 실시간으로 코드 수정 및 게임 정보 수집하기Jaeseung HaNDC 2017 발표 슬라이드
시연 영상 링크: https://youtu.be/e9Tv3jkmqKk
게임 내 정보를 추가 구현이나 패치 없이 실시간으로 수집할 수 있다면 어떨까요? 이런 아이디어를 실제로 가능하게 구현한 NEXON ZERO 발표 슬라이드 입니다.
NDC 11 자이언트 서버의 비밀승명 양2011 NDC(Nexon Developers Conference)에서 발표한 마비노기 영웅전(미국명 Vindictus)의 자이언트 서버 아키텍처에 대한 슬라이드입니다. 게임 서버의 분산 서비스 아키텍처를 바닥부터 만들어낸 과정과 결과에 대한 내용을 담고 있습니다.
KGC 2014: 분산 게임 서버 구조론Hyunjik Bae분산 서버 설계는 원리 이해가 중요하다. 이를 모르고서는 잘못된 설계로 인해 고생은 고생대로 하고 결과는 결과대로 나쁠 수 있다. 본 강연에서는 분산 게임 서버 구조를 짜기 전에 반드시 이해해야 하는 원리를 설명한다.
NDC16 - 화성에서 온 사업팀 금성에서 온 개발팀 : 성공적인 라이브 서비스를 위해 필요한 것들Young Keun ChoeNexon Developers Conference 2016 에서 발표한 자료입니다.
* 발표자 소개 *
<플레로>에서 <에브리타운>의 개발 및 라이브 서비스를 담당하고 있는 경력 12년 차 기획자 겸 PD입니다. NDC 2014 에서 <엄마와>으로 발표한 이력이 있으며, 이후로 약 2년간 -론칭 후 기간으로는 약 3년간- 라이브 서비스를 지속시킨 경험으로 얻은 (NDC 2014에서 발표한 내용과는 또 다른) 것들을 NDC 2016을 통해 공유하고자 합니다.
* 세션소개 *
우리는 대개 '론칭'을 목표로 한 게임 개발/사업에만 집중합니다. 그러나 매우 잘 만든 게임들이 성공적인 론칭 이후 서비스 단계에서의 미스로 기대만큼의 성적을 거두지 못하는 경우가 종종 발생하는데, 이는 '론칭 이전의 게임 개발'과 '론칭 이후의 게임 개발'이 개념적으로 전혀 다르다는 것을 증명합니다. 론칭 이후의 게임 개발, 즉 '라이브 서비스'는 아무리 개발 부서의 실력이 뛰어나다 하더라도 개발 外 부서와의 시너지가 없다면 성공적으로 이어가기가 매우 어려우며, 그중에서도 특히 사업부서와 개발부서의 협업에 대한 중요성은 아무리 강조해도 지나치지 않습니다. 하지만 남녀관계가 흔히 '서로 다른 별에서 온 사람들'로 비유되듯, 두 부서 사이에는 많은 애로사항이 있으며 심지어 서로 간의 갈등의 골이 깊은 경우도 있습니다. 이 세션에서는 약 3년이라는 짧지 않은 시간 동안 비교적 성공적인 라이브 서비스를 지속해 온 '에브리타운 for kakao'의 사례를 통해, 무탈한 라이브 서비스를 위한 개발부서와 사업부서 간의 협업 방식과 그 ѫ성, 그리고 시너지를 내기 위한 노하우 등을 공유하고자 합니다.
[NDC14] 모바일 게임의 다음 혁신 - 야생의 땅 듀랑고의 계산 프로세스 중심 게임 디자인승명 양NDC14에서 발표한 야생의 땅 듀랑고의 계산 프로세스 중심 게임 디자인 발표 슬라이드의 공개용 버전입니다.
현장에서는 시간 관계상 진행하지 못한 QnA를 대신하여, 실시간 QnA 페이지에 올라왔던 몇 가지 질문에 대한 답변을 슬라이드 맨 끝에 추가했습니다.
Ndc2014 시즌 2 : 멀티쓰레드 프로그래밍이 왜 이리 힘드나요? (Lock-free에서 Transactional Memory까지)내훈 정Easy to understand review of nature of the Lock-free algorithm.
작년에 KGC2013에서 했던 내용의 업데이트 버전임. C++11에 맞추어 업데이트 되었음.
NDC 2017 하재승 NEXON ZERO (넥슨 제로) 점검없이 실시간으로 코드 수정 및 게임 정보 수집하기Jaeseung HaNDC 2017 발표 슬라이드
시연 영상 링크: https://youtu.be/e9Tv3jkmqKk
게임 내 정보를 추가 구현이나 패치 없이 실시간으로 수집할 수 있다면 어떨까요? 이런 아이디어를 실제로 가능하게 구현한 NEXON ZERO 발표 슬라이드 입니다.
NDC 11 자이언트 서버의 비밀승명 양2011 NDC(Nexon Developers Conference)에서 발표한 마비노기 영웅전(미국명 Vindictus)의 자이언트 서버 아키텍처에 대한 슬라이드입니다. 게임 서버의 분산 서비스 아키텍처를 바닥부터 만들어낸 과정과 결과에 대한 내용을 담고 있습니다.
KGC 2014: 분산 게임 서버 구조론Hyunjik Bae분산 서버 설계는 원리 이해가 중요하다. 이를 모르고서는 잘못된 설계로 인해 고생은 고생대로 하고 결과는 결과대로 나쁠 수 있다. 본 강연에서는 분산 게임 서버 구조를 짜기 전에 반드시 이해해야 하는 원리를 설명한다.
NDC16 - 화성에서 온 사업팀 금성에서 온 개발팀 : 성공적인 라이브 서비스를 위해 필요한 것들Young Keun ChoeNexon Developers Conference 2016 에서 발표한 자료입니다.
* 발표자 소개 *
<플레로>에서 <에브리타운>의 개발 및 라이브 서비스를 담당하고 있는 경력 12년 차 기획자 겸 PD입니다. NDC 2014 에서 <엄마와>으로 발표한 이력이 있으며, 이후로 약 2년간 -론칭 후 기간으로는 약 3년간- 라이브 서비스를 지속시킨 경험으로 얻은 (NDC 2014에서 발표한 내용과는 또 다른) 것들을 NDC 2016을 통해 공유하고자 합니다.
* 세션소개 *
우리는 대개 '론칭'을 목표로 한 게임 개발/사업에만 집중합니다. 그러나 매우 잘 만든 게임들이 성공적인 론칭 이후 서비스 단계에서의 미스로 기대만큼의 성적을 거두지 못하는 경우가 종종 발생하는데, 이는 '론칭 이전의 게임 개발'과 '론칭 이후의 게임 개발'이 개념적으로 전혀 다르다는 것을 증명합니다. 론칭 이후의 게임 개발, 즉 '라이브 서비스'는 아무리 개발 부서의 실력이 뛰어나다 하더라도 개발 外 부서와의 시너지가 없다면 성공적으로 이어가기가 매우 어려우며, 그중에서도 특히 사업부서와 개발부서의 협업에 대한 중요성은 아무리 강조해도 지나치지 않습니다. 하지만 남녀관계가 흔히 '서로 다른 별에서 온 사람들'로 비유되듯, 두 부서 사이에는 많은 애로사항이 있으며 심지어 서로 간의 갈등의 골이 깊은 경우도 있습니다. 이 세션에서는 약 3년이라는 짧지 않은 시간 동안 비교적 성공적인 라이브 서비스를 지속해 온 '에브리타운 for kakao'의 사례를 통해, 무탈한 라이브 서비스를 위한 개발부서와 사업부서 간의 협업 방식과 그 ѫ성, 그리고 시너지를 내기 위한 노하우 등을 공유하고자 합니다.
[NDC14] 모바일 게임의 다음 혁신 - 야생의 땅 듀랑고의 계산 프로세스 중심 게임 디자인승명 양NDC14에서 발표한 야생의 땅 듀랑고의 계산 프로세스 중심 게임 디자인 발표 슬라이드의 공개용 버전입니다.
현장에서는 시간 관계상 진행하지 못한 QnA를 대신하여, 실시간 QnA 페이지에 올라왔던 몇 가지 질문에 대한 답변을 슬라이드 맨 끝에 추가했습니다.
Ndc2014 시즌 2 : 멀티쓰레드 프로그래밍이 왜 이리 힘드나요? (Lock-free에서 Transactional Memory까지)내훈 정Easy to understand review of nature of the Lock-free algorithm.
작년에 KGC2013에서 했던 내용의 업데이트 버전임. C++11에 맞추어 업데이트 되었음.
NDC14 모바일 게임서비스를 위한 사설 클라우드 구축/운영 분투기Jinuk Kim모바일 게임 서비스를 위한 사설 클라우드를 개발/운영/디버깅 하면서 얻은 점들을 공유한다.
일반적인 하드웨어랑 오픈소스소프트웨어를 써서 사설 클라우드를 만들고 게임을 런치하면서 고생한 부분, 문제되었던 부분들을 짚어본다.
NDC 2014 [48시간 만에 게임 만들기: '수줍은 메두사' 포스트모템과 게임 개발의 왕도]Imseong KangNDC 2014에서 발표한 슬라이드를 올립니다. 그외 정보들은 아래 링크를 참고해주세요.
* 게임 다운로드 페이지(윈도 전용)
http://globalgamejam.org/2014/games/peeping-medusa
* 게임 플레이 동영상
https://www.youtube.com/watch?v=gzESlDtHqhA
* 짧게 정리한 포스트모템 글
http://imseongkang.wordpress.com/2014/01/29/peepingmedusapostmortem/
* 정제되지 않은 44시간의 개발 기록
http://imseongkang.wordpress.com/2014/01/27/peepingmedusa/
[ NDC 14 ] 가죽 장화를 먹게 해주세요 - [ 야생의 땅 : 듀랑고 ] 의 자유도 높은 아이템 시스템 디자인 Jungsoo Lee[ NDC 14 ] 가죽 장화를 먹게 해주세요 - [ 야생의 땅 : 듀랑고 ] 의 자유도 높은 아이템 시스템 디자인
따로 발표용 스크립트가 없어 PPT에 부연설명 및 사진 등을 추가한 버전입니다.
문의 사항이 있을 경우 lune89@nexon.co.kr로 연락주세요.
바라는 대로 라이터가 쓰게 만드는 시나리오 디렉팅 기법Lee Sangkyoon (Kay)NDC2014, KGC2014에서 발표한 슬라이드입니다.
시나리오 "라이팅"에 대한 내용이 아니고, 시나리오 "디렉팅"에 대한 내용이라 기본적으로는 PD, 디렉터, 라이터를 강연 대상으로 하고 작성했다는 점 참고로 말씀드립니다.
[NDC 2014] 시나리오라이터의 과거와 현재, 그리고 미래 Hwang Sang Hun뛰어난 게임 시나리오란 무엇인가, MMORPG가 없는 상황에서 시나리오 라이터는 무엇을 해야 할 것인가, 그리고 궁극적으로 게임에 시나리오가 들어가는 이유는 무엇인가에 대한 슬라이드.
[NDC 14] '미쿠미쿠하게 해줄게' - MMD MV 제작 사례와 매력적인 캐릭터 애니메이션Nexon KoreaNDC14에서 발표한 내용입니다.
취미작업을 중심으로 매력적인 캐릭터 애니메이션은 어떻게 하면 좋을까 고민했던 내용이며,
설명이 미흡할만한 부분을 공개버전엔 조금 추가했습니다.
본 발표 내용은 소속된 조직과는 관련 없습니다.
* 포함된 영상에 소리가 있습니다. 볼륨 조심하세요.
[NDC14] 타임라인 던전 포스트모템 - 스마트폰 시대의 머드게임과 SNSYounger Jo머드게임은 그래픽 기술의 발전과 함께 역사속으로 사라졌습니다. 시커먼 화면 속의 단 몇줄의 텍스트가 만들어내던 상상의 즐거움은 더 이상은 불가능한 것일까요? 본 세션은 트위터의 사용자 경험에서 착안하여 개발된 모바일 RPG "타임라인 던전"의 개발과정을 소개하고 이를 통해 머드게임이 어떤 방식으로 스마트폰에서 재창조될 수 있는지 살펴봅니다.
NDC14 - 엄마와 누나가 게임을 즐기는 법 : [에브리타운 for kakao] 서비스 포스트 모텀Young Keun ChoeNexon Developers Conference 2014 에서 발표한 자료입니다. 약간의 오탈자 수정 후 공유합니다.
* 발표자 소개 *
現 [에브리타운 for kakao] PD. [에브리팜], [에브리타운 온라인] 등 에브리타운 시리즈를 기획해 온 경력 9년차 기획자.
* 세션소개 *
2013년 3월 5일 런칭하여 2013년 5월 5일까지, 약 1년 2개월 동안 구글플레이 매출 순위 기준, 4위~27위에서 한 번도 벗어나지 않으면서 SNG 분야 매출 기록을 현재진행형으로 경신해 나가고 있는 [에브리타운 for kakao] 의 서비스 포스트모텀 입니다. '게이머'임이 틀림없는 '게임 기획자'가 '논게이머'인 유저들, 즉 우리의 엄마, 이모, 누나들을 만나면서 겪었던 시행착오 및 그에 필요한 성공적인 운영전략 등을 공개할 예정입니다. 비슷한 컨셉의 유저층을 타겟으로 하는 게임을 기획/개발 중인 현업인과 사업 및 마케팅 담당자들에게 추천합니다.
21. 어떻게 만드나
• 바닥부터 만들려니 (...)
• 그때 디렉터 님이 공유해주신 링크
http://www-cs-students.stanford.edu/~amitp/game-
programming/polygon-map-generation/
이거다!olleh!
22. Polygon Map Generation
• 원하는 기능이 전부 여기에...
• Flash로 된 오픈 소스제공
(MIT License)
• 친절한 알고리즘 설명
이것부터
알아 봅시다
23. 일단 기본 용어 정의
• Node : 다각형
• Edge : 다각형 모서리
• Corner : 다각형 꼭짓점
• Center : 다각형 중심점
Corner
Node
Edge
Center
24. 다각형 데이터 구조 - Edge
• Edge
• Corner 1
• Corner 2
25. • Node
• List of Nodes
• List of Corners
• List of Edges
다각형 데이터 구조 - Node
Node
Nodes
Node
Corners
Node
Edges
26. • Corner
• List of Nodes
• List of Corners
• List of Edges
다각형 데이터 구조 - Corner
Node
Node
Node
Corners Edges
27. 시작: 다각형 데이터(Node) 생성
• 섬을 표현하기 위한 가장 기초적인 데이터
• 다양한 형태의 다각형(Node) 데이터 필요
• 다각형 생성(Node)을 위해선?
• 사각형 공간 내에 무작위 점의 집합 생성
• 해당 점들을 통해서 Voronoi Diagram 생성
• Voronoi Diagram?
28. Voronoi Diagram
• 주어진 점들로부터 거리에 따른 영역 분할
• 각 점들이 가지고 있는 일종의 영향력
• 무작위 점의 집합을 이용해서 다양한 모습의
다각형(Node) 생성 가능
• 생성된 다각형의 편차가 너무 큰 점이 문제
29. Lloyd’s algorithm
• 각 다각형의 중심점(Node Center)을 인자로 사용
Voronoi Diagram 다시 생성
• 적당히 균일한 상태가 될 때까지 반복
(15회 반복)
해당 중심점들을 이용해서
Voronoi Diagram 다시 생성
33. 기본 섬 모양 생성
• 모든 Corner 의 ‘땅’ / ‘물’ 여부 결정
• Corner의 위치에 대응되는 Noise값 사용
• 특정 값 이상이면 ‘땅’ / 이하이면 ‘물’
• 모든 Node의 ‘땅’/ ‘물’ 결정
• Node를 구성하는 Corner들의 ‘물’ 비율에
따라서 ‘땅’ / ‘물’ 결정
물 물
Corner
땅 물
35. 바다 생성
• 일단 사각형 가장자리에 있는 Node를 ‘바다’로 설정
• ‘바다’ Node의 이웃 Node로 전파
• 이웃 Node가 ‘물’일 경우 : ‘바다’ Node, 반복
36. 해변 생성
• ‘해변’ Node 설정
• 주변 Node의 일부가 ‘바다’ / 일부가 ‘땅’ 일 때
37. 섬의 높이 설정
• 만들려는 섬의 모습
• 섬의 중심이 가장 높고 가장자리로 갈수록 낮아짐
• 섬의 높이 = 해변으로부터의 거리에 비례
• 일단 가장자리에 있는 Corner 부터 높이 설정
• 이웃한 Corner 로 이동하면서 높이 증가시킴
• 이웃한 Corner가 ‘땅’일 때만 높이 값 증가
• 호수를 주위에서 가장 낮은 지역으로 만들기 위해서
해변 해변중심
Hanauma bay
40. 섬의 높이 재분배
• 기존 높이값을 우리가 원하는 분포로 설정
• 기존 값은 어느 정도 경향은 있지만 Random
• Corner를 높이 순서대로 정렬
• 순서에 따라서 0~1 사이의 값을 설정
• 제일 높은 곳은 1, 중간 높이는 0.5, 가장 낮은 곳은 0
• 적당한 분포 함수를 적용해서 새로운 높이 할당
• 새로운 높이 = f( k / n )
• k 는 정렬 순서, n 은 전체 Corner 개수
44. 강의 생성
• 물의 성질: 높은 곳에서 낮은 곳으로 흐름
• 산 정상에서 해안가로
• Corner의 높이 활용
• 모든 Corner가 인접한 가장 낮은 Corner를 알고 있음
• 가장 낮은 Corner를 따라가면 결국 해안가
www.scienceall.com
46. 강의 생성
• 적당한 개수의 강 시작지점 선택
• 일정 높이 이상
• 여러 물줄기가 만나는 경우 강의 폭 증가
• 근처에 호수가 있을 경우 자연스럽게 호수 쪽으로
• 호수를 주위에서 가장 낮은 지역으로 처리했음
48. 습도 설정
• 생물 군계 데이터를 생성 하는데 필요
• 기후 시뮬레이션?
• 복잡한 계산 없이 그냥 강,호수 데이터 이용
• 강, 호수로부터의 거리에 따라서 상대 습도 값 설정
• 강, 호수 같이 ‘물’ 속성을 가진 Corner에 기본 습도 값 k 할당
• 주위 Corner 로 1보다 작은 값을 곱해서 전달 (ex: k * 0.9)
• 반복!
Fig1 in Krahn 2004
50. 습도 재분배
• 강 / 호수의 모양에 따라서 습도의 총 합이 달라짐
• 섬마다 총 습도의 합은 동일하게 유지되길 원함
• 모든 Corner를 습도 값으로 정렬
• 높이 재분배 할 때랑 같은 방식
• 순서에 따라 Corner에 1~0 사이의 습도 값 재 설정
• 제일 습도가 높았던 곳은 1, 중간은 0.5, 가장 낮았던 곳은 0
• 따로 분포 함수는 적용하지 않았음
• 그냥 f(x) = x 인 함수
이 부분의 합이 섬마다 달라짐
52. 생물 군계 설정
• 습도 / 온도에 따른 생물 군계
• 다양한 동/식물 표현에 필요
• 온도는 높이를 이용해서 계산
• 높은 곳일수록 저온
• 이렇게 작은 섬에 저런 데이터가?
• 게임적 허용 (...)
57. 여기까지는 전부 사이트에 있는 내용
• 짤방은 한땀 한땀 제가 만들긴 했지만...
• 설명이 부족하셨다면 사이트 방문을 권해드립니다
• 여기서 다루지 않는 몇 가지 추가사항
• Edge noise
• Lava, Road 생성
• 필요하시면 역시 사이트 방문을 추천
59. Windows Form을 통한 툴 제작
• C#으로 쾌속 개발!
• 알고리즘 자체는 Flash code 가 제공되므로 간단
• Voronoi Diagram / Noise 생성
• 외부 라이브러리로 해결
• Rendering이 문제
• GDI+ 로 어떻게든 해결
• 그래도 힘든 건 Per Pixel 연산
Youtube: Top Ten Fastest Animals In The World
61. Fortune’s Voronoi algorithm
• Code Project 에 있는 C#용 Library 사용
• Fortune’s Voronoi algorithm implemented in C#
• 간편하게 사용 가능
• List<Vector> 로 입력 데이터 전달
• List <Edge> , Dictionary<Vector, Node> 로 데이터 출력
• Corner 데이터는 Edge / Node 모음을 통해서 생성
• MPL License
• 원본 코드를 고칠 일은 없음
• 공개 배포 되는 프로그램도 아님
62. Noise 생성
• 섬 생성 및 데이터 출력에 고품질의 Noise 필요
• 섬의 모양 생성
• 생물 군계 데이터
• LibNoise for .Net 이용
• A portable, open-source, coherent noise-generating library
• 고품질의 다양한 Noise 지원
• libnoisedotnet.codeplex.com
• MIT License
63. LibNoise for .Net
• 다양한 Noise 생성 방법 지원
• 3D Gradient Noise (Coherent Noise)
Coherent Non-Coherent
Perlin Ridged Billow Turbulence
64. LibNoise for .Net
• Fractal Noise 생성 지원
• 자연적으로 많이 보이는 패턴과 유사
Freq=5 Freq=10 Freq=20
Freq=40 Freq=80
위 Noise를 전부 더해줌
(값은 고주파로 갈수록 작게)
65. GDI+ Rendering
• 원하는 사이즈의 Bitmap 생성
• Graphics 객체를 이용해서 Node / Edge Rendering
• Bitmap 에서 Graphics 객체 가져오기
Graphics canvas = Graphics.FromImage(srcBMP);
• 기본 바탕색 설정
canvas.FillRectangle(clearBrush, 0, 0, srcWidth, srcHeight);
68. Heightmap Rendering
• 기존 Node Rendering 방식 사용 불가
• Node 윤곽이 그대로 보임
• 각 Corner에 저장된 높이 값을 이용한 Gradient Rendering 필요
69. Gradient Rendering
• Drawing2D.PathGradientBrush 사용
• PathGradientBrush(PointF[] points)
• gradientBrush.CenterPoint
• gradientBrush.CenterColor
• Node가 가지고 있는 높이 값 사용
• gradientBrush.SurroundColors
• Corners가 가지고 있는 높이 값 사용
• Graphics.FillPolygon(gradientBrush, pointArray)
Brush 생성시 Node에 속한
Corners 값 넣어줌
Corners
Center
70. Pixel Operation
• Bitmap을 Pixel 단위로 Read/Write 필요
• 최종 결과물에 Noise 적용, Mask 생성
• GetPixel, SetPixel 함수 사용 불가
• 믿을 수 없을 만큼 느림
• LockBits / unsafe block 이용
Rectangle rect = new Rectangle(0, 0, width, height);
BitmapData data = bmp.LockBits(rect, ImageLockMode. ReadWrite, PixelFormat.Format32bppPArgb);
unsafe
{
byte* origin = (byte*)data.Scan0.ToPointer();
}
bmp.UnlockBits(data);
71. 그 외 환경설정 작업
• 게임에 쓰일 섬의 적절한 Preset을 찾기 위해서 필요
• 추후 Random Seed만 바꿔서 섬 대량 생산
• Random Seed 값 설정
• 섬의 크기 설정
• 점의 개수 설정
• 강의 개수/넓이 설정
• Noise 생성 옵션
72. 초기 모습
• 개발 초기 결과물
• 512x512, 점 10000개
• 섬이 좀...
• 너무 고주파 Noise 사용
• Noise 설정 변경 필요
74. Node 밀도 증가
• 게임에는 좀 더 디테일 한 모습 필요
• Node 형태 안 보이게
• 점 40000개 적용
• 밀도 2배
• 문제발생
의도했던 디테일은 증가하지 않고
오히려 전체적인 모양만 단순해짐
75. 고밀도 Node 문제
• 고밀도 Node 사이즈 소형화
• Node 배치에 따른 변화 량이 작아짐
• 섬의 외곽선이 점점 단순화
• Node 단위 작업
• 해변이 점점 짧아짐
• 생물군계 분포
• 점점 패턴이 보임
• Random 필요!
76. 해변이 짧아짐
• 일단 첫 번째 해변 Node 계산
• 그 후 해변 Node 주위의 Node를
해변으로 변경
• Node 밀도에 비례해서 반복
• 점 개수의 제곱근에 비례
• 10000개 1번
• 40000개 2번
77. 섬의 외곽선 단순화
• 저밀도 섬의 모양 미리 계산
• ‘땅’ / ‘물’ 여부를 Mask Map으로 저장
• 고밀도에서 앞의 Mask Map을 읽어서 ‘땅’ / ‘물’ 결정
• 저밀도에서 큰 폭의 변화 그대로 유지
• 저주파 데이터 + 고주파 데이터로 Detail : 일종의 Fractal
‘땅’ / ‘물’ 결정
Mask Map
85. 추가 구현 내용
• 지금까진 주로 아티스트의 의도만 반영
• 일단 보기 좋게 만들자
• 게임 디자이너의 의도 역시 반영 되어야 한다!
• 디자인 요구사항
• 생성되는 땅의 면적 조절 기능
• 생물 군계의 비율 조절 기능
• 자투리 섬 생성 안되게
• 봉우리 개수 조절 가능하게
86. 생성되는 땅의 면적 조절기능
• Noise에 따라 달라지는 땅의 면적
• 섬마다 땅의 면적이 너무 차이 나면 문제
• 땅의 총 면적이 원하는 값이 되도록
“기준 값”수정
물 물
Corner
이쯤에서 섬 생성 로직 다시 리뷰
Corner의 위치에 해당하는 Noise값을 이용
“기준 값” 이상이면 ‘땅’ / 이하이면 ‘물’
87. 생성되는 땅의 면적 조절기능
• 알맞은 “기준 값” 을 찾기 위한 방법
• 땅의 면적은 기준 값의 크기에 따라 정렬
• 기준 값 땅의 면적
Binary Search
• 요구 면적에 근접할 때 까지 반복
• 땅의 면적 : 모든 ‘땅’ Node 면적의 합
• 그냥 모든 ‘땅’ Node 개수의 합으로 근사
Best
기준 값
땅의 면적
기준 값
요구
면적
88. • 땅의 비율이 55% 정도가
되도록 기준 값 자동 조절
• 섬모양의 변화는 유지
• 땅의 면적은 비슷하게
• 고정된 기준 값
• 섬마다 땅의 면적 차이 발생
Before
After
89. 생물 군계의 비율 설정
결국 원화는 비율이 되도록 “기준 값“
(온도 A,B / 습도 I,K,M) 을 수정!
• 생성되는 생물 군계의 비율은 Random = 그때 그때 달라요!
• Seed 가 변해도 기획자가 설정한 생물 군계 비율은 유지되게!
생물 군계 설정 방법
if(온도 < A)
if(습도 > I) = 설원
else = 툰드라
else if(온도 < B) = 온대림
else
if(습도 > K ) = 열대림
else if(습도 > M) = 초원
else = 사막
90. 생물 군계의 비율 설정
• 땅의 면적 조절 기능과 거의 비슷함
• (설원 + 툰드라) / 나머지는 온도 A로 구분
• 온도 A를 Binary search
• 계산된 온도 A값을 확정
• 설원 / 툰드라를 구분하는 습도 I 계산
• 동일하게 B, K,M 을 계산
• 온도 B = 온대림 / (열대림 + 초원 +사막)
• 습도 K = 열대림 / (초원 + 사막)
• 습도 M = 초원 / 사막
온도 A
(설원 + 툰드라) Node 개수
온도 기준
요구
개수
92. 여기까지가 현재 구현된 내용
• 그럭저럭 볼만한 섬 생성 가능
• 아직 서버 연동은 (...)
• 계산 시간
• 1024x1024, 40000개 기준 5초 정도
• 4096x4096, 640000개 기준 1분 이상
• Voronoi Diagram 생성에 많은 시간사용
93. 앞으로 개선할 사항
• 자투리 섬 생기지 않게
• 섬마다 개수 / 크기가 제각각
• 사실상 죽은 땅
• 본토 섬으로 병합처리 필요
• 호수의 면적이 일정하지 않음
• 지금은 땅의 면적만 일정하게 유지
• 호수가 너무 크거나 작으면 문제
• 일단 동일하게 섬 생성 과정 처리
그 후 섬 안에서 다시 호수 생성 하면?
94. 앞으로 개선할 사항
• 좀 더 자연스러운 강의 표현 필요
• 삼각주 / 곡류 / 선상지 등의 표현
• 좀 더 S라인이 되어야 할 듯?
www.scienceall.com
103. 결론은 자동생성 좋아요
• 이미 많은 게임들에서 자동 생성되는 컨텐츠를 사용 중
• Minecraft, 디아블로, 마비노기
• Realm of the mad god
• 최대한 컴퓨터가 할 수 있는 일은 컴퓨터가 하게
• 사람은 좀 더 창의적이고 도전적인 일을 하자!
• 이런 자동생성 작업이 상당히 재미있음
• 결과를 바로 바로 눈으로 확인 가능
• 아주 약간은 신이 된 기분
• 하지만 아트 센스가 없다면 어떨까(...)
• 우리모두 함께 해요
104. Q&A (발표 할 때 올라온 질문들)
• Q. 좋은 맵이 어떤 것인가에 대한 평가 기준을 정하는 것이 어려울 것 같
은데, 그 부분에 대한 고려가 궁금합니다.
• A. 저희 프로젝트 기준으로 말씀 드리자면, 첫 번째로 일단 생성된 섬을
눈으로 봤을 때 패턴이나 인공적인 느낌이 들지 않고 실제 자연에 있을법
한 섬의 모습을 가져야 합니다. 이건 수치로 평가하긴 힘들고 눈으로 직
접 확인하고 게임 내에서도 테스트 해봐야 되겠지요.
• 두 번째로 첫 번째 조건을 만족하면서도 게임의 기획 의도에 따른 특성을
만족시켜야 합니다. 앞에서 말씀 드렸던 섬의 크기, 생물 군계의 비율 등
이 될 수 있겠네요. 게임마다 필요한 필수요소 들이 있을 테니 그걸 잘 파
악하시는 것이 중요할 것 같습니다.
105. • Q. 노이즈맵을 생성해서 만개의 맵을 만든다고 하셨는데 만개의 노이즈
맵의 용량이 상당하지 않나요?
• A. 일단 섬의 생성 개수에 대해서 말씀 드리자면 만개의 맵을 만드는 것
은 아니고 게임에 필요한 개수 만큼 동적으로 생성하는 것이 목표입니다.
그리고 노이즈 자체도 따로 맵으로 만드는 것이 아니고 일반 Random 함
수처럼 좌표 값을 넣으면 Seed + 수식계산을 통해서 그 좌표에 해당하는
노이즈 값을 알아오는 방식이기 때문에 따로 메모리나 하드에 미리 노이
즈맵 파일을 생성하거나 하지는 않습니다.
• Q. 해안 절벽 같은 건 없나요?
• A. 아직 해안 절벽에 대한 고려는 해보지 않았습니다. 프로젝트에 필요하
다면 연구를 해야겠지만 어떻게 처리할지는 아직 잘 모르겠네요
106. • Q. 알고리즘 기반으로 만들어진 섬에 기획의도와 다른 결과물이 나오면 알고
리즘을 수정하게 될 텐데, 그러면 기존에 생성된 섬 데이터는 수정이 불가능하
지 않은지? 또한 그런 원치 않는 요소는 실제로 출현하기 전까지 알고리즘의
문제로 노출되지 않을 수도 있는데 결과물은 어떤 방식으로 검증하셨는지?
• A. 이미 만들어진 섬은 당연히 수정이 쉽지 않습니다. 아주 미세한 수정이고 기
존에 만들었던 섬 데이터의 Seed와 각종 설정 값을 저장하고 있다면 그걸 바
탕으로 새로 만든 섬으로 변경이 불가능한 것은 아니지만 여러 가지 부작용(예
를 들어 섬의 모습이 바뀌어서 땅 위에 지어놓은 집이 물 위에 있다거나)이 생
길 수 있으니 게임에 이미 쓰이고 있던 섬의 수정은 최대한 지양해야 합니다.
• 따라서 일단 기획의도와 다르게 만들어진 섬은 처음부터 게임에 쓰이지 않도
록 생성시 제대로 검증을 해야 합니다. 알고리즘 자체를 수학적으로 엄밀히 검
증하기는 힘들지만 결과물이 수학적 기획의도 대로 나오는지의 여부는 쉽게
검증할 수 있습니다. (예를 들어서 땅의 비율, 생물 군계의 비율, 섬의 경사도
등) 하지만 섬의 모양이 자연스럽지 않다거나 생물군계의 패턴이 보기에 단순
하다 등의 비주얼적인 측면은 자동 검증이 힘들기 때문에 최대한 많이 만들어
보고 경험적으로 확인하는 수 밖엔 없을 것 같습니다.