Nemesis_guru

여러 서버에서 공통으로 사용하는 스크립트 데이터를.

하나의 프로세스에서 읽어두고, 다른 프로세스들은 이미 저장된 스크립트 정보를 읽어가면 좋지 않을까 싶어서 알아 본내용(사실 개발존에서는 여러 서버를 한 머신에서 띄우기 때문에, 같은 동작을 좀 줄여줄수 있으면 개발할때 편하지 않을까 해서...)

윈도우 Named Shared Memory

 

참고한 페이지

http://msdn.microsoft.com/en-us/library/windows/desktop/aa366551(v=vs.85).aspx
http://ezbeat.tistory.com/457
http://blog.naver.com/PostView.nhn?blogId=marindie&logNo=144944471

개념.

다른 프로세스에서 공동으로 접근이 가능한 메모리 공간에 String 을 key로 하는 메모리 공간을 만들어서 값을 쓰고, 읽고, 할수 있는 Window API

 

함수.

[1] CreateFileMapping
설명 : http://msdn.microsoft.com/en-us/library/windows/desktop/aa366537(v=vs.85).aspx

공유 메모리 공간을 만드는 함수. 어떤 크기로 어떤 “String”에 연결해서 만들지를 넘겨주면, 공유 메모리를 할당하고 그 Handle을 돌려준다. Handle이 Null 일 경우 실패. 자세한 내용은 설명 페이지 참조

[2] OpenFileMapping
설명 : http://msdn.microsoft.com/en-us/library/windows/desktop/aa366791(v=vs.85).aspx

공유 메모리 공간에서 특정 “String”을 key로 저장되어 있는 메모리가 있는지 찾아서, 있으면 해당 공유 메모리의 Handle을 돌려준다. 없으면 Null. 자세한 설명은 페이지 참조

[3] MapViewOfFile
설명 : http://msdn.microsoft.com/en-us/library/windows/desktop/aa366761(v=vs.85).aspx

특정 공유 메모리 Handle에서 메모리 공간에 접근할수 있는 포인터를 돌려준다.

 

사용법.

저장하고자 하는 내용을 특정 String을 key로 CreateFileMapping 을 이용해서 공유 메모리 공간을 만들고, 만든 공간을 MapViewOfFile로 위치를 받아서 접근해서 데이터를 저장(or copy) 한다.

사용하는 쪽에서는 OpenFileMapping을 이용하여 특정 String을 Key로 공유 메모리 Handle을 얻은 다음, MapViewOfFile로 메모리 공간을 접근하여 데이터를 사용한다.

 

주의할 점.

예제를 보면 Shared Memory에 값을 올리고, getCh()로 일부러 저장하는쪽의 프로세스를 죽이지 않고 끝내고 싶을때 키 입력으로 프로세스를 내리게 되어 있다.

그래서 프로세스가 떠 있는 동안에는 동작하지만, 프로세스가 내려가면서 unmap이나 핸들을 close 하고 나면 다시 초기화 된다.

 

고민되는 점.

만약 Named Shared Memory에 데이터를 잔뜩 넣고 Handle을 close 하지 않은채 프로세스가 죽어버리면 어떻게 되나? (아마 handle 계열은 프로세스 정리할때 잘 되었던거 같기도 함). 그렇다면 만약 여러 프로세스가 접근중인 메모리를 할당했던 프로세스가 죽어버리면, 다른 프로세스는 다시 그 데이터에 접근할 수 없는가? 테스트 필요함.

=> 간단히 테스트해본 결과 역시 Handle을 Create한 프로세스가 죽으면 공유 메모리 데이터도 다 날아가네용(Handle이 해제되서 그런거 같습니당) ㅠㅠ 주의 주의

 

항상 앞으로 나아가자.

여기서 "앞으로 나가는 것"은 "발전"을 의미한다.

