|
방이 갈리는 이유. 방갈림현상. -추가 | | | § 강의 게시판 |
카테고리가 조금 애매하군요..
고급강좌도 아니고 초급도 아닌거고..
내용이 어렵긴 하지만 그래도 맵 메이커라면 알아야 할 내용이고..
그래도 조금 원론적으로 접근하기에 고급이라는 말을 감히 붙여 봅니다. '-'
※글을 생각하지 않고 손가는대로 마구 적기에 두서가 없습니다. -_- 이해하세요.
주말같은때에 수정하겠습니다.
각설하고 바로 본문 들어갑니다.
귀차니즘 때문에 스크롤 확 내려버리지 마시고, 맵을 만드시는 분들은 꼭 한번 읽어보세요. '-';
메모장에 적어보니 그림빼고 길이가 10kb긴 합니다. -_-;
노곤한 글(?)이지만 읽다보면 재미(?)있으니 읽어보세요;
재미 없으신분들은 태클(?)을 걸 목적으로 읽어보셔도 됩니다. 태클걸거 많을겁니다. -_-;;;
아. 한가지 말씀드려야 할건 100% 맞는 말은 아니라는 겁니다. 제가 100% 알지도 못하구요. 추측임을 먼저 말씀드립니다.
하지만 어느정도는 맞을겁니다.
w3m.co.kr 질답게에서 나름대로 활동많이 하고 답변도 달고 하면서 쌓인 지식과 제가 겪어본바로 추론을 하고 글을 씁니다.
이게 어느정도는 맞는 말 일겁니다.
방이 갈린다. 갈린다라.
갈린다 함은, 플레이어와 플레이어간의 연결이 논리상의 에러에 의해 뚝 끊어져 버리는겁니다.
논리상의 에러가 날 소지는 다분합니다만, 그 중 가장 쉽게 일어나는 일이 바로 컴퓨터간 연산속도 차에 의해서 벌어지게 됩니다.
또한, 인위적으로 공용하는 데이터가 모든플레이어에게 공통적용이 아닌, 한쪽컴퓨터에서만 변조가 되면 일어나기도 합니다. (베넷에서 치트엔진등으로 치트쓰면 바로 갈리지요.)(중간에 전송중 데이터 손실로 인한 방갈림 현상도 있습니다.)
뭐.. 많은 이유가 있지만 대부분의 이유는 위 두개에 의해서 일어나게 됩니다.
일단, 컴퓨터간 연산속도차. 이건 거의 모든 멀티프로그램에서 유명하죠 -_-
특히나 mame라는 에뮬레이터의 넷플, 카일렐라는 이 부분에서 절정에 달했습니다. -_-;
이 부분에 대한 갈림을 추가설명해 드리겠습니다.
일단 디펜스류 하시는 분들은 많이 경험하셨을겁니다.
뭔가 대량의 웨이브가 터질것 같아서 만반의 준비를 했더니 같이 플레이 하는 사람이 나가 버리는일. -_-
대표적인 연산처리속도의 문제라고 추측해 봅니다.
대량의 데이터를 처리해야 할 때, 그때 발생하게 되는 연산작업이 서로의 차이에 의해 갈림이 생겨버리는 겁니다.
물론, 어느정도는 커버를 하기 위해서 컴퓨터가 빠른 사람도 게임이 버벅이긴 합니다만, 갑자기 한작업을 할때 서로 겹쳤을때 그때 방갈림이 납니다.
광범위에서 대량의 몹리젠을 할 경우, 이런일이 발생하긴 합니다. 꼭 몹리젠 뿐 아니라, 처리할 일이 순간 방대해져 버리면 이런일이 발생한다는 겁니다.
방대하다의 개념은 어떻게 확실히 잡아드릴 수는 없습니다만, 문제가 없는 트리거인데, 갈림현상이 일어난다면 트리거가 너무 무거운 트리거(처리할게 많은)가 아닌지. 확인해 보시고 쓸데없는 부분지우시는게 좋을겁니다.
기본루프문이나 wait문을 사용해도 갈린다는 분들이 있는데..
글쎄요 -_-;; 이부분은 확실한 명답을 주기가 힘드네요..;;; 설명은 하겠습니다만..a..
루프문의 경우는 일단 확실히 무거운 트리거가 되는 액션 중 하나입니다. 일단 플레이어가 연산속도 차에 의해서 루프문을 서로 다르게 돌립니다.
기본적으로는 같기야 하겠지만, 갈라지는 경우가 있는데,
예를들어 플레이어 1부터 12까지 같은 루프문을 돌릴때, 1부터 10까지 돌린다고 생각해보자구요. '-'
각 연산속도는 달라서, 플레이어 1같은경우 루프문 연산을 시작합니다.
플레이어2의 경우는 조금 느려서 조금 지체후에 루프연산을 시작합니다.
플레이어 1은 벌써 한바퀴 돌고, 정수변수에 +1을 합니다.
플레이어는 2는 이제 돌아가려는데, 벌써 숫자가 2가 되어있는
wait문도 비슷한 맥락으로 해석하시면 될거구요..(wait문도 엄히 말하면 loop문을 내장하고 있는걸로 압니다만..)
한가지 빼먹었군요.
가장 빈번하게 발생되는 상황중 하나가 '게임을 들어가자 마자'입니다.
이는, 맵의 로딩이 끝나면 초기화트리거라는게 돌아갑니다. 이건, 맵에 들어가서 게임 시작하기 전에 실행되는 트리거입니다.(배경음악이 로딩이 끝나면 나오는걸 보니)
로딩은 말 그대로 연산덩어리 입니다. 컴퓨터 차이가 여실히 드러나는 부분이죠.
여기서 조금만 충격이 가해져도 우수수 튕겨 버립니다.
실험을 예전에 하나 했었는데, 초기화 트리거에 0.01초 반복을 하는 루프문에 액션 몇 개 끼워넣었더니 풀방만 되려고 하면 우수수 튕겨 나가더군요.
꼭 풀방이 아니어도 튕기고.. 여튼;; 꽤나 문제 많은 부분입니다.
오브젝트가 과도히 많아지는것도 초반 로딩에 가장 큰 몫을 차지합니다. 물론, 초반로딩에 의해 튕기지는 않지만 초반로딩을 끝낸사람과 안끝낸사람의 차이가 심해지면 심해질수록 (처리해야 하는 양이 많아 질 수록) 초기화 트리거에 걸리는 부분이 많고 여기서 시작튕하는 분들이 많습니다. 아. 한가지더. 초반로딩의 차이가 플레이어 간 로딩시간 차이가 2분 이상 벌어질경우 타임아웃에 의해 disconnect 되는걸로 알고 있습니다. '-';;
뭐.. 중구난방식이지만 어느정도는 개념이 잡히셨을 겁니다. -_- 말재주가 없고 시간이 없는 지금상황이 조금 안타깝네요;
그 다음, 자료 전송의 차이에 의해서 에러가 나는 부분도 있습니다.
우리가 관여 할 수 없는 네트워크상의 문제입니다만..
모뎀 쓰실때, 많이들 겪어보셨을겁니다. 요즘 컴퓨터 사시는 분들중 전화모뎀을 써보신 분이 몇이나 될지;; 잘모르겠지만 말이죠..
모플이라고 합니다. 모뎀플레이라고 해서 1:1의 게임을 할 수가 있지요. (워크2부터 디아1을 포함, 스타1까지 지원했던 기능입니다. 디2부터는 사장된 기능이죠. 지금도 멀티플레이 눌러보면 스타에서 3번째인가에 Modem이라고 있을겁니다. 이 사이에 나온 시대의 게임은 다 지원하던 기능이죠.)
모플에 대한 자세한 메커니즘은 설명치 않겠습니다. 중요한건, '전화선'으로 서로간의 데이터를 전송하고 게임이 가능해지는 겁니다.
모뎀의 속도에 대해서 조금 설명하자면 요즘은 1Mbps. 즉 초당 1메가 바이트를 전송하는 광통신 시대입니다만.. 그때만 하더라도 7.2kb(이 이하의 모뎀은 저도 사용 못해봤습니다. 1.0kb 모뎀은 용산에서 구경한 적 있는것 같습니다.), 14.4kb, 28.8kb, 56kb, 128kb와 같이 나뉘어 졌습니다. 128kbps라고는 하지만 모뎀은 70kb이상의 속도를 내기가 참 힘들었지요. (이때부터 ISDN 어쩌고 하면서 112kbps짜리 랜을 사용하는 통신법이 나왔습니다. 모뎀은 이때부터 사라졌죠. 이때 한참 인기던 선전이 '전화와 PC통신을(당시는 인터넷이 아니랍니다 ㄷㄷ) 동시에?' 라면서 떠들었었죠. 제가 초등학교때 일입니다만..
어쨋든, 모뎀의 전송속도래봐야 정말 하찮은 속도 -_- 기 때문에 (14.4k쓸때 10메가 받는데 10분걸렸습니다. -_-; 지금은 느려도 10초지요. -_-;;) 모플을 하다가 유닛이 조금 많아지면 (전 스타도 친구들끼리 모플을 했었습니다. 토나오는 속도.) 버버버벅. 지옥의 시작. -_-
버버버벅 거리는 이유는 서로 튕기지않게 서로를 싱크로하는 작업. 즉 서로의 데이터를 일정하게 유지하려는 기능입니다. (튕김을 dsync. 디싱크로나이즈라고 합니다. 싱크로에 실패한거죠.)
여기서, 좀만 더 무리하게 유닛을 움직이거나 전쟁을 할 경우는 바로 disconnect. 방 갈려 버린거죠.
요즘이야, 광통신이다 해서 이런일은 없지만, 컴퓨터의 연산속도에 의해서 이 부분이 추가로 발생하긴 합니다.
자료 전송이 예전에는 통신속도에 의해서 튕겨버렸지만 지금은 컴퓨터간 연산처리속도와 서버의 문제에서 튕겨버립니다.
연산처리야 본문의 위에서 줄창 설명했으니 패스. 서버의 문제도 우리가 관여할 부분이 아니니 패스.
인위적으로 치트엔진등의 메모리주소를 직접 변조를 할 경우, 그건 그냥 튕깁니다. sync할 건덕지가 없는겁니다.
클라이언트 클라이언트
↔ 서버 ↔
클라이언트 클라이언트
블리자드의 베틀넷 시스템은 위와같이 돌아갑니다.
클라이언트간 자료전송은 없고, 오직 중앙에 있는 베넷서버를 통해 움직이게 됩니다.
서버에서는 자료를 받고 내보낼뿐 아니라 자체적으로 플레이에 관여해 인위적인 코드의 조작을 방지 합니다.
베넷에서 싱글플레이를 해도 메모리 에디트를 쓸수 없는 이유 입니다.
여기서 만약, 메모리 에디트를 한다면?
클라이언트 클라이언트
↓ 변조
────→ 서버
클라이언트 클라이언트
이런 현상이 되어 버리지요. 혼자 따로놉니다.
클라이언트 / 클라이언트
sync에 의한 /
disconnect / 서버
클라이언트 클라이언트
이는 바로 서버에서 kick을 해버리게 됩니다. 어울리지가 않거든요.
이해가 가실지 모르겠는데, sync작업중, 1234플레이어의 서로간 상황이 맞물려 돌아갈 때, 이때 인위적이든 어쩔수없는 손실이든 자료의 변조가 일어나면 서버에서 자동으로 kick이 됩니다.(베넷에선 그렇지요.)
꼭 서버가 관여를 안하더라도. 즉, 다른 ip/ipx등의 플레이는 클라이언트-서버-클라이언트가 아니라, 호스트-클라이언트의 관계가 됩니다. 이때는 데이터가 조작 된다 하더라도 베넷 메인 서버는 알수가 없습니다. 베넷이 아니니까요. 하지만, 서버는 몰라도.그래도 desync가 되어버려 튕깁니다.
여기까지는 이해가 가셨을겁니다. 그러면 위의 설명과 결부해서 같이 설명이 가능하겠지요.
메모리를 굳이 고의성으로 건드림이 없다하더라도, 연산속도차에 의해 데이터의 손실이 생길 수 있습니다.
그러면 desync. 튕김.
아. 한가지더. '그러면 맵핵은 왜 안튕기냐'라고 하실지도 모르는데, 그건 일종의 뭐랄까요. 그냥 블랙마스크를 강제로 제거한것처럼 보이게만 하는겁니다. 즉, 실제로는 블랙마스크가 정말 지워진게 아닙니다. 일전에, 정말로 블랙마스크를 지우는 맵핵이 있었는데 그건 멀티에서 쓰면 튕긴답니다. '-';;;
일종의 훅이죠. '왜 자원은 그렇게 못하냐'라고 하실지 모르겠습니다만, 블랙마스크를 단순히 지운것과 자원을 고정시킨건 조금 문제가 있지요 '-'; 블랙마스크를 지운거야 단순히 그걸로 끝나는 겁니다. 판단은 사람이 하는거죠. 대신, 자원을 고정시켰을 때는, 남들이 보기에는 분명 저 사람의 자원은 금 10인데(실제로 보이지는 않지만 서버에서는 그렇게 처리하겠죠) 갑자기 키메라를 뽑는다고 했을때, 여기서 desync가 발생. 튕김.
뭐,. =_= 디싱크를 설명하기 위해서 뱅뱅 돌아 왔습니다만, 이해는 가셨을 겁니다.
이 아래 부분이 중요합니닷...! 솔직히 말해 제가 뱀디 맵의 구조를 한 번 보고 싶네요. 위는 저도 잘 이해가 안갑니다 -_-
(etiang 본인 제가 쓴겁니다. 요 대사는)
여기까지는 이제 설명이었고, '그러면 어떻게 해야 안튕기느냐!' 라고 물으실겁니다. (위에 하나도 안읽고 여기부터 읽으셔도 됩니다. -_-ㄷㄷ)
저도 정확한 방법을 아는건 아닙니다만. -_-;
일단 과도한 연산을 필요로하는 트리거를 사용해선 안됩니다.
당연히 desync될 확률이 팍팍 높아지는 부분입니다.
초기화 트리거는 너무 무겁다 싶으면 액션이 게임시작해도 크게 관여 하지 않는다면, 게임시작후 1초, 게임시작후 2초, 3초 4초 이런식으로 조금씩 갈라서 하세요. (장식물-나무를 까는 방법도 이와같이 하는겁니다. 미리깔아놓으면 로딩 엄청길죠.)
또한, 각자의 컴퓨터에 연산을 맡기는 짓은 왠만 해서는 안됩니다.
자세한 설명은 loop문쪽을 다시한번 참조하세요. =_=;
같은 맥락을 몇개 설명하자면 loop, wait, 각플레이어 등등.
100% 튕긴다고는 말할수 없습니다만, 확실히 갈리는 빌미를 제공하긴 합니다. 주 기둥을 이루는 트리거로나 자주사용하는 트리거로는 왠만하면 사용하지마세요. (wait는 어쩔수 없습니다. -_-;;)
그리고 이건 블리자드의 실수로 보입니다만 '고급-겜플상수'에서 '크립 반경'을 바꾸시면 안됩니다.
이건 1만 바꿔도 개 갈립니다. -_- 몇명만 튕기는게 아니라 완전 다갈려버려서 개인플레이 되는거죠. -_-;; 어쩔수 없죠. 쓰지 마세요;;
일단 어느 맵 포럼이든(국내든 국외든), 맵갈림현상을 현재 아주 제거를 하진 못하는 단계인것 같고 어느정도 절감 하는 단계입니다.
서로들 어느정도의 추측만을 뿌리고 다니는 상태입니다. 아쉽긴 하죠. =_=;;
일단 기본적인 방갈림 현상의 이유를 알기쉽게 설명하자면 '트리거의 무분별한 과다사용'과 '쓸데 없이 길어진 로딩', 그리고
'서버상의. 넷웍상의 문제'입니다.
우리가 줄일 수 있는건 처음과 중간을 줄일 수 있으니, 최대한 맵을 최적화 하시기 바랍니다. (옵티마이저를 프로텍터로 착각하시는 분들이 있는데, 옵티도 최적화하는데 상당히 도움이 됩니다.)
※중간에 삼천포로 빠진부분이 상당합니다만, 이해하시는데 도움이 될것 같기에 굳이 삼천포로 간것도 삭제는 안합니다. '-';
지금 시간이 없어서 글이 상당히 두서가 없습니다만, 나중에 한번 손봐서 보기 편하게 다시쓰겠습니다. 귀차니즘 때문에 언제가 될런지는 몰라요. -_-
※본문은 w3m.co.kr에는 올라가지 않습니다. 해당 게시물은 강좌라기보다는 질답게에서의 추가답변이라고 생각해 주세요.
추가답변 치고는 여담과 개인적인 말이 많이 들어가서 강좌란에 올립니다.
------------------------------------------------------------------------------
위에서 읽으셨다 싶히 옵티마이저 부분은 제 trpg와도 공감이 가는 부분이죠.
결국 뱀디에서 의심되는 부분은 계산이 필요한 과도한 트리거인데...
한가지 예로서 467 버전에서 타워혁명을 하면 거의 90% 방이 갈리더군요.
여기서 주사위 100개, 이게 문제가 되는 듯 싶은데 말이죠. 뭐 아님 말구요 ㅎㄷㄷ
아무튼 뱀디 곳곳에 이러한 변수 관계 상 문제점이 많을 수 있다는 겁니다.
가장 좋은 방법은 쓸 때 없는 트리거를 줄이로 스크립트로 대체할 수 있는 부분은 그렇게 하는 거죠.
연산이 필요한 트리거 부분은 최대한 줄여버리구요.
방갈림이 주로 20분 대 ~ 40분 대 에서 일어나는 것으로 보아 플레이 시 필요 없는 정보들... (예를들어 유동 텍스트 쌓임)
이런 것들이 많이 쌓이거나 후반에 업그레이드 하는 그 무언가가 문제가 될 수도 있죠.
특히 가끔 암영 대미지 글씨가 깨지는 경우가 있는데 이게 유동 텍스트의 자취(?)가 남은 뭐랄까... 어쩔 수 없는
버그랄까요. 한글 유동 텍스트가 많은 맵에서 자주 일어나는 현상인데 아무튼. 이런 것들이 다 원인이 될 수 있다는 거죠.
흠, 마음 같아선 맵을 한 번 보고 싶은데. 그건 안되겠고
참고로 전 지금은 Etiang이라는 아이디를 쓰고 있으며 예전에 shob 클랜이 활동 할 때 (약 3년 전?)
shob_pain 이라는 아이디를 썼습니다. 물론 그 때는 방갈림이 없었죠.
흠 그러고 보니 방갈림이 시작된 맵과 그렇지 않은 맵을 비교해보는 것도 좋은 방법이겠네요. 힘들겠지만;;;
좀 길어도 다 읽어보시는 걸 추천합니다.
첫댓글 우와 ㅋㅋㅋ 좋은 정보네요 ㅋㅋㅋㅋ
ㅎㅎ;;;
이거 다쓰신거..?
ㅎ;; 중간 내용은 퍼온거 약간 수정요 ㅎ
안읽으셨나... 읽으셨다면 댓글좀;;;