OOJJRS

둘 중 고맙습니다가 권장되어 요즘은 일체의 TV 아나운서들도 모두 고맙습니다로 언어를 순화한 지 꽤 된 것 같다.

문제라면 그 이유에 대한 탐구인데,

감사感謝라는 단어가 일제의 잔재이므로 사용하지 말아야 한다...라는 잘못된 지식이 전파되고 있어서 문제다.

본래 취지는 고맙습니다의 경우 순우리말이고 감사합니다는 한자어이므로 우리말 보존의 차원에서 순화되었다.

감사라는 한자어는 한중일이 모두 동일하게 사용하고 있으며 우리나라의 경우 조선왕조실록에서도 기록되어 있으므로 일제 시대에 들어왔다는 의견은 얼토당토않다.

또한 잘못 퍼지고 있는 내용이 국립국어원에서 그렇게 이야기했다고 하는데, 그쪽에서는 우리말 보존 차원이라고만 이야기하고 있다.
http://www.korean.go.kr/09_new/minwon/qna_view.jsp?idx=63167

http://krdic.naver.com/rescript_detail.nhn?seq=411

다만 우리나라는 아직도 순우리말보다 한자어를 더 정중하고 격식있는 표현으로 취급하므로 감사합니다를 완전 버릴 수 있을 것 같지는 않다.

제작 동기

1. 자체 라이브러리의 완성도 제고

2. AI 엔진 제작

3. 내 입맛에 맞는 매니지먼트 게임 제작

4. 오랜 시간을 (큰 노력 없이) 들여야하는 특성의 게임을 제작하고 싶은 욕구

자체 엔진을 활용한 연습용(튜토리얼용?) 제작 게임에 가까우며 삼국지 열전 제작의 기반이 될 것입니다.

게임 특징

1. 관찰

몇 가지의 간섭 방식을 제외하면, 플레이어는 신이 세계를 보는 것처럼 관찰하기만 합니다.

2. AI 자동화

플레이어는 게임 속 객체의 활동에 대해 강제할 수 없습니다.

3. 실시간

모든 객체는 실시간 속에서 활동합니다. 시간 단위는 물론 현실보다 훨씬 가속화되어 있습니다.

4. 추적

생성되었다 사라진 임의의 특정 객체 A에 대해 연대기를 생성할 수 있습니다. 실시간 추적도 가능합니다.

모든 객체는 자신의 역사를 갖고 실시간으로 기록됩니다.

5. 모눈

세계는 모눈 격자로 표시됩니다.

http://www.wordhippo.com/

사전 기능을 좀 더 세부적으로 만들어둔 곳이라고 할 수 있다.

단어의 유의어, 반의어 등을 찾을 때 유용하게 활용할 수 있어서 링크

그 외에도 많은 기능이 있더라

사놓고 한동안 잊었던 AOE 2 HD 버전을 실행했다가, 5분만에 한 번 튕기고

한 35분여 플레이하다 또 튕겨서 빡쳐버렸다.

스팀 쪽 refund 는 시도해본 적이 없지만 귀찮아서 어쩔까 하다가

(행사로 싸게 샀기 때문에 어쩌구 저쩌구 설라무네?)

잠깐 검색해보니 다음과 같은 글이 있었는데

http://www.escapistmagazine.com/forums/read/9.405187-Age-of-Empires-2-HD-is-broken-much-anger-is-being-felt

결론은 실행 시 별도의 런처가 수행되는데 그 런처를 빼고 바로 다이렉트하게 하니까 잘 되었다...라는 내용이 있어서

한 번 시도해보려고 한다.

덤프 파일을 보고 나서 무의식중에 열어서 (pdb도 없이) 디버깅을 하다가 내가 지금 무슨 짓을, 이라는 생각이 들었다.

(동병상련 따위는 아니라고!)

-------------------------------------------

글을 다시 읽어보니 정작 방법을 설명해두지 않아서 (링크해둔 글에 있기는 하지만) 잘 된 것 같아 방법도 게재한다.

