OOJJRS

(현재 글을 쓰고 있는 시스템에는 익스프레스 버전 뿐이다. 보통은 등록되어 있지 않으니 찾아보기로 경로를 잘 찾아들어가자)

해당 방식은 내가 만든 것이 아니라 이미 숙련된 프로그래머라면 대부분 쓰고 있을(또 만들 수 있는) 방법이다.

그 동안 이 방식보다는 다른 방법을 이용했었는데, 이번에 라이브러리화시키면서 끝내 만들게 되었으므로 하는 김에

조금 더 시간을 투자하여 많은 분들(특히 프로그래머 지망생들)에게 소개하고자 한다.

이 글을 읽기 위해서는 꽤 폭넓은 기반 지식이 필요하다(깊을 필요는 없다).

가능한한 모든 연관된 것을 설명하겠지만 링크나 검색 등으로 때우는 경우도 있을 것이다.




switch(sz)
{
　　case "Name":
　　　　...
　　　　break;
　　case "Age":
　　　　...
　　　　break;
}


위와 같은 구문이 C나 C++ 상에서 돌아가지 않는다는 것은 이미 잘들 알고 있는 사실이다.
(당연하죠! ... 때문에 컴파일 오류가 나잖아요? 라고 반문하는 사람은 없길 바란다)


switch 명령은 case가 많을수록 이론상 if문과의 성능 차이가 기하급수로 벌어지게 되어 있다.

이론상인 이유는 if - else if 열거식의 경우에도 만약 비교하는 대상 중 어느 한쪽이 상수라면 현대의 똑똑한 컴파일러가

자동으로 점핑 테이블을 만들어 마치 switch - case처럼 동작하기 때문이다.

※ 상수 값에 따라 IP 는 마치 함수호출처럼 자신의 주소를 향해 펄쩍 뛰어간다. break 구문을 만나면 switch 가 끝나는 블럭으로 또 한 번 점프한다. break 나 continue 는 goto 구문의 다른 (특수한 용도로 한정된) 이름이다.




그런데 상수가 아닐 경우는 점핑 테이블 생성이 불가능해진다. 아니, 불가능하다기보다는 우리가 원하는 그 성능이 나올 수가 없다.

점핑 테이블을 쓰는 것은 시간이 오래 걸리는 테이블 생성 작업을 1회 한 후(2011. 05. 31. 수정되었음) 한 번의 비교로 원하는 곳으로 찾아가 작업하겠다는 성능을 기대하는 것인데

변수가 case에 들어가게 되면 일반적인 if - else if 로밖에 구현이 안되는 것이다.

EIP = EIP + jmptable[nIndex];

하지만 변수가 case 에 가능하다고 하면 대체 jmptable 은 얼마나 커져야할까. 게다가 변수가 상수가 아닐 경우에는

nIndex 값 자체가 산출되지 않아 저런 식으로는 불가능하고 연결리스트 따위를 동원해야하니 속도 성능 같은 건 나락으로

떨어지는 것이다.




그래서 보통 빨리 짜야하거나 몇 가지 안되는 케이스를 가진 문자열 비교는 고전적으로 if - else if 로 행해진다

if(strcmp(sz, "Name") == 0)
{
}
else if(strcmp(sz, "Age") == 0)
{
}
else ...

이런 연쇄 else if 구문을 볼 때마다 속이 메스껍고 피로함을 느낀다면, 반갑다. 나도 그렇다.

게다가 더 큰 문제는 else if 중첩에는 한계가 있다는 것이다(error code C1061 참고)
(물론 정확히는 else if 중첩만이 문제가 아니지만, 어쨌든 많이 쓸 수가 없다)


그래서 이것을 개선한다면, 전통적으로 map이나 hash_map 을 사용해왔다.


static map< string, int > m;
void Init()
{
　　m["Name"] = ENUM_NAME;
　　m["Age"] = ENUM_AGE;
}

void func()
{
　　switch(m[sz])
　　{
　　　　case ENUM_NAME:
　　　　　　...
　　　　　　break;
　　　　case ENUM_AGE:
　　　　　　...
　　　　　　break;
　　}
}



오, 오오... 깔끔하게 스위치 전환에도 성공했고 성능상의 이점도 가져왔다.

아 그런데... 뭐 좀 부족함이 느껴지지 않는가?

저런 문자열 비교 루틴이 수십 군데서 사용된다고 생각해보자(물론 다들 문자열 목록이 다른).

그런 경우가 얼마나 있겠냐고? 단순히 스크립트 데이터를 해석하는 코드만 해도 저런 것들이 부지기수다.


그래, 난 근성가이야. 하면서 그 수십 군데의 루틴을 모두 저렇게 열거형 상수를 선언하고 맵으로 고친다...

