[💬] 1인 개발자를 위한 워크플로우 - 레딧 포스팅 2부 (한국어번역)

<지난 포스팅>

다시한번 이 포스팅은 서로 조언을 얻고 어떤 방법이 자신에게 맞을 지 찾기 위한 글이지 어떤 게 맞고 어떤 게 틀리다를 논하는 글이 아님을 알림

시험기간에 개발까지 겹쳐서 좀 늦음 ㅜㅜ 다음주까지 시험있고 과제도 개발도 해야되서 3부도 다음 주말쯤은 되야될듯

그리고 수정할 게 있는데 iteration(대부분 반복 작업이라 번역함)이 단순히 반복작업을 뜻하기도 하지만, 개발 주기를 지칭하는 말이기도 하고

지난번에 설명한 Waterfall(폭포수) 방법론의 대체재? 격으로 개발에 주기를 설정해서 기간별로 다른 성격의 작업을 하는 것을 뜻하기도 하는 거 같음.

잘알 있으면 등판 좀 부탁함..

et1337

저는 10페이지짜리 구글독 하나에 "리빙 디자인 문서"라는 이름을 붙여놓고 사용해요. 단기, 중기, 장기 할일 목록에다 전체적인 디자인 목표랑 스토리 개요가 추가된 형태로요.

별개로 스프레드시트 하나에다 오디오랑 대화 에셋들을 정리하구요.

프리 프로덕션은 상당 부분이 프로덕션-알파 단계 하위로 들어가 있네요. 그것만 빼면 제가 만드는 과정이랑 비슷한데요!

MoLoLu

제대로 이해하신 거 맞습니다. 저도 이 부분에 대해서 여기다 말한 적이 있는 것 같은데 이거랑 관련된 거에요 :

<저는 이 접근이 굉장히 마음에 들었고 현재 따르고 있는 방법이기도 한데, 문제는 결국 더 많은 디자인 작업을 하게 될 것 같단 거에요.>

지금 저는..음..(찾아봄) 방 하나에 복도 하나, 좁은 공간 한곳 이렇게에만 136개의 C#과 유니티 스크립트가 돌아가요. 이런 공간에요 <사진>

제 프로토타입에 있는 건 문자 그대로 그게 전부지만, 대부분이 향후 만들어질 일반 버전에서도 사용 가능한 것들이고 핵심적인 기능들은 전부 의도한 수준에서 크게 벗어나지 않기도 해서 아마 20-30%분량 정도의 기능만 추가하면 될거에요. 그리고 사실 게임플레이의 모든 부분을 테스트하진 않습니다. (예 : 나중에 업그레이드 할 예정이거나 자주 수정하는 기능들) 기본적인 틀이 확실히 되었는지만 점검해요.

그리고 난 다음 더 나은 아트스타일에 대해 고민하거나, 나쁜 코드를 고치거나, 레벨들을 어떻게 연결시킬지 지도를 만들거나, 게임의 요소들이 어떤 방식으로 한데 모일 지를 고민하거나 하는 데 시간을 투자합니다. 동시에 그 시점부터 게임의 월드 제작에 착수합니다. (프로덕션-알파) 다만 저는 "베타" 에셋을 제작하는데, 이유는 제가 1인 개발을 하다 보면 결국 알파와 베타 둘 사이의 경계가 모호해지기 때문이에요. 보통은 게임이 가는 대로 제작하는데, 그러니까 튜토리얼부터 시작해서 거기서부터 나아가고, 추후 디자인 과정에서 결점이 발견되면 그 때 돌아와서 수정을 거치는 방식입니다. 제가 하는 방법이 작성자님이 궁금해하던 , 다시말해 'Iterate적인 접근'에 효율적인 방식이에요.