설치된 폴더로 가서 Launcher.exe 를 없애고 대신 AoK HD.exe 파일을 Launcher.exe 로 변경하면 된다.

가끔 vs를 사용하다보면 vs의 버그라든지 버그라든지 버그 같은 것을 만나서

신기한 상황에 봉착하곤 하는데 대개는 삽질을 여러 시간 한 뒤에 알아차리게 되므로

굉장히 우울한 경우가 대부분이다.

이번에도 역시 마찬가지로, 특정 파일이 계속 encoding 이 뻑나는 상황이 나오기에

나는 해당 텍스트 파일이 미쳤거나 모종의 파일 BOM 트릭 같은 것에 걸린 줄 알았다.

그러니까, 다음과 같은 상황인데

// Note : 호환 이라는 구문이 잘 보이는가?

하지만 닫았다 열면,

인코딩이 깨진다.

삽질을 한 줄로 요약하여 결론을 내자면,

다음과 같은 새 프로젝트에서도

그냥 호환 << 이라고 주석을 달아버리니 깨진다.

두 글자들이 다 깨지는 것도 아니고, // 호환 이라고 해도 깨진다.

이러다가 깨지지 않는 글자로 인해 인코딩이 정상적으로 먹으면, 그 뒤로는 호환 이라고 써도 깨지지 않는다.

내 진짜 억울해서 팔딱팔딱 뛸 일이다만... (내 30분...)

방심하다가 가끔 당한다.

http://gamsung.org/hk/sboard3/download.php?db=geo&uid=13&upfile=upfile

아키텍처를 현재 조직구조에 맞추도록 한다.

DB가 추가된 이유가 DB팀이 일거리를 찾기 위해서 라는 식은 곤란하다.

25개 이상의 최상위 아키텍처 컴포넌트가 존재하는 건 너무 복잡하다.

한 개의 요구사항이 설계의 전체 방향을 이끌어나간다.

이 요구사항이 없어지면 그 아키텍처는 다른 이슈를 감당하기엔 지나치게 다른 길을 걸어왔다.

하나의 요구사항에 집중하면, 다른 이슈들을 건성으로 다루는 경향이 있기 때문이다.

아키텍처가 운영체제의 특정 버전에 의존적이다.

생각보다 이런 경우가 잦다.

표준 컴포넌트가 사용될 수도 있는 곳에 독점적인 컴포넌트를 사용한다.

하드웨어 단위 구분과 동일하게 컴포넌트를 나눈다.

시스템이 진화하여 하드웨어가 변경되면, 넌 x 된다. 소프트웨어 조직을 하드웨어에 끼워맞추지 말라.

신뢰성 확보라는 명분 하에 필요하지 않은 중복이 있다.

DB 이중화, 2개의 시작 루틴 따위는 시스템을 필요 이상으로 복잡하게 한다.

설계가 예외상황 중심적이다.

핵심 공통성이 아닌 기능의 확장성만을 강조한다.

개발조직에서 시스템 아키텍트를 식별할 수 없다.

아키텍트 또는 프로젝트 관리자가 아키텍처의 이해 관계자를 식별하는데 어려움이 있다.

관계도가 명확하지 않다는 것은 고려 없이 만들었을 가능성이 높다.

개발자가 두 컴포넌트의 상호작용을 코딩하는데 있어서 지나치게 많은 선택권을 갖는다.

아키텍처가 과다하게 선택권을 제공하거나 해당 이슈를 간과하도록 설계됐다면, 아직 아키텍처를 정의하는 중이다.

아키텍트에게 아키텍처 문서 작성을 요청하면, 클래스 다이어그램만 만들고 다른 것은 만들지 않는다(못 한다).

아키텍트에게 아키텍처 문서를 요청하면, 누구도 보지 못한 도구에서 자동으로 생성된 다량의 문서더미를 제시한다.