못할 건 없다. 초기화 함수 하나 만들고 변수 하나 선언하고 열거형 쯤 만들면 되지.

하지만 저런 부분들은 노가다 작업이다. 아무나 해도 될 뿐더러 저런 작업을 하고 있으면 굉장한 손해를 본다.

성능상으로야 가장 퍼펙트하지만(map 대신 hash_map을 쓴다면, 비록 표준은 아니지만 더욱 성능으로는 우위에 설 수 있을 것이다)

코드의 유지보수 관리에는 개떡이 되는 것이다.

매번 문자열 토큰(대개 태그라고도 하는데) 하나 추가될 때마다 상수도 추가해야하고 초기화에 라인도 추가해야하고

뭔가 작업할 곳이 최소한 세 군데가 생기는 것이다(열거형 상수쪽, 초기화쪽, switch 안)



그래서 생각하기를, 그냥 case 하나 달랑 추가하면 그 모든 걸 자동으로 해주는 신통방통한 녀석 없을까? 다.

완전 베스트 아닌가? 소개한다.


아래 소개된 코드는 앞서 이야기한대로, 내가 최초 사용한 기법은 아니지만, 작성은 스스로 했다(내 입맛에 맞게).

하지만 이해하기 쉽도록 몇 부분을 고쳤으며 이대로 활용하기엔 조금 불안한 부분이 있음을 미리 고백한다.
(뭐, 실무용으론 조금 부족하지만 예제용으론 그냥 써도 된다)


#define STR_SWITCH_BEGIN(key) \
{ \
　　static stdext::hash_map< string, int > s_hm; \
　　static bool s_bInit = false; \
　　bool bLoop = true; \
　　while(bLoop) \
　　{ \
　　　　int nKey = -1; \
　　　　if(s_bInit) { nKey=s_hm[key]; bLoop = false; } \
　　　　switch(nKey) \
　　　　{ \
　　　　　　case -1: {

#define CASE(token)  } case __LINE__: if(!s_bInit) s_hm[token] = __LINE__; else {
#define DEFAULT()    } case 0: default: if(s_bInit) {

#define STR_SWITCH_END()   \
　　　　　　}      \
　　　　}       \
　　　　if(!s_bInit) s_bInit=true; \
　　}        \
}



실제 사용은 다음과 같이 한다

STR_SWITCH_BEGIN(sz)
{
　　CASE("Name")
　　　　...
　　　　break;
　　CASE("Age")
　　　　...
　　　　break;
}
STR_SWITCH_END()


자, 이제 우리 입맛에 맞는 것들이 준비되었다. 앞으로 case가 추가된다 하더라도 단지 저곳에만 작업해주면 된다.

그럼 나머지 부분들은 모두 자동화되어 처리된다.

그런데 여기서 그냥 납득하지 않고 의문을 갖는 분들이 있다. 현명한 자세다. 세상에 공짜는 없는고로, 저런 게 그냥 됐으면

진작에 C++ 에서 표준으로 제공했을 것이다.

map(또는 hash_map)을 사용한 switch 보다 손해보는 점은 case 구문마다 if가 들어간다는 점과 위에서 미리 사용한

변수들이 자칫 기존 코드와 겹칠 수 있다는 점, 마지막에 STR_SWITCH_END 가 들어가 혼동된다는 점 등이다.

하지만 이 정도는 감수할 수 있을 정도에 불과하며, 사후 코드 관리 측면에서는 월등한 이점을 가져다준다.



마지막으로, 코드만 봐도 쉽게 이해할 수 있겠지만 위의 것을 사용할 때 놓치기 쉬운 몇 가지 주의점에 대해 언급하고자 한다.




1. 최초 1회에 한하여 초기화 과정을 수행하는데, 따라서 처음 1번의 비교는 제법 시간이 걸린다(모든 요소에 대해 일단 다 돌고 나서 원래 비교하려고 했던 값을 비교하므로). 그러니 만약 1회 비교하고 끝나는 루틴 같은 곳에는 저거 쓰지 말기 바란다.


2. hash_map 은 현재 C++ 표준이 아니다. 물론 그럴 확률은 지극히 낮지만, 언제 가서 코드가 메롱해질지 장담할 수 없다. 불안하다면 그냥 map 을 써도 좋다. map 은 표준인 만큼 견고함에 있어서는 해시보다 월등하다. 물론 비교 성능은 해시보다 좀 떨어진다.
(그래서 나도 해시맵을 탐탁찮게 생각하는 사람 중 하나이며, 해싱이라는 스킬 자체가 과연 키 해싱에 대해 무결성이 가능한지에 대해서도 회의적이므로 늘 불안불안하다)


