(레딧번역) 1인 개발자들을 위한 워크플로우

1인 개발자들을 위한 워크플로우

Workflow for Solo Indie Dev

이 글은 Reddit.com/r/gamedev에서 최초 작성되었으며, 

이후 제가 디시인사이드의 인디게임 개발 갤러리에 번역하여 올린 포스팅을 조금씩 다듬어 올리는 것입니다.

이런 방법이 옳고, 다른 방법은 틀렸다는 내용이 아니라 서로 정보를 공유하고 

자신에게 좀 더 맞는 방법을 찾고자 하는 목적의 게시글임을 명심해주세요.

원본 링크(레딧)

---

Workflow for Solo Indie Dev 한국어번역 / 원 작성자 - pTricked

안녕하세요. 

저는 질문에 답변해주길 좋아하기도 하고, 여기 오기 전에 아주 많은 조사를 해 봤는데 이 주제에 대해서 충분히 많은 지식을 습득했음에도 불구하고 제가 찾는 정보들은 없었어요.

1인 인디 개발자들을 위한 실용적인 워크플로우를 알아보고자 하는데요 

전 컴퓨터 프로그래머/음악가 출신이고, 제 게임의 모든 아트워크는 구매하거나 외주로 맡기려고 해요.

이런 방식을 사용하는 이유는, 워크플로우는 상황(또는 배경)에 따라 유기적으로 구성되어야 한다고 생각하기 때문이에요.

현재 제 워크플로우는 다음과 같습니다:

1. 전체적인 일정을 기술해놓은 Trello board를 가지고 있습니다. (예 : 프리 프로덕션, 알파, 베타, 출시로 나뉨)
2. 현재 진행 중에 있는 일정에는 표식을 달아놓거나 색으로 강조합니다. (현재는 프리 프로덕션입니다.) 그리고 현재 작업중인 일정 내의 상위 항목들에 대한 리스트를 따로 작성 해 놓았습니다. 지금같은 경우엔 레벨(맵) A 디자인이라던가, 그런 종류의 것들이 올라가 있죠.
3. 그 상위 항목들 중 현재 작업중인 안건을 표시해 놓고, 거기서 또 세분화시켜 완료 표시를 남길 수 있을 정도로 작은 규모의 작업들을 리스트로 가지고 있습니다.
4. 전체적인 일정들과 상위 항목들에는 마감 기한을 정해놓았습니다. 하위 항목들에는 따로 정해놓지 않았구요.
5. 하위 항목을 모두 완료하면, 상위 항목 하나를 완료한 것으로 표시하고 다음으로 넘어갑니다. 그 다음 해당 상위 항목의 하위 작업들을 판단/결정하고 개발에 착수하는 식입니다.
6. 그렇게 모든 상위 항목을 완료하면, 한 단계의 일정이 완료되며 다음 일정으로 넘어갑니다.

지금까지 이 방법으로 아주 잘 해오고 있구요, 특히 Trello가 정말 좋아요.

제가 헷갈리는 부분은 좀더 이상적인 이터레이션과 작업 과정에 대한 거에요. 예를 들어서, 프로토타입을 제작하는 것이 현명한 일일까요? 만약 그렇다면, 여러분은 몇 종류의 프로토타입을 만드나요?

이 기사를 보시면 <기사> 프로토타입에 상대적으로 더 많은 노력을 들여서 게임이 재미있고 의도한 모든 것이 작동하는지를 검증하되, 거기까지만 하고 다른것은 모두 graybox 처리하며, 아트는 마지막에 할 것을 제안합니다.

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

지금 제 작업 일정을 설명드리자면

