|
:: 게시판
:: 이전 게시판
|
- 경험기, 프리뷰, 리뷰, 기록 분석, 패치 노트 등을 올리실 수 있습니다.
통합규정 1.3 이용안내 인용"Pgr은 '명문화된 삭제규정'이 반드시 필요하지 않은 분을 환영합니다.법 없이도 사는 사람, 남에게 상처를 주지 않으면서 같이 이야기 나눌 수 있는 분이면 좋겠습니다."
10/01/27 18:25
간단하게 생각한 건데, 선수들의 PC에 동영상 녹화 프로그램을 설치하고, 게임 시작과 동시에 백그라운드에서 게임 진행 과정을 녹화하도록 하면 어떨까요?... 실시간으로 동영상을 녹화해서 disk에 기록을 해 두면 정전이 되어도 자원현황, 인구수, 상대방 멀티 체크 여부 등은 파악 가능하지 싶은데 말입니다.
물론 동영상 녹화 부하가 게임 진행에 부담을 주어선 안되겠지만요;
10/01/27 18:28
위의 경우는 선수 개인화면을 송출하기 위해 부조종실로 선수들의 화면이 입력이 되는것으로 알고있습니다.
그것을 녹화하여 보존하는지는 제가 너무 오래전에 일을 그만두어서 잘 모르겠습니다. 그것은 판정을 위한 자료가 될 순 있겠지만 중단된 경기를 재개시킬수는 없을것입니다.
10/01/27 18:38
안전벨트 딜레마가 생각나네요. 안전벨트가 발명되어서 교통사고가 줄어들지 알았는데 안전벨트 믿고 운전자들이 속력을 높여버린. 그래서 운전자 사망자는 그대로였고 부작용으로 보행자 사망자는 엄청 늘었다고 해요. 그런 프로그램이 있으면 좋겠지만 그걸 믿고 방송사가 방만해질거 같아요. 엠겜은 정전재발방지도 안할거 같고.
그리고 수치만 맞춰주면 경기가 그대로 흘러갈거같지만 선수들 어깨가 풀리는거나 기세가 끊어지는거도 있어서 완벽재현이 될지 모르겠어요. 다크템플러에 일꾼털리는거 모르고 튕겼는데 재개할때는 알게되거나. 저작권도 문제네요. 블리자드가 스타1의 개선에 신경쓸거 같지 않네요.
10/01/27 18:39
음.. 저작권이 가장 무서운 문제로 보이는데요.
아무리 선의에 의한 프로그램일지라도 블리자드에서 소송걸면.. 답이 없어 보입니다. 가급적이면 서드파티 프로그램 개발하지 마세요.. 예전에 windows xp 입맛대로 수정해서 화면이 이쁘게 보이는 june에디션 나왔는데 그거 뜯어 고친 사람은 MS와 6억인가 소송에 휘말렸죠. http://mlbland.com/mlbland/zboard.php?id=free&no=41681 (물론 이분은 배포에 대한 배상이긴 합니다만 본인이 배포 안해도 그냥 일방적으로 덤탱이 씌운거 같네요) 더구나 요즘은 저작권 침해를 친고죄가 아니란 얘기도 있던데요.. 뭐.. 저걸 각오하신게 아니면 가급적 서드파티프로그램은 안하시는게 좋을거 같습니다.
10/01/27 18:39
일단 개발비용이 너무 지나치지 않다면 있었으면 좋겠습니다. 정전같은 비일상적인 일이 아니더라도 디스커넥트 등에 의해 경기가 중단되는 것은 흔한 일이니까요. 물론 저작권 관련해서 블리자드에 문의가 필요할 것 같습니다만
10/01/27 18:43
게임중의 PC에 다른 프로그램을 돌리는 것은 반대입니다. 그로인해 야기될 부작용의 가능성이 더 큰 문제를 야기할 수도 있다고
생각되기 때문입니다. 극단적으로 랜덤 대미지의 랜덤 변수를 조작하여 전투상황의 결과를 변경할 수도 있고, 극단적으로 짧은 시간 벌어지는 전투 상황에서 영향을 줄 수도 있다고 봅니다. 워3의 장조작 사건 같은 경우가 없으리란 보장이 없습니다. 선수 개인 PC에 동영상 녹화 프로그램을 설치 하지 않고, 경기 상황을 녹화할 수 있는 방법은 얼마든지 있다고 생각합니다. 선수 PC의 VGA 출력 신호를 컴포넌트 단자를 통해 뽑아 (상당수의 VGA 카드가 이를 지원하고 있습니다) 이를 다른 PC에서 받아 실 시간 인코딩 하는 방법은 아주 쉽습니다. (오스프레이나 DRC 보드만 설치된 컴퓨터라면 매우 간단하며, 아예 디지털 녹화기를 사용하면 쉽습니다.) 정전이 걱정된다면 노트북을 통해 인코딩을 하는 방법도 있겠습니다.
10/01/27 18:46
헉 T1 기술개발 코치님.....
워드 프로세서와 같은 실생활에 유용하기 쓰이는 프로그렘에 다 있고 심지어 적용되는 자동저장 시스템... 있어야 할 필요는 있는것 같습니다. 그러나 역시 가장 중요한건 블리자드와의 저작권 문의겠지요.
10/01/27 18:50
글과 동떨어진 얘기일 수 있겠지만 제가 잘 몰라서 그러는데 워크에는 자동 저장 기능이 있지 않습니까? 리플로 말입니다 근데 왜 스타에는 없는건가요? 워3가 조금 더 늦게 만들어져서 블리자드가 그때 그 생각을해서 넣은건가요?
10/01/27 18:53
그런데 온게임넷에도 자원채취현황이나 인구수 이런거 보여주는데 그것도 프로그램이라는데 그럼 블리자드에 소송걸리지 않나요? 블리자드가 허락해준건가?
10/01/27 18:55
DynamicToss님// 그건 저도 참 궁금합니다만.. 제 생각엔 저작권 침해이지만 블리자드에 큰 해가 없어서 일단은 묵인일듯 합니다..
그러나 나중에 스타1이 스타2의 걸림돌이 되면 저작권행사를 할 수 있지 않을까 하는 생각을 해봅니다. 또하나, 블리자드의 특성이 불법유저를 한꺼번에 소리소문없이 징계한다는 거죠.. 디아블로를 보면 어느날 갑자기 맵핵, 오토 쓰던 계정이 로그인이 안된다는 얘기를 주위에서 많이 들었지요.. 스타야 계정블럭은 전혀 의미가 없으니, 시디키 블럭일듯..
10/01/27 19:07
왠지 협회에 뭔가 제안을 넣었다가 거절당한 후 요즘의 협회 까는 분위기에 교묘하게 편승하려는 글로 보이는데..
서드파티를 쓰는데에 문제가 없어서 세이브파일을 저장한다 하더라도 제대로 하려면 아예 실시간으로 0.1초마다 한번씩은 저장해야 할텐데, 그게 컴퓨터에 영향을 주지 않고 쉽게 가능할까요? 저장간격이 10초 이정도가 되면 전투 하나가(마메탱vs저럴) 일어나고 저그가 대패했는데 디스커넥트가 났다고 칩시다. 이때 우연히도 가장 마지막에 저장된 부분이 그 전투 이전이었다면 논란은 계속되겠지요. 게다가 써드파티 프로그램으로 그걸 하는 것 역시 메모리 후킹 아니겠습니까. 일반적으로 XP에서 0.1초에 한번씩 맵의 모든 유닛과 그 액션(맵의 어느 위치, 혹은 어느 유닛 혹은 건물을 강제공격한다, 어디와 어디 사이를 패트롤한다 등등등..) 자원데이터를 대규모로 가져오면서 오류 전혀 없이 깔끔하게 남의 프로세스를 후킹하는건 굉장히 어렵습니다. 오히려 스타가 갑자기 강제종료된다던가 하는 일이 일어날 여지가 더 많죠. 온겜에서 자원상황을 보여주는건 뭐냐..라고 하시겠지만 그건 몇바이트 데이터일 뿐이고 그나마도 옵저버 컴퓨터에서 하니까 문제가 생겨도 옵저버만 튕기면 끝이죠.
10/01/27 19:53
ComeAgain님// 서드파티 프로그램 맞습니다.
그러나 블리자드도 그 맵들로 블리즈컨 하는걸 보면 사실상 묵인인듯 하네요 그 점에 대해서는 소송을 걸거 같진 않아 보입니다.
10/01/27 21:08
프로그램에 대해 여러가지 의견이 나오는것같아 살짝 설명을 드리겠습니다
스타크래프트에는 실시간으로 리플레이를 만드는 알고리즘이 이미 있습니다. 이 알고리즘을 변형하여 세이브파일을 얻어내는기술이 주요기술이구요 이미 적용된 알고리즘을 쓰기때문에 부하가 생기지는 않을꺼고, 제가 알기론 0.1초단위로 알고있습니다.
10/01/27 21:11
(쉽게 쉽게) 선수들 컴퓨터에 UPS 달면 되는 것 아닌가요? ^^;;; 5분 정도만 버텨도 될 텐데 그 정도 버티는 UPS는 비싸지 않습니다.
10/01/27 21:45
지구사랑님// 이번 사태보다 좀 더 넓게 보자면 ups설치로는 정전 이외의 사태는 막을 길이 없어보입니다.(어렵게 어렵게??)
감히 말씀드려보면 해당 프로그램 개발에 관련해선 블리자드 측에 먼저 문의하시는게 순서 아닐까 생각해봅니다. 다만 조금 두려워지는 상황은 'XX 써드 파티 프로그램 개발해도 되겠습니까?' '안됩니다. 지금 쓰는 것도 있다면 다 금지임!' 이런 것이겠죠;. 팬의 입장에서는 0.1초 정도의 간격이라면 도입해도 될 것 같습니다. 물론 실제로 쓰이기 위해서는 선수들의 입장도 수렴해서 공정하고도 최적의 재개방법을 생각해 내는 것이 밑받침 되어야겠죠. 이 부분은 협회에 맡길 수 밖에..
10/01/27 22:14
스타크래프트는 피아노하고 굉장히 비슷합니다. 피아노 치신 분들은 아시겠지만 갑자기 피아노 치는게 중단되면 그 시점부터 치는게 상당히 힘듭니다. 그 곡을 엄청 연습한 경우라면 모르지만 대게 처음부터 다시 치거나, 곡 진행상 중간에 끊어지는 부터 쳐야 다시 리듬에 맞추어 칠 수 있습니다. 스타도 마찬가지라고 봅니다.설사 0.01초 단위로 저장되는 프로그램이 나온다고 쳐도 실제로 게임이 중단되고 그 프로그램을 실행하여 바로 전 상황부터 다시 시작한다 하여도, 게이머들의 리듬이 다시 돌아올지는 의문입니다. 즉 만약 정전이 없었을 경우에 게임이 진행되는 것과 정전이 중간에 개입되고 나서 진행되는 게임은 그 판도가 충분히 달라질 수 있다는 이야기입니다. 이렇듯 제3의 요소가 개입되어서 게임의 결과가 달라진다면 결국 실시간 저장이란 방편도 그저 임시방편일 뿐 궁극적인 대책이라고는 보기 힘들거 같습니다.
10/01/27 22:16
자동 세이브 프로그램 개발해서 일반에 유포시키지 않고, 케스파와 계약해서 프로리그와 스타리그에만 쓰면 될 것 같은데요.
아니면 별로 어렵지도 않은거... 블리자드에 요청이라도 해보면 흠
10/01/27 22:26
임금// 그거야 두 말 할것도 없는 말이긴 하지만, 제가 말씀드리고 싶었던 것은 이것도 단지 임시방편일 뿐이고 이러한 프로그램이 개발되고 블리자드의 허가 등 프로그램 배포 및 실용화에 관한 요건이 모두 갖추어져서 실제로 경기에 도입된다 하더라도, 여기서 만족하면 안되고 보다 궁극적인 대책을 찾아야 한다는 취지로 쓴 것입니다.
10/01/27 22:36
분명히, WCG나, 스타리그 등에서 쓰이는, 실시간으로 자원 및 유닛 현황을 보여주는것도, 뭔가 프로그램을 돌렸다는 이야기인데,
그거나, 리플레이를 자동저장하는거나, 저작권 문제로 걸리는 부분은, 그리 다를 것 같아 보이진 않습니다. 일반인에게 배포한다면 문제가 될 수도 있겠지만, 케스파와 블리자드가 잘 협약해서, 공인대회에서만 쓰이도록 하면 됩니다. 그리고, 만약에 선수들이 플레이할때, 디스크 I/O때문에 미묘한 랙이 걸릴것이 걱정된다면, 옵저버나 레프리의 PC에서 돌리면 되지요. 전, 적극적으로 찬성입니다.
10/01/27 22:40
광기님// 개발자로서 궁금한 부분이 생겨 몇 가지 질문 드리려 합니다.
1. 저런 프로그램의 경우 중간 데이터를 램에 저장하는것은 의미가 없습니다.(컴퓨터가 꺼지면 곧바로 날아가니까요) 그렇다는건 0.1초마다 계속 엄청난 데이터(보통의 리플레이 파일보다 훨씬 커야 합니다. 왜냐 하면 리플레이파일은 현재의 전황에 대한 정보는 전혀 없고 시시각각의 플레이어의 액션들만을 담고 있기 때문이지요.)를 램이 아닌 하드에 써야 한다는건데 부하를 안준다는건 믿기 어렵습니다. 프로그램을 아무리 잘짜더라도 하드웨어의 한계를 넘어서기 어렵다는 이야기입니다. 2. 만약 리플레이파일에 있게 될 정보만을 담는다면 1에서 지적한 부하는 크지 않을 지도 모릅니다. 그럴 경우 스타크래프트 프로그램 자체의 엔진을 이용해 해당 리플레이 파일을 해석하고 게임이 끊어졌던 마지막 순간으로 시간을 돌려줄 수 있는 부가적인 장치가 필요하게 됩니다. 이걸 어떤 식으로 구현하신(하실) 것인지요?
10/01/28 07:07
Kivol //
예리한 질문을 주신것에 대해 감사드리고, 제가 개발자가 아닌관계로 아는 선에 한해 최대한 답변을 드리고자 합니다. 1. 현재 자동저장프로그램의 핵심개발요소는 현재 전황의 상황을 매 시간마다 강제로 세이브파일로 부하없이 생성해내는것이 목표입니다. 이 부분을 구현하기 위해 보다 심층적인 연구가 필요한 부분은 맞습니다. 블리자드 특유의 mpq 압축방식의 영향인지는 모르겠지만 스타크래프트 맵을 비롯한 관련 파일들은 경이로울정도로 압축률이 높습니다. 가령 맵의 모든 타일정보를 담고 있는 파일이 불과 수kb에 불과한 예가 있죠. 지금 깔린 스타크래프트 폴더에 보셔셔 세이브파일이 있으시다면 확인해보세요. 제가 가진 최장시간 세이브파일이 5시간(유즈맵)인데 용량이 불과 500kb에 불과합니다.(1시간이 늘때마다 100kb씩 늘어나는듯합니다) 또한 온게임넷에서 사용하고 있는 자원측정기(본 프로그램명을 잊은관계로 약칭하여 이렇게 부르겠습니다)도 서드파티프로그램을 이용, 실시간으로 스타크래프트 플레이어의 자원정보뿐만 아니라 인구수, 보유 유닛수까지 후킹하여 제3의 매개체로 전송하여 자막화 하여 방송에 사용하는것으로 간략히 원리를 추정해 보고 있는데, 스타크래프트 실시간 후킹 자체는 이미 검증된 사례도 있고, 수 많은 맵핵을 비롯한 각종 핵의 사례에서도 볼 수 있듯 스타크래프트 자체에 부하를 주는 것은 아닙니다. 다만 지적해주신대로 지속적인 하드디스크 쓰기가 필요한 점은 저도 인정하긴 하는데 이 부분에 대해서 개발팀의 의견을 현재 물을수가 없어 자세한 답변이 어려움을 양해 부탁 드립니다. 저의 부족한 예상으로는, 부하가 예상될시 1초간격으로 저장하도록 하면 큰 문제는 없을 것으로 생각됩니다. 2. 리플레이를 세이브로 변환하는 프로그램은 이미 중국의 개발자가 서드파티 프로그램으로 개발한 적이 있다 합니다. 개발자가 중국인인 관계로 도움을 받기엔 사실상 힘듭니다. 하지만 구현이 가능하다는 증명은 되는 상황이죠. 세이브파일과 리플레이는 큰 차이가 없습니다. 스타크래프트에서 리플레이라 하면 매시간별 플레이어가 행한 변수를 기록해 두었다가 재생시 그 흐름대로 경기를 재현하는것을 의미합니다. 따라서 리플레이에는 플레이어가 유닛을 명령한 위치라든지, 선택한 유닛의 갯수, 생산 명령한 유닛, 자원의 정보등이 기록되어있습니다. 플레이어가 행한 모든것의 궤적임엔 동의하실 것입니다. (실제로 리플레이로 개인화면 보기.. 등등이 가능한 서드파티 프로그램이 있죠) 세이브파일의 구조도 다른것이 없습니다. 세이브파일은 좀 더 단순한것이 리플레이가 게임시작부터 종료까지의 모든 플레이어의 궤적을 담았다면, 세이브파일은 세이브 시점에서의 플레이어의 행동만을 담고 있습니다. 좀 더 쉽게 설명하자면, 세이브 시점에 행하고 있는 행동 (이동명령,공격명령,생산명령 등)만이 기록되어있어 리플레이보다 가볍습니다. 중국인이 만들었다는 그 프로그램을 제가 보지않아 자세히는 알 수 없지만 아마도 리플레이의 궤적을 세이브파일의 형태로 인식하여 그 시점부터 플레이어가 플레이 가능하도록 하고자 하는것이 구현원리가 아닌지 추정됩니다. 더욱이 쉬운것은 lastreplay부분이 블리자드에서 이미 실시간으로 저장토록 프로그램이 되어있다는 사실입니다. (이번 사태처럼 부득이하게 경기가 중단되었을시에도 기록이 되는지는 확인이 불가능하지만, 알고리즘 상으론 그렇다 합니다) 만약 그렇다면, lastreplay를 저장하기 위한 부하는 이미 스타크래프트에 가해지고 있고, 검증된데다 무리가 없으므로 그것을 세이브파일로 치환하는 서드파티 프로그램은 스타크래프트를 실시간 후킹할 필요조차도 없고, 단순히 그림파일 확장자 바꾸듯 파일형태를 변환해주는 유틸리티?정도의 기능을 발휘할 것입니다. 사실 저희 개발팀에서는 이렇게 개발하기를 바라고 있는데, 연구/분석이 끝나야 더 정확한 정보를 알 수 있을듯 합니다.
10/01/28 10:44
스타크래프트의 리플레이 저장 매커니즘은 잘 모르지만, 일반적인 구현 상황에서 생각해본다면, 리플레이 파일을 직접 디스크에 기록하는 시점은 게임의 종료 명령이 떨어진 직후가 아닌가요? 제 생각에는 LastReplay는 일반적인 수동 리플레이 저장과 아무런 차이가 없습니다. 단지 기록을 자동으로 해주느냐, 명령을 통하느냐의 차이일 뿐이죠.
제안하신 프로그램은 경기 도중에도 일정 시간(또는 매 프레임)마다 디스크에 기록한다는 것으로 보이는데, 이는 제가 보기에 LastReplay의 방식과는 명백히 다릅니다. LastReplay 저장이든 일반 리플레이 저장이든 게임 종료 시점에 디스크 기록이 시작되므로 기록 시간이 얼마나 걸리는지는 사용자에게 아무런 영향을 주지 않습니다. 그러나 게임 도중에 파일을 저장하는 행위는 분명히 사용자의 눈에 그 딜레이가 느껴집니다. 이는 차라리 게임 세이브에 더 가깝다고 봅니다. 아니, 거의 동일하다고 봐야겠군요. 싱글 게임으로도, 게임 도중에 세이브하게 되면 잠시 기다리라는 메시지와 함께 게임이 잠시 멈춥니다. 그 정도로 하드디스크 입/출력은 컴퓨터에 있어서 가장 느린 행위입니다.(CPU가 하드디스크 입출력을 위해 기다리는 시간은 CPU입장에서는 영원보다 더 길 것입니다.) 대부분의 상황에서, 매 프레임마다 저장이나 로드를 위해 하드 디스크를 검색하게 되면 게임은 더 이상 게임이 아니게 될 정도로 느려집니다. 게임에서 로딩 과정이 있는 이유가 이것 때문이죠. 물론, 저장하는 파일 용량이 작고, 스타크래프트 프로그램이 아닌 다른 프로세스에서 작업을 시도하면 게임 자체가 간헐적으로 멈추지는 않을 수도 있겠죠. 그러나 하드 디스크에 저장하기 위한 검색을 시도하는 것만으로도 발생하는 오버헤드는 피할 수 없을 것입니다. 더구나 매 순간 저장이 이루어져야 하므로, 결과적으로 게임할 때 극심한 렉이 걸린 상태에서 하는 것처럼 되거나, 심지어는 간헐적으로 게임이 뚝뚝 끊기며 진행되는(이 때마다 리플레이 세이브가 이루어지죠.) 것처럼 보일 것 같은데요. 리플레이 저장을 세이브 형식으로 변환하거나, 외부 프로세스에서 게임 정보를 리플레이로 저장하는 것 자체는 문제가 없어 보입니다. 하지만 그 작업이 게임 도중에도 실시간으로 이루어져야 한다는 게 문제라고 생각합니다.
10/01/28 11:54
제 생각에 하드디스크에 저장하는것때문에 렉을 피할수 없을것이라는 의견이 있는데,
하드디스크를 꼭 쓸필요는 없습니다. 저장매체가 휘발성 D램이나 하드디스크만 있는게아니죠 요즘은 SSD같은 비휘발성메모리를 이용한 저장매체도 많이 나옵니다. 랜덤writing 속도는 하드디스크와 비교불허할정도이구요. 실시간으로 리플레이를 만들어내는 알고리듬이 있고 현대의 고성능 멀티코어 PC사양이라면 게임에 전혀 지장없는 상태에서 구현가능하다고 생각됩니다.
10/01/28 17:53
그렇다면 게임이 중단이 되어서도 게임을 다시(!) 진행할수록 하는 프로그램아닌가요
그렇다면 어떤이유에서든 대찬성입니다. 꼭 구현이 가능했으면좋겠네요^^
10/01/28 18:13
개발팀에서 lastreplay에 대한 설명을 부탁드려 이에 리플을 추가하오니 참고하여 주시길 바랍니다.
LastReplay.rep 파일에 대해서 대부분 혼동하고 있는 것은, 이 파일의 본격적 저장이 게임이 종료된 다음에야 끝난다고 생각하는 것입니다. 하지만 경기 2시간하고 리플레이를 저장하나 경기 10분 하고 리플레이를 저장하나 그 시간은 같습니다. 물론 파일 크기는 다르죠. 리플레이는 우리가 게임을 하며 명령을 내리는 그 동안 실시간으로 저장됩니다. 이후의 내용들을 자꾸 추가하고 추가해나가는 방식입니다. 따라서 위에서 언급된 전제인 "리플레이 파일(LastReplay)은 게임이 종료된 후에 저장되기 때문에 정전이 일어나면 소용없다"는 잘못되었습니다. 또 여러분께서 지금 스타크래프트의 최소 사양과 권장 사양을 마치 아이온이라던가 마비노기 영웅전의 그것처럼 생각하는 것 같은데, 의외로 스타크래프트는 그 처리 알고리즘이 매우 간단하여 경기 진행에 문제가 되는 경우가 거의 없습니다. 따라서 만약 위에서 말씀드린 대로 Replay 외의 다른 후킹을 사용한다고 하더라도 경기 진행 자체에는 전혀 무리가 없습니다. 마지막으로 개발자님께서 올려주신 질문입니다만 이 내용은 사실 생각해보면 매우 단순하게 결론이 날 수 있습니다. 개발자님께서 동영상을 재생해 보실 때 프로세스 관리자 등으로 프로세스를 살펴보셨을 경우, 프로그램에서 파일 크기만큼 메모리량이 늘어나던가요? 어차피 리플레이든 세이브되는 게임이든 그 시간시간마다 한 내용이 순차적으로 진행되므로, 전체적인 시간에 따라 일어나는 전체적인 내용을 미리 기억할 필요도 없습니다. 혹 C언어에서 언급하는 파일 포인터란 것, 들어보신 적 있으십니까? 그리고 이를 사용해보셨는지요? 여러분들의 서드 파티 프로그램에 대한 저작권 거론 문제에 대해서는 저희도 매우 심각하게 고려하고 있습니다. 물론 협회 측과의 이러저러한 내용도 고려하고 있습니다만, 그 이전에 블리자드와의 협의가 필요조건이겠지요. 단지 일부 사람들에 의해 잘못 알려진 상식이 여러분들의 지적 판단을 혼란케 하는 것 같아 우선적으로 바로잡습니다. 배포 목적은 아니더라도 개발은 계속될 예정입니다.
10/01/28 19:22
광기님 말씀대로라면 시스템상으로 선수들이 체감할만한 추가적 부하는 걸리지 않는 다는 것..
그럼 협회의 협력과 블리자드의 동의만 가능하면 충분히 실현되고 사용할 수 있다는 거군요. 온겜이나 엠겜이나 오프닝 제작이나 세트 제작.. 어설픈 가상스튜디오에 들일 노력으로 이런 거에 몰두해봤으면 좋겠네요.. 협회는 뭐 두말하면 입 아프고요.
10/01/28 19:23
광기님// 파일 포인터를 들어봤냐는 질문은 좀 너무하신 것 같구요, -_-; 동영상 재생시 램을 별로 안먹는건 전혀 관계 없는 얘기인데 물타기인듯 하고요.
"LastReplay.rep 파일에 대해서 대부분 혼동하고 있는 것은, 이 파일의 본격적 저장이 게임이 종료된 다음에야 끝난다고 생각하는 것입니다."라고 하셨는데요, 직접 실험을 해 보시면 아실테지만(그리고 MSL 결승에서 증명되었다시피) 게임을 하는 도중에 전원코드를 뽑아버리면 lastreplay가 안남습니다. 즉 오리지널 브루드워의 경우에는 게이머가 내리는 모든 명령들을 램에 놓아두었다가 게임이 끝나면 그제서야 하드에 쓰는 것이죠. 그리고 후킹의 안전성은 프로그램의 간단한지/복잡한지에 달린게 전혀 아닙니다. 기본적으로 OS의 코어랑 놀아야 하는 것이기 때문에 같은 코드라도 어떨 때는 다운이 되고 어떨 때는 잘 동작하는 경우가 수도 없이 많습니다. 리버스엔지니어링의 불안전성을 과소평가하지 마셨으면 하네요. 그리고 세이브파일과 리플레이에는 큰 차이가 없다고 주장하시지만 이루 말할 수 없을 정도로 엄청난 차이가 있습니다. 아니, 전혀 관계가 없다고 보는게 더 맞을 것입니다. 기본적으로 리플레이는 과정만을, 세이브파일은 결과만을 기록합니다. 그렇기 때문에 차라리 이런 시나리오라면 가능하겠지요. 1. 리플레이를 (리버싱으로 인한 안전성이나 부하의 우려가 없다는 가정하에) 계속 읽으면서 실시간으로 씁니다.(써드파티의 역할) 2. 다운이 됩니다. 3. 게임중 써놨던 리플레이를 하드 어딘가에서 건집니다. 4. 이 리플레이를 실행합니다. 5. 실행하면서 마지막 순간에 유닛의 상태들을 캡쳐하여 세이브파일로 만듭니다.(써드파티의 역할) 6. 이 세이브파일로 게임을 재개합니다. 그렇다면 해당 프로그램이 안정적으로 동작하려면 중간에 많은 과정들을 통과해야 합니다. 리플레이를 실시간으로 쓰는 것이 integrity를 보장할 수 있는가? 그 리플레이를 실행이 잘 되게 만들 수 있는가? 그것을 세이브파일로 만드는 과정 역시 integrity가 보장이 되는가? 이 질문에 대한 답을 확실한 yes라고 할 방법이 없습니다. 리플레이파일은 생각보다 자주 깨집니다. 그리고 리플레이파일을 만드는 중간에 1비트라도 어긋난다면 전체 게임의 내용은 전혀 달라지게 됩니다. 저는 리버싱 관련한 일을 해봤기 때문에 그것에 대해 회의적인 것입니다.
10/01/28 19:57
개발팀이 어떤 설명을 내놓았는지는 정확히 모르지만, 제 생각엔 광기님께서 리플레이 저장에 대한 설명을 잘못 이해하고 계신 듯 합니다. 게임을 하면서 실시간으로 저장하고 있다고 하신 부분은, 데이터가 램에 저장되어 있는 상태입니다. 그건 아직 하드 디스크에 저장한 상태가 아니에요. 그래서 게임 도중에 전원이 차단되면 리플레이가 안 남는 겁니다.
게임이 종료되면 저장된다는 부분은, 그렇게 게임의 매 순간마다 모아놓은 명령 데이터들을 한꺼번에 모아서 디스크에 기록한다는 얘기입니다. 왜 이런 방식을 쓰냐 하면, 램과 하드디스크의 데이터 액세스 시간이 엄청난 차이를 보이기 때문입니다. 게임 중에는 어떤 동작에도 즉각적인 반응이 일어나야만 하죠. 따라서 데이터 저장을 위해서 매 순간마다 하드를 사용하면 안 됩니다. 하드는 엄청나게 느리거든요. 그래서 일단 남아 있는 메모리에 데이터를 차곡차곡 모아두었다가 게임이 끝나거나 사용자가 리플레이 저장 명령을 내리면 그제서야 메모리에 모아두었던 데이터들을 리플레이로 만들어내기 시작합니다. 게임을 한창 도중에 LastReplay 파일이나 그 임시 파일이라도 생겨나는 거 보신 적 있으십니까? 아마 없을 겁니다. 위와 같은 과정을 거치기 때문이지요. P.S : 파일 포인터 사용해봤냐 질문은 뭐... 개발자가 아니라고 하셨으니 그러실 수도 있겠지만, C/C++ 프로그래머에게는 축구 선수에게 슛 할 줄 아느냐고 묻는 것과 같은 것입니다.;;
10/01/28 19:59
개발팀에서 추가 답변 정리해 올리겠습니다.
혹 starcraft.exe 프로그램에 대해 메모리 후킹을 시도해보신 적 있으십니까? 스타크래프트에서는 현재 자원 상황이라던가 각종 통계, 업그레이드 상황, 유닛별 소리 등등을 저장합니다만, 지금까지 시행했던 명령어 목록을 하나하나 저장하고 있진 않습니다. 몇 개의 아직 밝혀지지 않은 부분도 있어서 그 안에 명령어 목록이 들어갈지는 모르겠습니다만, 특정 메모리 주소(물론 상대참조)에 특정한 성향의 값만 들어가고 이것이 몇 번의 프로그램 실행을 해 보더라도 마찬가지라는 것은 곧 포인터 등을 사용하여 다른 곳에 저장한다는 얘기가 됩니다. 말씀하시는 '모든 내용을 메모리 안에 저장한다'는 것도 일리는 있습니다만, 음, '밝혀지지 않은 부분'에 대해서는 나름대로 노력해보겠습니다. 일리는 있으니까요. LastReplay.rep 자동 저장 건에 대해서는 제가 서드 파티 프로그램 덕분에 혼동했습니다. 단지 '따로 저장한다'는 내용은 변하지 않습니다. 기록 매체가 HDD냐 Ram이냐에 대해서는 위에서도 말씀드렸다시피 아직 모르는 내용이므로 언급은 하지 않도록 하겠습니다. 혼동 건에 대해서는 죄송스럽게 생각합니다. 후킹의 안정성에 대해서 말씀하신 부분에서 한 가지 놓치신 사실이 있습니다. 저희가 만드는 프로그램은 replay 등의 자료를 '보기' 위함이지, '값을 덧씌우기' 위함이 아닙니다. 즉, 말씀하신 내용대로의 일은 '읽기만 한다면' 딱히 문제되진 않습니다. 물론 읽기 자체를 금지하는 경우도 있긴 합니다만, 플레이어들이 Windows에서 플레이하는 이상 읽기 금지에 대해서도 이미 해결되었으므로 딱히 문제될 것은 없다고 봅니다. 세이브 파일과 리플레이 파일이 큰 차이가 없다는 것은 아직 여러 분들에게 전해진 정보는 아닙니다만 이것이 꽤 관련된다는 일련의 실행 결과를 봤기 때문입니다. 이에 대해서도 설명드리지 못 한 제 불찰이 크네요. 본 내용으로는 '리플레이 파일을 열 때 세이브 파일이 임의로 만들어져 리플레이 재생 시 이를 이용한다' 정도입니다만, 아무래도 타인을 한 번 거쳐서 온 것이다 보니, 이 쪽도 연구해봐야겠습니다. 당장은 이렇다하고 말씀드리긴 어렵습니다만, 그렇다고 무턱대고 기정사실화한 것은 아니랍니다. 아, 물론 말씀하신 대로의 내용을 실제로 구현한 프로그램이 있었습니다. 그게 중국인이 개발한 것인지라.. 리플레이 저장의 안정성에 대해서는 이미 라이브러리까지 나오고 안정성이 여러 사람을 통해 보장된 만큼 문제는 없다고 봅니다. 무엇보다도 저희가 걱정하는 것은 세이브 파일로 만드는 과정이라기보다는 세이브 파일 자체에 대한 라이브러리입니다. 현재까지는 (블리자드를 제외하면) 그 어느 쪽도 제대로 이 내용에 대해 말해놓은 바가 없기 때문에 매우 곤란합니다. 아실지 모르시겠습니다만 starcraft는 c++을 사용하여 만들었기 때문에 역어셈블이라던가도 매우 힘들고요. 개발 건에 대해서 이렇게 관심을 가져 주시니 감사합니다. 영감이 떠올랐습니다만 앞으로 넘어야 할 산이 꽤 많아진 것 같네요. 나중에도 이 쪽에 여러모로 도움 주시길 부탁드리겠습니다. 참, 동영상 재생 시 램을 별로 안 먹는 것과는 전혀 관계가 없다고 말씀하셨습니다만, 아닙니다. 말씀드리고자 하는 바는 '동영상을 재생할 때 순차적으로 한 프레임 단위(혹은 몇 프레임씩 한꺼번에 가져오기도 하지만)씩 가져오는 방식을 채택하고, 파일의 입출력도 한꺼번에 파일 내용을 다 메모리에 넣는 일은 하지 않다. 마찬가지로 리플레이 파일이 커질 경우 스타크래프트에서의 메모리 필요량이 점점 늘어나야만 정상인데 실제로 그렇게만 흘러가진 않는다. 마찬가지로 리플레이 저장 목적으로 모든 명령 일람을 메모리에 죄다 기록한다는 것은 프로그램의 효율성상 타당성이 부족하다'였습니다만, 너무 생략했을까 모르겠습니다. 물론 그렇다고 HDD 안의 어딘가에 저장한다고 하는 제 말에 대한 근거로 입증하는 내용이 아니란 것은 아시리라 믿습니다. 포인터 관련 건에 대해서는 제 머리가 너무 과열했던 것 같네요. 인신 공격이라던가의 의도는 없었습니다. 혹 불쾌해하셨다면 너그러이 양해를 부탁드리겠습니다.
10/01/28 20:02
chowizard님// Kivol님// 같은 분야에 종사한다고 해도 기술은 천차만별입니다.
광기님이 자신하시니 기운 빠지게 하지 마시고 지켜 보시는 게 좋을 듯 합니다. 꼭 HDD에 저장해야 하는 것도 아니고 SSD든 뭐든 비싸도 빠른 비휘발성 메모리에 저장하게 하면 될테니까요. 안 될 것 같으니 하지 말라는 식이면 누가 도전하겠어요.
10/01/28 20:17
ArcanumToss님// 하지 말라고 한 적은 없습니다. 그냥 지켜보면 된다고 하면 굳이 의견을 묻는 식의 발제글이 필요가 없지요. 그냥 '우리 이런 거 합니다.'라고 소개만 하면 되는 일 아닌가요?
말씀대로 같은 분야(정확히는 같은 분야라고 하기도 뭣하죠. 전 스타크래프트 리버싱같은 건 별로 관심없으니...)에서도 기술 차이는 있지요. 물론 광기님 개발팀 쪽이 그 쪽에 대한 지식과 정보가 더 많을테니 개발에 성공한다고 해도 놀랄 일은 아닙니다. 전 그냥 일반적으로 도출해볼 수 있는 문제점들에 대해 상기시켜본 것 뿐입니다. 저도 실전에 사용할 수 있을 정도로 안정화가 가능한지 아닌지는 모릅니다.
|
||||||||||