자동으로 생성이라도 되면 다행이다. 너무 복잡해서 생성하다가 프로그램이 터지는 프로젝트를 나는 알고 있다.

전달된 문서가 예전 내용이라면 당연히 최신 내용으로 관리되지 않고 있다.

설계자 또는 개발자에게 아키텍처를 설명하도록 요청하면, 못 하거나 상이한 아키텍처에 대해서 설명하고 있다.

- 소프트웨어 아키텍처 평가 286p

굵은 글씨는 내 경험 상 깊이 느꼈던 부분들이다.

http://codeka.com/blogs/index.php/2009/03/21/got-visual-studio-2008-professional-want

http://veblush.blogspot.kr/2012/10/map-vs-unorderedmap-for-string-key.html

매우 정리가 잘 되어 있는 글입니다

http://en.wikipedia.org/wiki/Library_(computing)

http://stackoverflow.com/questions/140061/when-to-use-dynamic-vs-static-libraries

http://msdn.microsoft.com/en-us/library/958x11bc.aspx

http://stackoverflow.com/questions/4546507/lib-linking-other-libs

로 출발한 내용들

일단 기본 지식부터

SxS

http://en.wikipedia.org/wiki/Side-by-side_assembly

/MD, /MT 설정들

http://msdn.microsoft.com/en-us/library/2kzt1wy3(v=vs.100).aspx

제기한 주제와는 큰 관련 없지만 그럭저럭 /MD 와 /MT 설정에 대한 토론글

http://stackoverflow.com/questions/757418/should-i-compile-with-md-or-mt

역시 별 관련은 없지만 마침 나처럼 부스트 라이브러리를 빌드하는 사람의 글이 찾아져서

http://stackoverflow.com/questions/9527713/mixing-a-dll-boost-library-with-a-static-runtime-is-a-really-bad-idea

이건... 내 의문과 딱 떨어지는 누군가의 질문

http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/a98b46f1-2d26-45c5-89c5-30714b18596a/

전통적으로 인스톨러를 좋아하지 않는 나는 기본인 /MD 설정보다 /MT 를 즐겨쓴다.

VisualC.PDF

매번 찾기 힘들어서 링크 2

http://msdn.microsoft.com/en-us/library/vstudio/hh567368.aspx

http://msdn.microsoft.com/en-us/library/hh567368.aspx

우씨 근데 정작 찾는 페이지가 없네 어디갔지

매번 찾기 힘들어서 링크

http://msdn.microsoft.com/ko-kr/library/b0084kay(v=vs.100).aspx

프로젝트 규모가 조금 커지면 간혹 만나볼 수 있는 문제다.

주로 프로젝트 관리가 체계적이지 못하거나 잘못되어 발생하는 문제인데, 의외로 원인을 찾는데 시간이 조금 걸린다.

문제의 원인이 여럿이기 때문이지만, 크게 중요한 문제가 아니라서 생각되어 그냥 넘어가기도 한다.

하지만 개인적으로는 이 문제를 매 수행 시 개발자를 번거롭게 할 뿐 아니라 빌드의 정합성을 보장하지 못 하게 하는 문제로 판단한다.

지금까지 경험했던 원인은 다음과 같았는데,

1. 빌드 대상인 파일이 모종의 원인에 의하여 마지막 수정 시간이 현재 시간보다 꽤나 앞으로 설정된 경우

이 경우 obj 파일에 찍힌 timestamp 보다 cpp 파일의 수정 시간이 항상 크기 때문에 항상 빌드를 요청한다.

대개 시간과 얽힌 테스트를 할 때 시스템(OS) 시간을 조정하면서 작업을 하다보면 저도 모르게 발생함.

2. 실제 include 되어 사용하지만 프로젝트에는 포함되지 않은 파일이 있는 경우

대개 헤더파일의 경우가 많이 발생하는데 (유니티 빌드의 경우는 cpp도 발생함) 결국 timestamp 비교가

온전치 못해 발생한다.

