디시인사이드 갤러리

마이너 갤러리 이슈박스, 최근방문 갤러리

갤러리 본문 영역

[번역] 스카이림의 모듈러 레벨 디자인 - 3(완)

piNutz갤로그로 이동합니다. 2019.08.29 00:51:31
조회 227 추천 2 댓글 2
														

1편 : https://gall.dcinside.com/mgallery/board/view/?id=gamedesign&no=403&page=1

2편 : https://gall.dcinside.com/mgallery/board/view/?id=gamedesign&no=404&page=1



3) 그레이박스 단계Graybox Phase

그레이박스 단계의 목표는 키트를 구체화하고 무엇이 가장 일반적인 조각이 될지 파악하는 것이다.

증명 단계에서 처럼 아티스트는 최종 텍스쳐 작업을 하지 않고 조각 반복을 상대적으로 빠른 프로세스로 유지한다. 키트의 복잡성에 따라 일반적으로 1-4주정도 걸린다.

첫번째 그레이박스는 주요 서브키트 혹은 가장 자주 사용할거같은 서브키트여야 한다. 그래야 문제를 빨리 파악할수 있고 키트의 레벨 디자이너는 "진짜" 레이아웃을 가지고 스트레스 테스트를 시작할 수 있다.

키트가 어떻게 기능하고 보여야하는지 집중해야함을 명심해라. 그러나 특정 시각적 요소들은 임팩트를 가지고 있고 이 단계에서는 대략적으로 가지고 있어야 한다. 보통 여러 풋프린트를 가로질러 붙여야하는 시각적 컴포넌트가 이에 해당한다. 각 키트는 다른 목적을 가진다. 그리고 이런 요소들이 어떤 것인지 파악하는데에는 (컨셉 단계에서 설정한) 공통의 비전에 의지해야 한다. 만약 중앙을 가로지르는 파이프가 있는 룸 키트를 만들고 싶다면, 파이프를 넣어라. 혹은 비대칭적인 동굴 키트를 만ㄷ르고 싶다면, 그레이박스 조각에 대칭성이 명확한 것을 넣어라. 그레이박스를 너무 일반적으로 만들면 어떤 문제도 해결할 수 없다.

이 지점에서 레벨 디자이너와 아티스트는 네이밍 규칙을 함께 도출해야 한다. 지루한 작업이지만, 초기에 정렬하는게 중요하다.

좋은 네이밍을 하는 요점은 가독성과 간결함 사이의 균형을 유지하는 것이다. 한번도 본적 없는 이도 이해할 수 있는 네이밍 규칙을 만들도록 해라. 지나치게 축약하면 해독하는데 해독기가 필요한 암호화된 골칫덩이가 되버린다. 레벨 디자이너가 필요한 조각을 찾는데 헤매게 만드는 걸림돌이 될 수도 있다.

만약 만족스러운 네이밍 룰을 갖고 있다면 모든 키트에서 그것을 유지해야 한다. 이는 일종의 스튜디오 공용 언어가 된다. 레벨 디자이너가 여러 프로젝트 속에서도 새로운 키트를 익히는걸 쉽게 만든다.

예시에서 "UtlBayCorInMidPRTT01L01"라고 이름붙여진 폴아웃3의 조각을 분석해보자. 네이밍 룰에 따르면 이는 하기와 같이 구성돼있다.

  • Utl - Utility 키트의 일부임을 표시.
  • Bay - Bay 서브 키트의 일부임을 표시.
  • Cor - Corner의 약자. 대개 "In","Out"등이 뒤따름.
  • In - 안쪽Inside 코너임을 표시. Outside는 반대로 굽혀짐.
  • Mid - 타일 조각의 일반적인 약자. 대개 바닥. 이 경우 Bay 서브 키트가 수직으로 배치된다.
  • PRTT01 - 모르겠음.
  • L - Left. 조각의 미러링 버전인지 표시하기 위해 이름 끝에 L/R을 달곤 한다.
  • 01 - 비주얼 배리에이션이 있는지를 표시. 추후 상세히 기술.

