최근 1~2년간 내가 몸담고 있는 게임에 크래쉬가 부쩍 늘었는데, 그 속을 들여다보면 절반 이상이 메모리 부족이다. 이 문제는 시스템 사양을 올려도 해결되지가 않는다. 제아무리 시스템 메모리가 넘쳐나는 세상이라고 해도, 아직 32bit 윈도우를 쓰는 사람도 많다. 그래서 게임은 32bit 프로세스로 돌아가게 만들어야 하고, 그렇게 하면 프로세스가 할당받을 수 있는 유저 메모리는 2GB가 한계이기 때문이다. 실제로는 스택 영역도 있고, 단편화나 뭐 이런저런 문제로 진짜로 쓸 수 있는 메모리는 2기가가 안되기 마련.
문제는 게임의 수명이 길어질수록 컨텐츠가 늘어나게 되고 그에 따라 사용하는 리소스의 양도 많아진다는 것.
어느 게임이든 그럿지만, 개발 당시에는 어떻게든 출시하는게 목표였을 것이기 때문에, 일단 되는 방향으로 개발해야만 했을 거다(그당시의 상황을 나는 모른다). 이렇다할 컨텐츠가 많이 없었기 때문에 게임에 포함된 모든 리소스를 메모리에 올려놔도 사용하는 것만 메모리를 할당하는 것과 몇MB차이가 안났을 게다. 그래서 의도인지 아닌지는 모르겠으나, 게임에 쓰이는 모든 리소스가 게임 구동시에 메모리를 차지하도록 구성되어 있었다. (두둥)
아마도 짐작컨데, 이런 시나리오였을 거다. FPS게임이 있고, 출시 당시에 총기를 대략 20종 준비해 놓고 출시했다고 가정해 보자. 한 방에서 게임하는 플레이어가 대충 8:8이라고 치고 최악의 경우를 상정하면 16명이 16종의 총기를 골고루 들고 나오는 건데, 게임 구동시 모든 총기를 다 로딩해 놔도 기껏해야 4종의 총기 리소스에 해당하는 메모리만 추가 부담하면 된다. 총기 하나에 5~6MB를 차지한다고 치면 껏해야 20MB. 이마저도 게임에 플레이어가 들어오고 나가고를 몇번 하다 보면 어차피 다 로딩되어야 하는 경우도 심심치 않았을 거다. 게다가 게임 구동시에 로딩이 일어나므로 맵 로딩 시간 및 난입 랙이 줄어드는 순기능마저 있다. (lol)
그러다가 총기를 추가하는 업데이트를 한다. 한번에 한두개의 총기만 추가되므로 추가되는 메모리 부담 역시 10MB안쪽이다. 요즘 같은 세상에서는 납득할 만한 수치이다. 게다가 총기 한개 더 넣자고 기존의 리소스 관리를 뜯어고쳐서 새로 만드는 것 역시 수지가 안맞는 일이다. 이런저런 이유로 기존의 방식 대로 총기 리소스가 들어간다.
그런데 세월이 흘러 총기 한두개씩을 넣는 업데이트 30회를 거쳤다. 총기가 3배로 늘어났다. 그럼 총기가 60종이 되는 건데, 최악의 상황을 가정해도 16명이 16종의 총기를 들고 나오는 거다. 그런데 기존 스킴 대로 게임 구동시에 모든 총기의 리소스가 로딩된다면 게임 중 쓰일 리가 없는 총기 44종의 리소스는 말 그대로 메모리 도둑일 뿐이다. 게다가 같은 총기를 들고 오는 사람이 있다면 낭비는 더 심해진다.
물론 이런 일이 일어나서는 안된다.그런데 그것이 실제로 일어났습니다.
이는 부분적으로 언리얼 엔진의 구조 때문이기도 한데, 언리얼 스크립트는 게임 진행에 필요한 리소스가 참조될 경우 스크립트 로딩과 동시에 해당 리소스를 로딩해 버린다. 신경써서 짜지 않으면 실행경로에 없는 리소스도 마구 로딩돼 메모리를 차지하게 된다.
그럼 방법은? 리소스가 로딩될 시점을 프로그래머가 제어해 줘야 하는데, 이 역시 난관이 있다. 개발 작업에 사용하는 애셋에는 일반에 공개되면 안되는 리소스도 많이 있다. 그래서 패키징 시에 공개될 버전에서는 참조되지 않는 리소스를 제외하고 패키징하는데, 리소스를 프로그래머가 동적으로 로딩하면 언리얼 스크립트에서 제공하는 리소스 참조 관리를 거치지 않으므로 참조되지 않는 것으로 처리하여 패키징에서 빠지는 불상사가 일어난다.
동적으로 로딩하는 것들을 별도로 관리하는 매커니즘을 만들면 되긴 하지만, (그리고 실제로도 만들었다) 문제는 지금까지 작성된 스크립트를 고칠 엄두가 안난다는 것이다. 작업량도 많거니와, 새 컨텐츠 만들 시간도 없는데 기존의 것 고치자고 노가다를 하기도 좀 그렇고, 게다가 고쳤는데 버그라도 일어난다면 누가 책임진단 말인가.
해서, 우리 게임의 메모리 사용량은 계속해서 계속 계속 계속 증가하기만 해왔고, 급기야 이제는 클라이언트 크래쉬의 주 원인으로 떠오른 지경. (후새드) 이거야말로 가랑비에 옷젖는 줄 모르는 대표적 사례.
결말은? 근 2주에 걸쳐 각종 총기과 무기, 캐릭터에 주렁주렁 달려 있는 리소스를 동적로딩으로 바꾸고 대략 200MB를 절감할 수 있었다는 것. (올레!)
문제는 게임의 수명이 길어질수록 컨텐츠가 늘어나게 되고 그에 따라 사용하는 리소스의 양도 많아진다는 것.
어느 게임이든 그럿지만, 개발 당시에는 어떻게든 출시하는게 목표였을 것이기 때문에, 일단 되는 방향으로 개발해야만 했을 거다(그당시의 상황을 나는 모른다). 이렇다할 컨텐츠가 많이 없었기 때문에 게임에 포함된 모든 리소스를 메모리에 올려놔도 사용하는 것만 메모리를 할당하는 것과 몇MB차이가 안났을 게다. 그래서 의도인지 아닌지는 모르겠으나, 게임에 쓰이는 모든 리소스가 게임 구동시에 메모리를 차지하도록 구성되어 있었다. (두둥)
아마도 짐작컨데, 이런 시나리오였을 거다. FPS게임이 있고, 출시 당시에 총기를 대략 20종 준비해 놓고 출시했다고 가정해 보자. 한 방에서 게임하는 플레이어가 대충 8:8이라고 치고 최악의 경우를 상정하면 16명이 16종의 총기를 골고루 들고 나오는 건데, 게임 구동시 모든 총기를 다 로딩해 놔도 기껏해야 4종의 총기 리소스에 해당하는 메모리만 추가 부담하면 된다. 총기 하나에 5~6MB를 차지한다고 치면 껏해야 20MB. 이마저도 게임에 플레이어가 들어오고 나가고를 몇번 하다 보면 어차피 다 로딩되어야 하는 경우도 심심치 않았을 거다. 게다가 게임 구동시에 로딩이 일어나므로 맵 로딩 시간 및 난입 랙이 줄어드는 순기능마저 있다. (lol)
그러다가 총기를 추가하는 업데이트를 한다. 한번에 한두개의 총기만 추가되므로 추가되는 메모리 부담 역시 10MB안쪽이다. 요즘 같은 세상에서는 납득할 만한 수치이다. 게다가 총기 한개 더 넣자고 기존의 리소스 관리를 뜯어고쳐서 새로 만드는 것 역시 수지가 안맞는 일이다. 이런저런 이유로 기존의 방식 대로 총기 리소스가 들어간다.
그런데 세월이 흘러 총기 한두개씩을 넣는 업데이트 30회를 거쳤다. 총기가 3배로 늘어났다. 그럼 총기가 60종이 되는 건데, 최악의 상황을 가정해도 16명이 16종의 총기를 들고 나오는 거다. 그런데 기존 스킴 대로 게임 구동시에 모든 총기의 리소스가 로딩된다면 게임 중 쓰일 리가 없는 총기 44종의 리소스는 말 그대로 메모리 도둑일 뿐이다. 게다가 같은 총기를 들고 오는 사람이 있다면 낭비는 더 심해진다.
물론 이런 일이 일어나서는 안된다.
이는 부분적으로 언리얼 엔진의 구조 때문이기도 한데, 언리얼 스크립트는 게임 진행에 필요한 리소스가 참조될 경우 스크립트 로딩과 동시에 해당 리소스를 로딩해 버린다. 신경써서 짜지 않으면 실행경로에 없는 리소스도 마구 로딩돼 메모리를 차지하게 된다.
그럼 방법은? 리소스가 로딩될 시점을 프로그래머가 제어해 줘야 하는데, 이 역시 난관이 있다. 개발 작업에 사용하는 애셋에는 일반에 공개되면 안되는 리소스도 많이 있다. 그래서 패키징 시에 공개될 버전에서는 참조되지 않는 리소스를 제외하고 패키징하는데, 리소스를 프로그래머가 동적으로 로딩하면 언리얼 스크립트에서 제공하는 리소스 참조 관리를 거치지 않으므로 참조되지 않는 것으로 처리하여 패키징에서 빠지는 불상사가 일어난다.
동적으로 로딩하는 것들을 별도로 관리하는 매커니즘을 만들면 되긴 하지만, (그리고 실제로도 만들었다) 문제는 지금까지 작성된 스크립트를 고칠 엄두가 안난다는 것이다. 작업량도 많거니와, 새 컨텐츠 만들 시간도 없는데 기존의 것 고치자고 노가다를 하기도 좀 그렇고, 게다가 고쳤는데 버그라도 일어난다면 누가 책임진단 말인가.
해서, 우리 게임의 메모리 사용량은 계속해서 계속 계속 계속 증가하기만 해왔고, 급기야 이제는 클라이언트 크래쉬의 주 원인으로 떠오른 지경. (후새드) 이거야말로 가랑비에 옷젖는 줄 모르는 대표적 사례.
결말은? 근 2주에 걸쳐 각종 총기과 무기, 캐릭터에 주렁주렁 달려 있는 리소스를 동적로딩으로 바꾸고 대략 200MB를 절감할 수 있었다는 것. (올레!)
TAG 게임개발
