-
Notifications
You must be signed in to change notification settings - Fork 10
/
0303.txt
364 lines (364 loc) · 18.7 KB
/
0303.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
안녕하세요 포프입니다.
예전에 제가 한번 언리얼과 유니티
막 이런 이야기 하면서
결과적으로는
언리얼이 더 커질꺼다.
이런 비슷한 이야기를 했던거 같아요
그리고
그게 벌써 좀 됬는 얘긴데
그런 조짐이 요즘 보이고 있죠
참 다행으로 생각하고 있고
제가 마지막으로 몸담았던 게임 회사에서도
유니티로 원래하다가 언리얼 쪽으로 해다가 새로운 IP
IP라고 하면은 보통
Intellectual property인거 같아요 지적 재산권
그러니까
어디서 외주받아서 하는게 아니라
자기만의 아이디어로 게임 디자인하고
게임을 만든다인거 같은데
그것도 언리얼로 진행을 하고있었어요
그래서
거기서 이제 프로토 타입 만드는 과정에서
언리얼을 조금 만질 기회가 있었고
그러고 일단 제 직책이 직책이다 보니까
애들을 처음.. 이렇게 뭐랄까 구조잡는거 있잖아요?
뭐를 어떻게 하고 뭐를 어디에 두고
어떤거를 해야되고 어떤거를 하지 말아야 되고
이런 거를 혼자 리서치하고 이제
Recommendation(권고)하는 그니까
제안하는 그러니까 룰을 만드는 거죠.
그런 일을 좀 했었는데
그때 이제
제친구 중의 하나 정확히 얘기하면 제가 예전에 가르켰던 학생 중에 하나가
지금 미국에서 언리얼엔진 3하고 4를 거치면서까지 계속 언리얼 개발자를 하고 있었거든요.
그래서 이제
그 친구에게 물어봤었죠
"야 내가 요번에 이걸 하는데 과연 어떤어떤 조언을 해줄 수 있냐."
아무래도 이제 넌 해봤으니까 조언을 구하는거 좋잖아요.
그래서
그때 받아놨던 조언도 있고
그리고 그 조언
과 이제 제가 했던 경험을 기반으로 대충 어느정도
Unreal 4는 이렇게
잡고 들어가는게 좋다라는게 있었어요.
그러니까
어찌보면은 굉장히 기술적인 면보다는
Best practice(모법 경영)같은 개념의
그런 리스트가 있었거든요.
그 리스트가 노트 정리하다가 보이길레 한
좀 추려서 한 7개 정도만 대충 말씀드릴려고해요
그러면 이제
멋있게
Unreal Engine 4를 만질때
뭐뭐.. 주의할 점
7선 이렇게 하고 나올 수 있는거지.
무슨 7선은 무슨 명작 동화 이런 느낌이야
어쨋든 음 그래서
일단 제가 그때 썻던 그 주의할 점 7가지를 정리했는데.
더 많았어요 사실은
일단 7가지만 이야기 하면은
첫번쨰는 이제 Coding Standard(코딩 기준)에요
과연 이제 어떤 coding standard를 써야되냐
라는 이야기를 하잖아요
근데
저는 이제 언리얼 코드를 많이 봤는데요
언리얼 코드가 굉장히 깔끔해요
참고로 언리얼은 오픈 소스입니다.
그래서 첫번째 coding standard는
언리얼에서 쓰는 coding standard를 따르는게 제 일 좋다고 봐요
기본적으로 실제
Unreal engine 4의 그 Documentation(서류)있거든요.
문서되어있는거 웹에
거기가면 coding standard도 써있고
그리고 이 친구들이 특히 마음에 드는게
컨테이너같은 거를 쓸 때
자체 컨테이너를 구현해 놓은게 있어요.
그래서
제가 언제나 STL 컨테이너대해서 이제 게임쪽에서는
//STL(표준 템플릿 라이브러리)
Standard Template Library
좀 만들어 쓰는게 아직도 좋다는 이야기를 해왔잖아요.
콘솔쪽 이야기도 하면서
그런거를 미리 잘 만들어 놓고
생각을 굉장히 깊게 잘 만들어 놨더라구요
그래서
그런 거는 이제 언리얼 거를 따르도록 하고
두번쨰는 이제 블루 프린트의 문제거든요
블루 프린트 얘기를 하기 시작하면 굉장히 많아져요. 왜냐하면
블루 프린트가 어떻게 보면은 이제
언리얼의 게임 로직을 만드는 가장 중점이 되는 부분이거든요
블루 프린트를 할때 여러가지 얘기들이 있는데.
첫번쨰는 일단
블루 프린트끼리 이렇게 서로 참조를 할때가 있잖아요.
뭐 블루 프린트 A하고 B하고 C가 있는데
A가 B를 참조하고 B가 C를 참조하고 C가 A를 참조하고
이런거를 뭐 OOP쪽에서는
뭐라고 하지 한국말로 뭐라그러는지 모르겠는데
이게 뭐 Cyclic reference 이렇게 해요
//Cyclic reference: 순환 참조
그러니까 빙글빙글 돈다그래서서
이런거를 피하기 위해 최대한 노력을 해야되요
뭐 그러기 위해서는
제가 그닥 이렇게 좋아하는 편은 아니지만
Interface를 많이 써야 되는 경우도 있고
뭐 그런 것도 있는데
제가 특히 말하고 싶은 거 블루 프린트에 대해서는
블루 프린트는 게임 기획자 아니면은
그냥 스크립트 짜는 애들이 굉장히 빨리
아 게임 로직을 테스트 해볼 수 있는 기회에요
그래서
그런걸로 그냥 블루프린트로 막 노드 연결해가면서 막 테스트를 해보되
최종적으로 이걸 게임에 넣자 말자 결정을 할때에는
이거를 그러니까 블루프린트로 만든 거를 어느정도 C++로 옮기는 작업을 염두해 둬야되요
왜냐하면 블루프린트 자체가
아직 그렇게 빠른편이 아니기 때문에
결국에는 블루프린트는 이렇게 Iteration 돌리면서
여러번 테스트 할때 쓰는 용도
//Iteration : 반복
그러나 정작 게임이 나갈때는
C++ 구현을 짜는게 좋다고 생각을 해요
그리고
심지어는 블루 프린트를 가지고 놀때도
최소한 Interface정도 만큼은 C++로 일단 만든 다음에
블루 프린트가 블루프린트 Interface가 그걸 상속해서
다시 블루 프린트 구현이 그 Interface를 상속하는 방식으로 가게 되거든요?
그게 제일 좋은 방법이라고 생각하고
그리고
블루 프린트가 느리기때문에 게임 출시 전에
문제가 되는 경우가 많을 수도 있어요
모든 블루 프린트를 C++로 바꿔야 되진 않겠지만
굉장히 많은 부분을 바꿔야 될거라고 생각을 해요.
그래서 이제 그 부분에 대한 미리 규.. 뭐라그럴까
스케줄을 잘 짜놓으시고
한가지 여기서 지금 약간 뭐라그러지
Bright Light 라고 그러잖아요
뭐지 빛이 보인다. 광명이 보인다. 라고
교주같에 이렇게 말하니까.
그 부분은 뭐냐 하면
언리얼 지금 이제 나온거 최신 버전을 보면은
Preview 그러니까 Beta 기능으로
블루 프린트를 C++로 알아서 변환을 해서 컴파일해주는 그런 기술을 넣었어요
그래서 아직은 쓸모가 있을 정도까지는
안정이 되진 않은거 같은데
앞으로 몇버전 안에는 그게 정식으로 들어올꺼 같고
그러면 C++손코딩을 직접 해야 될 일은 조금 적어질 수도 있어요
블루 프린트 C++ 컴파일이 얼마나 잘되냐에 따라
두고볼 일
그거는 제가 볼때는 그렇게 어렵진 않을거라고 생각해요. 기술적으로
블루프린트는 거기까지.
세번째 되게 단순한 얘기에요
유니티도 보면 똑같지만 에셋 스토어가 있어요. 언리얼도
그래서 뭔가를 언리얼로 만들때는
인건비보다 에셋을 사서 쓰는게 쌀 수도 있어요.
플러그인이라던가 이런 기타 등등을
그래서 그런거를 그냥
사는거를 아까워하지 말아라.
개발 기간이 단축이 되고
오히려 개발 일찍 끝나고
애들을 빨리 짜를 수 있..다고말하면 안되지
뭐 어쨌든
그렇게 인력이 많이 필요하지 않기 때문에 그게
금액적으로 맞는 경우가 꽤 많을 거에요.
그걸 사는 걸 아까워하지 말길 바라고
이제
머테리얼을 만드는 거 있잖아요
//머테리얼(material): 오브젝트의 재질을 정의
(예:색,광택,투과성)
쉐이더 머테리얼이라 그러죠. 그게 4번짼데
이 머테리얼을 쉐이더를 노드로 해가지고 짜는 그런 개념이라고 보면 되요
해서 머테리얼을 만드는 주체는 반드시
Technical Artist 아니면 그래픽 프로그래머여야 한다고 생각을해요
왜냐하면 이것을 이상하게 노드를 짜는 순간 속도가 엄청 느려질 수 있어요
해서 머테리얼을 짜는 거는 반드시
TA나 프로그래머가 하고
그럼 머테리얼에 들어가는 그런 parameter가 있잖아요.
//parameter : 매개변수
플롯 숫자라던가 텍스처라던가
이런거는
일반 아티스트들도 마음껏 바꿀 수 있어야 되는데
그걸 머테리얼에 직접 바꾸면은
뭐랄까 머테리얼 전부가 바뀌니까
그 머테리얼을 두고 거기서 Instance를 상속으로 뽑아서
거기서 특정 parameter만 바꾸거나 하거든요
그래서 이 머테리얼 Instance를 바꾸는 거는
당연히 아무나 할 수있지만
이 기반이 되는 실제 쉐이더 노드 테크닉을 보여주는
머테리얼만큼은
TA나 프로그래머 그러니까
그래픽 프로그래머가 짜게 하는게 성능에 좋아요
그리고 이게 뭐 나중에 고치면 되지 하고 갔다가
이런 머테리얼이 수천개 수백개 되고
이거 나중에 성능 안잡히면은
정말 잡기 힘들거든요.
그리고 비주얼이 다 바뀌고 나중에가서
그래서 이거는 처음부터 까다롭게 이렇게
채찍질을 해야하는 부분이에요
예전에 제가 Kgc 한 번가서 발표를 했던
우버 쉐이더에서도 마찬가지였거든요.
이거를 자유롭게 플레이 할 수 있게는 해주되
결국에 채찍질은 누군가 해야된다.
그렇지 않으면 나중에 최적화할 때 문제다 라는 이야기를 했었어요
그래서
그거는 이제 4번쨰였고
5번째는
이 언리얼 빌드가 좀 느리단 이야기를 해요
왜냐하면 일단 C#처럼
런타임에 정보가 많은 것도 아니고
컴파일도 좀 많이해야되고
그리고 에셋 굽는데도 시간이 많이 걸리고
그런데 에셋의 파이프 라인은
기본적으로 유니티보다 훨씬 나아요
그래서
이걸 빠르게 하는 방법 중에는 결국에 뭐가있냐면은
만약에 언리얼이 회사에 10대가 깔려있잖아요.
그러면 제가 뭐 언리얼에서 라이트 맵을 굽는다 그럴때
놀고있는 다른 언리얼 깔려있는 회사 컴퓨터를 써가지고
베이킹을 해요. 그러니까 이건 Render Farm이죠.
그건 기본적으로 하니까 상관이 없고
두번째는 언리얼에서 에셋을 구을때마다
이 구워놓은 바이너리를 캐쉬로 저장을 해놓거든요
이게 보통 개인 컴퓨터에 다 있어요
그러면
내가 빌드해도 내꺼에서 캐쉬만드는데 시간이 걸리고
내 옆 동료 컴퓨터에도 시간이 걸려요
근데
빌드하는 캐쉬들어가는 디렉토리를 네트워크 쉐어로해서 네트워크에 같이 지정을 할 수 있어요.
그럼 제가 미리 구워놓은 에셋은 얘는 구을 필요없이 그냥 갔다 쓰면되거든요
해서
이런 네트워크 쉐어는 반드시 해주시는게 에셋을 굽는 시간을 굉장히 줄일 수가 있어요.
그래서 그거를 5번째로 말하고 싶었고
6번째는 이제 레벨 쉐어링 기능이에요.
이거 생각보다
제가 말한 모든 거는 언리얼 문서에 되게 잘 나와있어요.
좀 전에 말했던 블루 프린트 뺴놓고는
언리얼 문서에 되게 잘 나와있는데
이것도 나와있는 거고
월드맵 같은 거를 서로 만지기 시작하잖아요.
유니티도 그렇고 언리얼을 좀 이렇게
아무 생각없이 잘못쓰면은
내가 이 맵을 고치고 있을때
다른 사람이 이 맵을 못 고쳐요.
왜냐하면은 맵은 어짜피 바이너리 파일이기 때문에
양쪽에서 고치고 머지가 안되거든
내가 고칠동안은 남이 건들지 말아야 되는게 문제에요
좀 힘들죠? 쉽지 않죠 아무리 생각해도
그래서 일단 레벨을 어떻게 짜르느냐에 따라
여러명이 일을 못하는 경우가 되게 많이 생겨요.
예를 들어서 계속 한 게임에서 어느정도가
규모가 있고 계속 이렇게 걸어가는 오픈 월드 게임이라면
맵 청크가 있잖아. 그 청크를 내가 고칠때는 다른 놈이 손도 못댄다는거에요
그럼 이건 대규모 프로젝트에서 좀 힘들어지거든요.
근데 이걸 할 수 있는 방법이 있어요. 사실은
그거를 어떤 개념이냐하면은
언리얼에는 오픈월드를 지원하기위해
스트리밍 맵이라는 개념이 있어요
그러니까
내가 이 월드를 하나 만들어요.
이건 말 그대로 컨테이너야 아무것도 없어
그리고 이 안에서 스트리밍 존으로
지역 1, 2, 3, 4, 5이렇게 만들어 놓고
어느 1에서 2로 가는 어느 정도 경계에 들어가면
거기에 컬리션 박스를 하나 만들어 놓고 거기 들어가면
스트리밍 zone 2를 로딩을 해라 이런식으로 해서 계속
이어지게 로딩 스크린 없이하는 법이 있거든요.
그런데 이거를 똑같이 이용을 하면은
그냥 zone 하나에 월드를 만들어요. 그게 zone 1 월드야
그러니까 이게 지역이라는 이야기죠. Zone
해서 Zone 1 월드고 그럼 여기서 이 안에 만약에 여러가지 레이어를 레벨로 만들 수 가 있어요.
예를 들면은 배경 모델 인바이런먼트 레이어를 만들고 그 위에 라이팅 레이어를 따로만들고
이게 하나하나의 레벨 , 맵으로 저장이 되는 거에요
그리고 그 위에 무슨 뭐 글로벌 이펙트. 포그(Fog)나 DOF(Depth of field) 이런 것들
그런 맵을 따로 만들어 놓고 스트리밍 존으로 로딩을 해놓으면 되요 그런데
스트리밍 존에 로딩을 할때
옵션이 두개가 있거든요? 스트리밍이 되는 옵션이 있고 언제나 로딩이 되게 하는 옵션이 있어요
언제나 로딩하게 되는 옵션을 하면은 언제나 같이 열려요.
근데 재밌는건은 아까전에 여러개로 쪼깨놨잖아요?
한 맵을 레이어로
그럼 난 이 레이어만 락을 걸면 되요
그러면 이 레이어를 락을 거는 순간 다른 사람은 이 레이어를 못만지지만
그 사람들은 여전히 그 레이어를 제외한 다른 아까 말한
3개 정도의 레이어는 자유롭게 건들 수 있다는 거죠.
그래서
회사에서 업무하는 스타일에 따라
라이팅을 따로하는 사람도 있고
배치를 따로하는 사람이 있고
무슨 뭐 케릭터를 어디에 두는 사람이 있고
게임플레이 노드를 따로 두는 사람이 있다면
그런 개념별로 여러개를 나눈 다음에
레벨을 운영할 수 있어요
심지어 자기 이름을 넣고 레벨을 운영한 다음에
저장하고 리드가 와서 그 레이어만 검토하고
아 이거 제대로 됬다
그 다음에 그걸 락걸고 메인 레이어를 락걸고 이걸 카피한 다음에 다시 락을 풀어도 상관이 없죠.
그런식으로 여러명이 공동 작업할 수 있는 방법이 언리얼에는 있어요.
그거를 좀 잘 이용하길 바라고
마지막은 또 간단한건데
소스 컨트롤 문제거든요
근데 게임 개발에는 어짜피 그렇지만 바이너리 컨텐츠가 있고
바이너리 컨텐츠는 머지가 안되는 상황이잖아요
처음부터 사람이 아예 손을 못대게
내가 일단 손을 대고 있으면
이 옆동내가 손을 대기 시작하지도
못하게 아예 막을 수 있는 방법이 사실은 필요해요.
불행히도 git은 거기에서 쥐약이고
svn은 락은 걸 수 있는데 체크인을 못하게 막을 뿐이지
그걸 이제 고치는걸 막을수는 없거든요.
그래서 아주 솔직히 말하면 퍼포스가 왕입니다.
게임쪽에서는 어쩔 수 없이
특히 바이너리 컨텐츠가 있는 쪽에서는
그래서
언리얼을 봐도
언리얼 에디터 안에서 퍼포스지원은 굉장히 뛰어나요
내가 고치는 동안 락도 걸 수 있고
이걸 UI에서도 할 수 있고
끝나고 체크인 누르면 이거 바뀌었으니까 체크인 할레? ok누르면 체크인 해주고
그런거 잘 되어있고
svn지원도 들어 있긴 해요.
그것도 작동해요.
Git지원은 자체 지원이 아니라
외부의 어떤사람이 Plugin 같은걸로 해서 지원을 하는데
써본결과 별로 였어요. 사실은
뭔가 안되고 이런게 많아서
아직은 좀 premature한거같고
//premature : 시기 상조의
그러니까 뭐라그러지 좀 이른거 같고 시기가
나아질꺼같긴하나데
바이너리 컨텐츠가 들어간 이상 git은 정말 어려워요.
사실은
그래서 뭐 거기다 LFS지원을 잘해주면 모르겠는데
아직은 LFS지원이 제대로 나온거같지도 않고
제가 한 두 달 전에 봤을때는 그게 없었어요 LFS지원이 제대로.
그래서 이 비디오 나갈때 쯤이면 한 4달 전이 되겠다. 미리 만들어 놓는 거거든요.
퍼포스는 돈이드니까 뭐.. 어쩔 수가 없는데
뭐 큰 회사라면 그 정도 돈내고 쓰는 사람이 있다면 다행이고 아니면 뭐 어쩔 수 없이
SVN이 지금은 제일 나은거 같고 돈을 안들이려면
깃에 LFS지원이 제대로 나온다면 그 것도 해볼만 하구요.
해서 오늘 7가지는 좀 긴비디오가 된거같은데 그렇게 정리를 할려구해요.
간단하게 마지막으로 정리를 하고 끝낼께요.
언리얼에서 주의할점 7가지는
첫번째 Coding Standard는 언리얼을 따를 것
두번째 블루 프린트는 순환 레퍼런스하는 걸 막고
블루 프린트로 프로토 타입을 열심히 만들고
C++로 마지막에 아마 손코딩을 해야되거나
아니면 지금 나오는 자동 컴파일 기술
그게 해결해 줄거라는거.
세번쨰는 언리얼 스토어에서
에셋사는걸 아까워하지말 것
네번쨰는 머테리얼은 언제나 TA나 그래픽 프로그래머가 만들고
다른 모든사람은 거기서 인스턴트를 뽑아
텍스쳐나 파라미터를 바꾸는 정도로만 쓸 것
다섯번째는
레벨을 여러명이서 공유하는 방법이 있다
그 방법을 문서에서 잘 읽어보고
자기네 워크 플로우에 맞게 쓰길 바라구요
여섯번째는
빌드를 할때 캐쉬파일을 네트워크 쉐어에 넣고 공유하는 방법이 있으니까 그걸 잘 이용해서
에셋 빌드 시간을 빠르게할 것이고
일곱번째는
소스 컨트롤은 퍼포스가 왕이고
그 다음이 SVN 그 다음이 Git + LFS다
Git+LFS가 없으면 손도 대지 말아라
라고는 말을 하고 싶어요.
☆★☆★☆★☆★☆★☆★
☆★예. 포프였습니다.☆★
☆★☆★☆★☆★☆★☆★