1. 프로토타입 - 게임플레이의 샘플을 빌드하고 재미있는지를 검증합니다. (완료) - 이 과정은 완료하였는데, 모든 게 정상 작동했지만 이쁘진 않았어요. 처음부터 끝까지 핵심 목적은 실현 가능한지를 검증하는 것에 맞춰져 있었습니다. 게임이 잠재적으로 가질 수 있는 최대 분량의 데이터를 저장하는 것이 가능한지 알아보기 위해 세이브 시스템 또한 만들었습니다. 평소같았으면 세이브 시스템은 뒤로 미뤘을 텐데, 게임의 느낌을 결정하는 데 아주 중요한 사안이었기 때문에 구현시켰습니다.
2. 프리 프로덕션 - 월드의 구성을 디자인합니다. 현재 제가 작업중인 단계입니다. 레벨의 구조물, 분석, 요소들이 어떻게 어우러질지, 퍼즐 같은 것들을 구상하고 있는데, 모든 과정은 종이와 Trello를 이용해서 작업중입니다.
3. 프로덕션 / 알파 - 2번째 과정에서 나온 요소들을 모두 'graybox'하여 게임이 시작부터 끝까지 모두 작동하는 지 알아보는 과정으로 하려 했던, 하지만 아직 아무런 아트 과정도 거치지 않은 단계입니다. 
4. 프로덕션 / 베타 - 이 과정에서 아트를 거쳐 게임을 꾸미고 동시에 버그를 수정하려고 했습니다.
5. 출시 - 베타 직후부터 출시까지 버그 수정만 거치게 될 단계입니다.

프리 프로덕션이 좀 과하게 힘든 과정이 될 것 같아 보이는 동시에 충분한 수준으로 구현되지 못할 것 같아요. 거대 스튜디오가 아닌 1인 개발의 특성상 일종의 이터레이티브한 접근이 좀 더 낫지 않을까 하는 생각이 듭니다. 예를 들면 레벨 하나를 graybox하고 AI와 퍼즐을 넣는 과정으로 Iterate하고 난 다음 다음 레벨을 디자인하는 식을 반복하는 거요.

다른 솔로 인디 개발자(혹은 였던)분들의 조언과, 여러분들은 전체 개발 과정에서 어떤 방법이 가장 효과적이었는지를 듣고 싶어요.

고마워요!

<정보) 'graybox'하다 : 별도의 머티리얼이나 세부 모델링, 또는 사운드를 첨가하지 않고 게임플레이 메커니즘 자체만 구현하는 방식>

<정보) 이터레이트(Iterate) : 격주 개발 또는 구현-피드백 순환같은 개발방식을 통해서 제품에서 부족한 점을 향상시키는 개발 방식. 또는 개발 주기 자체를 칭하기도 하는 광범위한 용어. 사전적인 뜻은 단순히 '반복'을 일컫는다.> 

astrallurker

모든 걸 아주 잘 파악하신 것 같군요. 사실 저도 이 포스팅에서 몇 가지 배우고 갑니다.

제 의견을 말씀드리자면 Iterate적인 방법이 효율적인 것이 있고, 계획적으로 짜여진 작업이 효율적인 것도 있다 생각합니다.

저는 이전에 레벨 디자인 쪽으로 경험이 좀 있었는데 게임 개발의 단계는 딱 중간부터 시작하는 것이 최고라고 판단했습니다. 

50종류의 단계가 있다고 칩시다. 그러면 25단계부터 시작해서 양방향으로 제작하는 것입니다. 25단계는 기술적으로 완전하며 밸런스가 잘 짜여진 상태여야 합니다. 그보다 낮은 단계로 내려가면, 기술적인 요소들이 점차적으로 빠지고 단계적으로 레벨이 단순화되어 끝에는 튜토리얼 레벨같이 보이는 지점까지 도달합니다. 25단계보다 높은 단계로 올라간다는 것은 점점 더 엄격하게, 대충 넘어가는 일이 없이 만드는 것을 의미합니다. 이 과정에서는, 밸런스와 관련된 작업은 많이 덜게 되며 과도하거나 평평한 수준의 학습 곡선을 방지할 수 있습니다. 

컨트롤의 느낌과 요소들 간의 상호 작용을 디자인하는 과정만 이터레이트적인 작업이 필요하다고 생각하는 부분입니다. 