3. VS 상에서 컴파일할 경우 릴리즈모드는 상관없으나 디버그모드에서는 컴파일 옵션을 바꿔주지 않으면 컴파일이 되지 않는다. 저 부분이 무슨 역할을 하는지는 검색하면 금방 나오니 활용하길 바란다.

원래 디버그 모드는 Program Database for Edit & Continue 옵션으로 되어 있는데

이것을 Program Database 로 바꿔주어야 한다(릴리즈 모드 옵션이다)


__LINE__ 이라는 매크로 때문인데 이것이 /ZI 옵션 상에서는 상수가 아니라 변수로 제어되기 때문에

상수로 코드에 박히는 /Zi 옵션이 필요한 것이다.
(case 에는 상수만 쓸 수 있다는 것을 다시 한 번 상기하자)


4. 실제 돌려보면 알겠지만, case 부분에 변수가 사용 가능하다! 하지만 컴파일만 되는 것일 뿐, 수행 결과는 첫 1회 초기화 때의 값에 따라 switching 되어 나온다. 너무 들뜨지 않길 바란다. 왜 그런지는 소스를 보면 잘 알 수 있을 거라 생각된다.



5. 혹시나 해서 첨언한다. 위의 예제 코드와 내가 만든 코드 사이의 차이는 언어 코드(MBCS / UNICODE) 분석 부분과 여러가지 예외 / 에러 처리 등이다.




많은 이들에게 도움이 되었으면 한다.

wowfull.exe

  내 너와 같이 만든 베히모스를 볼지어다, 녀석은 소와 같이 풀을 먹는다.
  그 힘은 허리에 있고 ...(중략)
  그것이 정신 차리고 있을 때에 누가 능히 잡을 수 있겠으며 갈고리로 그 코를 꿸 수 있겠느냐 ?

위의 내용은 수많은 베히모스의 설정(?) 중 하나로 성경에서는 하마와 같은 모습으로

본래 베히모스는 사막에 산다고 알려진 전설 상의 괴수다.
 
주로 그 출전과 기원은 복잡한 신화를 지닌 중동 - 아라비아 사막에서 특히 잘 찾아볼 수 있는데,
 
문제는 그 중동의 사막이 워낙 여러 종류의 문명들이 지나다닌 곳이라 체계적으로 확립될 기반이 안되었다는 것이다.

그나마 가장 정설로 받아들여지는 것은 아라비아의 기록과 성경에 인용된 히브리인의 그것인데, 그 외에도 수많은 -

심지어 러시아나 우크라이나의 문화권 영향도 받았음을 알 수 있다.

그 외에도, 실존하는 동물 - 특히 코끼리나 하마였을 거라고 하는 기원 또한 지배적이다.
 
문제라면, 코끼리는 반추 동물과 관계가 없다는 것이고, 하마는 잡식을 하니 문제지만...

그래도 굳이 실존 동물로 꼽으라면, 여러 뒤죽박죽 설정 가운데 가장 가까운 것은 하마인 것 같다.

삼국지 -열전- 은 한 마디로 잡탕 게임이다. 많은 게임의 내용이 뒤섞여 있으며 시뮬레이션의 성격이 강하다.

턴 방식 진행이라고 할 수도 있지만 반-실시간이라고 하는 것이 더 어울릴 듯 하다.

기획 시 가장 중점을 둔 부분은 바로 '현실성'이다. 플레이어와 게임 세계를 동화시켜 현실감 있는 배경이 되게끔 여러 장치를 두어 노력했다.



1. 진행 방식

싱글/멀티 플레이가 가능하며 장수 플레이를 기본으로 한다. 각종 장르의 요소가 섞여 있기 때문에 가장 비슷한 장르를

고르라고 한다면 MMORPG 삼국지를 울티마 온라인처럼 만들었다고 하는 것이 어울릴 것 같다.

1턴은 전략 턴(30초~무제한) / 실행 턴(2분)으로 나뉘어져 있으며 전략 턴에 장수의 행동을 정하고 실행 턴이 되면

동시에 결과가 진행된다. 삼국지6의 그것과 가장 비슷하다고 할 수 있지만 좀 더 확장되어 있다.

실행 턴에는 모든 플레이어(컴퓨터 포함)의 행동이 종료되면 2분을 다 채우지 않더라도 자동 종료된다.

물론 군주나 태수처럼 지휘권을 가진 장수는 다른 장수에게도 임무를 명령할 수 있는데 기존 시리즈처럼 수행하지는 않는다.

이와 관련해서는 다른 글에서 설명할 기회가 있다.