webNameBreakdown.jpg

대부분의 명명은 해석하기 쉽고 다른 키트들과도 사용할 수 있다. 하지만 "PRTT01" 부분은 해독할 수 없었다. 이 조각이 위, 아래, 혹은 각 벽면에 붙여질지 나타내려고 의도했다. 하지만 그걸 다넣기는 매우 힘들었고, 키트는 활용하기 힘들어졌다. 이는 정말 부끄러운 일이다. 이 키트는 코어 게임에 적합하지 않았던 많은 잠재성을 갖고 있었기 때문이다. 헛수고가 됐다. 

이 예시는 타산지석으로 꽤나 유용하다. 그러나 몇몇 네이밍 룰은 "처음 보는 이에게도 쉬워야 한다"는 규칙을 만족시키진 못한다. 예를 들어 우리는 직선 복도 조각을 "1Way"라고 부른다. 그리고 코너/턴 복도 조각을 "2Way". 더 명확한 것은 "3Way", "4Way" 교차점이다. 쓰기도도 쉽고 비슷한 조각들을 리스트에서 잘 정렬해주기에 우리는 이런 룰을 채택했다. 이 명명을 이해한다면 모든 복도 서브 키트를 이해할 수 있을 것이다.  이는 단지 빠른 반복 속도을 위한 둔한 네이밍 규칙과 일관되게 사용하는 오프셋의 사례이다.

위에서 간단하게 언급했듯이 시각적 변화를 가한 조각에 "01"을 접미사로 쓰는건 유용하다. 그러나 만약 그렇지 않다면(시각적 변화가 아니라면) 특정한 역할을 부여하고 같은 풋프린트 안에서 사용해라. 01/02/03을 접미사로 쓰면 한 리스트로 묶여 찾기도, 바꾸기도 쉽다. 

이 시점에 피벗 위치 역시 결정해야 한다. 일반적으로 우리 키트 조각들의 피벗은 대개 접지면 중앙에 위치한다. 그러나 항상 예외는 있다. 파이프 키트는 그 끝에 피벗이 있다. 정렬하기도 쉽고 힌지처럼 굽히기도 쉽기 때문이다. 플랫폼 키트는 접지면 대신 플랫폼 바닥에 있다. 덕분에 다른 영역들과 쉽게 붙일수 있다. 피벗을 바꾸는 것은 큰 문제를 야기한다. 예를 들면 수백개의 인스턴스를 수작업으로 업데이트 해야할 수도 있다.

4) 확장 단계Build-Out Phase

다음은 확장 단계이다. 이때 키트는 진짜 아트로 완성되기 시작한다. 그리고 팀에게 널리 전파할 수 있게 된다. 코어 조각들은 검증됐고 기본 레벨에서 기능적으로 배치가능하다. 아티스트는 이런 조각들을 시각적으로 개선하기 시작하고 사용 사례에 따라 덜 치명적인 조각과 변경점을 추가한다. 

이는 또한 그동안 키트를 갖고 일했던 레벨 디자이너들이 그간 키트 작업을 하지 않았던 다른 레벨 디자인팀에게 전파하기 좋은 시점이다. 그리고 현재 상태와 향후 계획, 키트에 관한 기본 개념을 전달하기에도 알맞다. 다른 레벨 디자이너가 처음 키트를 갖고 자신의 레이아웃을 구축하는 시점이다. 많은 유용한 피드백이 생성된다.

실제 텍스쳐와 지형이 만들어지기 때문에 이 단계는 꽤 길어질 수 있다. 특히 얼마나 서브 키트가 많으냐에 따라 몇달이 걸리기도 한다. 만약 그레이박스 단계가 성공적이었면 레벨 디자인을 계속 뒤로 미뤄서는 안된다. 최종 아트를 완성한다면 아트는 쉽게 교체 가능하기 때문이다. 항상 그런 것은 아니지만 이 기간동안 예기치 못한 문제가 레이아웃 기반을 약하시키지 않도록 조심해라.