게임 출시일 직전까지 컨트롤의 느낌을 만지는 작업을 반복하고 있대도 놀랄 일이 아니에요.

프로토타입 쪽에서는, 그냥 많이 만드는 것보단 모듈러 형식으로 만들어서 어떤 기능을 먼저 진행하고 나중에 진행할지 결정하는 것을 선호합니다. 만약 어떤 기능이 게임을 어수선하게 만들거나 불필요한 것이라면 저평가시키기도 합니다. 각 기능의 중요도를 점수로 매겨서 게임을 밸런싱하는 데 도움이 될 수 있게끔 해보세요.

ㄴ pTricked

댓글 고마워요!

 프로덕션 과정 중에 말인데요, 최종 아트 작업 같은건 마지막에 하시는 거겠죠? 개발 중에 너무 과하지 않을 정도로 적당한 디자인 요소를 작업하는 정도를 어떻게 조절하면 좋을 지 고민중이에요. 구현에 들어가기도 전에 디자인 관련 문서가 산처럼 쌓이는 일은 피할 수 있게요. 

사실 제 질문에 정확한 답이 있는지도 모르겠어요. 그냥 개인 취향 차이의 문제일 수도 있겠죠. 제 내면 한편에서는 게임 전체를 계획하고, 구현한 다음에 보완 및 아트 작업을 하길 원하는데, 또 다른 한편으로는 전통적인 소프트웨어에서 배운 요소들을 활용해서 내가 가는 대로 만들어나가고 싶은 부분도 있어요.

 그 방법을 고려해보기 위해서, 지난번 Ludum Dare에서 금요일 밤에 게임을 디자인하고 주말간의 작업을 계획했어요. 토요일에는 정확히 계획한 대로 실행했고 오후 1시쯤에 하루 일과를 마쳤어요. 일요일에는 계획했던 것을 끝낸 뒤에 엔트리를 제출했구요. 결과는 31등이었고 기간 중에 단 한번도 과로나 지치는 일이 없었는데, 이 방법을 장기 프로젝트에 적용했을 때 얼마나 괜찮은 방법이 될지 모르겠어요. 내가 디자인하고 있는 게임플레이에 대해서 직접 느낄 수 없으면, 폭포수 개발 모델을 차용하던 시절로 회귀한 기분이에요. 그 모델이 결국 어떻게 됐는지 보세요. 

 소프트웨어 개발자 신분으로 있었을때 제 생활은 항상 디자인 반 구현 반이었고 특히 "제대로 만들기 어려운"부분을 디자인할 땐 아주 많은 시도를 해야 했거든요. 게임 개발은 저에겐 완전히 새로운 분야라서 디자인과 구현의 사이에서 한쪽에 너무 치우치지 않고 딱 적절한 균형을 찾고 있어요. 

격주 개발같은 방법이 효과적일수도 있을까요? 한 주 동안은 월드와 게임플레이를 구현하고 디자인을 검증하는 데 쓰고, 다른 한 주는 디자인한 걸 수정하고 개발 주간에 배운 것들을 받아들이는 시간으로 사용하는 거죠.

<정보) Ludum Dare : 라틴어로 "to give a game"을 뜻하며, 제한된 시간 내에 게임을 만들어 경쟁하는 행사.>

ㄴㄴastrallurker

<1문단 답변>

아트는 외주로 돌리기로 하셨으니까, 이 경우엔 최소 2단계의 아트 개발 과정이 유효해요.

첫 단계는 당연히 작성자님이 아트스타일을 직접 결정하시고, 외주 작업자들이 그걸 가공하는 과정이 될거구요,

둘째 단계에서는 1단계에서 나온 컨셉아트를 기준으로 게임에 필요한(작성자님이 원하는 거 말구요) 모든 종류의 아트를 리스트로 정리해야 합니다.

