사적인 블로그에서 긁어왔기때문에 블로그의 주소는 밝힐 순 없습니다. 또한
개인 사적 블로그라서 말투는 조금 양해해 주시길 바랍니다.

MezoCritical//
===================================================
테이블을 이루는 규칙을 좀더 간단명료한 하나의 공식이나 알고리즘으로 도출해낼 능력이 없거나
그런 공식이나 알고리즘을 줬을 때 프로그래머가 구현을 할 수 있을지 없을지를 판단할 능력이 없어서지.
한마디로 공부 좀 더해야 된다는 거다.
===================================================
지나치게 공격적인 글이 아닐까 싶은데요...
본인이 생각하기에 인신공격으로 이해할 수도 있을듯...
싸움나겠어요...

근데 뭐 틀린소리가 아닌거 같아서 ㄲㄲ
이후로 달릴 리플들이 그냥 분쟁성으로 가지 않길 바랄 따름이예요. 말투가 거슬린다 해도 뭐 원래 블로그를 위해서 썼다는거지 tig에 올릴 목적도 아니고.

개인 블로그에 있다는 거니까 너무 열내서 읽을 필요는 없지요.
구구절절히 맞는 소리라서 더 뜨끔하네요. 잘 읽었습니다.

처음 중년 게이머?/ 그분의 글을 보고서
어라 이걸 왜 공식으로 안하고 테이블로하지? 뭐 다른 이유가 있나보네...라고 생각했었는데
역시나 이런 생각을 하는 분이 있었군요 ㅋㅋㅋㅋ

지대로 관광태우는 글이네요. ㅋㅋ

가끔 보면 면접자리 참관하다보면 면접 진행자를 지대로 관광시키는
면접자가 종종 보이는데

말은 안해서 그렇지 나름 재밌더군요 ㅋㅋㅋㅋ

그리고 한가지 덧붙이자면
관리자님이 이 글 좀 게이머 발언대 메인 페이지에다 띄워줬음 좋겠네요.

물론 그럴일 없겠지만? ㅋㅋㅋㅋ

그런데....
테이블로 할 경우 A게임에서는 1,2,3,4 아이템만 나온다.
B게임에서 3, 4, 5, 6 아이템만 나온다...
이런 게 가능하겠습니다만 공식에서는 어떨까요?
공식을 사용할 경우 따로 제한을 달아주지 않으면 개발자 의도에 상관없이
오직 아이템의 가치에 의해서만 보상이 결정될 것 같은데요..?

글쎄요. 공식화가 굉장히 좋은 대답이긴 하지만. 아이템의 가치화가 마음에 걸리는군요.
A미니게임에서 300짜리와 100짜리에 보상가치가 거의 차이가 없는 아이템을 지급하게 될 경우 또한 B미니게임에서는 A게임의 100보상을 300에 주고 300보상을 100에 주는 경우 하나의 아이템 테이블로는 바보가 되는 경우가 발생하기 때문에 결국 각 미니게임에 아이템테이블을 각각 달거나 아니면 한 아이템의 가치를 2~3개로 매겨야 하는 사태가 발생할 겁니다.

걍 면접관이 까라면 까는거임.

분명 중년게이머 님은 문제에 대해서 조언을 구한 것인데...
좋은 댓글들로 좋은 분위기 흘러가다가, 결국은 엄하게 흘러가는 군요.
엔씨소프트던 카이스트(?)던 하버드던 난독증이 있으면... 문제.
조언이라면 조언이겠지만, 방식이 틀렸다는 생각이 드는 군요.
ps. 실제로 면접을 보러왔을 때, 이런저런 해답을 내면서 '관광태우는' 면접자를 보고 싶어하는 것이 중년게이머 님의 마음이 아닐까요?
능력있는 분이 들어와서 좋은 게임을 만드는 것을 바랄테니까요.

수백, 수천개의 아이템 테이블에 A미니게임 B미니게임에 대한 가치를 추가 하느니.
A게임 B게임 에 대한 보상테이블을 만드는 편이 훨씬 좋습니다.
공식도 훨씬 간단해지죠. '그냥 테이블에서 뽑아와.'
간단한 공식 몇개로 마무리 된다면 개발,기획자 모두 편하지만. 둘중 하나가 잘 모르는 경우 가 되면 별 쓸데 없는 짓일겁니다. 개발자 다 나가고 유지보수 하러 듣보잡 왔는데 테이블만 고쳐서 게임 유지보수 하면 될거 개발공식 확인하고 이거 멈미 하고 물어보면 바보되는겁니다.