이 지면에서 그렇게 깊게 까지 들어가진 않지만, 한가지 매우 중요한 것은 변경본을 만들기 전에 시각적으로 완벽한 조각을 만들어야 한다는 것이다. 만약 추가사항이 아트 디렉션 피드백을 기초로 했다면 전체 키트 대신 한 조각(혹은 적은 수의 조각들)을 더하는 것은 매우 쉬운 일이다. 이는 엄청난 시간을 아끼게 해준다. 키트 폴리싱에는 엄청난 시간이 든다. 풋프린트, 스냅 룰, 피벗 지점과 같은 기능적으로 영향을 미치는 부분의 변경을 우선적으로 예측하고 피해야 한다.

또다른 주의 사항은 "영웅 조각Hero Pieces"을 만들고 싶은 욕구이다.

webHeroPiecesAreLame.jpg

영웅 조각은 특별한 이벤트에서 쓰이거나 굉장히 독특한 아트를 지닌 조각을 말하는데, 이들은 궁극적으로 초기에는 중요한게 아니다. 중요해 보일 수도 있겠지만 이들의 사용처는 매우 적으며 수백 수천번 사용하는 표준 조각을 만드는 것이 훨씬 중요하다. 언제든 추후에 만들수 있고, 그것들이 필요한 소수의 상황에서나 병목현상이 될 뿐 이다.

지금까지 소개하지 않은 다른 하나는 "도움 마커Helper Markers"이다. 이것들은 에디터에서만 보이는 마크업으로 굉장히 유용한 정보를 갖고 있다.

web_Helpermarkers.jpg

이 마커들의 예시에서 마커들은 키트들이 어떻게 서로 붙어야 하는지 알려준다. 문의 방향이 어딘지, 어디에 천장을 달아야 하는지(카메라를 위아래로 조절할 필요 없이) 알 수 있게 한다. 디자인 팀이 키트들을 처음 다룰 때, 그용도를 좀 더 직관적이고 명확하게 알려준다.

5) 폴리싱 단계The Polish Phase

드디어 폴리싱 단계에 이르렀다. 나머지 프로젝트 기간 전체에 걸쳐 진행해야하는 단계이다. 앞으로 몇달간 키트 아티스트는 실제 사례, 버그, 추가적인 기능에 대응해야 한다. 키트 아트를 배포하는 방식에 따라 추가적인 아트 폴리싱에 대한 필요가 있다면 진행해야 한다. 이는 매끄러운 프로세스여야 한다.

이 프로세스를 진행하면서 발생하는 모든 요청사항에 대해 레벨 디자이너와 아티스트는 매우 비판적으로 얘기를 나눠야 한다. 모든 요청사항에 아티스트가 "Yes"라고 답한다면 키트는 쓸데없이 비대하고 통제불가능하게 된다. 키트를 만들면서 내렸던 결정에 대한 이유를 기억해라. 그리고 추가적인 조각이 가치가 있는지 확인해라. 특성 사용 사례를 위해 조각을 추가할때 적절한 대안은 없는지, 혹시나 다른게 이미 있지는 않는지, 진짜 이 사용 사례가 키트를 확장해야 하는 가치가 있는지 확인해라. 대답은 항상 "No" 일수도 "Yes"일 수도 없다. 선택은 당신 몫이다.

일련의 초기 과정에서 아티스트는 주로 제한된 영역 설정에서 한명의 레벨디자이너와 일한다. 개발 단계를 거쳐 수많은 다른 레벨 디자이너들이 수많은 다른 레벨을 만든다. 초기 과정이 어쨌던간에 언제나 예기치 못한 이슈는 발생한다. 다가올 방향 수정을 위한 추가적인 키트 폴리싱 타임 계획과 사례이 될 것이라고 여기자.

그리드 다루기: 고급 기술Going Off the Grid: Advanced Techniques

여기서는 그리드에서 사용할 룰 기반 키트를 어떻게 만들지를 다룬다. 코너 조각, 직선 조각, 복도, 방 등등은 잘 들어맞는다.

webBR2kit.jpg

