롤 스텟 중에 주문력이라는 개념이 있는데
이 개념으로 대다수의 캐릭터가 마법피해라는 개념이 존재하잖아? 아닌 것도 물론 있지만.
그러면 롤은 챔피언이 만들어지기 이전에 스텟이 존재한건가
아니면 챔피언이 만들어지고 난 뒤에 스텟을 추가한건가?
전자라면 어떻게 미리 나올 컨텐츠에 대해 거의 모든 경우를 시뮬레이션해서 스텟을 넣을 수 있는거야?
만약 후자라면 해당 스텟이 생김으로 인해 거의 모든 컨텐츠에 대한 수치 재설정이나 시스템 변경이 이루어질 것 같은데
그게 일반적인 개발 프로세스인거야? 그렇다면 개발일정이 픽스되어져 있는 상황에선 시스템 변경이 불가능할 거같은데
롤 주문력 정도라면 상상할 수 있는 범주 내일 수 도 있지만
POE라는 게임에서 공격이라는 개념과 주문이라는 개념이 있는데
공격 스킬들은 무기에 달린 데미지 기반으로 피해량이 산출이 되고
주문 스킬들은 스킬 자체에 달린 데미지 기반으로 피해량이 산출되거든?
해당 피해량들은 또 물리타입, 원소타입(냉기, 번개, 화염), 카오스 타입으로 나뉘고
각 타입별 방어력 산출공식은 다 따로란 말이지.
이건 진짜 컨텐츠가 나와있는 시점에선 시스템이랑 수치를 전면 개편해야하는 상황이 생길거 같은데
이런 공식을 넣자라고 생각하는 지점이 언제인거야?
그냥 일정 늘어지는거 감수하고 시스템 변경을 하는건가?
감수 못하면 타협하는거고?
그걸 기획이라고 불러요
근데 예시로 든 롤은 스파게티코딩 심한걸로 유명한 겜이라 중구난방이긴 할거임 하도 많이 꼬여있어서 리펙토링도 못하고 그냥 기워넣기만 하고있다는걸로 알고있다 제일 유명한게, 초기 챔피언들은 내부 데이터상으론 사실 미니언이랑 개체가 구분이 안되고 있다고 함 특정시점 신캐들부턴 구분되고
@ㅇㅇ(61.78) 그러니까 일반적으로 나오는 게임들은 대다수는 나올 컨텐츠의 경우의 수를 시뮬레이션하고 시스템을 짠다는 건가? 라이브 중에는 시스템 바꾸는 경우는 거의 없다고 보면 되나?
@글쓴 Indie(125.244) 확신이 있으면 그렇게 할수도 있지만 나중에 생각이 바뀔수도 있고 보통은 실제로 그러니까 수정하기 쉽게 최대한 유연하게 소프트코딩 해놓지
@글쓴 Indie(125.244) 진짜 단순하게 예를들면, 공격력만 있던 게임에 마법공격력이 추가하고 싶어졌을때 그동안 '스킬데미지 = 공격력' 으로 코딩놨다면 전부 갈아엎고 새로 만들어야함 하지만 스킬데미지 = A 로 해놓고 특정 스킬을 사용할경우 A는 공격력이 된다. 이렇게 만들어 놨으면 그냥 마법스킬을 쓰면 A에 마법공격력을 넣게하는 식으로 엄청 간단하게 확장할 수 있으니깐
@ㅇㅇ(61.78) 일반적으론 후자라는구나. 그냥 일 두 번 세 번 네 번 하는건 감수해야겠네
@ㅇㅇ(61.78) 근데 내 말은 코딩의 영역은 아니고 데이터 갖고 싹 전면개편해야하는 상황을 이야기 한거긴 해
@글쓴 Indie(125.244) 그냥 데이터 추가하는 데 기존 데이터가 다 조져질 일이 있음? 내가 논점파악을 잘못하고있나
@ㅇㅇ(61.78) 내가 파악하고 싶은 부분은 코드 쪽이 아니라 해당 스텟이 생김으로 인해 수치적 밸런싱이랑 해당 데이터에 영향받는 모든 컨텐츠들에 영향가니 이 부분 반복 작업은 감안하고 들어가는건지 궁금한거 였음. 만약 롤에서 POE식으로 피해량 산출공식으로 변경하자고 하면 기존에 만들어둔 컨텐츠들은 전면 개편해야하니...
@글쓴 Indie(125.244) ㅇㅎ 그건 뭐 아예 없던걸 추가하는거니 당연히 따라올수밖에 없는 노가다긴 함..
@글쓴 Indie(125.244) 이 상황이 되어버리면 단순히 공식하나 바꿔서 해결되는게 아니라 진행을 많이 했을 수록 바꿀 컨텐츠가 기하급수적으로 늘 거 같아서
@글쓴 Indie(125.244) 그 일거리를 줄이는것도 코딩이지 소프트코딩을 잘해놨으면 딸깍으로 수정 끝이야
@ㅇㅇ(61.78) 코드 설계관련 이야기는 아니긴 해. 프로젝트 전반적인 관점에서 선택을 보통 어떻게 하냐가 궁금한거라
@글쓴 Indie(125.244) 관련없는게 아니야 만들다보니 아쉬울수도 있고, 새롭게 추가하고싶은게 생길수도 있는데 누가 미래를 알겠음? 그리고 실제로 그런건 무조건 생길수밖에 없음. 처음부터 완벽한건 불가능하지. 그러니 처음부터 '그게 뭘지는 모르겠지만 분명히 나중에 뭔가 추가하게 될거다' 라는 마인드로 코딩해야되는거고 그렇게 잘 해왔다면 일정 늘어짐 없이 언제든지 시스템변경을 자유롭게 하겠지. 추가만 하는게 아니라 제거도 쉬울거고
@ㅇㅇ(61.78) 본문 질문 : '이런 공식을 넣자라고 생각하는 지점이 언제인거야? 그냥 일정 늘어지는거 감수하고 시스템 변경을 하는건가?' 답 : 언제든지 넣을 수 있게 미리 준비해둔다. 일정 늘어질 일이 없다.
@ㅇㅇ(61.78) 이렇게 할줄알게되면 소원이 없겠다 예상 개발기간 최소 1년은 더 단축될듯 ㅋㅋ
@ㅇㅇ(61.78) 음.. 그 부분이 영향이 없다라는 얘기가 아니고, 내 질문 중점이 프로젝트 내 미시적인 부분 중 하나인 코드 설계 부분이 아니라는거야 아무래도 요구명세에 맞춘 프로그래밍만 해왔다보니 기획쪽이 약해서, 기획자들은 보통 이 부분에 대해서 미리 다 설계하고 가나 싶어서 물어본거야. 밸런싱이나 컨텐츠 설계 및 수치작업 노동을 내가 다 해야하잖아? 아무래도 인디니까. 뭐 정답은 없겠다만 일반적으로 어떻게 선택하나 물어본거지. 해당 반복되는 일 감안하고 가는건지
@글쓴 Indie(125.244) 이거 갤에 이따금 올라오는 떡밥이기도 함 '저거 이러케 하죠? 이거 추가하죠?' 하면서 구현방법은 생각 안하고 아이디어 던지기만 하는 나사빠진 기획때문에 코드 싹다 갈아엎어야 되게 생겼다던가 코딩이 어떻게 되고있는지 이해하고 미리미리 준비해서 기획해줄 수 있는 사람이 좋다던가 뭐 그런?
@ㅇㅇ(61.78) 그 떡밥은 나랑 무슨 관련이 있는지 잘 모르겠음. 일단 다른 기획자들도 시뮬레이션을 완벽하게 하지않고 해당 시스템으로 인해 컨텐츠가 몇백개가 나와있는 상태여도 일반적으론 감수하고 수치작업 밸런싱 작업 한다는거지?
99%는 초기기획에서 만들면서 다듬어진 결과물임 딱 정하고 한게 아니라