또는 프로젝트에는 필터에 포함되어 있으나 실제 파일이 없는 경우도 동일하게 발생한다.

3. lib 파일의 timestamp 가 꼬여서 현재 시간보다 먼 미래로 가버렸을 때

꼬임의 이유야 몇 개 있겠지만 본질적으로 1번과 크게 다르지 않고 소스와는 달리 알아채기 어렵지 않다.

소스는 파일이 매우 많아서 찾기 어려울 수 있지만 lib 파일은 출력폴더의 특정 확장자만 뒤져보면 되기 때문

기억나지는 않지만 아마 몇 가지 사소한 원인이 더 있었다고 기억하는데, 오늘 새로운 원인을 접했다.

이것도 본질적으로는 그냥 프로젝트 관리 실수에다 timestamp 와 연관이 있는 문제여서 다른 원인들과 같은 범주다.

4. 프로젝트들의 PCH 파일명이 동일하여 뒷 프로젝트가 앞 프로젝트 PCH 를 덮어쓴 경우

이 원인을 찾기 위해 헤맸던 이유가, out of date 가 나는 양상이 기존 것들과 약간 차이가 있었기 때문인데,

clean and rebuild(build) => 성공

바로 리빌드 시 => 빌드 실패 (가장 이해하기 힘들었던 부분)

+ 빌드 => 리링킹(?)

+ 빌드 => 변경된 파일이 없으므로 빌드는 하지 않고 최후 lib 파일만 작성(timestamp 갱신)

+ 빌드 => 빌드 성공 (이후로는 빌드하지 않음)

웃기는 건 저 다섯 단계 사이에서 어느 시점에 실행하느냐에 따라 계속 out of date 가 나기도 하고

한 번만 더 빌드하기도 하고 한다는 점이다.

이런 랜덤한 양상을 겪고 나니 그 동안 희석되었던 PCH 에 대한 거부감이 다시 살짝 살아날 뻔했지만...

빌드 환경을 정리해주는 것으로 해결하였다.

http://stackoverflow.com/questions/10604243/call-stack-corruption-in-win32-vs2010-null-dereference-but-not-in-x64

자세한 해석은 귀찮으니 패스

결국 심볼이 잘못 연결된 문제

혹시 잊어먹을까 싶어 남겨둔다

파일, db, 네트워크 어떠한 기반 장치로부터인지에 관계 없이 데이터가 구축될 때 구조를 두 가지로 나눌 수 있을 것 같다.

(편의상 의미를 알아볼 수 있는 정도의 수도Pseudo 코드를 사용하였습니다. 그런 API 없는데요? 라고 하시면 곤란합니다 :-D)

1. 정형화Normalize된 데이터 구조라고 명명함. 혹은 목적형For Objective 스크립트라고 해도 되겠다(내 맘대로 명명했다).

이러한 데이터들은 코드에서 직접적인 행위를 통해 접근이 가능한 집단이다. 완전히 일반적인 언어를 만들고 있지 않는 한 데이터의 가공 및 처리 편의성을 위해 명확한 목적을 지닌 하드코딩 연결부가 존재하는데,

<server ip="192.168.0.1" port="15000" />

----------------------------------------------------------------

if(!LIB_NET::connect(xml["server"]["ip"], xml["server"]["port"]))

{

    cout << "접속 실패" << endl;

    return 1;

}

와 같은 예가 정형화된 데이터를 사용한 예다. 코드는 명확하게 xml 로 server 가 존재함(예외 처리가 추가될 수 있다고 하더라도)을 알고 있으며 "server" 라는 토큰은 명확히 어딘가로의 접속을 위해 사용되는 매개체가 된다. 조금 더 시간을 투자한다면 복잡한 일반화를 통해 코드에서 server 를 직접적으로 활용하여 connect 를 호출하지 않고 스크립트에 코드를 두며 해당 parser 를 제작하는 식으로 처리할 수도 있지만, 웬만큼 크지 않은 프로젝트 대부분에서 이는 낭비에 속할 것 같다.