또한 1인칭 시점 개념이 도입되어 플레이어가 군주라고 해도 모든 것을 제어할 수는 없다. 심지어 전투에 출전해도 자신의 부대가 아니면 직접 조종할 수 없다!(간접 조종은 가능하다)

이러한 이유로 삼국지 열전은 필연적으로 좋은 인공지능을 갖추어야 했으며 플레이어의 의도를 각 말단부(?)까지 정확하게

전달할 수 있는 수단을 갖추고 있다.



2. 게임 종료 조건

각 지위에 따른 승리 조건이 따로 마련되어 있을 뿐만 아니라 패배 조건 또한 다양하고 플레이 장수가 죽으면 기존 시리즈처럼

다른 장수를 선택하여 연속하는 것이 아니라 그냥 그대로 끝나게 된다. 이는 나중에 설정을 두어 조절할 수 있게 할까를 고민하고 있다.



3. 멀티 플레이

멀티 플레이를 할 때는 장수의 이름과 이미지만을 선택하고 랜덤한 능력치로 시작하는(타입은 결정할 수 있다) 랜덤 플레이를 지원한다.

삼국지 열전은 장수의 능력치가 은폐되어 있기 때문에 에디터를 사용하지 않는 이상 누가 얼마만큼의 능력치인지 알지 못하므로

랜덤 장수의 시작은 그 특성의 극대화가 된다. 물론 밸런스 파괴 같은 것은 없으며 다양한 방법으로 능력치 차이를 대처할 수 있으므로

관건은 자신의 능력 파악과 가능한 승리 조건을 노리는 전략적 감각이다.



4. 현실성 장치

모든 장수는 어떠한 '판단 기준'을 내재하고 있다. 예를 들면, 관우는 병사 훈련도에 대해 보병80, 극병40, 창병40의 기준 수치를 갖고 있고 장비는 보병70, 극병40, 창병90의 수치를 갖고 있다.
(실제 수치와는 같지 않고 그냥 예제일 뿐이다)

어떤 병사(또는 부대)의 훈련도가 보병75, 극병50, 창병50이라고 해보자.

이때 관우를 플레이하는 유저가 볼 때 그 대상은 보병 B급, 극병 A급, 창병 A급으로 나올 것이고
 
장비를 플레이하는 유저에게는 보병 A급, 극병 A급, 창병 C급으로 보일 것이다.

만약 관우와 장비가 AI라면, 군주인 유저에게 "진언"을 할 때 저 판단을 참고하므로 아마 둘의 의견은 엇갈리게 제시될 것이다.

당연히 관우는 보병 훈련이 더 필요하다고 할 것이고 장비는 창병 훈련이 더 필요하다고 할 것이므로 판단은 알아서...

물론 저 내재된 판단 기준은 공개된 수치가 아니므로 누가 어떤 수치가 더 높은지는 알 도리가 없다.

만약 군주인 유비가 관우처럼 보병80, 극병40, 창병40의 기준을 갖고 있다면, 아마 장비보다는 관우 말을 뽑을 가능성이 더 크지 않겠는가?

유비가 플레이어라도 자기 눈에도 관우처럼 보일테니 말이다.


이런 장치를 보조하는 것이 바로 "평가" 제도다. 평소 유비는 관우를 "보병A, 극병B, 창병B"로, 장비를 "보병A, 극병B, 창병A"로 평가했다고 하자.

그럼 이때 유비는 위의 정보에 기초하여 창병 훈련이 부족하다고 진언하는 장비 말을 선택할 수도 있다.

물론 이 평가도 실제 수치와는 무관하고 어떤 장수 A가 B를 평가하는 기준에 따라 하는 말에 불과하다.

만약 자부심이 높은 장수라면 자신의 능력을 실제보다 더 높게 평가할 것이고 사이가 나쁜 장수가 있다면 그놈의 능력을

더 까서 평가할 수도 있을 것이다. 물론 그것도 장수의 성향에 따라 달라진다. 공사를 엄격하게 구분하는 장수라면

자신의 감정에 따라 다른 장수를 깎아내리는 일은 하지 않을지도 모른다.


즉, 결론적으로 유저는 현실의 우리처럼 장수의 내부 수치가 아니라 "각 장수들이 지각한 내용"에 대해서 받아들일 수밖에 없다.



세부적인 내용에 대해서는 또 다음 기회에 올리도록 하겠다.

게임 제작이란 원래 눈에 보이는 것보다 보이지 않는 작업이 훨씬 많다보니 그 동안 작업 진척도란 것을 올릴 수가 없었다.

물론 작업을 시작한지도 1년이 훌쩍 넘어섰는데 이것밖에 못한 것은 게으름의 영향도 있다 하겠다.