그 발전이 무엇이든 그것은 각자 자신이 정의한 발전이다.

 오늘 하루종일 잠을 자면서 보냈더라도, 그 잠이 어제의 피곤을 회복하고 앞으로 나아가기 위한 체력을 보충하는 의미라면 그것은 발전을 위한 오늘을 보냈다라고 생각한다. 게임도 마찬가지의 의미를 가진다. 스트레스를 해소하는 수단은 사람마다 다르지만 그 스트레스 해소의 시간이 앞으로의 나에게 도움이 되는 행동이라고 생각하면 그것은 발전을 향한 일을 하고 있다고 생각한다(여기서는 또 "도움이 된다" 라는 기준이 다 다르긴 하지만 일단은 그러하다). 그래서 나는 이 "발전"의 단위를 1년으로 기준하고 있다. 그래서 항상 생각하는 것은 "1년전의 나와 비교하여 지금의 내가 더 나은 것이 뭐냐" 이다. 거기서 생각이 나는 그 무언가가, 바로 내가 1년동안 앞으로 나아간 내용이다. 그것은 작게 생각하면 어떤게임의 캐릭터를 만렙을 달성했다거나 하는 형태가 될 수도 있다. 그 게임에 대해서 더 잘 알게 된 것도 발전이라고 생각한다. 하는 일과 연관되어 있기 때문이다. 이 외에도 내가 스트레스를 잘 해결했다는 것을 증명하는 일이기도 하다.

 특정 기술을 익혔다거나, 책을 많이 읽었다거나 하는 것만이 발전을 위한 일이라고 생각하지 않는다. 완전히 멍때리지 않는 순간이 아닌 이상 나는 나아가고 있다. 드라마나 영화를 보거나, 애니메이션을 보는 것도 그 컨텐츠에 대해서 알게된 내용도 있고, 실제로 그런 컨텐츠 안에서 다른 지식을 얻는 경우도 꽤 있기 때문에 그것 또한 발전이라고 생각한다. 이런 유형의 발전은, 일에도 도움이 될 수도 있고, 다른 사람과의 대화에서도 소스를 제공할수 있으며, 앞으로 만들어야 하는 어떤것에도 도움이 될 "가능성"을 가지고 있다(지금 당장 나의 어떤 능력치(스탯)를 올려주진 않는다).

 이것이 내가 영화나 애니메이션을 보거나, 게임을 하거나, 하루종일 잠만 자거나 하는 행동을 정당화 하기 위한 것은 아니다. 미래로 연결되지 않는 행동은, 행동을 하는 그 당시에는 당장 발전하지 않지만, 발전할 가능성을 가진 행동들이라고 생각한다. 그 행동들을 미래의 발전으로 만드는 것은 나의 몫이므로 그 행동을 어떻게 이해하고 나의 생활에 내재화 시키느냐도 매우 중요하다.

 이런 생각을 가졌기 때문에 나 스스로가 가장 한심하다고 느끼는 경우는. 정말로 아무것도 하지 않고 숨만쉬고 있는 경우다. 가령 잠이 오는 것도 아닌데, 잠을 잔다거나, 내용을 열심히 보거나, 재밌게 보지도 않는데 TV를 그냥 켜놓은채로 멍하니 보고 있다거나 하는 것이 여기에 해당한다(또는 술마시고 다음날 상태가 안좋아서 아무것도 할수 없는 상태로 보내는 시간이라던가).

 그외에 아예 대놓고 내가 발전하기 위한 행동도 같이 포함되어야 한다. 무언가를 스스로가 "하고자 하는 마음"이 들었다면 그것을 "잘하기 위한 노력"이 반드시 수반되어야 한다고 생각을 한다. 재능에 의해서 처음부터 어느정도 잘할 수도 있다(나는 그런경우가 없었지만). 하지만 적어도 내가 그 일을 하고자 마음 먹었다거나, 그일을 반드시 해야 하는 상황이라면 "잘하기 위해 노력"을 하는 것이 내가 발전하는 길이라고 생각한다. 그에 수반되는 행동으로 가장 쉬운 것은 "그것을 잘하는 사람이 어떻게 하는지를 보는 것"이다. 가장 쉬운 방법들은 관련된 1) 책을 읽는 것. 2) 관련된 자료를 인터넷에서 찾아 보는 것. 그리고 3) 나와 같이 잘하기 위한 고민을 하는 사람이 모인 커뮤니티를 찾는 것. 이다. 이 3가지만 해도 다른 사람들과 그것에 대한 내용을 대화할 수 있는 정도의 실력은 가질 수 있게 된다. 그 이후에 그것에 대해 더욱 공부하고 노력해서 실력을 올릴지 말지는 다시 개인의 선택에 달려있다. 더 노력하는 이유는 그냥 그게 좋아서 일수도 있고, 필요해서 일수도 있다. 이유는 중요하지 않다.

 이렇기 때문에, 나는 좋아하는 사람의 유형과, 싫어하는 사람의 유형이 극명하게 갈린다. 나는 면접을 볼 때 꼭 물어보는 것이 있다. "이거 하나 만큼은 미쳐서 해봤다" 라고 할 수 있는게 뭔지를 꼭 물어 본다. 그리고 저 질문을 하지 않으면 "일도 좋고 공부도 좋고 취미도 좋고 이거 하나만큼은 많이 안다"고 말할 수 있는게 뭔지를 묻는다(비슷한 맥락이다. 꼭 그걸 잘하냐. 라고는 물어보지 않는다. 같은 노력을 들였더라도, 잘하고 못하고의 차이는 생기니까). 그리고 그것에 대해서 설명을 해봐달라고 부탁 한다(면접때 뻥치는 사람도 분명히 있다). 인상적이었던 면접자의 경우 특정 게임이었는데, 나는 그 게임을 하지 않아서 잘 모르는데도 불구하고, 그걸 설명하는 그 사람의 눈이 너무 반짝 반짝 빛나서 좋게 평가 했던 적도 있다. 자신이 좋아하고, 열심히 하는 그 무언가에 대해서 아무 노력을 하지 않는 사람과는 같이 일하고 싶지 않다. 일도 그렇게 할테니까.

 그리고 내가 저렇기 때문에, 나 스스로가 저런 사람이 아니고 싶기 때문에, 나는 항상 뭔가를 노력해서 공부한다(그게 게임이든, 노래든, 뭐든. 사실 이건 의도해서 한다기 보단 그냥 하게 된다-_-). 내가 무언가를 좋아하거나, 무언가를 해야 한다면, 그것을 잘하고 싶어하는 것이 가장 기본이라고 생각한다. 공부하고 노력한다고 반드시 잘하게 되는 것은 아니지만, 노력하지 않으면 잘하게 되지 못한다고 생각한다(재능도 한계는 있다고 생각합니다).