정형화된 데이터는 개발자 입장에서 읽고 쓸 때 명쾌하며 빠른 개발 속도도 보장한다.

빠른 대신 독립성의 이점은 별로 없다. 개발자가 모두 관리한다고 가정했을 때 이런 어중간한 데이터의 분리보다는 차라리 코드로 한 몸에 있는 것이 훨씬 낫다.

즉, 장단점을 하나로 정리하자면,

독립성, 관리비용 : 동적 데이터 구조 > 목적형 구조 > 코드

위와 같은 어중간한 방법이 가장 좋은 효율을 내는 경우가 아이템 1,000개를 만들 때 제작자와 개발자가 다른 경우다. 이때 목적형 스크립트는 서로 간에 의사소통 비용을 적절히 조율할 수 있고 요구사항/제공사항을 명확하게 나열할 수 있어 데이터의 1차 관리로 많이 활용되는 것으로 보인다.

<name>    아이템 이름

<stat>      아이템을 착용했을 때 증가하는 스탯 정의부

<desc>    아이템 설명

와 같은 명세서가 있다고 할 때 제3작업자인 스크립터는 쉽고 빠르게 단순반복 작업이 가능하다.

그러나 이 방식의 치명적인 단점이 있는데, 재활용하는 스크립트의 수가 적은 곳에 사용되면 1회용 코드가 난무하게 된다는 것이다. 위의 connect 에 사용된 server 정보와 같은 예다.

2. 동적Dynamic 데이터 구조

위의 구조를 좀 더 발전시켰다, 라는 개념보다 반대의 구조를 찾는다고 하면 동적 데이터 구조다. 목적형 구조는 하드코딩을 발전시킨 개념으로 보이지 하드코딩과 반대 개념이라고 보여지진 않는다.

동적 데이터 구조는 말 그대로 언어의 처리 방식과 비슷하다. 데이터가 얼마나 들어올 지, 무슨 데이터가 들어올 지 정해져 있지 않기 때문에 정형화된 모양으로 읽어들일 수가 없다.

<color name="black" r=0 g=0 b=0 />

<color name="blue" r=0 g=0 b=255 />

<color name="yellow" r=0 g=255 b=255 />

위와 같은 데이터는 얼마나 중복으로 들어올 지 알 수 없다. 동적 데이터를 처리하는 구조가 더욱 복잡해지는 이유는, 무엇이 들어올 지도 잘 모르지만 "얼마나 중복이 생길 지"도 잘 모른다는 사실이 더욱 구조를 복잡하게 만든다. 단순히 위의 예를 처리하려고 해도 정형화된 아이템 구조에서는 필드 하나로 끝날 스크립트가 리스트 구조 등을 요구하게 된다.

동적 데이터 구조는 코드에서 명확하게 그 대상을 지칭할 수 없다는 문제를 항상 염두에 두어야할 것 같다. 그렇게 만들려고 한다면 못 할 것은 없겠지만, 스크립트로 만든 데이터들을 코드에서 임의대로 지칭하려면 고려해야할 것들이 꽤 많다. 생성 영역과 관리 영역domain 이 다르기 때문이다. 반면, 스크립트에서 만들었다면 스크립트에서 해당 구조를 지칭하는 것은 그리 어렵지 않다.

<text color="yellow">안녕하세요?</text>

만약 yellow 가 하나 더 추가되어 2개가 되었을 경우 이를 코드 영역에서 지칭하려면 수정 후 리빌드 과정이 필요하지만, 같은 스크립트 레이어에서 이를 지칭하기 위해선 그냥 식별자identifier 만 수정하면 된다. 이는 코드에서 만든 것을 스크립트에서 지칭하기 어려운 이유와도 일맥상통하는데, 결국 관리자가 다르다는 것이 이유인 것 같다.

그래도 사용을 하려고 들면 못 하진 않는다. 다만 다음과 같은 일이 생기면 껄끄러운 것은 나 뿐인가?