저 같은 경우엔 추후 컨텐츠를 빠르게 만들어내고 코드를 필요한 만큼 확장하려면 핵심 기능들을 프로토타입하고 코딩할 필요가 있어요. 제가 한 번의 과정만 거쳐서 개발을 시도하면 결국 스파게티 코드로 난장판이 되고, 의지할 프레임워크도 얻지 못해요. 즉 전체적인 디자인이 일관되지 못한 채로 끝나거든요. 대신 저는 모든 과정을 일거에 끝내기 때문에 초기 과정에서 몇 가지 분야(예 : 사운드나 특정한 기능)는 끝낼 수 있게 되는데, 보통 특정한 클래스나 오브젝트를 변형해서 사용하는 식이기 때문이죠. (무기의 경우 추상적인 방법으로도 작동하고, 개조도 가능하다는걸 알긴 하지만, 의도한 대로 될 때까지 코드만 만지작거리는 작업일 뿐이라 장비 업그레이드나 근접 무기는 코딩하지 않았어요.) - 여기서 예외가 하나 있는데 바로 월드의 상태를 저장하는 일입니다.만 아직 프로젝트가 거기까지 진행되진 않았어요.

그러고는 게임이 다 완성되고 모든것이 제가 정해놓은 수준에 근접하게 가공될때까지 계속해서 더 나은 물건을 만들어나갑니다.

시간적으로 효율적인 방법은 아니지만 혼자 작업할 때 좋은 게, 언제든지 작업의 흐름을 바꿔서 의도했던 바와 다르게 만들어진 부분을 고칠 수가 있거든요.

ㄴpTricked

정말 고마워요. 말씀하신 이터레이션이 어떤건지 알겠네요. 최소에서부터 시작한다는 말씀 같네요, 예를 들어 FPS를 만든다면, 카메라/이동/총 하나부터 필요한 거군요. 그 다음으로 두 개의 총이 필요하고, 그걸 추가하는 과정의 대부분이 이전에 작성한 코드들을 개선하기 위한 재작업이 되는 거죠. 그렇게 개선하고, 정리한 다음 다른 기능의 작업으로 넘어가는 거구요.

저도 첫 문단에서 설명하신 것과 정말 비슷한 것을 작업해왔어요. 제가 지금 만드는 게임에는 한 개의 "플레이 공간"이 있고, 거기엔 큐브 같은 것들로 이루어진 평면 공간이 전부에요. 그 곳에서 게임 기능들을 테스트하죠. 게임 자체는 진짜 보잘것없는데 기능만 비대한 상태에요.

댓글을 읽고 있으니 제가 올바른 길을 걷고 있다는 생각이 드네요. 사실 아트 과정을 거치지 않은 게 다행이라는 생각이 들었는데, 제가 충분히 생각해보지 못했던 핵심 기능의 존재가 떠올랐거든요. feature creep과는 전혀 다른 게 게임 전체에 스며들어야 하는 기능이라 이미 최종 단계 아트를 끝낸 상태였다면 이걸 구현하는 데 어마어마한 양의 눈물과 고통이 따랐을거에요.

다시 한번 고마워요!!

(정보 : Feature Creep이란, 조금이라도 더 많은 기능과 디테일을 구현하는 데 집중하고 매달리는 성향, 또는 개발 방식을 뜻함)

그림 출처 : https://www.chargify.com/blog/feature-creep/

ㄴㄴMoLuLu

별 말씀을요. 모두가 같은 방식을 쓰진 않겠지만 소규모의 팀이나 1인 개발 프로젝트들의 경우에는 비슷한 생각을 많이들 해요.

좀 더 규모가 큰 프로젝트에선(게임에서는 대규모 프로젝트 경험이 없지만 IT쪽에선 경험해봤습니다) 모든 팀원들이 개발 일정에 맞춰서 자신들만의 워크플로우를 적용할 거라 믿고 계획을 짤 수 있고, 또 그럴 필요도 있습니다. 혼자서 할 땐 한 가지 분야에만 집중할 수가 없기 때문에 빠른 속도로 심도 깊게 들어가기가 힘들어요. 이럴 때 스스로 "부서"나 "직책"을 옮기며 작업하면 프로젝트 전체가 함께 진전되는 게 보일거에요. 이 말은 곧 작성자님이 프로젝트 매니저의 역할도 해야 한다는 뜻이죠. 다른 사람이나 팀과 소통하는 대신 개인적으로, 한 번에 한 부분씩과 하는겁니다.