문제는 이런 종류의 키트들은 항상 키트처럼 느껴진다는 거다. 모든 것들이 항상 90도를 유지하고, 플레이어들은 시스템과 예술 피로를 느끼게 된다. 모듈화된 레벨은 정말 모듈러화된 레벨처럼 느껴진다.

폴아웃3를 시작하면서 우리는 어떻게 키트처럼 안느껴지는 키트를 만들지를 고민했다. 우리는 규칙들을 학습하기 위해 많은 기간을 보냈다. 이제 우리는 그것들을 부술 때가 왔다. 규칙들을 비틀기 시작할 때 항상 그것들이 왜 처음에 규칙으로 정해졌는지 기억해라. 이런 규칙들은 한번 실수해보기전까지는 왜 그렇게 됐는지 깨닫기 힘들다.

만약 키트 로직 비틀었다면, 앞으로 만들 모든 키트에 꼭 적용할 필요는 없다. 각 키트별로 별도의 특이 로직을 두는게 최고이지만 반면에, 많은 것들이 빠르게 통제불능 상태가 된다. 규칙을 비트는데 드는 비용을 기억하는 것은 굉장히 중요하다. 아트 팀은 다른 조각들을 만드는데 추가 시간을 써야할 뿐더러 아트는 훨씬 복잡해진다. 레벨 디자인 프로세스는 역시 복잡해지고 실수하기 쉬워진다. 각 케이스별로 이러한 트레이드오프를 할만한 가치가 있는지 확인해야 한다.

복잡한 키트를 만들게 하는 다른 주요 기술은 "레퍼런스에 맞추기Snap to Reference"이다.

webSnapRefDiagram.jpg

Modular Level Design for Skyrim

이 기술은 어떤 오브젝트든 다른 오브젝트를 붙일 수 있는 원점으로 여기게 해준다. 이렇게 하면 모든 것들을 90도에 맞춰 정렬할 필요가 없다. 조각을 회전시키고 그것을 새로운 그리드로 만들어라. 그러면 새로운 조각들을 이 회전한 조각에 쉽게 붙일 수 있다. 이것은 다른 각도로 회전된 조각들의 차이를 명확하게 해주지만 우리는 다양한 방식으로 그 갭을 메울 수 있다.

스카이림에서 선보인 새로운 키트 타입은 Ratway에서 사용한 "피벗과 테두리Pivot and Flange"이다. 이것은 거의 파이프 키트와 유사한 복도 키트이다. 모든 복도 조각들을 자연스러운 흐름을 위해 각각의 독특한 각도로 회전시킬 수 있게 했다. 이런 복도 조각들이 제멋대로 회전하기 때문에 각 복도 조각들 사이에는 틈이 발생한다.

webPivotFlange.jpg

우리는 이런 틈을 벽, 바닥, 천장의 모든 곡률을 따르는 아치형 입구를 만들어 덮었다. 이 방식에는 몇가지 알아야 할 이슈가 있다. 초심자에게 레벨 디자인 프로세스가 더 선형적이게 된다. 각각 이상한 각도로 회전할 수도 있기 때문에 얼마나 많은 조각들이 각 방에 있는지 뿐만 아니라 모든 숫자/각도를 건네줘야 한다. 이는 꽤 적응하기 힘들게 한다.

이는 또한 보이지 않는 에러를 만들기 쉽게 한다.

Modular Level Design for Skyrim

이 아치형 입구가 모든 홀에 달라붙지 않기 때문에 레벨 디자이너들이 갭을 완전히 커버하게끔 정렬하기 어렵다. 그로인해 딱 맞는 각도에서만 보이는 작은 틈을 만들게 된다.(이는 에디터에 너무 오래 머무르지말고 작업물을 자주 플레이하는 것의 중요성을 강조한다.) 굉장히 구체적인 구조에서는 나쁜 시스템이기도 하다. Ratway는 기본적으로 유기적이고 어떤 것들을 함께 두기를 방해하는 것들에 의존하기 때문이다. 그리고 깨끗하고 구체적인 구간을 원하는 이들에게는 비주얼적으로 나쁘게 보인다. 그러나 자연스럽게 조직되고 굽은 복도를 원하는 이들에게는 많은 키트 조각을 요구하지 않는 환상적인 시스템으로 보인다. 왜냐면 완벽하게 Ratway는 고대의 부패한 지하 터널 시스템처럼 보이도록 의도했기 때문이다.