저는 아티스트 출신으로 혼자 게임을 개발중인데, 다른 아트들은 어떤 게 필요한지를 정의할 수 있을 정도로 충분한 수준의 프로토타입이 완성된 뒤로 미루되 컨셉아트는 MVP 단계에(뜻은 뒤에 나옴) 제작해야 한다고 생각해요.

<3문단 답변>

1인 개발의 최대 장점은 일정 관리의 유연성이에요. 개발 주기를 격주로 고정하는건 팀 개발에서만 효과가 있을 것 같아요. 제가 틀린 걸 수도 있지만 지금 저는 전체적인 디자인 일정을 짠 뒤에, 우선 순위를 부여하고 몬테 카를로 트리로 정리하는 식으로 나눠 분류한 다음 그 몬테 카를로 트리에서 쭉 내려가는 식으로 구현합니다.

<정보) 몬테 카를로 트리 Monte Carlo Tree : 의사 결정에 있어 어떤 동작들을 실행할 지에 대한 선택지들을 트리 도표의 방식으로 정리하는 방법.>

ㄴㄴㄴpTricked

그러면 전통적인 폭포수 모델로 디자인을 하고, 그 다음 몬테 카를로 트리를 사용해서 우선 순위에 기반한 구현을 하시는건가요?

아트를 시작하기 전에 게임 전체를 플레이 가능하게끔 프로토타입을 제작하는 과정을 두시나요? 개발 초기에 컨셉 아트 과정을 거치는 건 이점이 있어 보이는데, 아트 이전에 게임 전체를 graybox로 제작하는 방법이 정말 마음에 들었거든요. 

제가 생각하던 방법이랑 일맥상통했던게,

1. 전 아티스트는 아니지만 눈이 정말 좋아요(눈이 낮다던지 비위가 좋다던지 그런 뜻인듯). 그래서 게임을 이쁘게 꾸미는 건 뒤로 미룰 수 있고 만약 못생긴 CSG graybox에서 플레이할 때 재밌다면 아트와 사운드이펙트, 음악을 삽입한 뒤에도 재미있을 거라는 걸 알기 때문이에요.
2. 불필요한 작업, 돈, 시간 등등을 예방해줘요.

ㄴㄴㄴㄴ astrallurker

<전통적인 폭포수 모델로 디자인을 하고, 그 다음 몬테 카를로 트리를 사용해서 우선 순위에 기반한 구현을 하시는건가요?>

맞기도 하고, 아니기도 합니다. 저는 어떤 기능이 선결 조건이고 어떤 게 특징인지를 인지한 상태에서 1인 프로젝트를 해나가는 게 훨씬 쉬워요. 몬테 카를로 트리는 제가 한 방향으로 쭉 나아가야 하는지, 아니면 아직 미구현된 핵심 기능을 개발하기 위해서 가지를 확장해 나가야 하는 지 결정하는 걸 돕기 위한 거에요. 복잡하게 들릴 수도 있지만 저의 경우에는 색으로 강조된 To-Do 목록이나 간트 차트를 가지고 있는 것보다는 이 방법이 훨씬 효과적이었어요. 예전에는 작성자님과 비슷한 색강조된 일정표를 가지고 있었는데, 몬테 카를로에 맞게끔 큰 그림들로 바꿨어요.

<아트를 시작하기 전에 게임 전체를 플레이 가능하게끔 프로토타입을 제작하는 과정을 두시나요?>

저도 그 과정을 두고 있는데, 차이점이 있다면 그걸 MPP(Minimum Playable Product, 플레이 가능한 최소 수준의 제품)라고 부른다는 점이에요. 여기선 색으로 구분된 히트박스들만 사용해요. 여기서 컨셉 아트를 추가하면 MVP(Minimum Viable Product, 최소 기능 제품)가 됩니다. 아트를 직접 하시는 거라면 마지막 단계에 하는 것도 괜찮아요. 그런데 작성자분의 경우엔 외주를 주시는 경우이니 아티스트들이 MVP 단계를 플레이할 수 있게 해 주시거나, 게임을 플레이하는 영상을 제공해주는 것이 출시일을 많이 앞당겨 줄 거에요. 아트 작업은 시간이 오래 걸리기 때문에 이 단계에서 작업을 전체적으로 시작하는 게 더 효율적이라 생각해요.

