초보 제작자분들을 위한 개발자 입장에서의 트리거 최적화와 플레이어 입장에서의 트리거 최적화에 대한 글

이 글은 초보 제작자분들을 위한 트리거 최적화에 대한 글입니다. 아시는 분들은 그냥 글을 안읽으셔도 좋을겁니다.

 

최적화라는 것은 간단히 말하면은 '간단하고 부드럽게 만드는 작업'이라고 말할 수 있습니다. 맵을 아무리 잘 만들어도 용량이 크면은 아케이드맵 다운로드와 로딩시간이 매우 길것이며, 매우 많은 과정을 거치게 만들면은 게임 도중에 시 렉이 걸려서 플레이에 지장을 주게 됩니다. 따라서 최적화는 게임을 설계하는 데 있어서 매우 중요한 작업 중 하나이며 이는 다른 모든 게임에서도 마찬가지입니다.

데이터 쪽에서도 최적화를 할 수 있는 작업이 있지만 데이터 쪽의 최적화는 행위자, 모델, 효과 등 일부 카탈로그의 작업만 해당하며 솔직히 저도 그렇게 잘 아는 것은 아니므로 이 글에서는 트리거 쪽에서의 최적화만 이야기 하도록 하겠습니다.

 

트리거의 최적화는 기본적으로 지금 당장 쓰지 않는 트리거는 꺼뒀다가 나중에 필요할 때만 키는 방식으로 하면 됩니다. 나중에 요리를 할거라고 지금 가스레인지 불을 계속 켜두면은 가스낭비가 심하잖아요. 트리거도 쓰지 않는 것들은 맨 처음 게임 시작 시 지도 초기화 이벤트로 행동에 'XX 트리거 끔'으로 해놓으면 됩니다. 이를 통해서 기본적으로 트리거 연산량이 어느 정도 줄어듭니다.

여기서 좀 더 최적화를 하고자하면은 이제 개발자 입장에서의 트리거 최적화와 플레이어 입장에서의 트리거 최적화로 나뉘어지게 됩니다. 이 2개의 차이가 뭐냐 있냐고 하실 수 있는데 이 2개는 지향방향이 다릅니다.

개발자 입장에서의 트리거 최적화는 스크립트의 간소화입니다. 동일한 결과를 만드는데 있어서 스크립트가 10줄인 것과 3줄인 것이 있다면 개발자 입장에서는 당연히 3줄인 것이 더 좋겠죠? 그래야 나중에 해당 스크립트 관련 오류가 생겨도 고치기가 쉽고, 나중에 컨텐츠를 추가할때도 쉬우니까요. 따라서 개발자 입장에서의 트리거 최적화는 스크립트를 최대한 짧고 간단하게 만드는 것입니다.

그럼 플레이어 입장에서의 트리거 최적화는 무엇이냐? 바로 역시 렉이 없도록 만드는 것입니다. 그럼 트리거로 렉이 없도록 할려면 어떻게 해야할까요? 당연히 트리거로 인한 연산량 작업을 최대한 줄이는 것이 좋을것입니다. 이는 위에서 말했던 쓰지 않는 트리거를 끔으로 해두는 것도 포함되는 것이지요. 그럼 단순히 'XX트리거를 끔'으로 하는 것 말고도 트리거로 인한 연산량 작업을 줄이는 것이 또 뭐가 있느냐 하면은 바로 애초에 해당 트리거를 어떻게 설계하느냐 입니다.

예를 들어 '어떤 유닛이 죽었을 때', '해당 유닛의 소유 플레이어한테 어떤 유닛을 생성'이라는 트리거를 만들어 본다고 합시다. 여러분들은 어떻게 설계하실건가요? 아마 기본적으로 떠오르는 것은 아무 유닛 소멸 이벤트에서 For문, 선정문, Switch문 등으로 지역변수와 함께 해서 트리거 발동 유닛의 소유자가 해당 플레이어인지 조건을 넣어서 만들면 된다고 생각할겁니다.

