개인적으로 게임성은 나쁘지 않고 여러가지 경제구조만 완화시킨다면야
훌륭한 게임이라고 생각합니다. 하지만 반대로 최적화와 관련되서는 정말 실망스럽네요.
게임하면스 느꼇던 개선해야될 필요가 있는 목록을 적겠습니다.
빠른시일내에 완화되면 좋겠네요. 이제 곧 10년이 다되가는 게임입니다.
그동안 개발자들이 얼마나 무관심 했는지 그대로 보여주는게 아닌가 생각이 드네요.
특히 프로그래머들, 부끄러운줄 알아야지. 발로짜도 돌아가기만 하면 다인가?
클라이언트 개선사항 1. 팅김현상
-> 해당 사항은 맵을 이동하거나 할때 클릭을 하여도 종종 팅깁니다. 그말은 로딩중에 로딩이 끝나기전에 이벤트가 들어오면 이벤트를 받다가 죽는다는 이야기지요. 혹은 멀티쓰레드 최적화가 발로 되었다는걸 뜻합니다.
특히 맵 넘어갈떄 그라나도는 응답없음이 되지요. 이 이야기는 메인쓰레드에 텍스쳐 갈겨놓고 다음이벤트에서
어설프게 멀티쓰레딩을 한다는 뜻으로 추측이 되네요. 일괄적 빈틈없는 로딩(실수를 할수없는 상황)이 아니라
마치 없던 멀티쓰레드 로딩을 중간에 억지로 쑤셔박은 느낌이 물씬 풍기네요. 아니면 실력의 한계이거나.
그래서 이부분 리펙토링이 확실히 필요합니다.
클라이언트 개선사항 2. 메시지 방식
-> 개발하다보면 네트워크의 효율적인 이용때문에 메시지 방식을 택하게 됩니다.
하지만 only 메시지 방식으로 개발을 하게되면 분명 타이밍상 문제가 발생할 수밖에 없죠.
이 타이밍 문제로 많은 피해를 입고 있는게 스탠스가 바로 바뀌지 않아서 스킬을 잘못쓰는 경우이죠.
분명 개발하면서 이 부분때문에 많은 부분이 꼬여서 문제가 발생할것이라 판단합니다.
그래서 느슨한 처리와 급한처리를 확실히 구분해서 큰 아티클부터 정리할 필요가 있다고 생각합니다.
클라이언트 개선사항 3. 느린 로딩
-> 리소스 최적화도 의심이 되고, 무엇보다 단일 쓰레드에서 너무 많은걸 한다는 느낌이 강하네요.
그래서 간혹 쓰이는 방법이 저퀄리티 텍스쳐를 로딩해서 입혀놓고 점점 퀄리티 좋은걸로 바꿔주는 로딩방식의
도입은 어떤가요? 혹은 어딘가에 교착상태가 있는건 아닌지, 불필요한 서치같은것이 CPU의 많은 부분을 처먹고
있는다던지 프로파일링이 시급합니다.
클라이언트 개선사항 4. 사운드 렉
-> 이건 정말 보고 웃겼습니다. 왜 웃겼냐면 왜 이게 렉이 나는지 이해를 못하겠습니다.
타 게임이 렉이 안나는 이유가 있지 않겠습니까? 사실 이건 추측이 안됩니다.
주변글에 3DSound distance 효과라고 했는데 이건 그냥 볼륨조절이라 비용이 크지 않습니다.
만약 정말 그거라고 한다면 정말 노답이라고 생각이 드네요.
하지만 무분별한 channel 관리, 혹은 cache 를 재대로 하지못하였다거나 한다면
저정도의 렉이 발생할수 있다고 생각이 듭니다. 왜 렉이 날까요~ 후훗
서버 & 클라이언트 개선사항 1. 위치렉
-> 패스 엔진을 쓰고 있지만 결국은 그 엔진 때문에 서버랑 동기화의 문제가 생기는건지 추측이 안되네요.
하지만 너무 심한 순간이동과 위치가 맞지않아 마법진을 맞는경우등 불합리한 상황이 가끔, 혹은 자주 연출이 됩니다.
서버에서의 위치계산도 썩 탐탁치 않은것 같구요. 서버가 우선적인건 맞지만 자잘자잘한건 이미 오래전부터
클라이언트 의존으로 많이 바뀌었습니다. 서버에서는 어뷰징 체크해서 블랙리스트로 만들어두는 방식이 많이 쓰였구요
유저의 답답함을 개선하는게 가장 큰 목표이지. 어뷰징을 잡기위해 유저의 불편함을 가중시키는건
게임 서비스 목표가 아닌줄 압니다. 단지 그들을 정확하게 걸러내어 공평한 판단을 해주는게 게임사의 역할이 아닐까요?
서버 & 클라이언트 개선사항 2. 칼렉
-> 위와 연관되어 말씀드리자면 칼렉이 심한 게임으로써는 리니지, 그라나도, 라그나로크 등이 대표적입니다.
서버 선체크, 후 칼질방식 이지요. 이것도 요즘 안합니다. 1번에서 언급한 이유 때문이죠.
대략 클라는 나 칼질했어 라고 알려줍니다. 그리고 그냥 칼질 합니다. 그 후에 서버에서는
그래 너의 칼질에 누구누구 맞았어 라고 알려줍니다.
선체크, 후칼질 보단 구현이 어렵죠. 하지만 유저의 답답함은 없습니다.
서버 개선사항 1. 상자렉
-> 상자를 까면 가끔 서버에서 응답이 매우 느리게 옵니다. 클라이언트는 먹통이죠.
확실히 이부분에서 저는 확률에 대한 통제를 타이트 하게 한다고 느꼇습니다.
이유는 서버가 응답을 늦게, 그것도 하필 상자 깔때마다 자주 걸리는데 그건 또 하나의 확률서버 하나가
이를 통제하고 있다고 느껴지네요.
추측 히스토리는
C -> 상자 열게
S -> 기다려봐 물어보고
R -> 기다려봐 확률 계산좀하고 ( 이 상황에 클라이언트에서 온건 S가 무시 )
R -> S에서 결과를 통보
S -> C에게 결과를 통보
이 과정에서 R의 기다리는 과정에서 연산이 오래걸릴경우 데드락을 의심할 정도의 오랜기다림이 생깁니다.
요점은 그렇다면 어떻게 만들었길래 이 부분이 오래걸리는지 이해가 되질 않네요.
마치며..
제가 뭐 IMC개발자도 아니고 그라나도를 좋아하는 유저의 입장에서 오지랖 안떨라고 했지만
정말 해도해도 너무 심하네요. 지속적인 유지보수와 리펙토링을 하지않고 오로지 서비스에 급급하여
시대적 개발흐름에 뒤쳐진것, 그냥 무작정 여기까지 달려온게 너무 눈에 보입니다.
같은 소스를 짜더라도 잘 쓸수밖에 없도록, 버그가 없도록 구조를 짜서 만들면 이렇게 까지 안왔을겁니다.
설계자의 문제가 가장 크다고 판단이 들며, 많은 부분을 수정하지 않는다면 계속 유저의 스트레스를
갉아먹는 게임이 될수밖에 없을것 같네요.
스트롭형님이 하신말씀이 있잖아요. "잘쓰기는 쉽게, 잘못 쓰기는 어렵게."
이글을 만약 개발진에게 전하면, "그럼 니가 해봐" 라며 온갖 변명과 짜증을 낼지도 모르죠
그 유저 한명한명이라도 더 많은 관심을 줄때, 놓치지 마세요.
지금 이 순간이 흔하다고 느낄수도 있지만, 기회는 지나가면 다시 찾아오지 않는법 입니다.