Mines.zip

프로그램 실행 시

게임 도중 화면

1. AI 계의 발전에 일조

2. 현실적인 배경 및 일본 문화 탈피(일본식 왜곡/재해석, 문화 흡수 지양), 한국 정서에 맞는 한국식 삼국지 문화 형성

단순하게는 서로를 부르는 호칭 같은 대화의 문화에서부터 넓게는 의도적인 역사적 왜곡이나 일본식의 사건 해석 등을 벗어난 한국형 삼국지 게임 제작

3. 다형성(?) 플레이를 제작해보고 싶은 욕구

다양한, 여러 방식을 동시에 조합한 멀티 플레이 지향. 즉 2명이 한 컴퓨터로, 나머지 한 명은 네트워크로 3인이 함께 플레이할 수 있는 방식 등을 지원하고픈 욕심

4. 편리한 UX 제공

5. 높은 수준의 창조적 유저 생산성을 통한 순환 시스템 제작 욕구

게임에서 제공하는 모든 내용을 유저가 동일하게 에디터를 사용하여 만들어낼 수 있는 시스템 제공. 원한다면 자신만의 시나리오를 제공할 수도 있고 반드시 삼국지 시대가 배경이 아닌 다른 역사적인 시대를 배경으로 결과물이 나올 수도 있는 그런 자유성

삼국지 열전의 특징을 다음과 같이 정리할 수 있습니다.

1. 매니지먼트

직접 장수로 성과를 올리는 것이 아닌, 관계와 정책을 통한 관리형 게임

2. 높은 AI

현실이라면 당연히 이래야지? 와 같은 직관성에서 벗어나지 않는 세계의 움직임 구현

※ 개별 대화체 시스템, 정보 수집 결정 시스템, 정보 판단 시스템, 관계 시스템(기획 중), 의사결정 시스템 등

3. 동시 전략, 동시 수행

삼국지6 과 비슷하게, 전략/수행/보고 페이즈로 나뉘어 동시에 현재 상황에서 전략을 상정하고, 동시에 수행하며 결과를 보고받는 시스템

4. 내부 수치 비공개

장수A의 능력치가 내부적으로 수치가 있을지는 몰라도 플레이어에게는 공개되지 않는 시스템. 각 장수의 능력치는 '평가 등급'으로 표현되며, 유비가 관우를 볼 때와 장비가 관우를 볼 때 무력의 '평가 등급'은 서로 다르게 보일 수 있음을 뜻함. 따라서 플레이어는 여러 장수들의 간언을 보고 최종적으로 '선택 행위'를 통해 정책을 선택하는 플레잉 방식을 사용하게 됨

5. 관조자

역사 속의 위인으로는 플레이할 수 없으며(향후 기능 추가로 제공될 여지는 있으나) 기본적으로 자신의 캐릭터를 생성하여 플레이하고 역사에 포함되는 역할.

6. 단일 조작

캐릭터의 지위가 군주라고 하여 다른 장수들의 행동까지 설정하거나 간섭할 수는 없음. 모든 명령의 실행과 그 과정은 자동으로 진행되며 다른 도시의 정치, 행위 등도 모두 자동 위임되어 있음. 오직 플레이어들만이 자신의 캐릭터를 직접 조종할 수 있음.

7. 관계/정치 시뮬레이션

여타 삼국지가 대부분 전쟁과 전투를 테마로 하는 게임이었다면 삼국지 열전은 인간 관계로 대변되는 정치 시뮬레이션. 관계 매니지먼트의 끝은 정치지만 정치가 그리 어려운 개념을 말하는 것이 아님을 강변하는 특징.

※ 이 글들은 모두 1999년 ~ 2005년 정도까지 운영되던 http://user.chollian.net/~oojjrs 에 올렸던 글들을 편집, 재가공하여 최신화한 내용들입니다. 어린 나이에 어설픈 내용들을 인터넷에 떠돌아다니게 만든 것들에 책임을 져보고자 시작하였습니다(그래서 검색하면 여기 올라온 것보다 더 많은 내용이 있을 수 있습니다). 근데 업데이트는 느릴 수 있어요




녹갈색의 살갗에 90cm의 작은 몸집, 물 위를 뛰어다닐 수 있는 날렵함, 몸집의 절반 가량을 차지하는 긴 꼬리. 상상 속으로 그려본다면 상당히 괜찮은 이미지를 안고 나올 이 도마뱀은 바실리스크라는 현존하는 생물이며. 애완용으로 인기가 있다.

그러나 신화 속에 등장하는 바실리스크는 상당하다. 강력한 괴물일 뿐 아니라 특수능력도 갖추고 있다.