while( xml["color"].IsValid() )

colormap[xml["color"]["name"]] = RGB( xml["color"]["r"], xml["color"]["g"], xml["color"]["b"] );

------------------------------------------------------------------------------------------------

DrawLine(10, 10, 100, 100, colormap["black"]);

동적 스크립트로부터 얻은 데이터로부터 특정 키 값을 주어 라인을 그릴 때 색상 값을 취하고 있다. 아마 이 스크립트에는 다음과 같은 주석이 항상 따라다닐지도 모르겠다.

<color name="black" r=0 g=0 b=0 /> <!-- 코드에서 사용하고 있으니 변경 시에 개발자에게 문의하세요 -->

저런 경우가 많아지면 설계 상으로 꽤 곤란할 것 같은데, 나만 그렇게 느끼는 건지도 모르겠다.

위의 두 가지를 모두 지원하려니, 라이브러리가 DOM 형식과 반복자 형식을 항상 같이 지원해야 한다.

작금의 많은 XML 라이브러리들을 위시하여 스크립트 파서나 데이터 관리자 클래스들이 두 가지 모양을 모두 지원하는 이유에 대해 짧게 고찰해보았다.

DOM 형식이 코드도 보기 예뻐서 좋은데, 여러 모로 참 귀찮다. 으아아아아아!!!!!!!

결론은 한탄 뻘글

세 가지는 모두 비슷한 개념으로 여겨진다. 역할은 모두 인터페이스 교정에 사용되므로 공통점이 많은 이 세 가지 기법의 주요 차이점을 알아본다.

개인적으로 브릿지에 대한 오해가 약간 있었다.

Wrapper

Decorator 패턴의 주요 기법. 어떤 Component 의 기능을 그대로 놔두고 그 위에 기능을 얹는다(단순히 어댑터의 역할만 할 수도 있다).

어떤 Component 의 Wrapper Class 는 대상 Component 에 당연히 의존성Dependency이 강하다. 즉, Wrapper Class 만 따로 배포할 수는 없다는 뜻.

Bridge

Bridge 패턴으로도 사용됨. BUS, 공통 언어 같은 개념으로 보아도 무방할 듯. 대개의 경우 어댑터 역할을 할 때 설계 문서상으로는 암묵적으로 생략되는 경우가 많다고 함. 이는 임시적인 속성을 지니는 브릿지의 특성 상 그럴 듯하지만 구현과 설계의 괴리를 높이는 요소로 지적될 수 있을 듯.

Mediator

중재자 패턴은 링크 생략. 래퍼와 브릿지의 속성을 모두 지니고 있으며 두 패턴의 끝판왕 같은 기분으로 등장했다. 임시적인 녀석이 아니라 설계 단계에서도 명확하게 표현되는 특징적인 방식. 말하자면 서로 다른 라이브러리를 소통하게 하고 활용하고 꾸미기 위해 필수로 필요할 경우 해당 기능(래핑, 브릿지)을 모조리 모아 패키지로 구성했다고 생각할 수 있다.

게임의 비즈니스 로직에서 만약 중재자를 사용해야 한다면 엄청나게 슬픈 일이 될 것 같다. 엔진과 라이브러리 등의 밑단으로 잘 내려보자.

http://news.kukinews.com/article/view.asp?page=1&gCode=all&arcid=0001317814&code=11141100&cp=nv1

http://news.naver.com/main/read.nhn?mode=LSD&mid=sec&sid1=103&oid=001&aid=0003044402

http://thisisgame.com/board/view.php?id=372800&category=102&subcategory

http://www.gamechosun.co.kr/article/view.php?no=65399

http://www.3dmodelfree.com/

태생이 게을러 하질 못 하는 구나...

http://grammarist.com/usage/indexes-indices/

http://www.antimoon.com/forum/t2028.htm

http://www.kneoh.com/blog/2009/11/23/war-of-the-plural-suffixes-childs-vs-children/