<2문단 답변>

개발에 시간을 더 쏟을 여유가 있다면 사실 말씀하신 방법이 더 낫습니다. 이전에 제가 몸담고 있었던 프로젝트의 경우가 이 방법을 사용했는데 어느 시점부터 프로그래머의 중요한 작업거리가 다 떨어져서 우리 3명이 아트와 음악 작업을 하는 동안 컨트롤 작업만 계속하다가, 어느 날 프로그래머가 아트를 훨씬 일찍 시작했어야 했다고, 괜히 3달동안 아트가 끝나길 기다리면서 진부한 반복 작업만 하게 됬다고 말한 적이 있어요.

ㄴㄴㄴㄴㄴpTricked

와.. 진짜 유익한 조언 감사합니다. 이 몬테 카를로 구조라는 게 어떻게 생겼을 지 궁금하네요.

특정한 툴을 쓰시나요?

ㄴㄴㄴㄴㄴㄴastrallurker

따로 쓰는 건 없구요, 종이랑 펜으로 작성합니다. 예전엔 Trello로 작성하곤 했는데 몬테 카를로 방식으로 관리하는 새 방법이 마음에 들어서 현재는 쓰지 않아요.

제 로그북은 공유하기엔 너무 복잡한 상태라 몬테 카를로 트리를 넓은 벽 같은 데에 하나로 배치하면 어떤 모양이 될지 나와있는 사진을 첨부합니다.

ㄴㄴㄴㄴㄴㄴㄴpTricked

올려주셔서 감사합니다. 처음 보기엔 되게 복잡해 보이는데, 분명 이걸 쉽게 이해할 수 있게 해주는 원리가 있을 것 같네요.

et1337

저는 10페이지짜리 구글독 하나에 "디자인 현안 문서"라는 이름을 붙여놓고 사용해요. 단기, 중기, 장기 할일 목록에다 전체적인 디자인 목표랑 스토리 개요가 추가된 형태로요. 별개로 스프레드시트 하나에다 오디오랑 대화 에셋들을 정리하구요.

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

MoLoLu

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

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

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

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

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

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

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

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

ㄴpTricked

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

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

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

다시 한번 고마워요!!

(정보 : 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로도 진행))

bkbl

게임 개발자 몇분이 말해준건데, 피보탈 트래커(Pivotal Tracker)를 몇 달간 사용하면 정확히 들어맞기 시작한대요. (당신의 작업 속도를 학습하는 방식인데, 제대로 사용하려면 숙달될 필요가 있긴 해요.) 그 외에는 Trello에 한 표 던집니다.

ㄴpTricked

제안 고마워요! 잠깐 살펴봤는데 첫 인상으로는 거의 기존의 소프트웨어 모델이나 팀을 대상으로 한 소프트웨어 같아요. 게임 개발 팀에는 아주 좋을 것 같은데, 1인 작업에 적용하기엔 너무 과한 감이 있는 것 같네요. 덧붙이자면 저도 Trello를 진짜 좋아해요

<정보) Pivotal Tracker : Pivotal Labs에서 개발한 애자일 방식의 프로젝트 스케줄링을 지원해주는 툴. 

가입 후 첫 30일간은 제한 없이 무료이며, 3인 이하의 팀은 2GB의 저장 공간 내에서 2개의 프로젝트까지 무료로 사용할 수 있다.>

Eymrich

제가 프로토타입을 만드는 법칙은 "에셋 없이도 재미있고 완벽하게 조율된 게임플레이를 만드는 것"입니다. 색도 입히지 않고 오직 큐브만 사용해요.