바실리스크는 어원을 그리스 어에 두고 있다. 코카트리스, 혹은 바실리코크 등의 별명으로 불리던 바질리스코스Basiliskos는 뱀의 왕이라는 뜻이 있다. 또한 코카트리스라는 말을 잘 살펴보면 영어의 악어에 해당하는 크로커다일과 어원이 같다. 대개 바실리스크가 묘사될 때 악어와 비슷하게 표현되는 것은 우연이 아닌 것이다. 하지만 간단하게 악어형 도마뱀! 이라고 하기엔 조금 복잡한 계보를 가지고 있다.

처음 바실리스크는 커다란 뱀의 모습으로 표현되었다. 뱀의 왕이 원래 뜻인 만큼 당연한 일인지도 모른다. BC 1세기경 로마의 플리니우스는 유명한 학자인데, 그의 박물지에 바실리스크가 등장한다. 강력한 독을 가진 카토블레파스와 비교되어 아프리카의 키레나이카 지방을 산지로 들고 있는데, 4미터 가량에 코브라와 흡사한 묘사를 해놓았다. 또 다른 이야기에서는 바실리스크가 뱀의 지배자이기 때문에 모든 독사들이 왕과 같은 바실리스크 앞에서 모두 몸을 땅에 대고 기었기에 오늘날과 같이 스멀스멀꾸물락 기어다니게 되었다고 한다.

당시만 해도 강력한 독은 있지만 사안(시선이 마주치면 죽일 수 있는)의 능력은 바실리스크에게 없었으며, 족제비가 천적이라는 것 정도로 기술된 것으로 보아 완전히 뱀과 같았던 모양이다.


바실리스크의 독이 얼마나 강한지에 대해서 몇 가지 사례가 있다. 한 기사가 아프리카를 횡단하는 도중 바실리스크와 마주쳤을 때 녀석의 독이 두려워 말에서 내리지 않고 좀 떨어져서 창으로 바실리스크를 찔러 죽였는데 맹독이 창을 타고 올라와 기사와 말이 같이 중독되어 죽었다는 이야기가 있다. 또 비슷한 이야기로 바실리스크의 알을 깼는데 그 독에 중독된다는 내용도 있다. 이것은 중세로 갈수록 심해져서 아예 몸에서 독의 기운을 뿜어내다가 급기야 사안, 혹은 석화 시선(시선이 마주치면 석화되는)까지 발전했다. 이로써 바실리스크는 원래 없었던 신화도 그에 걸맞춰 창조되었다. 석화나 사안의 능력에 대한 얘기들인 것이다.

일설로는 알렉산드로스 대왕이 바실리스크 퇴치를 경험했다는 얘기가 있다. 동방 원정 행군 도중 바실리스크가 나타나 병사들 몇이 석화되어버리자 방패를 들이대어 포위하게 한 뒤 바실리스크가 그 방패에 비친 자신의 시선에 석화가 되게 만들었다는 것이다(아주 고전적인 내용으로, 페르세우스가 메두사를 잡을 때 써먹었던 방식이다).

사안은 제법 그 과학적(?) 근거도 갖고 있다. 독의 발산은 아무래도 두꺼운 살갗보다는 뚫린 입이나, 귀, 코 등을 통해 더 잘 빠져나오기 마련인데, 그 중 눈은 시선을 조절할 수 있다는 점에서 독의 진행과 더욱 밀접한 관련이 생긴다. 때문에 시선을 따라 독이 퍼져서 눈이 마주친 대상은 대상의 눈에 독이 퍼져서 결국 온 몸이 중독되어 죽고 만다는, 매우 황당한 얘기인 것이다. 그다지 논리적이진 못하지만 매우 강력한 능력임에는 틀림없다.


바실리스크의 몸에서 맹독의 기운이 퍼져 나오니 그 주변은 생물이 살 수 없었고 결국 바실리스크가 사는 곳 주변은 황무지, 혹은 사막이 되어버렸다(바실리스크가 사막에서 태어난다는 설과 상당히 유사점을 보인다). 혹은 아예 바실리스크의 맹독에 맞설 수 있을 만큼 생명력이 강한 지형이 조성되어야 하는데, 그것은 바로 늪지대이다. 때문에 바실리스크는 늪지와 사막, 양쪽에서 사는 것으로 인식되었다.

바실리스크의 특징이 이것 뿐만인 것은 아니다. 이들은 발톱이나 앞발의 힘도 상당하고 이빨도 날카로우며 늪지에서 사는 바실리스크들은 방어적이고 탄탄한 살갗을 갖추었고 사막에서 사는 바실리스크들은 두꺼운 피부에 발빠른 몸놀림을 갖게 되었다.

