(스크랩) 게임 기획자가 순서도를 알아야 되나요?

오늘 게임 기획자 커뮤니티에서 저 질문을 보고 생각난 김에 블로그에 글을 올려봅니다. 이 글을 커뮤니티에 쓰기에는 그냥 분쟁조장이라는 느낌이라, 개인적인 생각을 남기고 싶어서 여기다 씁니다.

1 : 게임 기획자 : 순서도를 알아야 되나요?

게임 기획자를 꿈꾸는 분들이 가끔 하는 질문입니다. 사실 게임 기획에 정답이 없다(는 주장이 대세이므로 하다)보니 순서도가 필요하면 그리고, 필요하지 않으면 그리지 않으면 된다.가 대부분의 경우 답변으로서는 정설입니다.

-- 요점정리 : 현 시대에는 "게임 기획에는 정답이 없다"는 주장이 대세임.

비슷한 질문으로 "기획자가 프로그래밍을 알아야 되나요?"도 있어요. 그런데 왜 "기획자가 셰이더를 알아야 되나요?"라든가 "기획자가 맥스를 알아야 되나요?"라는 질문은 나오지 않을까요? "기획자가 콤포저를 알아야 되나요?", "기획자가 작곡을 알아야 되나요?" 같은 질문은 왜 하지 않을까요?

-- 요점정리 : 왜 프로그래밍 관련 지식에 대한 질문이 많을까?

일단 결론으로 가기 전에, 저런 논의가 잘못 진행되는 경우가 있어요. 기획자라면 조심해야 됩니다. 예를 들면, "기획자한테 순서도를 요구하는 프로그래머는 신입이거나 경력이 낮다."같은 이분법적인 논리라든가 "순서도는 필요 없어요"와 같이 단언하는 내용입니다.

-- 요점정리 : 게임기획자가 이분법적인 논리를 펴거나 단언하는 것은 금기사항임.

가끔 프로그래머들의 커뮤니티 사이트에 올라오는 "우리팀 기획자는 X 도 몰라요. 기획자가 X 정도는 알아야 되는거 아닌가요?"라는 글을 보면 기획자로서 마음이 아픕니다. 사실 게임 기획에 정답이 없다면, 프로그래밍에도 정답은 없는 겁니다. 아니 세상 그 자체에 정답이 없는 겁니다. 어떤 프로그래머는 순서도가 없어도 프로그래밍을 잘만하고, 어떤 프로그래머는 순서도가 있어야만 일을 한다는 것을 경험적으로 알게 되어서 그 두 프로그래머의 차이를 "경력"으로만 판단하면 안됩니다.

-- 요점정리 : 프로그래머가 '순서도'를 요구하는 것은 낮은 경력 때문이 아니다.

또, 순서도는 필요 없다라는 이야기도, 알고 사용하지 않는 것과 필요하지 않으니 몰라도 된다는 완전히 다른 차원의 결정입니다. 물론 순서도가 없어도 기획은 가능합니다. 하지만 그것이 실력이 있고, 경력이 많은 프로그래머를 상대하기 때문에, 혹은 착한 프로그래머를 만나서 가능하다고 생각하면 안됩니다. 순서도가 필요없는 프로그래밍이기 때문에 순서도가 필요없는 겁니다.

-- 요점정리 : '순서도'가 필요없는 일이 있고, '순서도'를 요구하는 일이 있다.

결국 프로그래머와 협업할 때 간혹 불거지는 여러가지 문제들로 인해서 게임 기획자는 프로그래밍과 관련된 고민에 빠집니다. 게임 기획자가 순서도나 스크립트 언어를 써야/배워야하나? 항상 이런 문제는 알면 쉬운데 모르니까 결론을 못 내는 겁니다.

그럼 이제 화이트 - "순서도 안써도 되요", 그레이 - "써도 되고 안써도 되요", 블랙 - "순서도 꼭 써야되요."의 사례를 통해서, 순서도를 제대로 쓰는 방법, 즉 순서도를 어떤 경우에 사용해야 하는지 한번 알아볼까요? :=)

-- 요점정리 : 닭 잡는데 소잡는 칼을 쓸 필요는 없다.

2 : 화이트 : 안써도 되요.