필요한 경우에 간단한 사운드 정도만 넣어주고요. 이 방법으로 재미있게 만들 수 있다면 문제가 전혀 없는거죠. 작성자님도 그 길을 비슷하게 걸어오신 것 같네요.

그건 그렇고, 핵심적인 게임플레이를 한 주 정도만에 만들 수 없다면 그건 진행할 가치가 없어요. 물론 예외는 있습니다만, 가장 중요한건 완성까지 수 년 단위로 들어가는 게임은 피하자는 거에요.

"세련된 프로토타입"은 보통... 제 기준으로는 앞서 말씀하신 수직적 단면(Vertical Slice)이라고 보는데, 모든게 정상적으로 돌아가는걸 확인하고 커밋을 한 '후'에 하는 건 정말 좋은 아이디어에요. 최종 완성된 수준의 게임플레이를 5분에서 10분 정도의 분량으로 만들어 보는거죠. (사운드, 그래픽 에셋 전체를 포함한 완벽한 게임플레이로) 레벨(맵)의 경우에는 게임 초반부보다는 좀 심도 있는 수준의 레벨을 만드는게 좋아요. (분명 재밌을 거에요)

이 방법으로는 2가지 목표를 달성할 수 있는데,

1)에셋 전체를 만드는 데 얼마나 걸릴 지를 좀 더 잘 이해하게 될것이며, 시각적으로 보여지는 부분의 코드를 아마도 좀 더 현명하게 이해할 겁니다.

2)잠재적인 퍼블리셔들이나 기자, 유투버들 등의 흥미를 끌 수 있을만한 보여줄 거리가 "항상" 있을겁니다.

다른 어떤것보다 시간을 제일 중요하게 고려해야 해요. 저는 그부분에서는 아직 미숙하지만, 알파 단계에 도달하기 위한 시간은(주된 게임플레이 제작이 다 끝나고, 가공이 남은 단계) 게임 전체를 만드는 데 걸리는 시간의 1/3.14도 안돼요. 물론 많은 요소들에 의해서 좌우되긴 하는데, 그렇더라도 "충분한 테스트를 거쳤고, 세련되어 있으며, 버그가 없는 게임"을 만드는 것 보단 거의 무조건 적게 들죠.

<정보) 수직적 단면 Vertical Slice : 시연이나 개발 일정 판단, 데모 등을 목적으로 만들어진 짧은 분량의 게임플레이. 보통 최종 출시되는 수준의 퀄리티로 제작됨>

ㄴpTricked

고마워요!

제가 했던 다른 질문(가공된, 단편적인 프로토타입)을 정말 잘 짚어 주셨군요 (사람마다 다른 방식을 쓴다는 걸 알아요)

1인 인디 개발자들에게는 단편적인 게임플레이를 제작하는 것이 전체적인 진행과정을 미리 판단할 수 있고, 추가로 게임을 소개할 때 사용할 수 있다는 점에서 충분히 가치가 있다는 말씀 같군요. 

정말 좋은 아이디어라고 생각했는데, 이게 프로젝트 중반쯤에 준비되게끔 해야 하는 건지, 초반에 준비해야 하는 건지, 아니면 언제 준비해야 하는 건지 궁금했어요.  마케팅적인 측면들에 대해서는 여기서 지겹도록 토론되는 걸 알고는 있지만, 어떻게 기업들은 매번 다른 단면을 소개하는 듯 보이는지가 항상 의문이였죠. 다른 모든 부서가 게임의 최종 디자인을 작업할 때, 게임 코드에서 따로 분화되어서 데모를 제작하는 데에만 투자하는 부서가 있는 게 아닐까 하는 생각을 해요. 일부 게임들은 수명주기 초반에 이런 데모들을 볼 수 있는데, 가끔씩 출시된 결과물이 그것과 딴판일 때는 정말 이해가 안돼요. 뭐 AAA급 타이틀에서만 일어나는 일일수도 있겠지만요

ㄴㄴEymrich

