CK2 모딩 팁 CK2 모딩 가이드 | 제3장. 모드 언어 배우기 (7) - 조건 구역과 조건문 (1) (초고)

[tacitus]

3. 조건 구역과 조건문

스코프라는 거대한 장벽을 무사히 넘어오셨습니다. 스코프는 매우 중요한 내용이니, 반드시 알고 넘어오셔야만 합니다. 이제 당분간은 어려운 내용은 없습니다. 다만, 이제 자잘한 조건문이나 명령어 등을 실제로 보고 익히셔야 하는 부담이 조금 생기겠네요. 뭐, 따로 표 같은 걸로 만들어 두고 필요할 때마다 찾아서 봐도 되긴 하지만요. 절대로 시험공부하듯 달달달 외우지는 마십시오.

1_ 조건 구역

이 장이 시작하는 페이지에서, 이벤트 모딩은 결국 이러이러한 조건에서 이러이러한 효과를 발생시키라는 조건-효과 조합이라고 말씀드린 적이 있는데요. 따라서 디시전이건 이벤트건 반드시 조건을 설정하는 구역 설정이 되어있게 마련입니다. 물론 일부 이벤트에는 조건 구역이 없는 경우도 있지만, 그건 예외적인 경우니까 지금은 생각하지 마세요.

특히, 뒤에서 볼 효과 구역과는 달리, 조건 구역은 이벤트 모딩이 아닌 시스템 모딩의 경우에도 활용될 여지가 큽니다. 여러 시스템 요소들이 그 활성화 조건을 요구하는 경우가 많기 때문이죠. 따라서, 한 번 익혀 두면 끝까지 써먹을 수 있는 것이 바로 이 부분이라고 할 수 있습니다.

일반적으로, Crusader Kings 2 의 데이터 파일에서 potential = { } 또는 from_potential = { } 구역, allow = { } 구역. trigger = { } 구역 등은 모두 조건 구역이라고 생각하시면 틀리지 않습니다. (물론, 어떤 종류의 데이터 파일이냐에 따라서 쓸 수 있는 구역의 종류가 다릅니다. 그건 해당 부분에서 자료구조를 구체적으로 파악하면서 확인할 일입니다.) 이게 다가 아닙니다. 효과 구역에 비해 조건 구역의 종류가 압도적으로 많습니다. 나올 때마다 확인하겠습니다.

2_ 조건 구역의 특징

딱 하나만 유의하시면 됩니다. 조건 구역에서는 어떤 경우에도 명령어(명령문)를 사용할 수 없습니다. 사용하면 그 단위 구역이 제대로 실행되지 않으며, 그로 인해 같은 파일의 다른 부분의 실행에까지 영향을 미칠 수 있습니다. 조건 구역에는 반드시 조건 판단을 위한 조건문만을 사용해야 합니다.

스코프 지시자의 사용은 대체로 자유롭지만, 일부 조건 구역에서는 사용할 수 없는 스코프 지시자들이 있습니다. 특히 random_ 류의 스코프 지시자는 조건 구역에서 사용할 수 없다는 점을 유의하십시오. 스코프 지시자를 설명하면서 한번 짚고 넘어갔던 부분인데, 기억이 안 나신다면 다시 한 번 상기하시고 넘어가시면 됩니다.

3_ 조건 구역의 기본 스코프

드디어 이 이야기를 할 수 있게 됐군요.

지난 페이지까지 우리는 스코프에 대해서 열심히 공부를 했었습니다. 예시로 등장했던 모든 조건 구문에서 철저히 스코프를 검토하고 지정했었지요. 그래서, 아마 예시로 쓰인 대부분의 조건 문맥에서의 스코프 지시자는 ROOT 아니면 FROM 으로 시작하여 연결되었을 것입니다.

하지만, 때에 따라서는 스코프를 지정할 필요가 없는 경우도 있습니다. 다음의 예를 보시죠.

potential = {
	is_adult = no
}

potential = { } 구역은 위에서 살펴본 대표적인 조건 구역이니 여긴 당연히 조건 구역입니다. 사용된 조건문인 is_adult 는 현재 스코프의 캐릭터가 성인인지 아닌지를 판단하는 조건문으로, is_adult = no 이면 현재 스코프의 캐릭터가 성인이 아닌 경우에 참이 됩니다. 그런데, 늘 보아오던 스코프 지시자가 없습니다! 그러면 이 조건문은 대체 누구를 대상으로 조건을 판단하는 걸까요?