그러하다.

 

계속 생각나는 대로 갱신합니다.

1. FC

드래곤볼Z 2

캡틴츠바사 2

 

2. SFC

성검전설 3

드래곤볼 초무투전 2

드래곤볼 초사이어인 전설

드래곤 퀘스트 3

 

3. MD

랑그릿사

 

4. PC-E

이스4

에메랄드 드래곤

바람의 전설 제나두 1,2(2는 못해봤음..)

천사의 시2

 

한다면 SFC 먼저, 그다음 PC-E 정도 일려나..

 

게임데이터에 대한 update, insert는 게임에서만 한다. 웹이나, 앱에서 update, insert를 게임내 데이터로 직접 넣지 않아야 한다(select만 해야한다). 이게 잘못 되었을 경우의 파장은 어마어마 하다.... 게임데이터가 꼬여서 플레이 할수 없게됐는데, 롤백은 할 수 없는 무시무시한 상황이 될수도 있음..

- 반대로 말하면 웹쪽의 이벤트나, 앱쪽 기능을 위한 데이터는 게임에서 insert, update 하지 않는다.

 

한 가지 기능은 반드시 "하나의 크리티컬한 패스"를 반드시 지나가야 한다. 예를 들어 아이템을 획득하는 루트가 여러가지 일지라도, 실제로 아이템이 "획득" 되었다는 것을 무조건 보장해줄 수 있는 하나의 패스가 필요.

- 이걸 생각하게 된 이유는 히스토리 로그를 남길 때, 같은 로그를 두 군데 이상에서 남겨야 한다면, 변경에 대응하기 쉽지 않아지기 때문이었는데, 구지 히스토리 로그만이 아니라도, 변경에 대응하는데 있어서는 좋은 룰인것 같다. 예전에 모 게임의 아이템 생성 과정이 2~3루트로 만들어져 있어서, 한군데만 고치거나 하는 일때문에 사이드 이펙트가 많아서 고생했던 기억도 있다.

 

기능과 데이터는 분리되어 있을 수록 좋다. - 이거 하나만 설명하는데도 많은 글이나 시간이 필요하므로 자세한 내용은 생략한다(언젠간 길게 적을 기회가 있겠지)

 

모든 기획 / 내용은 변경될 수 있다고 생각해야한다. 이건 기획만이 아니라, 처음에 자신이 만들 때 생각했던 "가정"도 마찬가지. 함부로 가정하고 만들면 나중에 꼭 피를 본다.

 

서버에서 에러는 크게 2가지로 분류할수 있다. "유저에게 보여지는 에러"와 "시스템 내부 에러", 한 가지 기능에 대해서 이 2가지만 잘 구분해 놓아도 설계에 많은 도움이 된다. - 에러와 관련된 내용도 정리해서 하고 싶은 말이 많다. 다음 기회에

- 보통 기획자는 "아이템을 강화한다. 실패하면 실패 메시지를 띄운다" 라는 초간단 기획에서 부터, "아이템을 강화한다. 1) 강화 할 수 없는 아이템일 경우 메시지 A(강화할 수 없는 아이템에 대한 정의는 따로) 2) 더이상 강화할 수 없는 장비면 메시지 B 3) 재료가 부족하면 메시지 C 를 띄운다" 같이 에러 상황을 잘 명시한 기획까지 여러개를 만날수 있는데, 출력의 레벨 결정이나 메시지 결정을 개발자가 임의로 해야 하는 상황이 많다. 또는 에러 상황의 우선순위 결정에도 개발자가 임의로 하는 경우가 일상다반사인데(앞의 예를 든다면, 더이상 강화할 수 없는 장비이면서 재료가 부족하다면 더이상 강화할 수 없다는 에러의 우선순위가 높다), 저런 부분 하나하나가 설계나 시퀀스에 영향을 줄 수 있기 때문에, 개발에 앞서 에러 상황과, 우선순위 결정만 잘 해놔도 상당한 도움이 된다.

 