제 경우는 어떤 게임을 만드는지에 따라서 가장 많이 좌우돼요. 우선 "큰" 프로젝트에서 그렇게 해요. 1년 이상의 프로젝트에서라고 말해두죠. 

두번째로, 저희 작업선에 있지 않은 사람들에게 보여줄 필요가 있을 때 사용해요. 예를 들어서, 제가 특정한 게임을 정말 만들고 싶어요. 그리고 제가 아는 음악가를 프로젝트에 반드시참가시키고 싶어요. 그 사람은 저한테 자기는 비디오게임에 관해서는 하나도 아는 게 없다고 말했어요. 그러면 제가 해야 되는 게 단면적인 게임플레이를 제작하는거에요. 게임이 어떻게 만들어질지를 보여주는 "아주 잘 가공된 프로토타입"이죠. 그 사람이 게임을 많이 하던, 조금 하던 아무 문제가 없는 방법이에요. 주변의 다른 게임과 비교해볼 수도 있고, 그가 신뢰하는 다른 사람에게 보여주면 그들이 "괜찮네요. 해보세요"라고 말해주겠죠. 최소한은요...제 희망이에요 :D:D:D:D

그리고, 이 방법은 그래픽 파이프라인에 많은 스트레스를 줄 거에요. 초기 단계에서 처리해야 할 문제가 산더미같을거구요. 게임 중반에 있는 레벨을 만드는 거기 때문이죠(레벨이 10개정도 있다면 7번째 정도 맵을 단면 게임플레이로 만드는거에요).

마지막으로 말씀하신건, 상황에 따라 달라요. 이 방식으로 작업하는 스튜디오를 많이 들어봤어요.

1)주요 행사의 한달 전까지 게임을 작업합니다.

2)이벤트용 데모를 제작합니다.

3)데모 시연 이후에는 과정 2에서 했던 걸 고치고 쓸모없는 부분을 버립니다.

씻어내고 반복한다... 제 기억이 맞다면 이게 결국 No Man's Sky와 다른 많은 프로젝트들에 기대했던 사람들을 맥빠지게 만들어놓은 원인이죠. 제가 지금 작업중인 게임에서도 문제가 되는 부분인데, 프로듀서와 리드 디자이너는 항상 세련된 버전을 보여줄 수 있는 걸 원하거든요... 그게 모든 작업을 10배씩 더 오래 걸리게끔 만들어요.

ㄴㄴㄴpTricked

명백히 보이네요. 작업중인 버전을 세련된 상태로 유지하는건 시간을 많이 소모하죠. 그래도 세련된 프로토타입이 가치를 발휘하는 부분에 대해서 짚어주신 건 이해했어요. 아마 내년 중반에 IGF나 Indiecade에서 컨퍼런스를 진행해 볼 수도 있을 거 같은데 개발 주기가 1년이기 때문에 그 때쯤 베타 릴리즈가 될 수도 있어서, 그 중 하나를 진행할 때는 충분히 세련된 게임플레이 경험이 필요할 거에요.

ㄴㄴㄴㄴEymrich

무슨 말씀을요, 그리고 모든 걸 우리랑 공유해주셔서 고마워요! :D

zer0sumgames

전 그냥 구글독스에 거대한 To-Do 리스트를 두고 작업해요. PM은 그것만 있어도 되거든요.

ㄴpTricked

그 방법이 어느 정도는 유효한 거 같은데, 동시에 개발 주기가 필요보다 더 길어질 것 같기도 해요.

기존의 소프트웨어 수명주기에선 시간이 지날수록 점점 진화해요. 예를 들면, 제가 몸담았던 소프트웨어 사업에선 전세계 각지의 콜센터에서 사용하는 제품을 가지고 있었어요. 주단위로 새로운 기능들을 추가했고, 사람들은 그걸 좋아했죠. 처음 출시했을 땐, 물론 정상작동하긴 했지만 현재의 모습과는 많이 달랐어요. 아주 많이요. 시간을 거치면서 정말 많이 진화했거든요. 