바로 결론을 말하자면, Crusader Kings 2의 모든 조건 구역(효과 구역도 마찬가지지만)에는, 구역에 적용되는 기본 스코프가 정해져 있습니다. 따라서, 스코프 지시자에 의해 스코프를 정해 주지 않은 조건 구역 부분에는 언제나 이 기본값이 적용됩니다. 그 기본값이 무엇인지는 데이터 파일의 종류에 따라 다릅니다만, 보통은 ROOT 입니다. 단, from_potential = { } 구역은 그 이름에서 알 수 있듯이 기본 스코프가 FROM 입니다.

왜 ROOT 가 기본 스코프인 경우가 대부분일까요? 이유는 간단합니다. ROOT 가 존재하지 않는 경우는 생각하기 어렵기 때문이기도 하고, 모든 경우에 이벤트에 등장하는 객체 중에서 가장 중요한 대상이 바로 ROOT 이기도 하기 때문입니다. 실상 어떤 이벤트건 그 주인이라고 할 수 있는 대상은 늘 ROOT일 수밖에 없는 것 아니겠어요? 그 결과, 기본 스코프가 ROOT 가 아닌 경우가 매우 예외적으로 취급되는 것입니다.

아무튼, 그래서 위의 예시의 경우, 비록 스코프의 명시적인 지정은 없지만, ROOT 에 해당하는 캐릭터가 성인이 아닌 경우에 참이 되는 조건 구역이라고 생각할 수 있는 것입니다. (물론 ROOT 가 항상 캐릭터인 것은 아니지만, 거기까진 아직 생각하지 맙시다.)

4_ 조건 구역의 판단 규칙

★ 여러 개의 조건문이 있는 경우의 판단(연산) 규칙

일단 예를 하나 보도록 합시다.

potential = {
	is_adult = yes
	is_female = no
	prisoner = no
}

위의 potential 조건 구역에는 3개의 조건이 기록되어 있습니다.

• is_adult = yes/no 조건문은 바로 앞에서 본 것이니 설명을 생략합니다.
• is_female = yes/no 조건문은 현재 스코프의 캐릭터가 여성인지 여부를 판단하는 조건문으로, yes라면 여성일 때 참, no 라면 남성일 때 참이 됩니다.
• prisoner = yes/no 조건문은 현재 스코프의 캐릭터가 수감 중인지를 판단하는 조건문으로, yes 라면 현재 수감중일 때 참, no 라면 수감중이 아닐 때 참이 됩니다.

그동안의 예시들에서는 조건문이 하나의 구역 안에 두 개 이상 나온 적은 없었기 때문에 이 고민을 할 필요가 없었을 겁니다. 하지만 실제로는 어느 하나의 조건으로 이벤트 등의 조건이 결정되는 경우는 오히려 예외적인 경우겠죠. 따라서, 두 개 이상의 조건이 하나의 조건 구역 내에 서술되었을 때에 그 조건들 사이의 관계가 어떤 것인지는 매우 중요한 문제가 됩니다.

일단 답은 간단합니다. 어떤 조건 구역이든, 조건 구역 내에서의 기본 연산 원칙은 AND 연산입니다. AND 연산이라고 하니까 전산 쪽에 소양이 없는 분들은 좀 어렵게 느끼시겠네요. 간단합니다. 즉, 모든 조건을 만족해야만 참이 된다는 것이죠. 위의 예시에서라면, 성인이고 남성이며 수감 상태가 아니어야만 이 조건 구역이 전체로서 참이 된다는 겁니다. 이해되시죠?

별 거 아닌 내용이라고 생각하실 수 있습니다만, 지금 말씀드린 조건 구역 내에서 기본적으로 AND 연산을 한다는 규칙은 매우 중요합니다. 이 개념을 확실히 머릿속에 집어넣고 가셔야 이후의 내용, 더 나아가 여러 개의 연산자와 스코프 지시자 구역이 중첩된 복잡한 조건 구역을 해석하는 데에 무리가 없습니다. 다시 한 번 상기하시고 다음으로 넘어가겠습니다.

★ 연산자 : OR