스카이림의 동굴을 만들 때가 됐을 때, 우리는 우리의 규칙을 개선해야할 때가 됐음을 알았다. 동굴은 모듈화된 건축에서 항상 골치였다. 모듈화된 키트로서 굉장히 규칙 기반적, 직교적이어야 하지만 동굴은 굉장히 자유롭고 유기적이다. 스카이림에서 사용하기 시작한 다른 시스템은 쉘 기반 빌딩 시스템Shell-Based Building System이다.

이것은 전통적인 방식으로 만들어진 표준 키트 조각들로 만들어진 시스템이다. 그러나 자유롭게 배치된 벽, 기둥, 발코니를 통해 유기적인 방법으로 플레이 공간을 분해한다. 아래 그림은 예시들이다. 방을 만들기 위해 사용한 쉘 조각들, 코너보다 유기적인 모양을 만들기 위해 자유롭게 사용한 벽과 기둥을 보여준다. 그리드에 부착된 쉘grid-snapped shell덕분에 가능했다.

webCaveShellStages.jpg

이는 레벨 디자이너들에게 그들이 원하는 흐름과 형태를 갖춘 매끄러운 레벨을 만들수 있게 한다. 시각적으로 다르게 보이는 것들을 만들기 굉장히 쉽다. 그 아트들이 융합될 수 있는 임의의, 혼잡한 방법 덕택에 필요한 아트의 양은 굉장히 적다. 몇몇 아티스트는 이것들이 멋져보이지 않는 구체적인 교점을 걱정한다. 만약 그렇게 보인다면 그 구체적인 사용처를 모니터하는 아트 리뷰 단계를 통해 구조적인 피드백을 제공해라. 좋은 라이팅과 렌더링(앰비언트 오클루젼ambient occlusion같은)은 그런 이상한 교점을 가릴수 있게 해준다. 이런 방식으로 레벨을 만들면서 얻을수 있는 유연성은 어마어마하다.(그리고, 아무도 그런 작은 교점은 눈치못챈다.)

방향이 제한된 키트는 폴아웃3때부터 우리가 사용한 기술이었다. 전통적인 키트들은 아무 방향으로 회전할수 있고 같이 맞물릴 수 있다. 방향 제한 키트는 이렇게 사용할 수 없다. 다른 것들과의 관계에 사용되는 특정한 조각들이 있기 때문이다. 이로 인해 아트는 비대칭적인 홀, 구체적인 너비의 방(큰 아치가 걸쳐진 방과 같은)혹은 중요한 방향성을 지닌 독특한 조각을 지닌 방 키트들 같은 작업을 할 수 있다.

이는 아트팀, 디자인팀 모두에게 엄청난 작업을 필요로 한다. 하지만 모든 방향에 붙여야 할 텍스쳐와 표면에 대한 필요를 제거하기에 매우 유용하다. 이는 매우 많은 추가 작업이고 키트의 몇몇 핵심 로직을 변경한다. 자연스러운 키트를 만드는데 굉장히 유용함에 반해 방향 제한은 고도의 아키텍처를 위해 추가 노력을 들일 필요가 없다. 하기 그림의 A/B면처럼 각각의 표면을 다르게 생각하기 시작한다면 키트는 이해하기 쉬워진다.

image2019-8-25_19-49-16.png?version=1&modificationDate=1566730154876&api=v2

이를 만들때 주의해야할 다른 사항은 "꼬임 제거De-Twist"조각을 복도 키트 안에 만들어야 한다는 것이다. 만약 비대칭적인 복도가 한방향으로만 이어진다면, 그냥 문제없이 붙일 수 있다. 그러나 다른 방향으로 뒤집힌 다른 복도와 만날 때가 있다. 꼬임 제거 조각은 한쪽이 다른 쪽과 만나는 부분을 뒤집어 이 틈을 메운다. 하기 그림은 꼬임이 나타났을 경우와 꼬임 제거 조각이 필요한 자기 자신에게 이어지는 비대칭적인 복도의 예시이다.