그걸 기존의 게임 개발 주기와 대조해보면, 최종적으로는 100% 완성된, 아주 세련되어 있는 게임이 탄생해야 해요. Destiny같은 게임들이 그런 모델을 표방했지만 큰 성공을 거두진 못했구요, WOW같이 이 방법을 성공적으로 해낸 게임들은 확신컨대 초기 릴리즈부터 완벽한 상태였고, 시간이 지나면서 확장된 경우에요. 어느 경우가 됐던간에, 이 경우 우리는 거의 다 완성된 게임을 발매해야 하는 거죠.

이러한 기대로 미루어 볼 때, 기존의 이터레이티브한 접근법을 통해서 소비자의 피드백을 받는 것과 게임을 성장시키는 것은 서로 비슷하게 작용하는 것 같지 않아요.  만약 얼리 액세스를 한다면 좀 더 이터레이티브한 접근법을 통해서 잘 해낼 수 있을 거라고 생각해요. 만약 그게 싫다면, 99.99% 수준으로 완성되었으며 세련된 게임을 발매하는 편이 더 좋을 거에요.

자, 제 문제로 돌아가보자면 게임이 출시되었을 때 완전히 세련된 경험을 제공해 줄 수 있어야 한다는 기대감과 동시에, 우리는 개발 과정에 그 부분을 반드시 고려해야 해요.

개발 기간 중에 이터레이트를 너무 많이 해버린다면, 출시는 영원히 불가능할거에요. (Feature creep이라던가요) 만약 이터레이트를 충분히 하지 않고(좀 더 폭포수 모델 방식) 처음 디자인했던 대로만 만든다면, 우리가 시간 계산만 제대로 한다면 결과는 썩 좋진 않을진 몰라도 제 시간에 완성될 거에요. (보통 개발자들은 그렇지 못하거든요)

게임을 출시해본 경험이 있는 다른 인디 개발자분들에게 제가 듣고 싶은건, 개발 과정은 어떻게 진행되었는지, 그리고 제 시간에 발매하였는지 등의 여부에요.

ㄴㄴLaserDinosaur

구글 독스를 사용한다고 모두 폭포수 모델인 건 아니에요!

저는 개발 과정이란 해당 프로젝트의 성격에 맞추어 짜야 된다고 생각해요. 게임의 hook/apex는 장르나 복잡성, 프로젝트의 범위에 따라 크게 달라져요.

원하시면 저희 방식과, 했던 일들을(2인 팀입니다) 공유해드릴 수 있어요. 보시고 납득이 가신다면 작성자님의 프로젝트와 목표에 기반해서 조언을 해 주세요. 아무튼 관심 있으시면 메시지 보내주세요.

pTricked

맞아요. 구글독스가 폭포수 모델이란 뜻은 아니었어요. 잘못 표현한 거 같네요. 제 뜻은 상위로 어떤 구조도 갖지 않고 그저 방대한 To-Do 리스트를 갖고 작업한다면 저는 좀 Feature Creep 문제에 부딪힐 것 같다는 거였어요. 계속 리스트 마지막에 새로운 항목을 추가하게 되거든요.

지금은 Trello로 작업하는데, 새로운 기능을 추가할 때 디자인에 맞춰야 되는 구조로 되어있어요. 현재 진행중인 마일스톤에 맞추기 위해서는 상위 작업들을 새로 추가해야 되고, 그 항목들에는 또 기한이 있거든요. 그렇게 되면 결국 이전에 다른 일정에 할당했던 마감기한이 전체적으로 늦춰지게 되고, 그러면 저는 모든 일정의 마감 기한을 일일히 재조정해 주어야 해요. 그러면 결과적으로 출시 기한까지 미뤄지게 되는데, 그건 진짜 싫어요.

당연히 구글 독스로도 제 방식과 비슷하게 작업할 순 있지만, 별 생각 없이 새로운 것들을 추가하고 싶은 유혹이 존재해요.