그런데, 이벤트를 만들다 보면 언제나 AND 연산만 사용할 수는 없습니다. A,B,C를 모두 만족하라는 식의 조건도 물론 있을 수 있겠지만, A,B,C 중 어느 하나만 만족하면 된다는 조건도 얼마든지 생각할 수 있잖아요? 이런 경우, OR 연산자를 사용하면 됩니다. 아래의 예를 보십시오.

potential = {
			OR = {
						is_adult = yes
						is_female = no
			}
}

위의 예시처럼, OR 연산을 할 조건문들을 묶어주시면 됩니다. 일반적인 프로그래밍 언어와 연산자의 사용 방법이 다르므로 주의하십시오. "성인이거나 (성인이 아니라도) 남성이면" 위 조건 구역이 전체로서 참이 되는 겁니다. 두 조건 중 어느 하나만 충족하면 전체가 참인 거죠.

그런데, 모양이 어째 지난 페이지까지 열심히 공부했던 스코프 지시자와 비슷하지 않나요? 그렇게 생각하셨다면 지난 페이지까지 열심히 공부하셨기 때문이니 자신에게 칭찬 하나를 얹어주시면 됩니다. 네. 스코프 지시자는 스스로 하나의 구역을 열고 닫을 수 있었지요. 사실 구역을 이끌 수 있는(=열고 닫을 수 있는) 예약어로서 대표적인 것이 바로 스코프 지시자이긴 합니다만(그리고 그 종류와 갯수도 엄청나게 많았지요), 여기서 공부하고 있는 연산자 역시 위와 같이 하나의 구역을 이끌 수 있는 예약어입니다. 따라서, 어떤 것이 스코프 지시자이고 어떤 것이 연산자인지 알고 계셔야겠죠. OR = { } 을 보고 이건 무슨 스코프 지시자야? 하고 있으면 곤란하잖아요.

★ 조건 구역 내에 존재하는 구역의 해석 방법

아래의 예시를 먼저 보고 시작하도록 합시다.

potential = {
	OR = {
		is_adult = yes
		FROM = {
			is_adult = yes
			is_female = no
		}
	}
}

위 예시와 비슷한 것 같은데, 달라진 게 있습니다. OR = { } 이 이끄는 구역 안쪽에, FROM = { } 이 이끄는 또 다른 구역이 등장했습니다. 이런 경우 이 코드의 해석을 어떻게 할 것인가가 이번 절의 핵심입니다.

일단 답부터 먼저 던지고 시작하겠습니다. 연산자가 직접 이끄는 구역 내에 또 다른 구역이 등장하는 경우, 그 구역은 그 구역 전체로서 하나의 조건문과 같이 판단합니다. 현재 OR = { } 로 묶여 있는 구역 안에 조건문 하나와 스코프 지시자 FROM = { } 이 이끄는 구역 하나가 존재하는데, 이 두 개의 지위가 동등하다는 것입니다. 그 결과, OR = { } 연산자는 자신 내부에 있는 FROM = { } 이 이끄는 구역 전체가 마치 하나의 조건문인 것처럼 취급됩니다. 즉, 아래와 같이 해석된다는 거죠.

• (ROOT가) 성인이거나,
• FROM이 성인이고 여성이 아니거나

여기서 어라? 하시는 분이 분명 계실 겁니다. 왜 OR = { } 구역 내에 있는데, FROM = { } 안에 있는 두 개의 조건문의 관계가 "이고" 로 해석되는지 이해가 안 되시는 분이 분명 계실 거예요.

결론부터 말씀드리면, OR = { } 연산자는 자신의 안에 위치하는 FROM = { } 구역 내에 영향을 줄 수가 없습니다. 구역을 이끄는 연산자가 영향을 미치는 범위는 자신이 직접 이끄는 조건문(FROM = { } 이 이끄는 구역을 전체로서 하나의 조건문으로 보므로 OR = { } 의 입장에서는 구역 자체를 그냥 조건문 취급)에 한정되기 때문이지요. Crusader Kings 2 식으로 설명해 볼까요? 왕의 봉신인 공작이 있고, 그 공작의 봉신인 백작이 있는데요. 왕이 직접 백작에게 이래라 저래라 할 수 있나요? 없죠? 그것과 같은 이치입니다.