이미 예상하셨겠지만, 캐릭터 설정을 하거나 스토리 작성을 하거나, 배경음악 외주 기획서를 작성할 때 쓸 필요는 없습니다. 물론 스토리 작성시에 연대표라든가, 인물관계도가 순서도와 약간 비슷하긴 합니다만 명백하게 프로그래머가 말하는 순서도는 아닙니다. 그런데 제가 이걸 왜 보여드리냐면, 만약 저걸 다 글로 나열했다면 어땠을까를 상상해보시라는 의미입니다.

마비노기 업데이트 내역을 연대표로 나타낸 그림

( http://egloos.zum.com/Thirdsign/v/3468121 )

드래곤볼Z의 인물관계도

( http://egloos.zum.com/kwangaeto/v/6243317 )

어떤가요? 한눈에 파악이 되죠? 저 복잡한 업데이트 내역과 인물의 관계가 한눈에 보입니다. 그렇다면 이걸 필요로 하는 사람은 누굴까요? 당연히 어떤 복잡한 내용을 한눈에 보고 싶어하는 분들을 위한 문서겠지요. 사실 저렇게 자료를 시각화시킬 수 있는 것은 게임 기획자에게는 대단한 장점입니다. 그리고 이런 장점을 가진 분들은 회사에서 상사에게 많은 사랑을 받습니다.

-- 요점정리 : 복잡한 내용을 정리, 시각화시켜놓은 문서는 높은 분들이 좋아한다.

3 : 그레이 : 써도 되고 안써도 되요.

그런데 이거 아시나요? 어떤 프로그래머들은 기획자에게 순서도 작성을 시키지 않습니다. 심지어는 순서도 작성을 싫어하는 프로그래머도 있습니다. 그런데 왜 기획자한테 시킬까요? <-- 이런 생각은 하지 마세요. 만약 프로그래머가 게임 기획자에게 순서도를 요구했다는 이야기는 "난 당신 이야기 이해할 수 없어."로 알아 들으셔야 합니다. 이해할 수 없는 이유는 좀 더 뒤에 설명드릴게요.

( http://forum.falinux.com/zbxe/index.php?document_srl=553572&mid=note )

위 링크는 FA리눅스 포럼에서 어떤 분이 쓴 글입니다. 프로그래머조차 순서도를 작성해야 하나 고민합니다. 그러니 기획자가 고민하는 건 더욱 당연한 거라고 봐야겠죠. "프로그래머조차도 고민하는 순서도를 기획자가 그려야 하나?"라고 생각하지 마세요. 일단 서두에서도 말했듯이 알고 안쓰는 것과 안쓰니까 몰라도 된다는 완전히 다른 이야기입니다.

-- 요점정리 : 프로그래머도 순서도에 대해서 반신반의 한다.

위 글(+과 댓글)에서 나오는 순서도의 장점과 단점입니다.

장점	단점
1. 큰 그림의 의미와 효과. 2. 상호 검토로 변경될 소지를 미연에 방지. 3. 혼자가 아닌 협업이 가능.	1. 어차피 코드짜면 순서도와 내용과 다름. 2. 도형을 이용하는 순서도 작성은 어려움.  3. 수정에 매우 많은 시간과 노력이 듬.

그런데 댓글을 주욱 읽다보면 이런 내용이 나옵니다. 3번에서 무언가 감이 잡혀야 됩니다.

1. 딱 A4 용지 한 장에 심플하게 표현해야 좋은 블럭다이어그램, 순서도

2. 큰 그림을 그리는 것이 좋고, 세부적인 내용은 순서도로 그리지 않는게 좋다.

3. 단, 구조설계자와 코더가 따로 존재하는 프로젝트는 예외로 둡니다.
    코딩 룰이 정해진 상태에서 상세 순서도가 있어야만 코딩이 가능하니까요.

-- 요점정리 : 구조설계자와 코더가 따로 존재하는 프로젝트!

4 : 블랙 : 순서도 써야 되요.

그럼 마지막으로 순서도를 꼭 써야되는 경우를 이야기 해보도록 할께요. 위에 이야기를 종합하면 됩니다. 우선 프로그래머와 일을 하는 경우는 당연한 것이구요. 큰 규모의 프로젝트, 게임으로 따진다면 서버, 클라, 웹 프로그래머, 빌링 모듈 개발자, 보안업체 개발자 등 여러 명의 프로그래머와 함께 커뮤니케이션 해야 되는 경우라고 볼 수 있겠네요. 그리고 윗선에 보고용도 하나 추가할게요.

① 글로 작성했을 때 분량이 많다.

일단, 그냥 단순히 팝업창 한번 띄우는 기획에 순서도는 불필요합니다. 그런건 이제 거의 대부분 일반적인 한줄짜리 요구사항으로 처리됩니다. 그 반대의 경우라면 어떨까요?

요구사항이 수십장을 넘어가는 경우라면 말이죠. 글로 작성해도 엄청난 분량일 경우 그걸 잘 설명할 수 있는 방법은 없을까요? 혹시 이런 경우라면 순서도가 필요하지 않을까요?

어떤 분들은 요구사항을 10줄 이내로 작성하는 것이 좋다라고 이야기하지만 그건 PPT 만들때나 적용되는 이야기이고, 게임 시스템 디자인에서는 생략하는 것은 좋지 않습니다.

② 여러 명의 프로그래머와 작업한다.

두번째로 기획자와 프로그래머가 1:1로 매칭되어 일하는 경우라면 사실 큰 문제는 없을 것 같습니다만, 서버 프로그래머 3-4명과 클라이언트 프로그래머 2-3명, 그리고 웹개발자 1명까지 붙어서 개발되어야 하는 시스템이 있을 경우, 과연 말과 PPT와 화이트보드만으로 충분할까요?

제 경험상 대규모 시스템일 경우에는 뭔라고 하나 더 있어야 커뮤니케이션이 되었던 기억이 있습니다만, 물론 이건 제 경험일 뿐.

③ 윗선에 특정 게임 시스템에 대한 설명을 해야 하는 상황이 온다.

윗선에 특정 게임 시스템을 설명할 때, 그 분이 게임 기획도 모르고, 프로그래밍도 모른다. 이 경우 게임 기획자들이 제일 쉽게 빠져드는 함정은 '비유'나 '은유'를 사용하는 경우입니다.

예를 들면 '이것은 기술적으로 대단히 어렵기 때문에 설명드리기가 어려워서 비유를 하자면'으로 시작해서 '잘 차려진 밥상'으로 '유저들은 자신이 좋아하는 반찬을 골라먹을 수 있으며', '우리는 많은 매출을 올릴 수 있다'라고 말하는 경우입니다. 너무 극단적이니 마음에 두진 마세요.

저렇게 해서 윗선에선 만족할지는 모르겠지만 윗선이 그게 정확하게 뭔지 모르게 되고, 결과물이 눈에 보일 수록 점점 불만이 많아지고, 차츰 '뭐랑 똑같이 만들어'와 같은 주문을 받게 됩니다.

5 : 일반 문서보다 순서도가 조금 더 효율적인 순간

그럼 순서도를 잘 사용하는 예를 하나 들어볼까요? 뭐가 있을까?

(샘플은 샘플일 뿐, 너무 믿지는 말자 ! ㅋㅋㅋ)

음... 아! MMORPG의 몬스터 사냥시 파티 경험치 분배 같은 것이 되겠네요. 왜냐하면 글로 작성했을 때 분량이 많고, UI나 오브젝트 같이 눈에 보이는 것이 아닙니다. 게다가 계산 순서에 따라서 결과가 달라질 수도 있기 때문에 처리 절차가 어떻게 되는가가 중요합니다. 이걸 게임 개발 프로세스나 기획 개론에서 이야기 하는대로 풀어볼게요.

-- 디렉터나 윗선에서 보통 숙제를 줍니다.

상황 가정 : 기본적으로 몬스터가 죽으면 해당 몬스터 테이블에 정의되어 있는 경험치를 몬스터를 죽인 플레이어가 획득한다.가 구현되어 있다고 칩시다. 그래서 여러 플레이어가 파티를 맺고 몬스터를 죽이면 죽인 유저만 경험치를 얻는다고 생각해보세요.

-- 조사도 하고, 여기저기서 의견도 보내줍니다.

요구 사항 도출 : 마지막에 죽인 유저가 경험치를 다 먹기 때문에, 파티 플레이어들은 경험치를 먹는 순서를 정해서, 돌아가면서 막타를 때리는 노가다를 한다. 유저들 불만사항도 있는데, 몬스터가 다 죽어갈 때 쯤 나타나서 몬스터를 죽이고 경험치를 빼앗아 가는 스틸이 대유행을 해서, 필드에서 PK도 자주 발생하고 유저 불만 사항이 접수되었다. (너무 오래된 이야기죠? ㅋㅋㅋ)

-- 그리하여 기획팀은 회의를 합니다.

기획 의도 수립 : 여러 명이 파티 사냥을 하는 경우, 몬스터 경험치를 플레이어들에게 분배해서, 파티 사냥을 유도하고 싶다. 마지막 스틸을 방지하기 위한 장치가 필요해서 몬스터 HP의 1%에 해당하는 데미지는 경험치 분배시 제외한다.

-- 보통 지망생들은 요기까지 합니다.

시스템 컨셉 설계 : 이제 위 시스템의 담당자는 세부내용을 구상합니다. 우선 시스템이 2가지가 필요합니다. 하나는 파티 경험치 분배 시스템이고, 하나는 스틸 방지 시스템입니다. 대략적으로 어떻게 작동한다라는 것을 적어봅니다.

대규모 프로젝트 경험이 있는 분들은 이것도 두명의 업무로 쪼개진다는 것을 알고 계실겁니다. 하지만 요즘 스마트폰 게임업체로 업계에 입문하는 분들은 경험해 보기 힘든 일일겁니다.

시스템 구성요소 도출 : 그럼 이제 각각의 시스템에 필요한 요소들을 도출해볼까요? 경험치 분배부터 하지요. 경험치 분배를 위해서는 어떤 방식의 경험치 분배를 할 것이냐를 정해야 합니다. 제일 쉬운건 n빵입니다. 하지만 n빵은 쉬우니까 쓰지 않아요. 그래도 한번 써보도록 하겠습니다.ㅋ

-- 보통 신입 기획자들은 요기까지 합니다.

(가칭)n빵 파티 경험치 시스템

파티원 개인이 받을 몫 = 몬스터 경험치 / 파티원수

끝. 너무 쉽네요. 두 줄이면 끝나네? 순서도가 필요 없네요? 이상하죠? ㅋㅋㅋㅋ

그럼 이제 스틸 방지 시스템 만듭시다. 몬스터 스틸 방지는 뭘 기준으로 해야 될까요? 맨 처음 첫타를 때린 사람이 소유권을 갖는다고 해보죠!

 

(가칭)몬스터 스틸 방지 시스템

몬스터 경험치 및 아이템의 소유권 = 몬스터 첫빵 날린 유저

우와 기획 너무 쉽다! 순서도가 필요없네요?

이상하죠? 이게 결론이면 당연히 글 안쓰죠. ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ

위 내용들이 실제로 구현될 때 프로그래머가 어떤 일을 해야 되는지 확인해보세요.

(가칭)n빵 파티 경험치 시스템

파티원 개인이 받을 몫 = 몬스터 경험치 / 파티원수

기술적으로 구현되는 내용

1. 경험치 지급을 위한 파티목록이 선행 개발되어야 함.     - 파티 목록에는 유저 목록과 해당 유저들을 파티로 묶을 수 있는 UID를 부여해야 하며,     - 파티 생성, 초대, 탈회, 삭제 등을 할 수 있어야 함. 복잡하니까 했다고 가정. 2. 몬스터를 마지막에 죽인 유저가 파티원인가 체크     - 마지막에 죽인 유저가 파티에 소속되어 있다면        - 파티사냥 지급 경험치 = 몬스터 경험치 / 파티원수        - 파티원 수만큼 반복           - 각 플레이어의 경험치 = 각 플레이어의 경험치 + 파티사냥 지급 경험치     - 마지막에 죽인 유저가 파티 플레이어가 아니면        - 플레이어의 경험치 = 플레이어의 경험치 + 몬스터 경험치

에이, 파티 플레이 경험치만 복잡한 거에요. 스틸 방지는 쉬울거에요. 헤헷...

(가칭)몬스터 스틸 방지 시스템

몬스터 경험치 및 아이템의 소유권 = 몬스터 첫빵 날린 유저

기술적으로 구현되는 내용

1. 파티 목록 선행 개발했다고 가정 (내용 위와 동일) 2. 몬스터의 구조체에 소유권을 저장할 수 있는 공간 확보     (서버 컴파일 다시 해야함) 3. 필드든 던전이든 일반몹이든 보스몹이든 일단 생성후 처음 한대 맞으면,     - 때린 유저의 UID를 몬스터 구조체의 소유권에 저장한다.

쉬워보이네요. 그럼 저렇게 구현했다 치고, 실제로 돌려보니까 어떤 반응이 나올 것 같아요?

파티 시스템 업데이트에 환호하던 유저들이 몇일 지나니까 다른 의견을 보내주기 시작하죠. 더 고생한 사람이 더 많은 경험치를 받고 싶다! 누구는 파티 맺고 싸우다가 피 딸린다고 물약 사러 마을에 가버렸는데 안 돌아왔다. 이런 애들은 아예 경험치를 주지 마라.

몬스터 스틸 방지 시스템은 어떨 것 같아요? 여긴 더 난리도 아니에요. 애새끼들이 몹이란 몹은 다 치고 돌아다니고 있죠. 심지어 보스도 한대 치고 데미지 1준 뒤에 튀어요. 그걸 모르는 다른 유저들이 파티맺고 보스 죽였는데 경험치가 안들어오죠. ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ

이런 경우, 아래처럼 기존 컨셉을 유지하면서 개선 작업합니다. ^^

(가칭)n빵 파티 경험치 시스템_수정

(가칭)n빵 파티 경험치 시스템_수정_1

(가칭)n빵 파티 경험치 시스템_수정_2차

(가칭)n빵 파티 경험치 시스템_수정_3차_또 수정

(가칭)n빵 파티 경험치 시스템_수정_4차_컨펌됨

(가칭)몬스터 스틸 방지 시스템_수정

(가칭)몬스터 스틸 방지 시스템_수정_1

(가칭)몬스터 스틸 방지 시스템_수정_2차

(가칭)몬스터 스틸 방지 시스템_수정_3차_또 수정

(가칭)몬스터 스틸 방지 시스템_수정_4차_야근중

하지만 일정 수준이 되면 한계에 도달해서 아예 이름을 바꾸게 됩니다. 한번 고쳐볼까요!?

1. 고생한 사람이 더 많이 받게 하자.

2. 마을에 있었던 유저는 경험치 못 받게 하자.

3. 먼저 치는 것도 문제가 있다. 고치자.

(수정)누적 데미지로 경험치 분배 시스템

파티원 개인이 받을 몫 = 몬스터 경험치 * (개인별 누적 데미지 / 몬스터 HP)

(수정)몬스터 아이템 소유권 시스템

몬스터 경험치 및 아이템의 소유권 = 가장 높은 누적 데미지를 준 유저

그래도 아직 순서도 없이 버틸만 해여. 그렇져? ㅋㅋㅋ

 

(수정)누적 데미지로 경험치 분배 시스템

파티원 개인이 받을 몫 = 몬스터 경험치 * (개인별 누적 데미지 / 몬스터 HP)

기술적으로 구현되는 내용

1. 경험치 지급을 위해서는 파티목록이 필요 없지만 아이템 소유권 때문에는 필요함.     - 파티 목록에는 유저 목록과 해당 유저들을 파티로 묶을 수 있는 UID를 부여해야 하며,     - 파티 생성, 초대, 탈회, 삭제 등을 할 수 있어야 함. 복잡하니까 했다고 가정. 2. 몬스터 구조체에 누적 데미지 배열 추가     - 누적 데미지 배열은 유저UID와 누적 데미지가 저장됨.     - 누적 데미지 배열은 최대 100명까지 저장.     - 누적 데미지 배열은 데미지에 따라서 내림차순으로 정렬됨.     - 최대 인원수를 초과하게 되면 누적 데미지가 작은 값이 삭제되는 구조.     - 자료구조로는 우선순위 큐와 비슷. 알고리즘만 약간 다르게 설계하면 될 듯. 3. 몬스터 사망     - 몬스터와 플레이어의 거리 = 몬스터 위치 - 플레이어 위치     - 몬스터와 플레이어의 거리가 일정 이하일 경우       - 플레이어의 경험치 = 플레이어의 경험치 + 몬스터 경험치 * (개인별 누적 데미지 / 몬스터 HP)     - 몬스터와 플레이어의 거리가 일정 초과일 경우       - 경험치 지급 안함.

(수정)몬스터 아이템 소유권 시스템

몬스터 경험치 및 아이템의 소유권 = 가장 높은 누적 데미지를 준 유저

기술적으로 구현되는 내용

1. 파티 목록 선행 개발했다고 가정 (내용 위와 동일) 2. 몬스터의 구조체에 누적 데미지 배열 추가됨 (내용 위와 동일) 3. 몬스터의 소유권을 저장할 수 있는 공간 배열 확보 (파티원 숫자만큼 필요) 4. 필드든 던전이든 일반몹이든 보스몹이든,     - 죽을 때, 가장 많은 데미지를 준 유저가 해당 몬스터와 드롭된 아이템의 소유권을 갖게 됨.     - 만약 해당 유저가 파티에 소속되어 있을 경우       - 몬스터의 소유권 배열에 나머지 파티원의 UID도 추가함.

쉬워보이네요. 하지만 문제가 없을까요? 또 문제 생겨요.

이렇게 이야기가 계속 계속 진행되서 점점 길어지고 복잡해지고 하면서 글로 설명하기가 점점 힘들어 지는 걸 보여드리려고 했는데 제가 블로그에 글을 쓰는게 더 힘드네요. 이 부분은 반응봐서 더 추가하도록 할게요.

아무튼 기획하는 양보다 구현하는 량이 더 많아지면, 회의를 더 많이 하거나, 프로그래머의 경험에 의존하게 됩니다. 그렇게 해서도 기획 의도가 분명히 전달되어 잘 개발되는 경우도 있겠지만, 그렇지 않은 경우도 있고, 그렇지 않은 경우가 바로 위에서 처럼 눈에 보이지 않는 게임 시스템을 기획할 때라고 생각이 됩니다. 지금이야 누구나 다 아는 시스템이지만 몇 십년전 저런 걸 처음 만들어 보는 시절을 상상해보세요.

지금이야 잘 모르겠습니다. 워낙 게임도 정형화 되어 있고, 회사들도 기존 게임과 비슷하게 만드는 상태에서야 세부적인 디테일한 기획이 필요가 없을 수도 있죠. 

지금은 그것보다 더 중요한 이야기가 있어요! ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ

6 : 순서도를 필요로 하는 프로그래머

아까 마지막에 프로그래머가 게임 기획자에게 순서도를 요구했다는 이야기는 "난 당신 이야기 이해할 수 없어."로 알아 들어야 한다고 했었어요. 그 이유를 이제야 말씀드립니다. 한마디로 표현하면 이거에요. "프로그래머의 상식과 게임 기획자의 상식이 다릅니다."

( http://ayarin.egloos.com/v/2548489 )

단순히 상식의 차이로 발생하는 문제는 아닙니다. 또한 성격의 차이로 발생하는 문제도 아닙니다. 그냥 사회생활 하다보면 만나는 흔한 미스 커뮤니케이션의 일종일 뿐입니다. 하지만 그 원인은 심리적인 거에요.

커뮤니케이션 = 라틴어 Communicare(공유하다, 함께 나누다)에서 온 말입니다. 하지만 한국인들은 커뮤니케이션을 [생각을 공유하고, 서로 이해하며, 확산적 사고를 통해, 더 나은 결론을 도출]하기 보다는 [다른 사람에게 내 생각을 전달하거나, 내 생각에 맞추도록 하는 것]으로 생각합니다. 저런 모습 아이들을 통해서도 보입니다. 학교나 놀이터에서도 보여요.

우리나라 교육이 '협동', '협업'보다는 '경쟁', '지배' 이런 쪽으로 너무 많이 치중되어 있어서 어쩔 수가 없어요. 어릴 적부터 배운거라곤 남보다 뛰어나야 하며, 남을 설득해서, 내 주장을 펼치는 것이라고 배웠으니 어쩌겠어요. 교육이 바뀔 것 같지는 않으니까, 이제라도 스스로 바꿔야겠죠?

우리사회는 정반합이 필요한데, 항상 반-반-반-반-! 서로 대립하는 구도로 만들어 놓고, 서로를 악이라 부르죠. 이런 것 처럼 커뮤니케이션의 기준을 나에 두고, 내 생각을 전달하고, 내 기준으로 판단한다 것을 심리학에서는 ‘자기중심성(Egocentrism)’라고 합니다.

정반합, 헤겔에 의하여 정식화된 변증법 논리의 삼 단계. 곧 하나의 주장인 정(正)에 모순되는 다른 주장인 반(反)이, 더 높은 종합적인 주장인 합(合)에 통합되는 과정을 이른다.

자기중심성, 에고센트리즘, 에고는 많이 들어보셨죠? 이드, 에고, 수퍼에고 기억해요? 에고(Ego)는 자존심, 자부심 이런 뜻도 있어요. 요즘 재벌 2세, 3세 사건사고들 역시 에고가 강력한 분들이 많이 사고를 칩니다. 왜냐하면 사실 그게 기업가 정신이랑도 연결되어 있구요. 사이코패스 역시 에고가 강력합니다. 에고가 강력한 분들의 커뮤니케이션 특징을 자주 사용하는 말로 나타내보면,

자주 사용하는 말

1) 이렇게 쉬운 것도 몰라?, 내 말을 왜 이핼 못해? -- 타인도 나와 같다라고 생각함

2) 그건 아니지, 상식적으로 말이 돼? -- 자기 판단을 전적으로 믿음

3) 치열함이 없어, 여잔 안돼 -- 확고한 고정 관념

4) 내가 하고 싶은 말은… -- 상대의 반응을 고려하지 않음

 

