[📜일지] 1인 개발 일지 2 - 기획 및 플레이 테스트

[tazo(scarce2861)]

1번째 글이 뭔가 추천을 좀 받아서 용기를 얻어 원래 다음날 쓰려 했는데 오늘 쓰기 시작

---

프로젝트도 선정했겠다. 바로 코어(핵심 게임 플레이 루프의 준말)부터 기획 및 개발함

코어 플레이 테스트(앞으로 코어라 부름)는 이동한다 -> 적과 부딪친다(데미지, 체력 교환) -> 보상 획득 -> 다음 적과 부딪친다

기획에서 저렇게 코어를 잡았으니 개발에서는 구현 뿐

아트 리소스는 sprite animation으로 다 바꾸고..

데이터 관리는 구글 시트로 하고..

개발에서는 구글 시트를 json으로 컨버팅하는 에셋 구매해서 사용하고..

구글 시트 및 데이터 준비

데이터 작업은 항상 global sheet를 앞단에 둠

글로벌 시트는 대충 이런 식임

그리고 몬스터 시트는 프로젝트간의 교류 가능하게끔 core character sheet부터 작성

core character sheet는 프로젝트에 종속되지 않음

스텟 계산은 클래식한 D&D 세계관에서 가져온 CR(ChallengeRating), 6 스텟(STR, DEX, CON, INT, WIS, CHA)를 기반

암튼 이걸 기반으로 게임에 실제로 사용하는 데이터를 작성함 (체력이라던가.. 공격력이라던가 등)

여기서부터는 뭐.. 기획자 by 기획자 마음이기 때문에 생략

개발

개발은 뭐.. 말하자면 끝도 없이 말할 수 있는데 말하기가 귀찮다.. 궁금해하지도 않을것같고..

큰 것만 말하자면 대충 레이어를 3단계로 짜둠

1. 프로젝트 레이어(프로젝트에 종속됨, 패키지 및 라이브러리에 의존)

2. 라이브러리 레이어(아트 및 장르(방치형 게임)에 종속됨, 패키지에 의존)

3. 패키지 레이어(프로젝트에 독립적, 라이브러리에 독립적, 그냥 혼자 살 수 있음)

암튼 핵심 게임 플레이를 빌드하는 데까지 약 2주? 정도 걸림

빌드가 나왔으면 이제 뭐하냐? 코어를 테스트 해야 함

테스트

근데 테스트 자체가 재미 없었다.. 기획에서 개발 편하라고 쳐낼 것 다 쳐내가지고.. << 이게 최대 관문

억지로 테스트 했다. 개발 하다가 쉬는 타이밍 있을 때마다

테스트 하면서 중요한 점은 피드백 혹은 리포트를 하는 것

어차피 보고자는 곧 담당자이기 때문에 리포트하는 데 있어서 어려움은 없었다.

어느날 스스로에게 피드백

스프린트 반복

스프린트 << 자세히 몰라도 됨

기획 -> 개발 -> 테스트 -> (개선)기획 -> 개발 -> 테스트 암튼 반복하는 거다~

이 반복하는 주기의 이름을 애자일에서는 스프린트라고 함

이렇게 개발 팀 내부(지금은 1인 개발)에서 계속 반복하면서

피드백이 쌓이고(나같은 경우는 이게 곧 백로그화 됨) 어느 걸 개발 할 지 선택하고(플래닝)

개발하고 (개발) 빌드하고 테스트하고 또 테스트한걸 피드백하고..

(스포)프로젝트 마감(=출시 스펙까지 개발)하는 데까지 한 달 걸렸는데 빌드는 개발 1주차부터 수십번 한 것 같음

여기서 중요한 것은 기획에서 핵심(=코어 혹은 프로젝트 차별요소 혹은 경쟁점)을 어기지 않는 선에서 피드백(나뿐아니라 다른 사람까지도)을 필터링하고 개발 일감화 해야 함

기획 변화

이 글은 기획 위주이기 때문에 기획만 얘기하자면(개발 얘기는 다음에)