아트 과정에 대해 말씀하신 것처럼, 아트를 "모두" 혹은 전혀 하지 않으면 코드나 에셋을 자주 고쳐야 할 일도 줄어듭니다. 그게 목적이기도 하구요. 작성자님은 전체적인 퀄리티를 일관되게 유지하기 위해서 할 수 있는 최소한만 하려고 노력하고 계신 거죠.

새로운 과정을 시작하실 때(레벨 에셋 팩이나, 새로운 사격 모드라던가, 그런 거라고 해 두죠) 퀄리티를 올려놓고, 코드를 새로 추가하고는 잠깐 뒤로 물러서서 다음으로 어떤 작업이 가장 중요한지 판단해보세요. 이와 반대로 팀에 있을 때처럼 과정 전체의 완료에 중점을 둔다면, 경험이 쌓임에 따라서 나중에 작업한 게 초기에 작업한 것에 비해 양질이 되기 때문에 결과물들끼리 서로 잘 맞지 않을 수 있습니다. 결국 일관성을 유지시키기 위해서 결과물을 다듬는 데에 어마어마한 시간과 노력을 낭비하게 되죠. 제가 말씀드린 이 방법의 핵심은, 많은 노력이 반드시 들어갈 수 밖에 없는 것이 아니라면 시간 낭비를 피하는 거에요. (프로토타입이나 기초작업이 끝난 뒤로는요)

ㄴㄴㄴpTricked

<이와 반대로 팀에 있을 때처럼 과정 전체의 완료에 중점을 둔다면, 경험이 쌓임에 따라서 나중에 작업한 게 초기에 작업한 것에 비해 양질이 되기 때문에 결과물들끼리 서로 잘 맞지 않을 수 있습니다. 결국 일관성을 유지시키기 위해서 결과물을 다듬는 데에 어마어마한 시간과 노력을 낭비하게 되죠.>

아하, 이걸 보니 이해가 되는군요. 감사합니다.

Icelus

좋은 글이네요. 그리고 사실 워크플로우에 답이란 없습니다. 가장 잘 맞는 방법을 쓰세요.

저도 비슷한 워크플로우로 게임을 제작해요. 작업 목록에는 Trello를 쓰고, 개발 일정을 배치해놓죠.

개발 초기에는 제시해주신 Godot 포스팅에 나와있던 대로 했어요. 플레이스홀더 아트를 사용했고 게임의 기능, 테스팅, 피드백, 이터레이팅에 중점을 뒀어요. (그리고 큰 관계는 없지만 현재 제작중인 게임에 Godot 엔진을 사용중인데 정말 좋은 것 같아요)

워크플로우의 가장 중요한 목적은 게임플레이를 정의하는 것이라고 생각해요. 핵심 기능이 뭔가요? 재미있나요? 어떻게 하면 좀 더 재미있게 만들 수 있을까요? 어떻게 하면 피드백 과정을 단축시키고, 게임의 정체성을 조각해내고 강화시킬 수 있을까요?

게임플레이는 유저를 잡아두는 힘을 결정해요. 하지만 아트는 유저를 끌어들이는 역할을 하죠. 저라면 아트스타일을 디자인하는 데에 시간을 들일 거에요. 게임이 어떻게 보여져야 할까요? 비슷한 게임으로는 무엇이 있나요? 어떤 부분에서 비슷하게 보여질 것이며, 어떻게 차별화시킬 것인가요? 당신이 원하는 아트스타일을 제대로 달성할 수 있나요?