위 코드의 OR = { } 구역 안에서 OR = { } 과 직접 맞부딪치는 것은 두 가지입니다. is_adult = yes 라는 조건문과, FROM = { } 스코프 지시자가 이끄는 구역이 그것이죠. 이 둘은 하나는 구역이고 하나는 조건문이지만, OR = { } 연산자와 직접 연결되어 있다는 점에서는 같고, 따라서 이들은 OR = { } 앞에서 동등합니다. 그래서 OR = { } 연산자는(왕) 자신의 구역을 해석하면서, FROM = { } 을(공작) 만나는 순간 그 내부의 해석에 대해서는 본인은 알 바 아니라는 식으로 대응합니다. 대신 FROM 에게 "네 구역 안에 있는 객체들(백작)을 네가 통째로 해석해서 그 결과만 나에게 가져오라"고 요구하는 거죠.

그 결과, FROM = { } 이 이끄는 구역 내에서는 OR = { } 연산자가 힘을 쓰지 못하므로, 다시 원칙으로 돌아가 FROM = { } 구역 내의 여러 개의 조건문에 대한 해석 규칙은 AND 연산이 되는 것입니다. 따라서 FROM = { } 구역의 해석은 "성인이고 남성" 이라고 해석되며, FROM = { } 스코프 지시자는 이 해석 결과를 그대로 OR = { } 연산자에게 넘겨줍니다. 그리고 OR = { } 연산자는 그 해석을 전체로서 자신 구역 내에 있는 다른 조건문 또는 구역들과 동등한 지위에 놓고 판단을 하는 것입니다. 설명이 좀 장황했는데, 풀어서 설명하려다 보니 좀 길어졌으니 잘 이해해 보십시오. 그래도 이해가 안 되시면 질문하시고요.

★ 곁다리: 연산자가 만드는 구역과 스코프 지시자가 만드는 구역의 차이

설명을 드리다 보니 갑자기 노파심이 생겨서, 이 부분을 명확히 설명드린 후 진행해야겠다 싶은 관계로 잠시 옆길로 샜다가 다시 돌아오도록 하겠습니다.

이제 우리는 스코프 지시자와 연산자가 모두 하나의 구역 { } 을 이끌 수 있다는 사실을 압니다. 그런데, 스코프 지시자가 이끄는 구역과 그 외의 예약어가 이끄는 구역 사이에는 스코프 지시자의 해석에 있어서 중요한 차이가 발생합니다.

아래의 예시를 한 번 보시고 계속 설명드리도록 하죠. 이번 코드는 조금 복잡하고 어려울 수 있습니다.

potential = {
	location = {
		OR = {
			has_hospital = no
			port = yes
			owner = {
				is_adult = no
				character = PREVPREV
			}
		}
		is_winter = no
	}		
}

일단 본 적 없는 조건문이 하나 등장했죠?

• has_hospital = yes/no 조건문은 현재의 스코프 대상이 프로빈스인 경우에 사용할 수 있는 조건문으로서, 현재 스코프에 해당하는 프로빈스에 병원이 지어져 있는지 없는지를 판단하는 조건문입니다. yes 라면 있는 경우에 참, no 라면 없는 경우에 참이 되겠지요. Crusader Kings 2 에 병원이 도입되면서 새로 추가된 조건문입니다.
• is_winter = yes/no 조건문은 현재의 스코프 대상이 프로빈스인 경우에 사용할 수 있는 조건문으로서, 프로빈스의 기후 상태가 겨울인지 여부를 체크하는 조건문입니다.

그 외에는 사실 다 아는 조건문이고 스코프 지시자인데, 웬걸, 뭔가 해석이 삐걱거립니다. 아마 제 글을 충실하게 읽어오신 분 중 어떤 분은 위 코드의 오류를 지적하고 싶으실 수도 있어요. 제가 설명한 적이 없기 때문에, 이 모두는 타당한 반응이십니다만, 조금만 참으시고 마저 읽어보십시오. 단계적으로 해석해 보겠습니다!