const 를 잘 지켜야 한다. 리턴값이나 파라메터의 const보다. 함수의 const 함을 지켜야 하는 것만 잘 관리해도 상당한 양의 실수를 미리 알수 있다. 그리고 이런 const를 지켜주는 것이 코드의 깨끗함을 상당수준까지 올려준다(함수 이름과 기능이 다른 경우라던가). -  내가 가장 잘 안되는 부분이기도 함..ㅠㅠ

 

특정 행동을 한번의 프로세스로 끝내지 못할경우 - 다른 스레드로 넘겼다가 받아와야 하는 작업 또는 다른 프로세스, 다른 서버로 넘겼다가 결과를 받아야 하는 경우 - 그 작업이 진행중인데 같은 요청이 들어온 것에 대한 방어가 되어 있어야 한다. 매우 주의가 필요함(다르게 생각하면 멀티쓰레드 작업시 어느 부분을 멀티 쓰레드 세이프 하게(아토믹하게) 만들거냐 하는 문제와도 비슷함)

- 예전에 일하던 팀의 게임에서 클랜 가입 요청같은 것이 여기에 해당. 유저 A가 클랜 N 에 가입 요청을 보내고,  그 처리가 완료되기 전에 클랜 T에 또 가입요청을 보낼경우. 방어가 되어 있지 않다면 문제가 된다. 여기서 주의 해야 할 점은 "중복 요청의 범위"를 어디까지로 볼것인가 하는 것인데, 이 경우는 '클랜 가입 요청을 보내는 행위'에 대해 플레이어에 대해서 중복을 체크해야 한다. 즉, 한 플레이어는 하나의 클랜 가입 요청이 끝나지 않은 상태에서 다른 가입 요청을 보낼수 없어야 한다. 각 경우에 따라서 어느 곳에 "중복 체크" 안전 장치를 할 것인지에 대해서 고민이 필요하다.

 

구조체나 스트링이나 배열같은 크기가 좀 있는 데이터의 경우에 한해서, 한번의 함수 호출로 데이터를 모두 사용하고 필요없는 데이터가 된다면, 포인터나 참조로만 넘겨서 쓸데 없는 데이터 복사가 일어나지 않게 하는게 좋다. ... 당연한 말이니까 자세한 설명은 생략(... 하지만 이것도 내가 가장 실수 많이 하는 것들중 하나..)

 

어떤 기능을 구현함에 있어서, 지금 구현한 이후에 변경사항이 많을것 같고, 그 작업을 다른 사람이 할 때 혼란을 야기할 것 같다면(.... 이걸 미리 아는것도 어렵긴 하겠네.. ㅠㅠ), 다른 사람이 작업할 때에는 세부 구현에 신경쓰지 않아도 되도록(실수할만한 부분이 적도록) 구조를 고민 해 보아야 한다.

- 예를 들어, 캐릭터 정보가 변경되면 DB 업데이트를 해야 하는데, 캐릭터 정보에 새로운 것들이 추가될 때마다, 작업해야 하는 부분이 많으면 아무래도 실수할 부분이 많아진다. 그렇다면 -> 캐릭터 정보가 변경되는걸 알려주는 observer를 만들고, 변경 발생을 감지 ->데이터 전체를 업데이트 하는 하나의 함수로 업데이트 한다면, 새로운 데이터를 추가한 것만으로는 추가 작업이 발생하지 않는다(.. 설명에 좀 문제가 있긴한데 대충 이런 느낌으로만 봐주셈둥).

- 한가지 더 예를 들자면. 또 모 게임의 아이템 시스템 중, 장비 강화나, 인챈트 같은 시스템 같이 장비자체에 어떤 행위를 통해 데이터를 변경하는 시스템이 있는데, 이 장비를 장착한 채로 강화 또는 인챈트 할경우 그 데이터가 바로 바로 그 캐릭터의 스탯에 반영되어야 한다. 이런 경우 "장착한 아이템에 변경이 생겼다" 라는 이벤트를 받아서 -> 기존에 아이템 효과를 모두 제거 -> 다시 변경된 데이터의 아이템 효과를 다시 적용 하는 형태의 흐름만 잡아 두면 추가 데이터가 발생해도 이쪽을 다시 작업할 일이 없어진다(성능 이슈는 발생할수 있음).

 

반드시 순서를 가져야 하는 경우 "이정도 시간을 주면 되겠지" 하는 방식은 절대 금물, 반드시 순서를 보장해 줄수 있는 루트를 찾아야 한다.

- 예를들어, 캐릭터 로그 아웃시, 두 DB에 데이터를 써야 한다면, 한쪽 DB의 작업이 많다고 해서 해당 DB 쓰기 작업이 반드시 늦게 끝난다는 보장이 없기 때문에, 반드시 양쪽 모두의 "완료"를 확인하고 로그아웃 처리를 해야 한다(양쪽의 완료를 보장해주기 위한 장치가 반드시 필요하다).

 