image2019-8-25_19-49-31.png?version=1&modificationDate=1566730169456&api=v2webDetwist.jpg


엄청난 유연성을 제공하는 또 다른 간단한 키트 컨셉은 "플랫폼Platform"이다. 플랫폼 키트는 다른 표면 꼭대기 위에 있으며 플레이의 수평적인 면을 분할하는 레벨 디자인을 하게 해준다. 이것들은 굉장히 크거나 작은데, 두가지 예시 모두 스카이림에서 볼 수 있다.

Modular Level Design for Skyrim

이로 인해 레벨 디자이너는 키트의 복잡한 수직적인 규칙을 다룰 필요없이 흥미로운 플레이공간을 만들수 있는 힘을 부여받는다. 플랫폼 키트를 만드는데 필요한 조각들은 최소한이며 이것들은 같은 시각적인 테마를 가진 대부분의 서브 키트들과 함께 쓰이는 경향이 있다. 이런 플랫폼 키트들을 흥미로운 곳의 표면에 독립적으로 사용하기도 한다.

플랫폼 키트는 우리가 "접착제Glue"키트라고 부르는 것의 구체적인 예시중 하나이다. 우리의 현재 프로젝트를 시작할 때, 매우 다양한 종류의 키트와 서브키트의 변환 구간을 만들기 위해 존재하는 작은 범위를 가진 키트들을 다수 만든다.  접착제 키트는 kit-bashing을 염두에 두고 필연적으로 만들어졌다. 이것은 터널이든 절벽이든 어떤 것이든 될 수 있다. 그것들은 많은 이점을 우리에게 줬으며 혁신과 탐색하는 과정이 우리의 공식 워크플로에 얼마나 영향을 미치는지 알려줬다. 이는 꽤 좋은 것이다. 우리의 워크플로가 진화하는 것은 우리가 여전히 배우고 있음을 알려주기 때문이다.

결론

결론을 내리자면 여기서 논했던 것처럼 우리의 워크플로를 들여다보고 포용하지 않았다면 나는 우리팀이 스카이림을 만들수 없었을 거라고 생각한다. 세상을 만듦으로써 그것을 탐험하고자 하는 욕구가 우리를 이끌었다. 한 아이디어의 모든 우위edge를 폴리싱하는 시간이 우리가 다른 아이디어, 그리고 그 이후의 것들을 해볼 시간들을 앗아간다는 사실을 항상 조심했다. 우리 게임에서는 세계야말로 그것들의 메인 캐릭터라는 사실을 얘기하곤 했다. 개발을 거듭하며 이 세계들은 우리 눈앞에 살아났다.

이 워크플로들을 우리가 강요받은 타협안으로 판단하지 마라. 이것들은 삶을 행복하고 조화롭게 만드는 회사 문화working culture를 유지하면서 우리 게임 크기 만한 것을 만들수 있기 위해 우리가 해온 선택들이다.

왜냐면 나는 우리 팀이 다른 방식으로 스카이림을 만들수 있다고 믿지 않기 때문이다. 또한 스카이림을 만들수있는 다른 팀 역시 없다고 믿는다. 더 많은 시간과 돈, 사람, 다른 사상들을 갖고 다른 팀이 스카이림과 비슷한 게임을 만들수는 있을 것이다. 하지만 그 게임들은 우리가 만든 것과 다른 게임들이고 나는 우리가 만든 게임이 자랑스럽다.

삶의 마지막 날 당신이 만든 게임(당신이 이 세상에 내보낸 예술)은 당신 자신을 나타내는 표현이 될 것이다. 만약 팀의 일원이었다면 그 예술(게임)은 당신 자신이 아니라 더 많은 개인들에 대한 표현이 될 것이다. 팀의 일원으로서 어떤 사람인지, 어떤 관계였는지를 나타내는 외적인 표현이 될 것이다. 그리고 이런 관계들은 아마도 당신의 일생에 걸쳐 개선해나갈 가장 가치있는 것일 것이다. 이런 관계들을 발전시키고 함께 만드는 게임을 개선할 수 있는 기술을 찾길 바란다.