별개로.
'1. 최고의 답안은 만점짜리 답안이 아니라 '문제가 잘못되었음'이다.'는 빵점짜리 답안입니다.
난독증도 아니고 출제자가 저렇게 냈는데..까라면 까야죠 -_-;

유지보수의 측면에서도 공식보다는 테이블이 훨씬 유리합니다.
아무리 잘 짜여진 게임이라도, 예측 할 수 없는 수많은 변수들이 발생 + 추가 + 삽입 되어야 하고.
또한 상용화 이후에는 점점 더 그러한 방향으로 흘러가게 되... (쿨럭)지요.
때문에 모든 변수에 대응하면서, 최대한 유지보수가 원활히 이루어질 수 있도록 하는 부분에서는 테이블이 유리하며, 그렇기에 처음에 '그나마' 예측 가능한 테이블을 구성하고 이후에 나타날 변수에 대비해 여유를 두는 부분도 필요합니다.
글을 다시 한 번 읽어보니 이런 말이 있네요, ['아마추어 프로그래머' 분에게 문제를 던져줬다.]
아.... 아마추어 기획자 분이 아니셨군요. (__*);;;;

물론 프로그래머이셨던 분들이 기획자가 되시는 일도 비일비재하며, 잘 짜여진 기획으로 좋은 게임을 만드시는 경우도 많습니다. =)
그러나 제가 만나본 프로그래머 출신 기획자 분들은, 대부분 테이블의 중요성을 인지하고 있으며, 기획을 하실 때 테이블을 '전혀' 사용하지 않고 공식으로만 연결짓는 분은 없으시더군요.
오히려 '공식? 그건 잘못하면 실력 자랑밖에 안 돼. 게임은 그렇게 만드는 게 아냐.'라고 하시는 분들도 보았고요.
그 분들이 실력이 없거나, 듣보잡 회사이거나(웃음) 한 것도 아니고... 특히 보상의 부분에서는 예측 불가능한<< 부분이 중요해집니다.

유저의 카타르시스가 극한으로 다다르게 되는 부분이 바로 보상이기 때문에, 공식만으로는 100% 풀어낼 수 없기 때문입니다.
마음을 건드리는 것이거든요.
마음을 공식으로 풀어낼 수 있다고 한다면... 저는 그 분을 존 카맥, 빌 로퍼, 시드 마이어보다 더 위대한 개발자로 추앙하겠습니다. (__*);;;;;;
ps.그러고보니, 저는 답도 못 내고 낑낑댔으면서... 으윽;;

아앗. 중간에 굉장히 멋진 댓글이 있었는데... 사라졌... OTL

지극히 프로그래머 적인 마인드 군요.
장점도 지극히 자기 주관적인 관점으로 바라보고 있고,
단점도 지극히 자기 주관적인 관점으로 해석하고 있군요.
뭐! 개인블로그에 올라왔던 글을 가지고
이런 저런 이야기 하는 것도 좀
우습다는 생각이 드는 군요;

길시아// 아... 그러네요.... 아마추어 기획자가 아니였군요. -_ㅠ

답변을 하고 싶었지만 덧글로 달기엔 너무 길어지길래 제 블로그에 올려봤습니다.
http://abigfan.egloos.com/1888034

velvet//멋집니다........ 새 글로 올리셔도 될 듯. 우워워... =ㅁ=b
제가 하고 싶던 말을 시원하게 다 해 주셨네요...
전 제 머리 속에서 마구마구 맴돌아서... 게다가 아직 가방끈이 짧아서... 흐흐흐;;;

velvet님// 브라보~ -ㅅ-b

아... 중년게이머 님의 글에 중년게이머 님께서 달으신 댓글에 이런 내용이 있네요...
///플렛폼 사업단에서 내부에 들어올 CP들의 자율성을 주기 위해 가능한 확장 구조를 갖고 있는 형태를 원하니까요. 두개다 유동으로 늘어나도 해결이 가능한 상태입니다. 이벤트기간이나 기타 상황에도 DB의 구조를 바꾸지 않고 데이터 추가만으로 유지 보수가 가능한 형태라서 개발 이후 프로그래머나 DBA가 가능한 필요하지 않는 형태입니다.///
ㅠ_ㅠ 이 댓글이 묻혀서 그런가... 결국 산으로산으로산으로~!!