어떤 컨텐츠에서 timestamp 값을 사용한다면 그 값이 1) 서버 application의 시간인지, 2) DB의 timestamp 인지 잘 구별해서 사용해야 한다. 한번에 여러개의 테이블에 시간을 기록하거나, 그 시간이 모두 같아야 한다거나, 쿼리를 여러개 날리는데, 그 값이 같아야 할 필요가 있다면, 서버 application이 시간까지 계산하여 사용하는 것이 좋고, 그런거 상관없이 쿼리 당시의 DB 시간만 있으면 된다면 DB의 시간을 그냥 사용하면 된다. 크게 중요하진 않지만 지켜 주면 좋은 내용이라고 생각

 

무엇을 만들더라도 항상 "실수"가 있다고 생각해야 한다. 가장 먼저 생각할 수 있는 것은 스크립트나 어떤 데이터의 오류다. 이걸 판별하는 방법은 미리 검증을 넣어서 확인하거나(자동화된 테스트 등으로?), 서버 기동시 검증 하거나 하는 등의 방법이 있다. 중요 기능이 진행될 때 이런 실수에 의해서 잘못 동작할 우려가 있다면  1) 사전에 그 실수를 커버하는 상위의 규칙을 만들거나 2) 그 실수가 발생했을때 미리 알아 챌수 있는 시스템이 갖추어져 있어야 한다(둘중 하나는 반드시 있어야 한다). 이런 부분은 보통 기획자와 상의를 통해서 해결해야 하는 경우가 많다. 예를 들어 던전 입장시 피로도를 소모하는 게임에서, 특정 던전이 피로도를 소모하지 않는 대신 경험치를 주지 않는 다면(다른 보상), 1) 피로도를 소모하지 않는 던전은 반드시 경험치를 주지 않는다는 규칙을 시스템화 하거나 2) 피로도를 소모하지 않는 던전인데, 경험치를 주도록 되어 있는 경우가 없는지 미리 검증을 해서 수정할 수 있도록 해야 한다.

 

 

.

시작 2013년 1월 19일(토)

시작 초대장+도전장 : 2597 장(순수하게 직접 모은거. 잠쩔 안함) ... 이후에 너무 많이 써서 몇장인지도 모르겠음.

+ 봉인된 자물쇠에서 나온 것들

지속 갱신

매우 어려움 : 503

어려움 : 336

32 - 매어 : 마나증강(80제 에픽 너클)

37 - 매어 : 블레스 가이아(80제 유니크 너클) - 이계

42 - 매어 : 백색의 눈부신 목걸이(80제 명속강 목걸이) - 이계

107 - 매어 : 파이터의 진의(80제 유니크 권투 글러브)

125 - 매어 : 한기(80제 유니크 대검)

139 - 매어 : 몬즈메그(80제 유니크 핸드캐넌) - 이계

160 - 매어 : 한기(80제 유니크 대검)

174 - 매어 : 미니어처 흉가(80제 유니크 스탭)

193 - 매어 : 본 레드 드래곤(80제 에픽 소검) - 이계

214 - 매어 : 현인군자의 메달 - 데스페라도(75제 유니크 마법석) - 이계

216 - 매어 : 포츈 베이요넷(80제 유니크 창)

240 - 매어 : 화룡봉추(80제 유니크 토템) - 이계

278 - 매어 : 헤라의 수호 - 워록(80제 에픽 보조장비) - 이계

296 - 매어 : 서브마린 볼케이노 상의(80제 유니크 경갑 상의)

299 - 매어 : 현인군자의 메달 - 메탈하트(80제 유니크 마법석)

330 - 매어 : 본 블루 드래곤(80제 유니크 소검)

331 - 매어 : 헤라클레스(80제 유니크 둔기)

342 - 매어 : 지벤 황국의 완장(80제 에픽 보조장비)

342 - 매어 : 은밀한 카멜레온 가죽 벨트(80제 에픽 가죽 벨트)

344 - 매어 : 명강성주(80제 에픽 염주)

359 - 매어 : 영혼 절단기(80제 유니크 배틀액스)

377 - 매어 : 스파이럴 스핀(80제 에픽 단검)

380 - 매어 : 영혼 절단기(80제 유니크 배틀액스)

403 - 매어 : 인피니티 레퀴엠 판금 하의(80제 에픽 판금 하의)

426 - 매어 : 미지의 다크홀 하의(80제 에픽 중갑 하의) - 이계

455 - 매어 : 고대 귀족의 서적 - 스핏 파이어(여)(80제 유니크 보조장비) - 이계

461 - 매어 : 베넬제뉴(80제 유니크 머스켓)

463 - 매어 : 미노스의 비밀 - 헬벤터(80제 유니크 보조장비)

468 - 매어 : 영혼 절단기(80제 유니크 배틀액스)

482 - 매어 : 인피니티 레퀴엠 판금 상의(80제 에픽 판금 사의) - 이계

489 - 매어 : 플로레의 형상석(75제 유니크 마법석)

515 - 매어 : 미지의 다크홀 사의(80제 에픽 중갑 상의)

526 - 매어 : 민첩한 카멜레온 가죽 하의(80제 에픽 가죽 하의)