점차 발전한 바실리스크는 중세 중기 이후로는 닭과 같은 꼴이 되어버렸다. 코카트리스는 악어의 어원일 뿐만 아니라 닭이라는 말도 포함하고 있다고 생각한 것에서부터 발전했기 때문이다(사실 코카트리스는 공룡 중 랩터의 모습으로 자주 표현된다. 잘 생각해보면 닭하고 공통점도 좀 있지 않은가?). 사실 바실리스크가 현재와 같이 도마뱀으로 확립된 것은 근래에 들어와서 악어와 뱀을 합쳐놓고 이미지를 재탄생시켰기 때문이다. 심지어는, 도마뱀이란 이유로 크게 범위를 잡아서 드래곤 범주로 분류되기도 한다. 

바실리스크의 탄생에 대해서도 말들이 많다. 다만 그 많은 변화 중에서도 맹독의 특성만큼은 꼭 따라다닌다.

일설에는 따오기가 독을 가진 생물(주로 전갈이나 뱀. 이집트 지방의 얘기다)을 먹으면 그 독이 따오기의 몸 안에 축적되는데, 그 따오기가 알을 낳게 되면 그 알에서 바실리스크가 태어난다는 것이다. 때문에 따오기가 알을 낳는 시기가 되면 근처 주민들이 돌아다니며 따오기의 알을 모두 깨버렸다는 얘기도 있다(거기에서 또한 따오기의 알에 축적되어 있던 독에 중독되었다고도 한다).

또 다른 설로는 영웅 페르세우스가 메두사를 죽였을 때 사막에 떨어진 메두사의 피에서 태어났다는 것이다. 이 외에도 몇 가지 설이 더 있지만 흥미로운 내용은 아니므로 생략하자.

현대의 바실리스크는 굳이 분류한다면 동물계 이하의 파충류과인데도 불구하고 다리가 여섯 달린 것으로 묘사된다(많을 때는 여덟 개까지 달렸다). 머리에는 왕관과 비슷한 무늬나 벼슬이 훌륭하게 달려 있고 작은 것도 3미터에서 큰 것은 5, 6미터나 되는 초대형으로, 전체적으로 녹갈색, 혹은 적녹색을 띄고 있다(사막에 사는 바실리스크는 적녹색, 늪지에 사는 바실리스크는 녹갈색의 식이다. 벼슬은 아마도 닭 설정의 영향이 있지 않을까 한다).


ps : 귀차니즘에 쩔어 있는 제 대신 출처의 그림들을 찾아준 gmmk11 님에게 감사드립니다. 정작 찾아준 시기와 수정한 시기가 엄청나게 차이가 나는군요...

원래는 직접 프로그램으로 만들려다가 안 그래도 벌려둔 프로젝트에 이리저리 치이는 바람에

귀차니즘 지수가 급상승하여 괜찮은 프로그램이 없나 찾아보았다.