추천 비추천

2

고정닉 0

댓글 영역

전체 댓글 0
등록순정렬 기준선택
본문 보기

하단 갤러리 리스트 영역

왼쪽 컨텐츠 영역

갤러리 리스트 영역

갤러리 리스트
번호 제목 글쓴이 작성일 조회 추천
설문 SNS로 싸우면 절대 안 질 것 같은 고집 있는 스타는? 운영자 24/05/06 - -
AD 나혼렙 어라이즈 그랜드 론칭! 운영자 24/05/09 - -
공지 게임 기획 관련 사이트 모음 (2021.5) [7] Dunkirka갤로그로 이동합니다. 18.10.30 1541 1
공지 게임기획 잘하는 방법 Dunkirka갤로그로 이동합니다. 19.08.29 975 3
공지 게임 기획서(GDD) 총정리 (2018.11) [3] Dunkirka갤로그로 이동합니다. 18.10.30 3044 3
공지 게임 디자인 관련 추천 도서 (2018.11) [6] Dunkirka갤로그로 이동합니다. 18.11.12 5765 1
557 상업 용도 사용 가능 AI BGM 생성기 추천! 게갤러(220.65) 05.08 12 0
556 제19회 경기게임오디션 청중평가단 모집 안내 스펙토리갤로그로 이동합니다. 05.07 3 0
555 게임하면서 컴터 켜놓기만해도 쌀먹 쌉가능?? 필독 ㅇㅇ(146.70) 04.12 26 0
552 제19회 경기게임 오디션 안내 스펙토리갤로그로 이동합니다. 03.26 26 0
551 아우디 로고 디자인 수정 건의. TXT 미노루갤로그로 이동합니다. 03.13 39 0
550 아우디 로고 일케 바꾸면 훨 좋을 듯. TXT 텐구아레스갤로그로 이동합니다. 02.25 34 0
548 김실장 채널 꽤 괜찮네 게갤러(112.156) 23.11.29 151 1
547 게임 기획/개발/디자인 경험을 살려 창업을 할 수 있다면? 함께가자(14.4) 23.11.17 109 0
545 게임 개발 (진지한 글 주의) 부트캠프 후기 아이폰어플개발(125.131) 23.09.25 195 0
544 [취업을 도와줄 PM 템플릿/자료] 개발자갤로그로 이동합니다. 23.09.22 113 0
542 게임 만들기 ㅇㅇ(203.228) 23.08.03 103 0
541 비대면진료,맞춤주치의 닥터루시드를 만들고자 합니다_크로스앱개발자2(RN) 맞춤주치의(39.123) 23.08.01 55 0
540 [정보] 게임 개발에 관심이 있으신 경우 ㅇㅇ(210.103) 23.06.30 364 1
534 게임 기획 갤을 찾아온 뉴비들아 현업 질문 간절하면 연락해라 겜갤러(221.150) 23.02.20 447 2
533 갤에 유용한글 만네 ㅇㅇ(210.95) 22.12.26 219 0
532 해커같은 애미 뒤진 련 빼고 암살자나 쳐 내지 ㅇㅇ(220.122) 22.12.18 155 0
531 야 늬들은 게임잡에 포폴 올리고 스카웃 신청 받은 적 있냐? [1] ㅇㅇ(1.241) 22.11.23 340 0
530 요즘 펄어비스 내부어떠냐 아직도 개씨발이냐? [2] ㅇㅇ(118.235) 22.11.18 440 0
529 uv맵 좀 징그럽지 않음 ? ㅇㅇ(58.141) 22.10.13 164 0
526 기획 관련 질문입니다 [1] ㄱㄱ(128.134) 22.08.20 350 0
525 언리얼엔진5 루멘 라이팅의 퍼포먼스를 보여주는 해외 작품. 슬기로운스캔생활갤로그로 이동합니다. 22.08.13 192 0
522 갤 사람이 거의 없나? [1] 도기갤로그로 이동합니다. 22.06.04 359 0
518 이런 갤이 있었네 [1] ㅇㅇ(49.142) 22.03.18 303 0
517 혹시 만든 겜 홍보해도돼? [6] 엠제이마크갤로그로 이동합니다. 22.03.10 875 7
515 메타버스플랫폼 기획서때문에 예시를 만들어야하는데 사용할만한 툴 있을까요? [1] ㅇㅇ(122.34) 22.02.27 421 0
514 주딱 머함? ㅇㅇ(124.197) 22.01.16 212 0
513 창세기전 > 파판 > 원신 철학이 없는 차이나치 게임 ㅇㅇ(121.160) 22.01.02 243 0
512 보이스 게임 만들어보신 분 ㅠㅠ [1] ㅇㅇ(110.9) 22.01.02 146 0
511 여기 유익한 자료 엄청 많구나 ㅇㅇ(182.213) 21.12.22 308 0
510 이거 뭘까요?? ㅇㅇㅋㅋ(220.70) 21.12.06 309 0
509 여기 게임 디자인 관련 갤러리인가요? 아니면 게임 개발에 관련된 것? [1] 팡팡갤로그로 이동합니다. 21.11.19 618 0
508 혹시 이거 서로 같은 거야? ㅇㅇ(14.33) 21.11.06 202 0
507 이렇게 양질의 정보가 가득한 갤이 있다니 ㅇㅇ(106.102) 21.10.23 297 1
505 번역) 벤 브로드 - 게임 디자이너가 되는 방법 [2] 취업전선갤로그로 이동합니다. 21.08.03 949 7
504 번역) 벤 브로드 - 게임 업계에서 직업을 갖는 방법 취업전선갤로그로 이동합니다. 21.08.03 403 2
503 번역) The Door Problem: 직군별 문에 대한 문제 접근법 취업전선갤로그로 이동합니다. 21.08.02 335 4
502 안녕하세요 간만에 와서 인사글 써봅니다 ㅇㅇ(121.170) 21.07.22 207 2
501 언제 코드를 다시 써야 하는가. Dunkirka갤로그로 이동합니다. 21.07.02 274 0
500 온라인 게임 개발자가 Aim Lab에 관심을 가지는 이유 Dunkirka갤로그로 이동합니다. 21.07.02 420 0
499 생각한 것보다 까다로운 게임 현지화 Dunkirka갤로그로 이동합니다. 21.06.28 400 0
497 게임 디자인 과학이 중요한 이유 Dunkirka갤로그로 이동합니다. 21.06.14 747 3
496 개발사와 기획서 Dunkirka갤로그로 이동합니다. 21.06.14 367 0
495 게임 순위 차트 살펴보기 Dunkirka갤로그로 이동합니다. 21.06.07 434 0
494 게임 스토어 페이지의 '정보' 섹션을 개선하는 방법 Dunkirka갤로그로 이동합니다. 21.06.04 206 0
493 플레이어 보상하기 Dunkirka갤로그로 이동합니다. 21.05.30 481 0
492 다잉 라이트의 자연적인 이동 시스템 Dunkirka갤로그로 이동합니다. 21.05.30 278 1
491 튜토리얼 이후 플레이어 잡아두기 Dunkirka갤로그로 이동합니다. 21.05.27 266 0
490 마야 vs 블렌더 [1] Dunkirka갤로그로 이동합니다. 21.05.26 6122 1
489 생산성을 높이는 점진적 프로그래밍 Dunkirka갤로그로 이동합니다. 21.05.26 449 0
487 야근 안 하고 라이브 개발하기 Dunkirka갤로그로 이동합니다. 21.05.25 272 0
갤러리 내부 검색
제목+내용게시물 정렬 옵션

오른쪽 컨텐츠 영역

실시간 베스트

1/8

뉴스

디시미디어

디시이슈

1/2