528 - 매어 : 포츈 베이요넷(80제 유니크 창)

557 - 매어 : 현인군자의 메달 - 검성(75제 유니크 보조장비)

581 - 매어 : 미노스의 비밀 - 헤비배럴(80제 유니크 보조장비)

625 - 매어 : 서브마린 볼케이노 벨트(80제 에픽 경갑 벨트)

644 - 매어 : 포이즌 듀트 사이드(80제 유니크 낫)

650 - 매어 : 얼어붙은 공진의 낫(80제 에픽 낫)

683 - 매어 : 서브마린 볼케이노 신발(80제 에픽 경갑 신발)

700 - 매어 : 다크 고스 하의(80제 에픽 천 하의)

727 - 매어 : 미노스의 비밀 - 독왕(80제 유니크 보조장비)

799 - 어 : 포이즌 듀트 사이드(80제 유니크 낫)

821 - 매어 : 아테나의 지혜 - 사령술사(80제 에픽 보조장비, 한기(80제 유니크 대검)

823 - 매어 : 현인군자의 메달 - 용투사(75제 유니크 마법석)

* 유니크

블레스 가이아, 백색의 눈부신 목걸이, 파이터의 진의, 한기*3,몬즈메그,미니어처 흉가,현인군자의 메달-데스페라도,포츈 베이요넷*2,화룡봉추,현인군자의 메달-메탈하트,본 블루 드래곤,헤라클레스,영혼 절단기*3,고대 귀족의 서적 - 스핏파이어(여),베넬제뉴,미노스의 비밀 - 헬벤터,플로레의 형상석,현인군자의 메달,미노스의 비밀 - 헤비배럴,포이즌 듀트 사이드*2,미노스의 비밀 - 독왕,현인군자의 메달 - 용투사

 

* 에픽

마나증강, 본 레드 드래곤, 헤라의 수호 - 워록, 서브마린 볼케이노 상의,지벤 황국의 완장,은밀한 카멜레온 가죽 벨트,명강성주,스파이럴 스핀,인피니티 레퀴엠 판금 하의,미지의 다크홀 하의,인피니티 레퀴엠 판금 상의,미지의 다크홀 상의,민첩한 카멜레온 가죽 하의,서브마린 볼케이노 벨트,얼어붙은 공진의 낫,서브마린 볼케이노 신발,다크 고스 하의,아테나의 지혜 - 사령술사

 

 

이후에도 계속 돌고 있고, 초대장도 4천장정도 더 사용해보고, 항아리는 총 22개를 개봉했지만 타악손님은 나오지 않음. ..... 6/28

 

이번 업데이트를 계기로 x5 렙제 아이템이 드랍되지 않게 되었습니다.

그리고 할기가 드랍되지 않고 합성으로도 등장하지 않게 되어,

현재 풀려 있는 물량이상의 할기는 더이상 만들수 없게 되었습니다.

아마도 의도했던 것은 할기가 오버밸런스 템이라고 생각되었으니

더 이상의 새로운 오버 밸런스 템을 생산하지 않겠다는 것.

그리고 밀봉 횟수 제한이 있으므로 시간이 흐르면 점점 할기의 거래가 줄어들고

어느 시점이 되면 거의 멸종하게 될 것. 이라고 생각을 했던 것이 아닐까요?

 

하지만 문제는 "원샷 밀랍초"에 있습니다.

모르는 분들도 계시곘지만 원샷 밀랍초를 이용하면 재밀봉 제한을 넘어선 아이템도 밀봉이 가능합니다.

즉, 이걸 이용한다면 할기는 계속 거래가 가능하다는 말.

게다가 원샵 밀랍초를 써야 한다는 점과 드랍되지 않는다는 점에 의해서

"상상 초월의 고가"가 지속적으로 형성되어 끝없이 거래를 하게 된다는 점입니다

(결국은 거래가 없어지지 않음).

 

 패치전에 4~5천만 정도이던 할기가 지금은 8천만을 넘고 있습니다.

아마 지속적으로 계속 상승할거라고 생각합니다.

할기의 생산을 막아 오버 밸런스를 없애고 싶다는 의도였다면 "실패" 였다고 생각하며,

비슷한 방식으로 카운터 데미지를 올려주는

65제 유니크 반지 "라키의 본링"과 65제 에픽 반지 "쿠로의 반지"가

역시 마찬가지로 드랍되지 않게 됨으로 인해, 할기 대체품. 은 아예 존재조차 하지 않게 됩니다..

즉, 할기의 희소성은 더욱 상승하며,

결국 사라지지 않는 절대적인 가치를 지니는 아이템이 될 가능성이 더 생긴듯 합니다.

할기 없이는 캐릭 취급도 못받는 애들이 있는데... 걔네는 어떻게 되려나요(스커라던가 스커요)..

물론 저는 돌려쓸 할기가 하나 있으니까 패스... .... 쿠로의 반지도 이미 있으니까 패스... 헤헤헤.

(영추가 없는건 좀 아쉽지만. ㅠㅠ)

 

뭔가 좀 아쉽네요.

로망템이 점점 사라지거나 희귀해져 가서..

 

장비 사전을 업데이트와 동시에 다 넣지 말고

일단 유저들이 직접 먹고 커뮤니티 사이트에서 자료 모으고 하는 재미를 좀 줬으면 어땠을까?

80렙 보스 유니크, 유니크, 에픽 다 옵션이 뭔지 알게 되니까 살짝. 재미가 떨어지는 감이 있음.

내 직업에 고렙 로망템이 없다는 걸 빨리 알게 하는 것도 재미를 떨어뜨리는 요소...

반대로 미리 알게 되서 로망템을 향해 게임을 플레이 하게 만드는 요소도 있지만(스커.. 추뎀 12%라니.. 증뎀도 아니고 추뎀.. 추뎀...),

그런 경우는 정말 몇 직업 안되는 듯..

 

ps. 장비사전의 폐해인데.

75제 보스 유니크 '도' 가 분명히 지난주 처음 패치되었을 때는 "물리크리티컬 +20%"이었는데

오늘보니까 "물리크리티컬 +2%" 로 바꼈음.

....로망템이 또 없어짐.

 

얼마전 EVO 2012 에서 잠입님이 스파4 AE 2012버전 에서 우승을 했습니다.

영상을 보고 필 받아서.

다시 회사 분들과 스파를 하기 시작 했습니다. ㅎㅎㅎㅎ

그러다가. VS 달심용 윤. 과

다른분에게 알려드리기 위한. 캐미. 연습을 조금 했는데.

 

윤은 약간 다루기 힘들지만 재미가 넘치는 반면.

캐미는 재미는 일단 둘째치고. 완전 캐릭터가 좋네요. ㅎㅎ

요즘은 정역 흔들기가 없으면 재미를 많이 못느끼는거 같습니다 ㅎㅎㅎ

 

여튼 각설하고 영상 나갑니다.

 

윤 VS 페이롱(연습중인 윤)

 

페이롱 분이 마지막에 치염각을 EX로 썼으면 제가 졌음...

 

캐미 VS 칙칙이

 

콤보는 죄다 삑살이고. 히트 확인이고 뭐고 잡기만 함...

 

캐미 VS 더들리

 

저질 대전 영상 죄송합니다. 하하하하하

 

 

정말 오랜만에.
퍼펙 라운드를.. 해서 ㅠㅠ

기념으로 영상을 남겨봄.

아이디는 못가렸는데.
혹시나 보고 기분 나쁘시면 내릴게요.

-0-

작년 연말에 있었던 일이다.
연말에 팀 회식 자리.
사장님이 자리에 같이 하셨고.
마침. 내 옆자리에 앉아 계셨다.

하고 싶은 말이 없냐고 물으셨다.

오예.
이런 기회가 오길 기다리고 있었지롱.

그전에 생각해 뒀던.
사장님한테 물어봐야지. 했던 내용과. 제안하고 싶었던 내용을 다 말했다.

물론. 그 말들을 반영해 주진 않으실테지만.
나한테 있어서는 일단 말을 했다는게 중요하다.

그 중에 내가. "게임을 개발하며 가장 중요하다고 생각하는 요소" 지만.
지금 회사에서 너무 무시하고 있는 한가지 내용에 대해서도 이야기를 드렸다.

그 내용은. 바로
"QA" 이다.

이런 이야기를 꺼냇던 이유는.

QA 파트 혹은 팀이 있기는 하지만. 단순 테스트 팀이상의 역할을 하기 힘든 환경이다.
이유는 첫 번째로 인원이 너무 작다
일정 우선시 되는 개발 프로세스다.

라는 점때문인데.

즉, QA 팀의 인원이 적다보니.
단순 테스트 자체도 모두 소화하기 힘든 일정으로.
QA가 다른 일까지 맡기 힘든 악순환 이다. 라는 내용이다.

지금 팀은 아니지만. 이전 팀에 있었던 경험에 비추면.
일단 QA 팀 사람이 "기획 회의" 자체, 또는 "개발 회의" 자체에 참여할 수 있는 기회가 거의 없었다.

즉, 기획단계에서.
게임에 대해 가장 잘 알고 있는 사람의 의견.
혹은 기획자나 개발자가 놓칠만한 예외 상황에 대해 전혀 이야기 할 수 없다.
(물론 기획자나 프로그래머도 자신이 아는 한에서는 예외 상황에 대한 이야기를 많이 한다)

그러다 보니. 기획서는 부실해지고.
그 부실한 기획서를 바탕으로 개발이 진행되면.
테스트 단계에서야 그 내용을 확인한 QA 팀은 문제를 지적해도.
이미 일을 틀어져 있을대로 많이 틀어져 버린 경우가 많다.

그렇게 되면 어떤 일이 발생하느냐.

이미 그 단계까지 간 상황에서 기획을 대대적으로 수정하기엔. 일정이 맞지 않기 때문에.
일정이란 현실에 타협하게 되고.

게임에 있어서 가장 중요한.
재미를 해치는 기획이 게임에 들어가버리는 경우가. 허다하게 발생한다.
즉, 재미를 검증하지 못한채 올라간다.

내가 온라인 게임을 개발하며 느낀
온라인 게임에 있어서 가장 중요한 것은 2가지는.

1) 재미
2) 안정성