예를 들어서, 제 게임은 퍼즐 플랫포머입니다. 사람들이 말하기로는 다양한 퍼즐들에서 도전 정신을 느꼈고, 12개 정도의 레벨에 이끌렸다고 하더군요. 사람들은 방식의 차이와 퍼즐의 다양성을 좋아했습니다. 게임이 어떻게 진행되고 느껴지는지를 좋아했구요.

지금 저의 목표는 아트스타일을 정의하는 거에요. 컨셉 아트를 작업하는 아티스트와 함께 작업중이구요, 함께 생각해낸 아이디어들을 차용해서 인게임 에셋을 제작하고 있어요. 애니메이션과 씨름하고, 파티클 효과를 추가하고, 화면 떨림같은 것들을 작업중이구요.

작성자님의 워크플로우는 괜찮아 보이네요. 이미 핵심 기능은 추가하신 거 같아 보이는데, 새로운 아이디어가 떠오르는 대로 다시 돌아가서 가공하는 작업을 거치라고 말씀드리고 싶네요.

컨텐츠를 더 추가하고, 아트스타일을 정의하기만 하면 될 것 같아 보여요. 그리고 이미 잘 하고 계시구요. 행운을 빕니다!

ㄴ pTricked

답변 감사합니다. 저는 기능의 시각화랑 아트스타일을 거의 동시에 구상하는 편이에요. (그래픽적인)아티스트는 아니지만, 굉장히 아트적인 안목을 갖고 있죠. 그게 말이 되는 소린지는 모르겠는데 제 머리에서는 그렇게 돌아가요.

프리-프리 프로덕션 단계에서 아이디어가 떠오르기 전에도, 구글 이미지에 들어가서 아트 스타일을 검색해보는 걸 좋아했어요(게임 아트에만 한정하지 않고, 그냥 아트요). 그리고 뭔가 마음에 드는 걸 찾으면 게임만을 위한 Pinterest 보드에 저장했죠. 구글 이미지의 장점은 관련된 이미지 목록이 대개 정말 비슷한 스타일이라는 거에요. Pinterest 보드에 이미지가 적당히 모이고 나면, Pinterest에서도 좋은 것들을 추천해주기 시작해줘요.

이번에 여기서 받은 제안들 대로, 모든 기능을 구현하고 난 후엔 단편적이고 이쁘게 꾸며진 게임의 한 부분을 프로토타입으로 만들 예정이에요. Trello 보드도 맞게 수정하고, 그 다음 전체 아트 과정을 거친 게임의 1/10을 만든 경험을 기반으로 모든 과정들의 마감 기한을 재조정하려고 해요.

다시 한번 감사합니다!

ㄴㄴㄴIcelus

저도 그 과정에 있어요. 월드 하나를 만들거나, 처음 1/4부분을 만들고 아트 에셋을 최종적으로 마무리하는거죠.

그건 곧 타일셋 하나, 모든 오브젝트와 적, 또 애니메이션이나, 레벨에 캐릭터를 넣기 위한 재밌는 요소들 같은 것이에요.

피드백을 받고 싶으시면 다음번엔 스크린샷을 첨부해주세요!

ㄴㄴㄴㄴpTricked

꼭 그럴게요. 전 그 단계는 지나긴 했지만, 가능하다면 '피드백 금요일/스크린샷 토요일'에 꼭 참가할 거에요.

(정보: Feedback Friday/Screenshot Saturday는 레딧의 /r/gamedev에서 진행되는 주말행사 같은 것으로,

FF는 게임의 링크를 올리고 사람들에게 피드백을 받고, 역으로 그 사람들의 게임을 피드백해주는 문화이며(아트를 대변하는 스크린샷은 배제함)

SS의 경우 게임의 스크린샷, 애니메이션이나 영상을 올려서 게임 개발의 진척도를 알리고 사람들의 관심을 받는 문화임(동시에 트위터나 이런 데서 해쉬태그 #screenshotsaturday로도 진행))

꺅

[💬] 1인 개발자를 위한 워크플로우 - 레딧 포스팅 2부 (한국어번역)

댓글 2

다른 게시글