프로그램들은 버전과 신뢰성 문제로 여기에 직접 올리는대신 제목만 게재하였고 네이버 자료실(http://file.naver.com)에서

검색하면 쉽게 받을 수 있다.




Update Cleanup

윈도우 업데이트 시에는 레지스트리와 윈도우 폴더 내에 시스템 속성으로 설치 파일들이 남게 되는데

업데이트 후에는 사용되지 않으므로 지워주어도 되지만 함부로 손을 대기엔 껄끄러운 것도 사실이다.
(어차피 수동으로 삭제해도 레지스트리는 정리되지 않는다)

업데이트 클린업 프로그램은 이 파일들과 레지스트리를 정리해준다.

쉐어웨어지만 가끔 한 번 해주면 되는 용도이므로 라이센스는 큰 문제가 되지 않는다.

Continue 누르고 다음 화면에서 적당히 선택하고 삭제해주면 된다.

아차, "난 일어 중국어 불어 다 할 줄 아는데 영어는 몰라요!"라는 사람이 있을지도 모르는데,

대충 아무거나 찍어도 될만큼 버튼도 몇 개 없으니 겁내지 말자.

아차차, 비스타와 윈도7은 아직 지원 안된다. 참고 삼으시라.

실행 중 화면

중국과 유럽 간 무기 체계의 발전은 차이가 존재한다. 여러 가지 원인으로 그것을 설명할 수 있겠지만

기본적인 병사 개념의 차이가 가장 큰 것으로 생각된다.
(여차저차 하지만 역시 무기의 가장 큰 소요계층은 군대인 법이다)

군인이 하나의 직업이자 시민으로 구성된 그리스-로마 계열 군대에서 그들은 주력 전투원이었으며 존중받았다.
(용병을 사용했던 카르타고 등의 지중해 주변국도 결국은 "다른 나라의 시민"을 고용한 것이다)

존중받았다는 말의 의미는 적어도 중국에서 보병이 그러했던 것처럼 머릿수 채우기나 총알받이(총은 없었지만)로

사용된 것은 아니었다는 것을 의미한다.

중국은 인구가 많았던 것도 있지만(대개 소외되는 사실이지만 한나라의 전 영토는 고대 로마의 최대 판도보다 넓었다)

병사가 징병으로 주로 이루어졌기에 농민군이 주축이었고 하나의 직업이라기보다 국방의 의무를 지는 형태였다.

때문에 유럽에서는 중세에 봉건제가 되고 기사가 주전력이 되어 중국의 그것과 비슷한 전투 방식이 태어나기 전까지는

좀 더 보편적인 무기 외에는 생산되지 않았다. 대개 유럽에서 무기의 발전이라 하면 점차 대형화되어가는 추세에
 
각종 문화 차이에 따른 특수한 무기가 존재하는 것 정도가 전부였다.


반면 중국에서 대기병 전술이 발달하기 전까지 전투는 대개 일기토전 또는 계략전이었고

일기토전 - 무술 싸움이란 완전 그들만의 잔치였기에 그들의 기호에 따라 여러 특수한 개량 무기들이 줄줄이 탄생했다.

얼마나 무기가 많았는지 이미 송 말에는 무관의 "기본" 덕목으로(과장이 심하다고 생각되지만) 17종의 무기를 완벽하게

익히는 것을 들고 있다.


한대에도 이미 무기는 굉장히 많았다. 다만 역사적으로 이야기가 계속 추가되어갔기에 당대에는 없었던 무기들이나

조상에 해당하는 무기들이 잘못 그려져 전달되는 것들이 많다(그게 아니라면 아직 고고학적 발견이 이루어지지 않은 것이리라).

예를 들면 극이란 무기는 원래 창과 비슷하나 부속 칼날이 달려 있어 보병이 기병을 상대하기 좋게 만들어진 것이다.

이것까지 들으면 여포의 그것과 크게 다를 바 없어보이지만 부속 칼날이 초승달 모양이 아니라 갈고리 모양이다.
(무슨 차이가 있냐고? 무기편 두번째 시간에 혹시 그림이 추가된다면 그때 보시라)

초승달 모양의 부속 칼날은 송대 이후에 등장했다.
 
그러나 삼국지에는 이미 여러 종류의 극 무기가 등장할 뿐 아니라 여포의 방천화극은 유명하다못해 상징물이 되었다.
 
극의 조상에 해당하는 무기가 있어 이야기가 만들어지면서 혼동이 일어났거나(아니면 송대에 만들어졌거나),

있었던 무기가 대기병 전술이 알려지기 전까지 활용되지 못했다고 생각하거나 해야할 듯 하다.

연노를 발명했다는 제갈량의 결과물에 대해서도 여러 가지 학설이 존재하는데 그것이 실제 있었는가의 여부에서부터

정말 10발씩 동시 발사가 되는가, 위력적이었는가 하는 등의 숱한 의문들을 안고 있다.

이런 삼국지 시대의 무기에 대해서 목록별로 알아볼 주제를 마련해보았다.


아무래도 그림이나 사진을 추가해야겠지만 특유의 귀차니즘으로 이번편까지 넘어갔다.

무기편 -2-에서부터는 이해를 돕기 위한 그림을 첨부하겠다(언제 쓰여질지는?).

Nuri_3_0_Release.zip

애초에 다국어 버전으로 추가할 계획을 갖고 프로그램을 만들었으나 막상 리소스 셋을

하나 더 만들 생각을 하니 잡다한 툴팁과 설명을 원체 많이 써둔지라 양이 만만찮다 :-(

네이버 블로그에서 이사온 글이다

engword2.exe

옵션이 추가되었다.

시간 제한 및 문제 수를 조절할 수 있고 시간 제한은 통합 제한 또는 각 문제당 제한으로 선택할 수 있다.

2.0 버전에서 사용하던 데이터는 그대로 사용할 수 있다.

사용하다보니 대단찮은 버그가 한두개 쯤 발견되었는데 다음 버전 업 때 수정될 듯 하다.

나는 이것을 영어 단어장으로뿐 아니라 한문 단어장(?)으로도 사용하고 있다. 제법 한문 테스트가 그럴듯하다.

(하지만 글자 크기가 워낙 작은 듯하여 다음 버전에서는 글자 크기가 좀 커질 듯)

업그레이드를 하긴 해야겠는데... 요즘 안 쓰다보니 잊고 지낸다.

기존 네이버 블로그에 있던 글을 옮겨왔다