• 우선, potential = { } 구역이기 때문에 조건 구역이며, ROOT 또는 FROM 으로 시작하지 않았으므로 기본 스코프 대상은 ROOT 입니다.
• location = { } 스코프 지시자는 기억 나시죠? 현재 스코프의 캐릭터가 위치하는 프로빈스를 가리키는 스코프 지시자입니다. (location 스코프 지시자가 사용된 것으로 보아 ROOT 는 캐릭터임이 분명해졌네요.)
• OR = { } 연산자가 사용되었습니다. 안을 들여다보니 조건문 2개와 구역 1개가 있군요. 고로 일단 3개의 조건문이 있다고 보고 하나하나 판단해 봅시다.
• has_hospital = no 이므로 해당 프로빈스에 병원이 없는 경우를 의미합니다.
• port = yes 는 기억이 나실지 모르겠습니다만, 해당 프로빈스가 해안 프로빈스인지 여부를 확인하는 조건문입니다. port = yes 이므로 해안에 위치한 프로빈스이면 이 조건이 참이 되겠네요.
• 그 다음은 owner = { } 라는 스코프 지시자가 이끄는 구역이 등장했네요. 이 구역 전체로서 하나의 조건을 이루므로, 내부를 한번 들여다 봅시다. 아, owner = { } 스코프 지시자가 뭔지는 아시죠? 프로빈스 또는 타이틀 스코프 내에서 사용되어(저는 프로빈스에서 주로 사용하며, 타이틀 스코프 내에서는 holder_scope = { } 스코프 지시자를 사용합니다. 의미는 같아요.) 그 프로빈스의 소유자를 나타내는 스코프 지시자라고 말씀드렸었습니다. owner = { } 구역은 OR = { } 구역의 내부에 있는 별도 구역이므로 OR = { } 연산자는 영향을 끼치지 못하고, 따라서 내부의 두 개의 조건문은 AND 연산이 됨은 앞에서 설명드렸습니다.
• is_adult = no 는 다 아시죠. 해석해 보면, ROOT 캐릭터가 위치해 있는 프로빈스의 소유자가 성년이 아닐 것이라는 조건입니다.
• character = PREVPREV 이므로 ROOT 캐릭터가 위치해 있는 프로빈스의 소유자가 PREVPREV 스코프 지시자가 가리키는 캐릭터일 것이라는 조건이고, 바로 위의 조건과는 AND 관계이므로, owner = { } 구역 내의 조건 해석을 종합하면 "ROOT 캐릭터가 위치해 있는 프로빈스의 소유자가 PREVPREV 스코프 지시자가 가리키는 캐릭터이고, 그 캐릭터는 미성년일 것" 이라는 조건이 되겠네요.
• is_winter = no 이므로, 현재 프로빈스의 기후 상태가 겨울이 아니어야겠네요. 그리고 OR = { } 구역과 is_winter = no 조건문은 서로 같은 location = { } 스코프 지시자가 이끄는 구역 내에 있고, 별도의 연산자가 없으므로 각각 모두 AND 연산으로 해석하게 됩니다.

해석이 잘 되셨나요? 매끄럽지 않더라도 해석이 되시는 분은 지금까지의 내용을 잘 따라오신 분입니다. 아예 해석이 안 되시는 분은 앞의 내용을 다시 공부하셔야 하고요. 그런데, 해석이 되시는 분 중에서도 PREVPREV 에 대해서 의문을 제기하시는 분이 계실지 모릅니다. 요컨대 PREVPREV 스코프 지시자의 대상은 character 조건문의 인수이므로 캐릭터여야 하는데, 위 코드에 의하면 캐릭터가 아니라 프로빈스를 가리키고 있지 않느냐는 거죠. 이것이 바로 이 절에서 말씀드리고자 하는 핵심입니다.

우리가 앞에서 배우기를, PREV 스코프 지시자는 현재 스코프 지시자의 깊이에서 한 단계를 거슬러 올라간 위치의 대상을 가리킨다고 배웠습니다. 따라서 이 경우는 PREVPREV 이므로 두 단계를 거슬러 올라가야 하죠. 자, 질문입니다. 스코프 구역의 최상위 구역을 0이라 하고, 스코프 구역의 깊이가 하나씩 깊어질 때마다 1씩을 뺀다고 합시다(다른 모더분들은 어떤 방식으로 생각하시는지 모르겠습니다만, 제 경우는 이런 식으로 계산합니다). 이 규칙에 의하면 location = { } 스코프 지시자가 이끄는 구역의 깊이는 -1이 되겠지요. 그렇다면, 문제의 PREVPREV 가 존재하는 owner = { } 구역의 깊이는 몇이 될까요? 위에서 의문을 제기하신 분들은 아마 -3이라고 답하셨을 텐데, 아닙니다. -2 입니다. 왜?