이다.

재미. 에 대한 부분은 게임을 기획하고 만드는 입장에서. 검증해줘야 한다면
(물론 QA가 이 재미에 대한 검증도 같이 하긴 하지만)

안정성. 부분은.
프로그래머나 기획자들도 신경써야 하지만
QA가 가장 활약할 수 있는 부분이다.

워낙에 이전 팀에 있을떄.
패치 이후에 유저들 단에서 버그가 발견되고 문제가 된 경우가 많다 보니.
개발자가 노이로제에 걸릴 지경이었다.

테스트가 제대로 되지 못한 채로 실서버에. 유저들에게 패치되는 게.
얼마나 무섭고 떨리는 일인지. 겪어봐야 안다.

그리고 이렇게 안정성에 대한 품질이 떨어지는 게임은.
게임이 미치도록 재밌지 않는 이상 유저들이 떨어져 나간다.
(일단 나만해도 그렇다... 예전에 그라나도 에스파다 오픈 했을때 쌍욕을... 흠흠..)

게임이 실패하는 원인이 된다.



지금 있는 팀의 게임은.
5 VS 5  로 진행되는 대전 게임이다.

최소 10명이 되야. 제대로 된 게임을 테스트 할 수 있다.
몇가지를 고려하면 최대 14명. 최대인원 테스트를 하려면 15명의 테스터가 있어야.
하루종일 '테스트' 업무에 집중할 수 있다.