그러나 가끔 어떤 아케이드맵들 트리거 설계를 보면은 For문, 선정문, Switch문 이런걸 안쓰고 하나하나 아예 이벤트에서부터 아무 유닛 소멸이 아니라 아예 특정 유닛 소멸로 지정해서 트리거A, 트리거B, 트리거C등으로 나눈 맵도 있지요. For문, 선정문, Switch문 등을 모른다면 그럴 수도 있겠지만 안다고 생각되는 분들도 아예 안쓰고 하나하나 이벤트를 나눠서 트리거 설계를 하기도 합니다. 그러면 왜 그 아케이드맵을 만든 분들은 그렇게 트리거 설계를 했을까요?

이것을 알기 위해서 다음 두 가지 트리거를 봅시다

 

트리거 A : 아무 유닛 소멸 이벤트, 트리거 발동 유닛=C 조건, 정수 지역변수, switch문을 넣어서 트리거 발동 유닛의 소유자= 정수 지역변수이면 해당 정수 지역변수의 플레이어한테 어떤 유닛을 생성

트리거 B : C 유닛 소멸 이벤트, 정수 지역변수, switch문을 넣어서 C유닛의 소유자= 정수 지역변수이면 해당 정수 지역변수의 플레이어한테 어떤 유닛을 생성

 

이 2가지 차이점을 통한 문제점이 무엇인지 한 눈에 아신다면은 트리거 최적화에 대해서는 잘 아신겁니다. 바로 이벤트 발동 횟수에 따른 트리거 연산 작업량 차이입니다. 트리거 A는 C유닛이 죽는 것 말고도 다른 어떤 유닛이 죽어도 일단 트리거가 실행되고 조건을 확인하는 작업을 합니다. 따라서 해당 맵이 만약에 게임 플레이 동안 유닛 처치 수가 수천 마리에 달하는 맵이라면 트리거 연산 작업량도 그만큼 늘어나게 되지요. 혹시 어차피 조건확인을 통해 트리거가 실행 안되면 상관없지 않느냐라고 하시는 분들이 계실지도 모르겠지만 일단 조건을 확인한다는 작업량만으로도 연산이 늘어나기 때문에 혹시 이런 설계의 트리거가 많아서 맵에 렉이 걸린다면은 이런 설계로 만든 트리거를 다른 여러개의 트리거로 나누는 분산 작업이 필요해질 수도 있습니다.

그러면 A트리거 설계 방식이 나쁜 점이냐 하면은 나쁜 건 아닙니다. A트리거 방식의 설계는 개발자의 입장에서는 오류 수정과 컨텐츠 추가가 매우 수월하지요. 저 트리거 1개만으로 모든 플레이어한테 적용 가능하잖아요. 따라서 A트리거는 블러드 종류에서나 RPG에서 던전 사냥몹 등에서 쓰이곤 합니다.

B와같은 트리거가 이제 최적화를 위한 트리거 설계로 예를 들어 RPG에서 플레이어들이 하나의 영웅을 선택한다면 해당 영웅이 사망한 이벤트에서 실행되는 트리거를 플레이어 숫자만큼 만들어서 하면 됩니다. 물론 A트리거 방식대로라면 하나의 트리거로 해결되지만 만약에 게임 플레이 도중 렉이 걸린다면은 어쩔 수 없이 트리거를 나누는 분산 작업을 해야겠지요.

 

스2는 공허의 유산이 들어서면서 부쩍 최적화 말들이 많아졌지요. 최적화는 게임에서 매우 중요한 작업이지만 개발자를 위한 최적화와 플레이어들을 위한 최적화는 방향이 다릅니다. 너무 렉이 걸린다 싶으면 개발자들이 눈물을 머금고 플레이어들을 위해 이런 노가다 작업으로 최적화를 하는 등 정말 고생이 많지요. 혹시 자신의 맵이 게임하면서 렉이 걸린다 싶으면 눈물을 머금고 노가다 작업으로 한번 해보시길 바랍니다....