처음에 프로젝트의 핵심은 달리기 -> 부딪친다(데미지 교환) -> 결과 -> 다음 도전 -> 막히면 환생 -> 환생 보상으로 처음부터 강화 -> 달리기 ... 반복

이었는데,

테스트 하면서 어? 어느 부분은 생각보다 재미 없네.

어? 어느 부분은 생각보다 재미 있네.

어? 어느 부분은 이걸 넣는게 어떨까? 하는 부분들이 있었다.

대표적으로 스킬, 스킬 트레잇인데 왜 최초 출시 스펙에 없는데 기획하려 했냐면

너무 경험이 단순하고 반복이라 지루했던 문제를 해결하기 위해 경험을 다양화 시키고 싶었다.

환생을 해도 수치적으로 조금 더 세졌을 뿐, 경험이 다르진 않았다.

그래서 환생할 때마다 스킬을 초기화하고, 스킬을 랜덤 선택하는 시스템을 넣었고

더 나아가 스킬을 랜덤으로 강화하는(뱀서류 3지선다같은)것까지 테스트 해봤으나, 결국 아트에서 막힘

스킬 트레잇이 들어가는 스킬 1개 기획할 때마다 아트 공수가 트레잇을 대응해야 하는데, 어떤 부분은 대응할 수 있었지만 어떤 부분은 안됐음 + 기획 공수가 컸음

그래서 기껏 개발했는데 그냥 출시 스펙에서 빼버림(결국 개발력)

결론

직전에 있었던 의사 결정 과정이 중요한게 무엇이냐? 지금까지 썼던 이 글의 핵심이 무엇이냐?

-> 결국 잘 모르면(재미든, 개발력이든) 개발부터 해보고 플레이를 해서 맛을 보아라

1. 내가 만들 게임 플레이의 상상도는 항상 긍정적으로 갈 수밖에 없음

그리고 이 상상을 다른 사람(나는 1인 개발이지만)에게 100% 똑같이 보여줄 수 없음

아바타처럼 연결한다면 모를까

1-1. 막상 다른 사람이 직접 해봤는데 재미 없다 하면 어쩔?

1-2. 빨리 가지고 있는 개발력으로 차가운 현실을 깨우쳐 줘야함 (그래야 이상한 기획 안나옴)

2. 소비자 시점에서 테스트하는 것도 필요함

결국 플레이하고 우리한태 돈을 주는 건 소비자이기 때문

그럼 돈을 주는 사람 시점에서 어떤 '경험'을 하는지 파악을 해야 함

3. 남은 기간 내에 얼마나 스펙이 남았는지 좀 더 구체적으로 추정 가능

모르는 것을 먼저 개발한다 -> 개발이 완료 되었다 -> 기간이 나옴

이 걸린 기간을 가지고 다음 플래닝 혹은 대략적인 계획을 할 때 '추정'을 할 수 있음

예를 들어, 이 챕터에 이 스테이지를 개발하는데 2~3일 걸렸으니, 다른 챕터의 다음 스테이지를 개발하는데도 2~3일정도 걸릴것이다. 가 되는 것

자기가 해보지도 않았는데 2~3일 걸린다 라고 할 수 있나? 할수야 있긴 하다. 근데 비슷한 경험이 아예 없는 거라면? 

예를 들어 155mm 대포를 유지보수하기 위해 나 혼자서 이 대포를 전부 기름칠하는데 까지 걸리는 기간은? (남들이 안해봤을 것 같은 경험 막 떠올림)

이게 없으면 '추정'은 결국 개발자의 즉흥적이고 주관적인 상상일 뿐이라고 생각

근데 문제는 이 즉흥적이고 주관적인 상상을 개발을 모르는 기획자 혹은 피디들이 그대로 믿고 가즈아~! 하다가 마감날짜 될때 쯤 어? 하는 것

[익명(106.241)]

와 뭔가 존나 전문적이네... 경력자임? - dc App

[익명(106.241)]

출시하면 링크 꼭 남겨 플레이해볼께 - dc App

[tazo(scarce2861)]

ㄱㅅㄱㅅ 경력자 맞긴함 첫번째작은 부끄러워서 못올리겠다..

[-인.(unicornmoim)]