7 : 결론은 뭐야? 순서도 써야돼?

글 쓰기 시작한지 5시간째... 글이 안 끝나네... 이제 그만 써야겠습니다. 오타쩔어...ㅠ.ㅠ;

그래서 제 결론은요. 그냥 이것만 기억해주세요. 아까 요점정리 기억하시죠?

-- 현 시대에는 "게임 기획에는 정답이 없다"는 주장이 대세임.

-- 게임기획자가 이분법적인 논리를 펴거나 단언하는 것은 금기사항임.

결국 다 같은 말 같은데, 유연한 사고, 타인에 대한 이해와 배려, 상호 존중, 생각의 공유, 이런 것들이 있습니다. 위와 같은 말을 하는 것도 사실 이것 때문이에요. 게임 기획자라는 직업은 특히나 다른 파트에 비해서 커뮤니케이션이 업무에서 높은 비중을 차지 합니다. 프로그래머와 의사소통을 잘 하기 위해서 적재 적소에 필요한 문서와 데이터를 제공하는 것이 중요하고요. 순서도는 그런 도구 중에 하나입니다. 특히 프로그래머를 상대할 때 유용합니다.

그리고 게임 기획자가 되면 에고가 높은 분들도 끌고 가야 할 때가 있어요. 결론은 뭐 자기중심성에 대한 이야기가 되어 버렸는데, 프로그래머만 그런게 아니에요. 그래픽 디자이너나 사장님, 게임 기획자들 중에도 에고가 강력한 분들이 있어요. 게임 기획자들 중에서 에고가 강한 분들은 기획자의 가장 중요한 자질로 설득과 자기 주장을 잘하는 것을 꼽지요. 또 사장님들도 에고가 강해요. 만약 프로그래머가 저런 기질이 있다면 나중에 창업할지도 모르고, 창업해서 성공할지도 모르니까 너무 싫어하는 것을 내색하지는 마세요. ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ

1. 결론 없음. 

2. 순서도 쓰라 말라 할게 아님. 단지 순서도를 필요로 하는 상황과 업무가 있을 뿐.

3. 많은 수의 프로그래머와 협업하거나 복잡한 시스템의 경우.

4. 구현과 설계가 분리된 업무 환경에서 게임 시스템 디자이너로 전문적인 역량이 있을 경우.

5. 마지막으로 에고가 강한 사람을 만나게 되는 경우. 어쩔 수 없음. 신뢰를 쌓기 위해 노력할 것

출처 : https://blog.naver.com/tepet/220235523834