스코프 지시자 구역의 깊이를 계산할 때는 오직 스코프 지시자가 만드는 구역만을 계산해야 합니다. OR = { } 은 연산자일 뿐 스코프 지시자가 아니므로, OR = { } 내부의 스코프 지시자의 대상이 바뀌지 않습니다. 따라서 스코프 지시자 구역의 깊이를 계산할 때는 OR = { } 은 없는 것으로 치고 계산을 하는 거죠. 그렇다면, owner = { } 내에서 PREV 가 사용된 경우, 이 스코프 지시자가 가리키게 되는 현재 스코프 대상의 바로 윗 단계는 OR = { } 이 아닌 막바로 location = { } 구역이 되는 것입니다. 여기에선 PREVPREV 가 쓰였으므로 2단계 위로 올라가면 location = { } 구역보다 하나 더 위인 기본 스코프 지시자 ROOT 를 가리키게 되는 거죠.

스코프 지시자를 설명하면서는 구역의 깊이를 설명드리면서 오직 스코프 지시자가 만드는 구역의 깊이만을 놓고 설명을 드렸습니다. 그 때는 제가 그것밖에 가르쳐 드리지 않았으니까요. 그러나 이제는 구역을 이끄는 예약어가 스코프 지시자 외에도 존재한다는 것을 배우셨으므로, 이제부터는 단순한 "구역의 깊이"와, "스코프 지시자 구역의 깊이"를 구분하도록 합시다. 앞의 예를 가지고 다시 한 번 복습을 해 보죠. 아래 그림을 보십시오.

정리하면 이렇습니다. 단순히 구역의 깊이를 계산할 때는 종류에 관계 없이 하위 구역이 열릴 때마다 하나씩 깊이가 깊어지지만, PREV 스코프 지시자와 연계되는 스코프 지시자 구역의 깊이를 계산할 때는 오직 스코프 지시자가 생성한 구역의 깊이만 따져 계산한다는 것입니다. 단순 구역의 깊이는, 현재 구역에서 동등한 레벨에 있는 예약어 또는 구역이 무엇인지를 찾는 데에 활용합니다. 따라서 연산자로 묶인 구역에서 그 연산자가 영향을 끼치는 조건문을 확인하기 위해서는 단순한 구역의 깊이를 확인해야겠죠. 스코프 지시자 구역의 깊이는 PREV 스코프 지시자가 가리키는 대상이 어떤 것인지를 판단하기 위해서만 의미가 있습니다. 이 의미 차이를 설명하기 위해서 이런저런 예를 들어 봤는데, 설명이 잘 되었는지 모르겠습니다. 너무 어렵고 장황해 진 게 아닌가 싶기도 합니다.

독자에 따라서는 상당히 난해할 수 있는 내용이기도 한지라, 이번 페이지는 여기쯤에서 끊고 다음 페이지에서 조건문과 조건 구역에 관한 내용을 계속 살펴보겠습니다.

---

일단 눈에 띈 게 있어서 다시 원고를 잡긴 했습니다만, 1회의 글을 다듬고 내용을 추가하고 수정하는 데만 몇 시간씩 걸리다 보니, 이걸 과연 얼마나 더 할 수 있을지 의문이긴 합니다. 아무튼 하는 데까진 해 보겠으니, 또 중단되면 이후의 내용은 네이버 카페의 카페북으로 계속 이어서 보아주시기 바랍니다. 저도 2.6 ~ 2.7 이후로는 모딩에 거의 전혀 손을 대지 못했기 때문에 최신의 내용에 대해서는 거의 무지합니다.. ㅠㅠ

(최종 업데이트: 2018. 09. 24, 대응 버전: 무관)

[Jonah]

항상 잘보고있습니다..

[심심타파이야]

타키투스님 진심 오랜만이네요^^

[우리의카를씨]

타키투스님 히스토리 1년1월1일 버그 어떻게 고치나요? 다시 롤백해도 꺠짐

[tacitus]

그 버그가 뭔지 모릅니다...

[말랑말랑카우]

잘읽었읍니다