넌 왜 그런 고정관념이 생겼게?
아직 경험이 없어서 그래.. 공식이면 다 해결할 것 같은 미숙함에서 오는 경험말이야. 넌 테이블을 너무 우숩게 보고 있는데, 아직 경험이 없다는 증거야.
몬스터를 공격한 인원수와 피해를 준 순위에 따라 각각 다른 보상을 준다고 할 때 몬스터의 드롭리스트를 공식으로 할 때와 테이블로 할 때의 차이점을 잘 생각해보라구.

이글은 뭥미? ^^;;

어이가없네요.
게임 보상을 기계만들듯이 공식으로 해야한다는 발상자체가
지극히 프로그래머적인 생각만 하는 아마추어중에 아마추어고
이걸가지고 기획자들 공부좀해야한다는 발언을 하는걸보니 개념도 좀 빠진것 같군요
보통 이런설계를 할땐
공식을 기반으로 다 잡지만서도 일부러 테이블링을 해야한다고 봅니다.
게임이라는 분야는 어플리케이션처럼 프로그램을 만드는게 아니고
매일 변화하는 흐름속에 재미를 만드는 분야입니다.
어떠한 추가요소가 적용되고 어떤 밸런싱을 하게 될지 모르는데
정확히 규칙속에 돌아가는 공식으로 충분하다고요?
정말 미숙함의 끝을 달리는 발상이군요..

먼소리야?

제가 보기엔 두 분이 다른 걸 말씀하시는 것 같은데요 -_-;
정확히는 반박글을 쓰신 분이 문제를 침범하고 있네요.
요구사항은 어떤 게임의 어떤 등수에 따른 보상을
A. 기획자가 자기 생각대로 수정할 수 있게
B. 그리고 자료구조 자체에 대한 변화는 가능하면 없도록
자료구조를 구축하라는 건데 반박글에서 제안한 방법은 기획자가
수정할 수 있는 자유도가 전혀 없잖아요. A를 무시한 거죠.
반박글에 맞는 말도 많고 실제 개발 과정 중에 일어난 일이면
저런 논리로 기획자를 설득할 수도 있는 거니 상관 없겠지만
주어진 문제라고 생각하면 그렇게 하면 안 되죠.

질문의 요지를 아무리 봐도 질문한사람도 좀 .....
길게 말해봐야 분쟁(?)토론(?)만 길어질테니 간단히 말하자면,
"있는 문제의 요지만을 생각해야지 그 이상의 개인적인 생각이나 그런것이 끼어들면 안되는겁니다"
고로 위에 내용에만 부합하는걸 정리해야 되는거지요.
왜냐면 일방적인 요구이니깐요.

간지나는 공식 몇줄로 다 처리하면 짱일 것 같죠?
실무 안 해 봤다는 증거입니다 그게 그냥-_-;

"난 온라인 게임은 개발 안해봤지만.." 이라는 문구를 추가해주면 이해해주겠습니다.

'회사에 입사하는거 생각해볼테니까염' 이라는걸로 봐선 아직 안하신듯?
어차피 테이블도 공식으로 짜는데 뭥미?
검증이나 유지보수를 위해서 한줄짜리 공식도 테이블로 만드는 마당에 뭔솔인가 싶네요 'ㅅ')=3

그나저나 게시판 이름 바꾸죠.
'개발자 발언대'
아니면 만들던가.

공식이 다가 아님
잘못된 공식이면 어쩔거? 수정해서 다시 하드코딩?
나중에 문제 생기면 숨겨진 소스를 찾아 머나먼 길을 떠나겠구려~
중간에 값바뀌고 벨런스하는 과정에서 공식을 수만번은 수정해서 릴리즈버전을 만들겠구려~ 이게 왠 뻘짓 시스템 개발하기도 바쁜데 ㅋㅋㅋ
공식 멋지지 하지만 게임 개발에서 글쎄? 테이블로 때려박는게 더좋을걸요~

전 저런 테이블이나 수학적인 것은 잘 모르겠습니다.
(시스템 기획자는 꼭 수학도 잘해야하고 저런것은 기본적으로
알고 있어야 한다? 그런 전 탈락이겠군요.)
제가 생각하는 기획자는..
자신이 생각하는걸 글로 뿐만 아니라 다른 방식으로 쉽게 이해할 수있도록
잘 전달 할 수있는 사람이 아닐까 라는 생각을 해보게 됩니다.
또한 게임을 유저들이 쉽게 이해하고 재미나게 느끼고 즐길수 있도록
만들어야 하는게 아닐런지..
아무리 저런 테이블을 정밀하고 완벽하게 구성한다고 해서
과연 게임의 재미를 높이고 완성도를 높일 수 있을까요?