지금은 14명의 절반의 절반의 인원뿐이다.
....

개발자. 즉, 기획자, 프로그래머에 비해 압도적으로 적은 수의 인원이다.



그럼 내가 생각하는 게임 개발에 있어서 게임 QA는 어느정도의 규모여야 하며.
어떤 역할을 해주어야 할까.

내가 생각하는 최소 인원은.
"게임내의 컨텐츠중  최대 인원을 필요로 하는 컨텐츠를 QA 팀만이 단독으로 테스트 할 수 있는 인원"

예를 들어 와우의 40인 레이드 컨텐츠가 있다면.
적어도 40명의 인원이 테스트 할 수 있어야 한다.

인원이 모자르게 되면. 모든 케이스를 커버하는 테스트 자체가 불가능 하다.
이 인원을 채워서 테스트 하려면. 개발 인력을 데려다 써야 한다.
개발인력을 원래 개발 목적이 아닌 다른 목적으로 시간을 쓰게 하는 것 자체가. 아까운거라고 할수 있다.

그럼 QA의 역할은 최소한 어느정도야 하는가.

먼저. 위에서도 이야기 했지만.
기획 회의, 개발 회의에 적극적으로 참여하여.
현재 게임에 있는 컨텐츠와 새롭게 개발되는 내용간에 예외상황이나.
다른 문제에 대한 예측이나 판단을 할수 있어야 하며.
내용에 따라 테스트 기간 산출, 기획서에 대한 테스트 케이스, 테스트 수트를 작성할 수 있어야 한다.

이게 기본.
테스트 서버에서 테스트가 가능한 상황이 되면 테스트 케이스에 따라 일정에 따라 테스트 하고.
그결과를 피드백. 그냥 테스트가 실패 했다. 성공했다. 만이 아니라.
어떻게 개선했으면 좋겠다. 등의 의견 제시까지 필요.

만약 테스트 버전에서.
"일정 수준"(이 기준에 대한 것은 여기서는 정의하지 않겠다) 이 되지 않는 다고 판단되면.
과감히 해당 컨텐츠를 다음 패치 일정에서 제외 시킬수 있는 권한도 필요하다.
(지금은 기획자가 이걸 하는 경우가 많은데.. 대부분 QA팀을 무시한채 일정을 강요하며
 밀어 붙이는 경우가 많다)

이외에.
게임에서 "개선 했으면 하는점". 새로운 컨텐츠 제안도 가능 하고.
그게 기획에 반영되는것도 바란다.

사실 마지막에 말한 내용은.
QA 팀만이 아니라. 게임 개발자 모두가. 할수 있는 팀이 가장 좋은 팀이라고 생각한다.


내가 프로그래머 이고.
나는 내 코드를 믿지 못하는 못난 놈이기 때문에.
완벽에 가까운 테스트를 꼭 거쳤으면 하는 것이 소망이기 때문에.
이런 생각을 하는 것일수도 있다.

그냥 이런 저런 생각에
정리라도 할겸.
글을 남겨 본다.