[🐣질문] 님들아 기획자랑 협업할때

[도토리쥐(apost1234)]

몬스터관련 테이블을 만든다고 할때

스탯의 종류는 기획자가 정한다고 하고

테이블을 어느정도로 정규화하고 어떻게 구성할지에 대해

1. 기획자가 혼자서 다한다

2. 프로그래머와 기획자가 상의하면서 한다

3. 프로그래머가 혼자서 다한다

- dc official App

[Indie 1(118.37)]

당연히 2번...기획자는 예외처리등 프로그램적인 부분에 약하고, 프로그래머는 밸런스등 기획적인 부분에 약함.. 둘이 같이하면 서로 상호보완 해서 시너지를 내야지..

[Indie 1(118.37)]

상의하면서 하면 100% 서로 "아...이건 생각 못했네" 하는 상황이 계속 나와서 재밌음...

[도토리쥐(apost1234)]

그치 그게 맞겠지? - dc App

[도토리쥐(apost1234)]

좋은의견 감사합니노 - dc App

[Indie 2(110.12)]

상의는 당연히 해야 하는거고, 상의 하는 방법이 중요하다고 생각함. 나의 경우는 둘 중 하나가 본인의 생각을 쭉 정리를 하고 난 다음 그것에 대해 상의하면서 보완하는게 일이 수월하게 진행됐음. 우선 구두나 러프한 기획서로 기획 내용을 전달하고 프로그래머가 이 내용을 소화해서 '적절히' 구현한 다음 기획자가 이 구현 내용이 기획 내용에 적합한지 등을 검토 상의 하면서 개선 하는 방향이 좋았던 것 같음.

[Indie 2(110.12)]

내 생각에 이런 형태로 진행하는게 가장 속도도 빠르고 결과물도 좋았음. 하지만 상당히 많은 수의 프로그래머는 위의 방법을 버거워하고 상황을 싫어함. 여튼 말하고자 하는 것은 진행도 0인 상황에서 닥치고 '같이 상의해보자'라고 하는 것은 일이 잘 되지 않는 다는 것임. 둘 중 하나가 먼저 딥하게 들어가서 많은 고민 후 결과물을 내어야 함. 그것이 러프한 개발 결과물이든 디테일한 테이블 기획서든.

[도토리쥐(apost1234)]

음 확실히 준비를 해놓고 상의를 하는게 젛은것 같은 그냥 아무것도 없이 상의 하면 하다가 딴얘기로 빠져버리기도 하니까 - dc App

[Indie 2(110.12)]

한 가지 유의할 것은 기획이 딥할 수록 구현도 딥하고 무거워질 수 밖에 없다는 것임. 프로그래머는 기획이 딥할 수록 모든 것을 고려해 '이 기획이 유지된다면' 앞으로 수정하지 않아도될 최선의 결과물을 내고 싶어함. 하지만 기획이란 것이 변경되지 않을 리는 만무하기에 구현 초기 단계에서는 서로 러프하게 접근하는게 좋다는 생각이긴 함. 역시나 대부분의 프로그래머는 이러한 작업 방식을 잘 납득 못함.

[Indie 2(110.12)]

만들어서 구현을 확인하고 재미를 검증하고 디벨롭하는 단계와. 이 정도 시스템 선에서 컨텐츠를 양산해보자 라는 단계는 서로 다른 단계이고 각각 다르게 일을 해야할 것임. 몬스터 관련 테이블을 '만드는' 단계라고 했기에 처음 몬스터 시스템을 구축하는 단계라 생각하고 주는 의견이니 참고하기 바람.

[도토리쥐(apost1234)]

근데 보통의 게임개발 경우엔 워터폴 방법을 주로 사용하는걸로 아는데 왜 애자일 방법은 사용이 안될까요? 기획은 자주 바뀌는데 방법은 그대로 워터폴을 쓰니까.. - dc App

[도토리쥐(apost1234)]

기획이 자주 바뀌게 되는것도 문제되는거 아닌가요? 사소한 부분에서의 변경이라면 문제는 없겠는데 구성이나 설계를 바꿔야할 정도의 기획 변경은 문제가 있을것 같은데.. - dc App

[Indie 2(110.12)]

내가 추천하는 것은 구현 초기 단계에서는 애자일, 후반 단계에서는 워터폴임. 게임성을 만들어 나가는 초기 단계에서는 애자일로 러프한 단위로 빠르게 기본 단위를 검증하며 개발하는게 유리하다고 생각함. 이 단계에서는 기획이 큰 단위로 변경되는건 당연한 일임. 당연하다고 생각하는데... '애자일'이라는 프로세스를 추앙하는 듯 하지만 실제로 이 프로세스로 인한 수없이 많은 개발 변경, 뒤집음 이런 것을 잘 감당 못하는 개발자들이 많긴 함. 워터폴 프로세스로 일한다고 할 때 큰 기획 변경은 이슈가 있긴함.

[Indie 2(110.12)]

애자일로 하면 됨. 하지만 애자일스럽게 일하는 것은 실제로는 많이 어렵다는 것임. "대충 이런 것 부터 느낌 확인해보자"라고 하면 "ㅇㅋ 기획서 좀 더 자세하게 해봐"라는 대응이 꽤 많음. 서로의 애자일에 대한 이해와 수행 능력이 중요함.

[Indie 2(110.12)]

기획자를 일을 '주는' 사람이라 생각하기 보다 일을 '만드는' 사람으로 이해하는게 좋다고 생각함. 기획자는 좋은 플레이 경험을 만들기 위해 일을 '만드는' 사람임. "네가 준 일이 예전과 달라졌네... 앞으로는 일이 바뀌지 않도록 해줄래?" 같은 마인드는 좋은 개발자 마인드는 아니라고 생각함. 게임에 답이 정해져있는 건 아닌데, 프로그래머는 답을 찾기 위한 일을 주로 하기 때문에 생각의 격차가 자주 발생한다고 생각함.

[Indie 3(112.218)]

기획자가 AI에게 시켜서 게임을 만든다고 쳐보자 서로 상의 해가며 진행해야지만 가능하다. AI도 이런데 사람이라고 크게 다르지 않음.

[28(personal7900)]

222 방식의 문제라고 보는데요. 프로그래머가 선행해서 사용하기 좋게 테이블 작성할지, 기획자가 원하는 대로 테이블 작성이 필요한지 적절히 판단하셔서 하시면 좋을듯! 테이블 관리를 기획자가 많이 해야하고 복잡해서 관리가 필요할것 같으면 기획자한테 넘기는게 좋다고 생각.. 그런거 아니라면 플머가 코딩하기 좋게 짜는게 효율적인듯 합니다. 상황에 맞게 ㄱㄱ