전 저런 테이블이나 수학적인 것은 잘 모르겠습니다.
(시스템 기획자는 꼭 수학도 잘 해야 하고 저런것은 기본적으로
알고 있어야 한다? 그럼 전 탈락이겠군요.)
제가 생각하는 기획자는..
자신이 생각하는걸 글로 뿐만 아니라 다른 방식으로 다른 사람에게
쉽게 이해 할 수있도록 전달 하는 것이 아닐까 라는 생각을 해보게 됩니다.
(꼭 저런 테이블이나 수학적인 방식으로만 전달을 해야 하는 걸까요?)
또한 게임을 유저들이 쉽게 이해하고 재미나게 느끼고 즐길수 있도록
만들어야 하는게 아닐런지..
아무리 저런 테이블을 정밀하고 완벽하게 구성한다고 해서
과연 게임의 재미를 높이고 완성도를 높일 수 있는 걸까요?

전 본 게임 보다 미니게임이 얼마나더 유저에게 많은 재미를 줄 수있는가 부터
생각해 보겠습니다 ㅡㅡ;;;
본 게임보다 미니게임이 유저에게 재미를 크게 주지 못 할것 같다라면
미니게임을 아예 제작을 안하겠습니다.
차라리 본 게임에 더 많은 컨텐츠와 재미요소를 추가 하겠습니다..

전 본 게임 보다 미니게임이 얼마나 더 유저에게 많은 재미를 줄 수 있는가 부터
생각해 보겠습니다 ㅡㅡ;;;
본 게임보다 미니게임이 유저에게 재미를 크게 주지 못 할것 같다라면
미니게임을 아예 제작을 안하겠습니다.
차라리 본 게임에 더 많은 컨텐츠와 재미요소를 추가 하겠습니다..

전 저런 테이블이나 수학적인 것은 잘 모르겠습니다.
(시스템 기획자는 꼭 수학도 잘 해야 하고 저런것은 기본적으로
알고 있어야 한다? 그럼 전 탈락이겠군요.)
제가 생각하는 기획자는..
자신이 생각하는걸 글로 뿐만 아니라 다른 방식으로 다른 사람에게
쉽게 이해 할 수있도록 전달 하는 것이 아닐까 라는 생각을 해보게 됩니다.
(꼭 저런 테이블이나 수학적인 방식으로만 전달을 해야 하는 걸까요?)
또한 게임을 유저들이 쉽게 이해하고 재미나게 느끼고 즐길수 있도록
만들어야 하는게 아닐런지..
아무리 저런 테이블을 정밀하고 완벽하게 구성한다고 해서
과연 게임의 재미를 높이고 완성도를 높일 수 있는 걸까요?

재미랑은 상관없지만.. 게임의 원활한 구현을 위해서는.. 테이블설계정도는..흠냠;; 하셔야죵;;; 수학적인것도 조금 하셔야죠..(최하 중학교정도? ㅡ.,ㅠ) 구현없이는 재미도 없다죵;;

단델리온 / 가끔 수학공식이 안들어가는 게임도 있고.. 그런 소양이 전혀 필요없는 기획파트도 있습니다. (가령 NPC 인물들의 대사만 적는 텍스트라이터같은..)
그런쪽을 지망하는거라면 그냥 '저런것도 있다' 라는것만 알면 됩니다.
스트레스 받을 필요 없답니다. ^^

틀린말도 있고 맞는말도 있고 저글 쓴사람도 머
공식적인 글이 아니고 지들끼리 말한거 펌질한거니 거두 절미하고,
개발방법은 다양하지만 현재원하는것 향후에 활용방안 에 따라
달라질수 있다고 상각됩니다.
exam: 원하는게 미니게임 = x미니게임형태 이고 이건 향후 y룰까지 수정 가능하며 z시기에 (이벤트성) 적용과 소거 혹은 일시적 룰의 교체가 필요하다..
(적극적 활용: 다양룰의 변화 및 같은 구조의 미니게임의 양산화 -> 테이블(승), 단순한 로직 게임의 일률적,한게적변화 = 로직(승))

위에 문제를 해결 못한다는건 말이 안되지만 정확히 자기 게임에 적합한 환경을 기획해 내는게 답이라는 느낌이에요 ^^ 누가 맞네 틀리네는 좀;; 전체적인 시스템 기획이란 이런점까지 고려하는 모습이 아닐까 싶습니다. 위 논쟁은 전체의 의도하는바 미니게임의 최종활용방향에 따라 답이 달라지겟다 싶네요...