어제 Steam에서 구매한 (발매 일은 8/16)^[1] 게임. 가벼운(?) 게임 플레이를 제공하는 아기자기한 2D 게임을 원하던 터라 주저 없이 구매. 19.99 (이하 USD)를 할인해서 14.99던가에 판매하더라.. 다만 OST 합본 팩을 안 산걸 조금 후회… OST를 따로 사니 추가로 $5쯤 추가로 들었다 Orz.

전형적인 2D, 쿼터 뷰, 핵&슬래시 장르라고나 할까…
게임 배경이 배경이니 좀 음울하긴 하지만 색조는 화사(?)한 편에 가깝다. 2D에서 좀 더 보여주기 쉬운 색감이랄까.

화면 중앙 왼쪽의 다리 난간이 좀 이상하게 보일 거다. 던전(?)에 들어가면 일부 지역만 보이고/이동가능하고, 특정 경로로 이동하면 화면에 타일들이 `떠오른다’. 저 다리 난간도 떠올라서 생기는 중(…). 적도 그렇게 생긴 화면에 턱 하고 나타나는 경우가 있어서 나름대로 긴장감 유지에 좋음.

정말 좋았던 부분은 음악 + 해설(?). 주요 등장 인물 중 한 명이 주인공의 행동을 서술하는 형식인데. 이게 음성으로 낮게 깔려 나옴. 일부 동작 – 예를 들어 새로 얻은 무기로 열심히 물건들을 부순다거나, 추락한다거나, … – 에 반응해서 그에 대한 설명을 하기도 한다. 시작하자마자 떨어지고 나서 나오는 해설에 잠시 멍해지더라(…).

무기가 다양하게 나오는데 – 망치, 바셰티, 창(할버드?), 활, 저격소총, 샷건, 박격포, …이건 뭐라 설명할 수 없는 로켓포(?), 화염방사기 등… – 이에 대한 업그레이드 재료 + 돈으로 이 무기에 추가 옵션을 달아서 게임 플레이가 꽤 변한다. 로켓포 최종 업그레이드 같은 경우 자동 추적(…)옵션이 달리기도. (무려 범위 무기에 궁극 무기라 한 방에 거의 다 잡는데…)

스크린 샷에서는 터렛에 맞아가며 박격포를 조준하는 장면. 무기마다 컨트롤이 확연히 다른 것도 재미요소. 활은 오래 겨냥하면 더 세게 나가고, 저격 소총은 오래 겨냥하면 더 정확히 나가고… 박격포는 더 오래 겨냥해야 멀리 나가고(…). 일부 근접 무기는 오래 누르면 던진다거나 하기도; 그리고 무기 마스터 던전도 존재한다. 각 무기에 맞는 특정 미션을 수행하면 수행 수준에 따라 보상을 달리 주는 곳(…).

사원이란 시스템으로 난이도를 조절하는 것도 괜찮았음. 사원에 특정 신상을 활성화하면 특정 조건의 몹이 특정 형태로 더 강해지거나 하는 게 생김 – 물론 돈과 경험치도 더 줍니다… 그래서 별도의 난이도 시스템이 외부에 preset으로 주어지는 게 아니라 유저가 알아서 잘(?) 하면 되는 구조… 요즘처럼 게임이 대중화 된 상태에선 난이도에 대해 호 불호가 극명하기 때문에 이건 꽤 괜찮은 선택으로 보인다.

보너스: Steam 판매용 버전에만 있다는 깨알 같은 포탈 패러디. 특수 스킬을 고를 수 있는데 Gel Canister란 녀석이 있다(…). 이거에 대한 NPC들의 반응도 깨알 같다(…). 일단 `Who Knows Where’클리어 할 때 매우 편하다.

한 번 클리어한 던전에 또 진입할 수가 없는데, 대신 `Who Knows Where’라는 모드가 있다. 게임이 전체적으로 3종류의 던전 배경이 있는데 그 각각에 대해 몬스터의 웨이브가 k번 반복되는 그런 반복 던전. 돈은 여기서 모으면 됩니다. 어차피 스토리를 이해하기 위해선 꼭 한 번 씩은 가야 하니…

마을은 왼쪽에 보이는 노란 아이콘 (검은 배경) 같은 상점(?)류가 총 6곳 있다. 처음엔 0곳이지만 스토리를 진행하다 보면 늘어나고, 각각이 지원하는 기능이 다름. 하지만 마을은 큰 의미가 없는 게임이라(…).

전체적으로 올해 나온 게임 중엔 가장 맘에 듬. 짧다는 것만 빼고(…). 시작해서 엔딩 볼 때 까지 실 플레이 시간은 5시간 미만?. 물론 두 번 엔딩 봐야 하고(…), 업적도 채워야 하니 그보다 더 걸리긴 함. 일단 가격도 그다지 비싸지 않으니 추천. 이 게임 분류가 인디긴 하지만 무려 HD 해상도도 지원하고 / 그래픽 / 사운드(!!) 모두 나무랄 곳이 없다.

PS. 여기서 잠시 스포일러 성 멘트 하나. 게임 엔딩 선택지가 commit or rollback이다. 이런 공돌이들 같으니(?).

1. XBox Live Arcade를 통해서는 지난 달에 발매되긴 했다.

관련 글:

1. 게임물 등급 심의 제도에 관한 생각
2. Project DarkStar 는 왜 실패했을까?
3. Tomb Raider: Underworld

현재 상황은 대략 망해가는 프로젝트인 것 같다.

마지막 stable version이 작년 12월에 릴리즈. 다운로드 수는 누적으로 70회;

마지막에 등록된 티켓(trac issue)이 올해 2월.

위키 최종 편집 시간이 6월^[1] 포럼에만 활동이 약간 있는 정도. 이 정도면 거의 활동없는 프로젝트라고 봐야하나?

(실질적으로) 사용하는 곳이 없고 / 개발 팀도 응집되지 않은 듯 하고 (커밋한 사람 수를 보면…) / 앞으로 비전이 있는 프로젝트는 못 될듯 하다.

1. 그 이전에 올해 들어와서 수정된 페이지가 6개 , 그리고 각각 1번씩만 수정

관련 글:

1. Project DarkStar 는 왜 실패했을까?
2. Project Dark Star 개발 중단 및 오픈 소스화

인증 샷(…)

다만 Tomb Raider 시리즈와는 약간 궤를 달리한다는 점이 기존 시리즈의 팬들은 호오가 좀 갈릴 듯.

Tomb Raider 시리즈에서 흔히 볼 수 있는 퍼즐 점프 – 특정 빈 틈을 타고 올라가거나, 굴뚝 점프(좁은 공간을 좌우로 디디면서 점프해 올라가는 것), 경사면을 타고 가다 점프 등등 – 는 전부 제거. 그냥 일반적인 점프만 있다. 그래도 자석(?)을 이용한 로프 액션은 남아있음…

다만 기본 무기(?)인 창의 역할이 이전 작의 막대기 류 기능을 좀 확대해서 퍼즐의 가짓수는 줄이고, 사용 방법은 늘린 느낌. 대충 밑에 나온 그림처럼 사용한다.

작아서 잘 안보이면 클릭해서 좀 더 큰 사진을 볼 것.

들고 다니는 창을 던지면 벽 등에 박힌다. 그리고 이 위에 올라가서 다시 점프를 하거나 로프 액션을 하거나 하는 게 가능. 혹은 점프 한 번에 갈 수 없는 거리에 있는 벽에 던진 다음, 그 창을 목표로 뛰거나, 벽에 다가 창을 여러 개 꽂고, 그 위를 연이어 점프하는 것도 됨. 다만 창이 박힌 채로 남아 있는 총 수에는 제한이 있다.

예전과 폭탄 사용 방식이 바뀌었다. 단순한 무기에 가깝던 것에서, 설치->폭파를 모두 Y키로 제어할 수 있게 변경 됨. 이걸로 쇠공을 점프 시키거나, 스위치를 원격으로 조작하거나 하는 일이 가능. 즉 스위치를 일단 켜고, 폭탄 설치 후, 원거리로 이동한 후(벽 뒤라거나?) 다시 스위치를 누르는게 가능; 이걸로 만들어진 퍼즐들이 많다…

근데 기존의 “길을 찾아가는 재미”는 상대적으로 덜하긴 하다. 생각할 방법의 수가 사실 상 창/자석 두 가지 뿐이라…

이 길 찾기의 재미를 줄이는 원인 중 다른 하나로 시점이 고정으로 바뀌었다. 위 캡처 화면에 나온 것처럼 일명 쿼터 뷰(?) 화면으로 게임이 계속 진행된다. 물론 지형에 따라서 DMC처럼 적당히 카메라가 바뀌긴 한다. 그래도 예전처럼 카메라 돌려가면서 확인할 수 없으니, 상대적으로 퍼즐 난이도가 떨어질 수 밖에 없고, 현장감도 많이 준다.

예전과는 달리(?) Relic이나 Artifact는 일정 조건을 달성하면 주는 형식이 되었다. 예전에 숨겨진 걸 찾는 형식이었지만, 대신 “특정 모양의 입구”를 갖는 미니 던전이 스테이지마다 1~2개 있고, 이 안에 들어가서 퍼즐을 풀면 특정 relic 혹은 artifact를 얻는 식으로 바뀜. 이건 찾는 재미는 줄었지만, 풀기만 하면 되니 편해서 좋긴 하더라(…). 그리고 스테이지에 흩어진 해골(10개)을 모두 모으면 주는 artifacts들도 있음…

그리고 많은 무기가 클리어 시간, 점수(…) 등으로 지급된다. 이건 스코어로 지급되는 무기 중에 사기 무기(마지막 스테이지의 Spear of Light 같은 것)이 있어서 좀 밸런스가 안 맞는 기분… 스코어가 제일 쉬운 조건 같은데 말이지(…)

싼 가격에서 추측 가능한 만큼 볼륨이 좀 작다 – 플레이시간 6.2시간 만에 엔딩 크레딧이 떴음. 다만 퍼즐이 상대적으로 쉽고 – 특히 리메이크 판이었던 Tomb Raider: Anniversary에 비하면 정말 – 전투의 잔 재미는 늘렸단 점에서 가볍게 즐기기는 좋았던 듯.

관련 글:

1. Tomb Raider: Underworld

지난 주 금요일에 도착한 – 실제로 받은 건 추석 쇠고 서울로 올라온 후인 월요일이지만 – Civilization V의 엔딩을 봤다. 기본 난이도(Chieftain)라서 전 문명 전멸(domination) 승리라도 큰 감흥이 없긴하지만; 일단 엔딩 본 걸 기념하는 의미에서 자축 포스팅.

문명의 새 씨리즈도 역시 기대를 저버리지 않고 잘 만들어졌다. 전작에서 여러가지 의미로 논란이었던 – 특히 확장팩인 BTS에서 외교 승리 등등… – 종교 부분은 아예 삭제 되었다. 대신 외교 관련되서 재밌는 요소로 도시 국가(citi state)가 등장한다. 충분히 우호적이 되면 이 도시들은 문화 값을 올려주거나, 군사 유닛을 제공해준다. 그리고 외교 승리의 요건인 UN 투표에서 동맹국에게 표를 주는 효과도 있다 – 인구당 표가 있었던 전작과 달리 국가별로 1표씩 행사함.

유닛을 쌓아서(…) 보내기만 하면 되는 – 물론 초반은 안그렇지만 – 전작들과는 달리, 유닛이 한 자리에 쌓이지 않고 + 헥스 타일이라 거리도 잘 봐야하고 + 원거리 유닛이 좀 더 좋아진 상황이라, 전투가 좀 더 재밌게 진행된다. 그리고 도시가 자체 방어력을 갖기 때문에, 초반에 야만인들한테 점령당하는 엄한 사태도 안 일어나서 좋더라(…).
대신 이것 때문에 전작보다 폭격기/해상 포격 가능한 전함류/시즈 유닛들이 훨씬 중요해졌다. 예전엔 초반 약간 동안만 투석기 써서 collateral damage로 도시 점령했는데(…), 이젠 후반까지 전함/폭격기 의존이 꽤 되더라;;

기술 개발 관련해서는 IV에서처럼 기술을 사고파는(…)게 안되고 공동 개발만 되서, 상대적으로 테크 트리 올라가는 속도는 느려졌다. 그래서 초반에 자기가 가려는 승리조건/상대방 조합을 잘 보고 테크 트리를 타야할 듯 함.

자원이 두 타입으로 구분되는걸 명시 해주는 것도 맘에 들더라. 전략 자원과 사치품을 구분한다. 이 중 전략 자원을 소모하는 유닛들 – 주로 로마 군단병;Legion(전작의 근위병;Praetorian에 해당)폭격기나 전함처럼 성능 좋은 애들 – 이 있고 (총 수량 중 고정된 몇 개를 쓴다), 특정 도시가 특정 사치품 자원(…)을 요구하는 일이 있기 때문에, 진행하는데 적당한 랜덤성이 부여되서 좋더라.

도시 별 행복도가 있던게, 문명 전체 행복도로 바뀌었다. 상대적으로 신경을 덜 쓰게 바꿔준 것 같다 — 이거 말고도 도시 관리 메뉴나 생산, 인구 배치 등등이 훨씬 편하게 진행된다. 예전에는 생산 팝업이나 연구 팝업 뜨면 딴거 할 수 있는게 없었는데, 이젠 modeless 로 왔다갔다 하면서 처리할 수 있어서 좋다. UI 개선은 정말 만족스러움…

덤으로 원더들의 성능이 대폭 하락했기 때문에(…), 원더만 믿고 가다간 망한다.(이제 나의 원더만 믿고 가는 Augustus 전략은 ㅠㅠ)

이제 난이도 올려서 좀 더 큰 맵(과연)을 해봐야할 듯. 하지만 CPU 업그레이드 전엔 좀 힘들까? intel core2duo (E6750) 쓰고 있는데, CPU가 100%를 치는 일이 너무 잦다; 4 문명(+8 도시 국가) 설정으로 해도 후반부 가면 Civ IV 14 문명 설정 수준으로 느리다;;

성능 문제랑 아직 밸런스가 안 맞는 부분이 좀 있어 보이는거 빼곤 매우 만족스럽다. 오늘은 리밋이 풀렸지만(…) 매일 제한 시간을 잘 지키면서 해야겠다(…).

관련 글:

1. 이번 가을 Civilization V가 온다!

“내 휴대폰에 있는 게임은 등급물 심의를 받았는가?”

그리고 이걸 가지고 몇 가지를 생각하다보면, 게임물을 사전 심의하는 행위가 위헌인지는 제쳐놓고도 – 적어도 나는 위헌이고 빨리 철폐 되어야 한다고 생각함 – 별로 잘 지켜지고 있지도 않은 제대론 사실을 깨닫게 되더라..

일단 내가 법학을 전공하거나 그에 관련된 일을 하고있지는 않기에 부정확한 내용이 있을 수 있는 점을 염두에 두고 읽어줍시다.

이야기를 풀어놓자면,일단 내 휴대폰은 2008년에 나온 삼성전자 SCH-W450 이다. 소위 Anycall이라고 부르는 피쳐폰… 여기에 게임이 딱 하나 들어있는데, T-Net 이란 홍콩 국적으로 보이는(적어도 DNS 등록지 주소는…) 회사에서 만든 게임이었다. 심지어 gamespot 리뷰 페이지가 있다.

근데 일단 “게임 산업 진흥에 관한 법률” 33조 1항에 따르면, 등급물 정보를 표시할 의무가 있다. 일단 제작사는 이거 위반한게 된다. 그리고 32조 1항의 6번째 부분,

제33조제1항 또는 제2항의 규정을 위반하여 등급 및 게임물내용정보 등의 표시사항을 표시하지 아니한 게임물 또는 게임물의 운영에 관한 정보를 표시하는 장치를 부착하지 아니한 게임물을 유통시키거나 이용에 제공하는 행위

에 따라 이걸 유통시키고 이용에 제공한 삼성전자와 SKT역시 불법 행위를 저지른 듯? 이거 같은 법 45조에 따라 2년 이하의 징역 혹은 2천만원 이하의 벌금에 해당한다…

그리고 게등위의 규정에 따르면, 휴대폰 같은 모바일 장치용 게임은 게임 초기 화면에 3초 이상 내용 정보를 표시해야 한다는데 그런거 없다(…).

일단 게등위 게시판으로 신고(..)해 놨는데 이게 어떻게 처리될지는 꽤나 궁굼…

아니 이게 중요한…건 아니고. 사실 이런 사례가 아마 비일비재 할 것이다. 개인이 만드는 플래시 게임이나, 학교/학원에서 만드는 컴퓨터 게임 – 게다가 많은 수가 공유/배포 될테니 이미 법률 위반… – 들이 잔뜩 있다. 이걸 게등위가 다 검열심의 한다는 건 물리적으로 불가능해 보인다.

이렇게 게임 자체의 이름을 걸고 유통되는 것만 있는가? 오늘 게등위 게시판에 올라온 질문 중 제일 걸작이었던 것은 “곰 플레이어에 이스터 에그로 게임이 들어있는데 심의 안된 불법아닌가?”하는 것이었다. 그리고 답변은 불법인 것 같으니 공문을 발송할 거라고…

내가 언급한 휴대폰 게임처럼, 한국에 유통되고 있는 수 많은 전자기기 – TV, DMB 플레이어 등 많은 수의 휴대용 미디어 플레이어, 전자 사전, … – 에 미니 게임 형식으로 많은 수의 게임이 포함되어 있다. 이걸 다 심의 하겠다고?

아마 물리적으로 불가능할 것이다. 게등위가 생기기 이전에 작성된 게임도 심의 받아야하는 게등위의 구조적 특성 상^[1] 아마 절대로 힘들 걸?

결국 합리적인 대책은 – 지금 국회에서 계류 중인 수준의 법이 아니라 – 전면적인 게임물 등급 심의 철폐 및 개별 게임 제작자(사) 혹은 이들의 연합체에서 스스로 등급을 부여하고, 이게 잘못된 등급이라면 사법처리하는 쪽이라고 생각한다. 실제로 북미(미국+캐나다)의 ESRB도 이런 식으로 동작한다. 게다가 국민 전반의 수준을 낮게 보지 않는다면, 이런 사전 심의 제도가 정말 의미 있는지 궁굼하다.

노골적으로 성적인 내용을 다루거나, 폭력성이 강한데 등급이 낮다면 처벌하면 될 일이다. 이걸 지켜보는 눈도 많을테고(YMCA라거나 YWCA라거나…이런 쪽 지켜(?)보는 종교 단체나 NGO들 많다…) 실제로 등급 판정에 불만(?)을 갖는건 업계 쪽이나 개인, 이런 단체들 사이에 자주 있는 일이기도 하고.

1. 위키 백과 내용을 토대로 썼음. 이건 사실 관계를 확인 해야함…

관련 글:

1. NDC 참관기: 게임 애셋 스트리밍 패치
2. NDC 참관기: 메이플스토리 개발스토리 – 더 잘되는 게임을 위한 라이브 코어 개발
3. Tomb Raider: Underworld

http://www.civilization5.com/

공개된 정보는 개략적인 발매일(올 가을)과 3 장의 스크린샷 뿐.

Updated: Steam 을 통해 공개된 정보에 따르면, 스팀 쪽으로는 2010년 9월 2일에 발매됨 — http://store.steampowered.com/app/50100/

공개된 스크린샷도 총 5개로 증가.

일단 공식 홈페이지를 통해 공개된 스샷 중 하나를 여기에도 올린다. 모든 권리는 Firaxis Games 에 있다. (All rights are reserved to Firaxis Games)

Civilization IV 보다 좀 더 “생동감이 더해진” 그래픽이 맘에 든다. 사실 나와주는 것만으로도 감사! ㅠㅠ

아마 Amazon.com 에선 해외 배송이 안될 듯 하지만, 모든 수단과 방법을 동원해서(…) 구매해야지 Orz

관련 글:

1. Civilization V: 문답무용

게임 서버는 대부분의 경우 “게임 제작 시작”과 동시에 작성되기 시작하는 경우는 거의 없다. 그래서 엔진을 사서 얻을 수 있는 이익 중 하나인 “시간 단축”으로 인한 효과가 적거나 없다. 물론 상대적으로 안정화된 코드 베이스를 빨리 얻을 수 있다는 이점은 존재 한다.

2. 게임 서버 구조에 대한 컨센서스가 없다.

게임 클라이언트는 각 모듈들 – 게임 로직, 렌더링, AI, … – 이 어느 정도 잘 분해되어 있다 – 적어도 그런 종류의 고민이 많이 끝난 상태다. 하지만 서버의 경우 게임 로직과 게임 서버 자체의 구동을 위한 아랫 단의 구분이 성능 저하없이 잘 이루어져 있는 경우가 드물다. 그래서 이런 서버용 게임 엔진은 시장에 나와 있는 예가 거의 없다. 내가 아는 범위 내에서는 DarkStar 프로젝트와, BigWorld Technology의 BigWorld Server 정도 밖에 없다. 그리고 이 범위 내에서, 상업적으로 충분한 성공을 거둔 게임(eg: 연간 1m USD 이상의 매출)은 없다.

그리고 각 프로젝트마다 실제 서버 구조 차이는 꽤나 컸다 – 내가 본 사용 서버 코드만 4개가 넘는데, 각자 다른 구조를 차용하고 있고, 기본적인 도구 수준에서나 같은 모습을 볼 수 있다. 하지만 DarkStar 는 일단 단일 구조로 나왔고, 커스터마이징이 가능하긴하지만 전체 구현 자체는 MMORPG 를 노린 것으로 보인다. 그렇기에 충분히 큰 시장을 가지지 못했다고 생각된다.

3. Java 사용의 문제

* Java GC가 신뢰할 정도로 빠른가? 분명히 Java는 서버 어플리케이션의 throughput 면에서는 만족할 만한 성능을 내고 있고, 이런 분야 – 각종 트랜잭션 기반 금융 업무, 웹 페이지 렌더링 … – 에서는 거대한 시장을 이끌고 있다.

하지만 반응 속도 면에서, 최소한 일정 수준 이상의 반응 속도가 필수적인 게임 서버에서도 이게 보장되는가?^[1]  게임 서버에 가장 많은 부하가 걸릴 시간 – 메모리가 가장 모자라서 GC가 강제화라도 되어야할 시점 – 에 GC가 “한꺼번에” 일어나면 반응성의 문제가 생길 수 밖에 없다.

이건 약간 샛길로 새는 얘긴데, GC 문제는 C#에서도 역시 나타날 수 있다. 최근 런칭한 마비노기 영웅전 서버가 어느 정도 예측가능한 주기(<1일)로 비정기 점검(…을 가장한 서버 셧다운 넘기기)하는게 GC문제가 아닐까 의심 중이다. GC로 메모리가 모자라면 아주 일정한 수순을 거쳐서 서버가 죽게 된다.

1. GC로 반응(지연) 시간 증가

2. 큐에 작업이 쌓임

3. 더욱더 메모리가 필요해져서 GC 가 필요해짐

4. 악순환 시작. 실제 작업 로드를 내리는데 CPU가 사용되는게 아니라 GC에 들어감

5. 서버 사망

* 예전에 Rica 가 언급했던 서버/클라이언트 코드 공유 문제. 코드 생성기로 “우회”할 수는 있지만, 서버/클라이언트 코드 공유로 시스템 전체에서 중복을 제거하는 것도 무시못할 부분인데, 이 부분에서는 Java로 게임 클라이언트를 짜는게 거의 불가능한 상황^[2] 을 생각하면 좀 암울하다.

* Java 나 C# 류의 언어는 확실히 생산성이 높다. http://www.codinghorror.com/blog/archives/000299.html 참고. 하지만 여기서 말하는 “Write his own” 항들을 게임 서버에서는 적어도 현재로는 필요하기에 사실상 다 하고 있다. 혹은 게임 서버/서버 용 라이브러리가 있거나..

4. Java 가 새 하드웨어 기술을 잘 따라잡고는 있는가?

적어도 게임 쪽에서는 아니라고 생각한다. 게임 서버는 그렇게 “현재의 기술”만 가지고 만들어지질 않는다. 한 예로 DarkStar 가 타겟으로 잡았던 MMO 시장의 한 게임을 들어보자. EVE Online 이라는 게임이 있는데, 이 게임의 서버 구조는 어느 정도 알려져 있다 (참조: EVE Online’s Server Model)

이 게임은 서버 군(혹은 shard 란 명칭으로 흔히 부르는 그것)이라는 개념이 없다. 모든 사용자는 “하나의 논리적인 서버”에 들어가는 형태다. 이걸 가능하게 한 기술은 InfiniBand 라고 부르는 네트웍 기술덕인데, CPU 버스 수준의 통신 속도+지연 시간을 보장하는 네트웍 장치다(다만 point-to-point). 이런 상대적으로 low-level 한 기술을 나오는 즉시 사용하기에는 Java 언어 자체의 변경 속도가 느리다. 그렇다고 이걸 C/C++ 로 만든 드라이버를 작성하고, 이걸 DarkStar 같은 녀석 밑단에 JNI 연결하기엔 배보다 배꼽이 커질 것 같다. 게다가 이쯤 되면 프로그래밍 모델이 우리가 흔히 보는 UMA가 아니라 NUMA 모델에 가까워진다. 그것도 non-cc NUMA… Java는 아직 NUMA 에서 GC 구현조차 실험적 상태(experimental) 이다.

또다른 예로, 32bit –> 64 bit 넘어가던 시절에 만들어진 모 게임이 있다. 이 게임의 경우 64bit 운영체제가 시장에 나올 즈음을 타겟팅해서 작성되었는데, 출시가 늦어지면서(…), .dll 의 메모리 모델이 좀 다른 점을 이용해서, 공유 메모리 비슷한 형태로(…) 32bit 응용 프로그램이 쓸 수 있는 물리 메모리보다 더 많은 물리 메모리를 쓸 수 있게 수정해서 출시했다고 한다.^[3] 이런 low-level 한 시스템 프로그래밍을 DarkStar 같은데 연동하는건 절대로 쉬운 일이 아닐 거다.

물론 Java 가 새 기술을 따라잡으면, Java codebase 전체가 쉽게 이동한다는 장점은 있다. 그렇지만 Java 의 현재 가장 큰 시장은 게임 서버가 아니기에, 이 쪽으로의 이동이 빠를리는 없다 – 적어도 현재 시점에선 그렇게 보인다.

5. 이식성 문제나 하드웨어 호환성 문제는 서버 프로그래밍에서는 큰 이슈가 아니다

타겟 하드웨어와 타겟 OS를 정해놓고 작업할 수 있기에, Java 의 장점이라는 이식성/호환성 문제는 아예 이슈거리가 되질 않는다. 오히려 타겟 하드웨어에 맞는 최적화를 “손 쉽게” 쓸 수 없는 Java 의 문제가 생긴다.

6. DarkStar 는 모든걸 만들어야 했다

DarkStar 의 실패 원인 중 하나는, DarkStar 의 “기능”으로 소개한 것 중 중요한 것들은 3rd party library로 있는 애들이 많다는 거다. 혹은, 시장이 될만한 MMOG 제작사들이 이미 인-하우스 툴이 갖춰졌을 시점이라는 것.

DISCLAIMER: 이 글은 rein 의 개인적인 견해이며, 소속 기관 어디와의 연관성도 없음을 밝혀둔다. 또한 이 글의 각 사실 관계에 관해서는 현재 알고 있는 바에만 기초했으며, 이걸 사용해서 얻어지는 직/간접적인 결과에 대해서는 rein은 아무런 책임이 없음을 밝힌다.

1. 물론 클라이언트에서 이런 반응 속도를 속이기 위한 각종 테크닉을 사용한다. 사용자의 입력에 대한 일단의 액션을 보여주고, 최종적인 결과 처리는 서버의 판단 후에 반영된다거나(이럼 RTT 만큼의 시간은 걸린다).
2. Java 용 게임 클라이언트 라이브러리의 수는 C++용 게임 클라이언트 라이브러리 수와 order-of-magnitude 의 차이가 난다. 질 적인 면에서는 그 성숙도에서 엄청난 차이가 날 게 틀림이 없음에야…
3. 이건 PAE 같은 CPU 확장 기능을 이용하면 32 bit OS 라도 16GiB~32GiB 수준의 메모리를 쓸 수 있어서 가능한 것

관련 글:

1. Project Dark Star 그 후는?
2. Project Dark Star 개발 중단 및 오픈 소스화
3. C++ 객체에 (흔히) Initialize/Finalize 같은 함수가 있는 이유

Project Dark Star 의 포럼 공지에 따르면,

Today is a difficult day for all of us associated with Project Darkstar. Regretfully, we must inform our community members that Sun Labs engineering effort is no longer being applied to Darkstar development. You will hear from the individual engineers about what this means for them, but the organized lab project will not be moving forward.

One of the reasons that we developed Project Darkstar as an open source project was to allow the community to continue if the research objectives of the core team were changed. We will be maintaining the source repositories and the projectdarkstar.com site for as long as we can, but we are also investigating other homes for both the code and the supporting content.

As interesting as the technology development has been with Project Darkstar, I must say that I found the building of the community around that technology one of the most satisfying and interesting experiences of my professional life. I hope that the community will continue, and personally plan on at least observing and perhaps contributing (as an individual) to that continuation. Thank you all, and my very best wishes going forward. To the core team, I can only say that it was an honor and a privileged to work with you on this project and this technology.

간략히 요약하자면, “썬 에서는 더 이상 다크스타에 자원을 투입하지 않을 예정. 공시적인 개발은 더 없다. 웹 사이트와 소스 저장소는 가능한 유지 할 것이며, 코드와 지원 자료를 위한 공간을 찾는 중이다.”.

예전에 이 프로젝트 다크스타의 테크 데모를 봤지만 그 때 느낌으로도 “이거 망하겠네”였는데, 약 2년 반 정도 지난 지금, 프로젝트가 내려지는걸 보고있으니 기분이 좀 묘하긴하다.

내가 생각하는 실패 이유에 관해선 곧 글을 하나 더 써보기로 하겠다.

ps. 프로젝트 다크스타의 github 이름은 red-dwarf. Dark star 가 (겨우) red-dwarf가 되어버리다니… 참 의미심장하다?

관련 글:

1. Project Dark Star 그 후는?
2. Project DarkStar 는 왜 실패했을까?
3. 리뷰: Coders at Work

작년 봄의 Tomb Raider: Anniversary 에 이어 이 컴에선 두 개의 팩키지를 클리어하게 되었다.

…

일단 전작과 비교를 하자면,

• 전반적으로 난이도가 쉬워졌다. 특히 마지막 스테이지에서 Natla 에게 갈 때 해야했던 점프 4종 세트^[1] 의 악몽을 생각해보면, Underworld 의 점프는 적당한 재미를 주면서도 “너무한다” 싶은 면이 없어서 좋았다
• 전투의 비중이 대폭 축소. Anniversary 에서는 개략적으로 “플랫폼 게임스러운 스테이지 진행” -> “보스전” 형태의 진행이었는데, 이번 게임은 그런 “보스전” 느낌의 뭔가는 없다. 퍼즐/점프에 집중하는 느낌.
• 수중 스테이지 비중의 대폭 증가
• 전체적으로 훨씬 움울한 분위기. 아무래도 배경이 “사후세계” 신화류가 되다보니 어쩔 수 없는듯?
• 바이크를 타고 진행하는 부분이 많다

정도?

일단 수중 스테이지 비중이 늘어난 덕에 “헤맬만한 부분”이 증가했다. 아무래도 물 속이라 그런지, 탐색해야할 공간이 무지 많다 -_-;

전투의 비중이 줄어든 탓에 싫어할만한 사람도 있었지만, 아무래도 그런 류보다 퍼즐에 재미를 느끼는 나 같은 플레이어들은 반길만한 일이라고 생각한다. 다만 최종장즈음부터 묘르닐 가지고 노는건 너무 재밌었음. 신도 죽이는 망치라 그런지 대학살 모드가 된다(……)

그렇지만 전체적으로 봐서 플레이 시간이 너무 짧다. 대략 12~16시간 쯤이려나? “실패할 만한 점프”가 적고, 보스전이 없어서 그런지 볼륨감은 전작과 크게 다를 바 없는 듯 하지만, “진행을 늦추는” 역할을 할만한게 없어서 그런듯하다. 다만 바이크타고 진행하는 부분은 딱히 재미가 없었음. 괜히 의미가 적은 공간만 늘어났단 기분이 드는데;;;

총평은 별 5개 만점 기준으로 3.5개란 느낌. 꼭 해봐야할 게임은 아니지만 시간 여유가 있으면 / 혹은 라라 크로프트의 팬이라면 해볼법한 게임.

1. 사실 벽타기 + 줄타기 + 봉 잡고 점프 등등 -_-;;

관련 글:

1. 리뷰: Bastion
2. 게임물 등급 심의 제도에 관한 생각
3. Project DarkStar 는 왜 실패했을까?

잠실/삼성역<->KINTEX 셔틀을 타고 갔다왔는데, 잠실에서 사람을 왕창 태우고 와서 삼성역에서 못타는 경우도 생기는 “!@#$%”한 경우 -_-a KINTEX가 멀긴 하더라. 근데 정말 관람객을 끌여들이고 싶다면 비싸도 COEX에서 해야하는거 아니냐 -_-;;

대략 10시 좀 넘어서 출발해서 11~3시? 경까지 참관하고 저녁 먹고 서울로 돌아오니 6:30쯤되더라.

참가한 업체가 대형 업체 위주로 새면 입구부터 시작해서 대략 한빛, NC, Nexon, 한게임, 피망, … 이 있었던 듯 싶다.
다만 플레이 할만한 상태의 게임을 가장 많이 내놓은 곳은 넥슨 부스 였던 기분. 단순히 디스플레이나 이벤트(?) 위주로 흐르는 부스가 많다는 사실이 참 아쉬웠음. 안 그래도 관심가는 게임이 적은 마당에 최소한의 기회인 “게임 플레이” 마저 제한하면 뭐 어쩌자는건지 -_-;;

전체적으로 스피커 볼륨 — 특히 되도않는 경품 이벤트 한다고 — 이 무진장 커서 귀 아프다. 전반적인 방송/음원에 대한 규제가 필요하다고 생각함. 이건 관람은 둘째치고 귀 막고 다니는게 일임…

일단 NC 부스 들려서 아이온…은 하고있으니 통과하고, 러브비트는 줄이 너무 길어서 포기. 게임 성향 덕인지 여성분/여고생들이 꽤나 긴 줄을 이루고 있었음. 옆의 넥슨 부스에가서 카바티나 스토리를 줄서서 플레이하고, 허스키 익스프레스를 플레이 했음.

카바티나 스토리는 모종의 얘기를 들었던거랑 달라서 놀랬지만 -_-a, 뭐 메이플 스토리 3D화 같은 느낌으로 플레이. 다만 액션 or 액션 RPG 같은 느낌이었는데 회피가 없는 점은 감점. 전체적인 동작이 과장되서 알아보기 좋고, 튜토리얼에서 키 조작을 알려주는 점은 좋더라. 참고해야. + 나눠주는 인형의 이름이 참 재밌어서 후후후후^[1] 

허스키 익스프레스는 “귀엽긴 한데, 뭐 어쩌라고” 의 느낌. 다만 클리어 상품으로 주는 허스키 모자가 귀여움(야)

전반적으로 느낀 아쉬움을 말하자면,

• 왜 서비스 중인 게임이나(몬스터 헌터/러브비트), 베타 플레이가 가능한 게임을 내놓는가 (Aion, 프리우스)
• 동영상만 틀어주는 센스는 뭐냐 (이런저런 많은 게임들)
• 중소 부스는 그냥 겉치레냐 (뭔가 이것저것 있긴한데 플레이도 못해보고 부스에 있는 스태프들도 반응이 미적지근)
• 너무 이벤트 위주로 흐른다. 게임을 플레이해볼 기회는?

정도. 귀 아픈건 앞에서 말했으니 넘어가자.

1. 인형의 이름이 ‘탱이”였다.

관련 글:

1. 리뷰: Bastion
2. 게임물 등급 심의 제도에 관한 생각
3. Project DarkStar 는 왜 실패했을까?

어제 저녁에 집에가서 세수를 하고보니, 뭔가 오른쪽 눈이 아랫쪽 반만 아주 붉게 충혈되어서, 출근하고나서 말하고 안과에 다녀왔다. (회사 근방 안과들은 빨라야 9:30에 문을 염)

의사: 알러지 있으신가요? 비염이라거나 …
rein: 냅더적
의사: 눈에 상처가 좀 났네요. 너무 비비지 마세요. (눈을 들여다보며)
rien: orz

…

스테로이드제 (안약) 하나랑 점안액(인공눈물?) 하나를 처방받고 왔음.

가끔 봄/가을에 눈이 2~3일 충혈되곤 했는데 이것도 알러지였나 -_-;;

Aion 오픈 직전

오늘부터 캐릭터 생성이 된다길래, 1섭으로 보이는 시엘 서버에 캐릭 하나 생성. 근데 말이죠(…) 이거 뭔가 WoW에서 도냥풀을 보던걸 다시 보게될 듯한 기분? 정찰자 인구가 어딜 가나 제일 많네 -_-;; (와우의 도/냥에 해당하는 살성/궁성이 정찰자가 전직한 직업…)

여튼 이런 애를 만들었음. 라인(rein)으로 만들까 했는데 없길레 뭐 할까 하다가 모 소설에 나오는 캐릭터 이름을… 

On The Border

회사 근처에 생겼길래 (도심 공항 터미널 지하쯤; 지상에서 바로 내려가는 계단도 있긴하지만 계단이 싫으면 도심공항터미널의 에스컬레이터로 ㄱㄱ) 가봤음.

아웃뷁에서 부쉬맨 브레드를 주는 것처럼 나초가 나온다(…). 대충 멕시코 스타일의 그릴요리들이 나오는데 적당한 가격의 마가리타(4900~6900쯤? 근데 스쿠너로 주문하면 대략 540ml 인가라 양이 많음…)랑 같이 먹으니 괜찮더군.
다만 1인분 치곤 요리 1개의 양이 많은편.

여튼 이 생각이 떠오르게 만든 오늘자 xkcd.com의 코믹스트립(CCL 2.5 license – Attribution / Non-commercial)

나는 분명히 문명(Civilization) 씨리즈라거나 WoW 같은 MMO, 그리고 에이스 컴뱃 같은 슈팅/액션 게임에 열광한다. 사실 그런 게임을 즐기기 위해 그 시기에 꽤나 하이엔드에 속할 CPU/RAM/GPU^[1] 를 사놓고 쓰고 있기도 하다.

하지만 가끔 … 보다는 한참 자주 일어나는 일 중 하나가 바로 “간단한 플래쉬 게임”에 빠져서 놀고 있는 것. 라프 코스터의 책 “재미이론“에서 말하는 것처럼, “배우는 재미”, “행동에 대한 보상”만 제공된다면 충분히 즐겁게 즐길 수 있는 것 같다.

현란한 그래픽이나 유려한 무비 혹은 충분히 긴 스토리라인이 꼭 필요한 건 아니다. 단순하기 그지 없는 “과로사” 같은 플래쉬 게임에 빠지면 10분 20분 그게 뭔가요(…)이니까. 
그런 것들이 게임의 재미를 “배가” 시켜줄 수는 있지만 — Gears of War가 Doom 오리지널 수준의 그래픽 수준이었다면 난 플레이 안 할 듯 싶다? – 그 자체가 게임의 재미가 되는 것은 아니니까. 문명 IV 같은 녀석을 들여다보면 게임브리오 그래픽을 다 뽑아냈다고는 죽었다 깨도 말 못할 수준이지만, 내가 문명을 플레이하면서 하얗게 지새운 밤의 숫자는(…)

새로운 입력 장치가 생긴다고 꼭 재밌는 것은 아니지만 잘 쓰면 엄청 재밌어 진다 — 예를 들어 wii의 위모트를 잘 쓴 wii sports나 2008 올림픽 게임(마리오+소닉의) 은 꽤나 재밌다. 반대로 이런 입력 장치에 치중해서 실패하는 NDS 게임들은 분명히 보인다(…). 즉 기술 발달만으로 재미를 주는데는 문제가 있다는 것. 그래픽이 좋으면 즐겁긴하겠지만 그림만 보고 게임을 하는 것도 아니니(…)

Updated:

뭔가 쓰다 만 글이 되버렸는데(…), 플래쉬 게임들이 재밌다고 느껴지는 이유는 화려한 그래픽이라거나 사운드 혹은 긴 스토리라인을 가진 경우는 없고^[2] , “어떤 배움”을 간단한 방식으로 제공하는데도 — 타워 디펜스라거나 과로사를 생각해보자 — 보상이 명확하고^[3] 몰입하는데 어려움이 없다는게 아닐까.

말 그대로 “게임 본연의 재미”를 준다는 느낌.

게임 커뮤니티 일부에서는 “게임 개발의 agile-development”는 SW 개발이 아니라, “매일 매일 ‘재미의 증가’를 가져와야 한다”고 말하기도 한다. 그 말이 무척 솔깃하게 들리는구나 -_-a

1. 물론 앞의 2가지는 “컴파일이 빨라요!”란 변명으로 구입하고 있긴하지만 마지막 하나는(…)
2. 있긴한데 그게 플래쉬 게임의 메인 스트림은 아니다
3. 이 경우엔 단순히 다음 스테이지라거나 등등

관련 글:

1. NDC 참관기: 게임 애셋 스트리밍 패치
2. NDC 참관기: 메이플스토리 개발스토리 – 더 잘되는 게임을 위한 라이브 코어 개발
3. 게임물 등급 심의 제도에 관한 생각

예전에 나온다는 걸 듣고 기뻐했었는데 이런걸 까먹기도 하는군. 역시 아마존에선 직접배송이 안되는군 orz

발견했으니, 참새가 방앗간을 그냥 지나가지 못하고 주문했음. 어서 오길 기다려야.

+ 하지만 플레이는 언제?

관련 글:

1. Civilization V: 문답무용
2. 이번 가을 Civilization V가 온다!

decadence in the rye의 “핀치의 부리”를 통해 간만에 읽은 셜록 홈즈의 구절들.

“Eliminate all other factors, and the one which remains must be the truth.” (4개의 서명, 1장)^[1]

“How often have I said to you that when you have eliminated the impossible, whatever remains, however improbable, must be the truth?” (4개의 서명, 6장)^[2]

“Data! Data! Data!” he cried impatiently. “I can’t make bricks without clay.” (너도밤나무 집의 모험)^[3]

“It is impossible as I state it, and therefore I must in some respect have stated it wrong.” (프라이어리 학교의 모험)^[4]

뭔가 오역과 비문이 난무하는 번역이 있지만 참아주실듯(…).

디버깅의 많은 경우,

• 불가능한 경우를 제거하고 — 물론 그에 대한 증명/데이터가 있어야하고
• 가능한 경우의 수를 모두 제거하고 — delta debugging?
• 재현 가능한 증거(=데이터)가 있어야하고 — 반복적인 재현이 되야 뭘 하던가(…)
• 가정을 의심할 줄 알아야

한다. 그런 면에서 “추리”와 참 닮아 있다.

ps. 비슷하게 의학(오락) 드라마 닥터 하우스도 비슷한 느낌을 잔뜩 준다. 다만 프로그램에나 가할 법한 실험을 인간에게 한다는게 좀 무섭지만[...]

1. 모든 나머지 요소를 제외하고 나면, 남은 하나가 진실이다.
2. 모든 불가능한 것을 제외하고 나면, 남은 하나가 아무리 일어날법 하지 않아도 그게 진실이라고 내가 몇 번이나 말했었지?
3. 데이터! 데이터! 데이터! 그가 참을성없이 외쳤다. 진흙도 없이 벽돌을 만들 순 없다고!
4. 내가 말한대로 이건 불가능해. 그러니 내가 뭔가 잘못 “말한” 것임에 틀림없어

관련 글:

1. 리뷰: Driving Technical Change
2. 리뷰: 프로그래머가 몰랐던 멀티코어 CPU 이야기
3. 리뷰: Clean Code

개략적인 내용은 서버 응용 — 특히 DBMS와 연동되는 다수의 요청과 그에 대한 transaction을 사용하는 구조 — 에서는 동시성을 위해서 하는 일이,

• 대다수의 작업이 transaction 기반
• 동시성 자체가 DBMS 단에서 처리됨
• DBMS 자체의 동시성 처리는 많은 경우 row lock -> page lock or index lock -> table lock 같은 잘 알려진 알고리즘으로 해결됨

과 같은 이유로 이미 풀려있는 문제에 가깝다라는 것. 그리고 서버용 동시성 응용도 rocket science ^[1] 지만, 충분한 수의 전문가 집단이 존재하고, 성공적인 방식으로 여러 번 완성시킬 수 있다는 것 — 그러니까 풀린 문제랄까.

반대로 요즘 issue가 되고 있는 클라이언트(=일반 응용프로그램) 에서의 동시성이란 것은 많이 다르다라는게 글의 요지.

거의 위에서 설명된 것과는 정반대로,

• 처리해야할 일 자체가 근본적으로 동시성에 적합하지 않아서 구조를 해집고 다녀야하고
• 프로그램에서 사용될 객체들이 그다지 동시성에 적합하지 않아서 (cf. DBMS)
• 명시적인 lock 기반이라 이런 저런 문제에 쉽게 노출된다는 것

그래서 현재의 상태는 V2 로켓을 만들던 시절의 로켓과학(rocket science)이고, 이를 좀 벗어나서 OpenMP나 intel TBB같이 좀 더 나은 상태를 거치고 있고, Task Parallel Library나 PLINQ 같은 훨씬 근대적인 라이브러리들이 생겨난다는 것.

+ 10월의 C++ Standard Comitee 쪽에서는 TPL이나 PLINQ 수준의 C++ native support에 관한 얘기가 있을 것이라함

글에서 설명된 것처럼 transaction-like 구조가 C++에 추가되거나 할지도 모르겠음.

여튼 간단한 결론: 잘 정규화되지 않는 클라이언트 쪽의 동시성(concurrent) 프로그래밍은 쉽지 않다.

개인적인 결론: 아예 Erlang을 쓰는 것은 어떻게 보면 무리 같고 (통신을 정의하는게 쉽지 않아 보임), 앗싸리 PLINQ 수준의 어느 정도 일반적인 동시성 구문이 생겨나야할 것 같다랄까.

1. 복잡하고 어렵고 고도의 기술/지능이 요구되는 분야를 가리키는 말. 비슷한 방식으로 ‘brain surgery’같은 것도 있음. from Wikipedia

관련 글:

1. 엄한 곳에서 뒤통수 얻어 맞기
2. C++ 0x 위에 트랜잭션 구문 만들기

보도 자료는 Firaxis 홈페이지에는 2K로의 링크만 있고, 2K의 링크는 여기.

1994년에 Microprose를 통해 발표된 게임 Colonization의 리뉴얼 버젼인데, 문명 IV에 사용된 엔진을 바탕으로 새롭게 만들었다고 한다 — 사실 문명 IV의 거의 다 고쳐쓸 수 있는 스크립트 엔진을 생각하면 누군가 이걸 유저 MOD로 안만든게 살짝 신기하지만(…)

이번 확팩에서 제일 멋진 점(?)은,

Colonization does not require the original Civilization IV product in order to be played.

Civ IV 오리지널 디스크가 없어도 플레이할 수 있다는 것. 문명 IV의 각 확장팩들이 원래 따로따로 설치할 수 있긴 했어도 — 즉 Warlord를 구입하지 않고도 오리지널만 있으면 BTS를 플레이할 수 있었음 — 이 정도는 아니었는데(…), 3번째 확장팩이라 그런지 좀 특이하구나[...]

근데 문명 확장팩이 계속 나오는 것도 좋은데 콘솔/휴대기기용으로 발매되는 Civilization: Revolution 말고도 PC용으로 발매되는 정통 후계자도 하나 나와주면 안될까 Orz

1. 2005년 올해의 게임이기도함
2. Warlord, Beyond the Sword 라는 2개의 확장팩이 각각 2006, 2007년에 나왔다

관련 글:

1. Civilization V: 문답무용
2. 게임물 등급 심의 제도에 관한 생각
3. 이번 가을 Civilization V가 온다!

8:20분쯤 과천에 모여서 출발했는데, 우리같은 미친 놈들이 많은지 가는 거리 절반쯤 막혔음 상당히 막혀서 12시 반쯤에야 주문진 도착. …하고 적당히 술마시고 일어나서 점심으로 회 + 매운탕을 먹고 그냥 돌아오진 못했고, 강원랜드를 갔다왔음.

내 개인적으로는 로또라거나 하는 류의 복권류, 그리고 카지노의 여러 도박류를 상당히 싫어하고 믿지 않는다 — 아주 기초적인 수준의 확률/통계 지식으로도 그 것들의 기대값은 음수(=내 손해)거든 -_-a^[1]

카지노에서 카지노가 플레이어에 대해서 확률/통계적으로 얻을 수 있는 이익의 비율을 house edge (혹은 house advantage) 라고 부르는데, 제일 간단한 예로,

룰렛 게임에는 36개의 칸이 있고, 두 개의 0 (0과 00)이 있다. R/B 혹은 홀/짝을 고른다고 하면 이길 확률은 18/38, 받을 돈의 기대값은 36/38이 된다.

처럼 카지노는 2/38 씩의 이익을 매 베팅/사람 마다 얻게 된다 — from wikipedia: Gaming Mathematics 중에서

내가 아는 게임 중 플레이어가 그나마 가장 높은 확률로 이길 수 있는게 블랙잭인데, 집에와서 검색해보니 플레이어에게 불리하지 않은 룰을 쓰고 플레이어가 최적전략을 구사할 경우 약 0.5% 미만의 house edge가 있다고 한다 — 즉 그나마도 카지노가 계속 돈을 버는 구조(…).

비슷하게 내가 지속적으로 해도 받을 돈의 기대값이 음수인(…) 게임 — 그러니까 카지노의 여러 도박이나 로또 등의 복권류 — 을 내가 할 이유를 못 찾겠더라고 -_-a
그러니 도박이 “게임으로써 즐길 수 있는 사람”이 아닌 누군가들께서는 수학공부나 다시 하시면 되겠다(…)라는 것인데;

우리가 사는 사회에서도 이런 류의 비용들 — 즉 이익을 준다고 비용을 지불하게 하지만, 실제적으로 계산해보면 지속적인 손해인 것 — 을 찾아서 열심히 제거해 버려야하지 않을까. 누구도 House^[2] 가 아닌 것들이 잔뜩 있을테니…

1. 하지만 랜덤신의 가호와 감자의 운으로 일행은(…) 5천원 이익보고 나왔다.
2. 뒤에서 이익을 얻을 사람

관련 글:

1. 게임물 등급 심의 제도에 관한 생각
2. Tomb Raider: Underworld

신문 –일명 주요 일간지 중 앞의 세 개 — 요즘 봐봐야 기분이 나쁘긴 매일반. 비슷한 이유로 부쉬 카운트다운과 이명박 카운트다운도 : 둘 다 내 정치 성향과는 극과 극이지 -_-

그리고 Civilization IV, Civilization IV, Civilization IV, Civilization IV …

어제 잠자리에 든 시간 : 새벽 3시

일어난 시간 : 오전 7:20분 경

출근한 시간 : 오전 8:30분

잠을 5시간 이하로 잤더니 무지 피곤하네 -_-;;; 역시 주말도 아닌 밤에 문명을 함부로 손대면 Orz

관련 글:

1. 이번 가을 Civilization V가 온다!

원제로

N. Baughman, M. Liberatore and B. Levine, “Cheat-Proof Playout for Centralized and Peer-to-Peer Gaming,” Feb. 2007, IEEE/ACM Transactions on Networking

실제로는 2001년 INFOCOM에도 냈던 논문의 연장선인데^[2] , 다루는 내용은 크게 세가지.

현존하는 동기화 방식의 문제

흔히 사용하게 되는 lock-step (frame-locking)과 bucket syncrhonization에 대해서 초점을 맞추고 얘기하고 있다.

락스텝 동기화의 경우 기본적으로,

1. 프레임이 시작
2. 개별 사용자가 프레임 패킷을 전송
3. 모든 사용자의 프레임 패킷이 도착하면 새 프레임 시작

이라는 구존데, 특정 사용자가 2를 하지 않고 버티다가 다른 모든 사용자의 프레임 패킷을 받고 , 그걸 토대로 자신이 유리하게 움직이는 look-ahead 치팅이 가능해진다. (대신 버킷 동기화의 치팅은 피할 수 있다)

반대로 버킷 동기화의 경우

1. 버킷의 시작
2. 버킷 시간 동안(고정 길이 혹은 가변 길이) 패킷을 받는다
3. 버킷 끝에서 받은 동작들을 수행

이런 식으로 도는데, 필연적으로(..) 데드 리커닝이 필요하고, 이를 속이는 치팅 — 업데이트 패킷을 안보내고 버티다가 자신이 유리해지게 조작하고 보내는 것 — 이 가능해진다.

치팅이 불가능한 동기화와 증명

치팅이 불가능하다는 동기화 방법으로 2-phase로 동작하는 lock-step을 제시한다.

1. Phase 1 – frame packet의 1-way hash 함수 버젼을 보낸다^[3]
2. Phase 2 – 실제로 frame packet 전송

각각의 phase에 대해서 lock-step 동기화가 이루어지면 2에서 보내는 패킷을 속이는 — 즉 다른 사람 패킷을 보고 행동을 취하는 – 행위가 불가능해진다는 것

성능 평가

사실 저 방법은 딜레이가 커지기 때문에, 저자는 월드 전체를 쪼개고 — MMORPG에서 흔히 취하는 셀 방식 — 각각의 셀에 대해 근처에 다른 유저가 있을 때만 2-phased lock-step을 쓰자! 라는 것 + 비동기 lock-step이라고 저자가 부르는 일종의 분산 clock을 쓰는 방식에 대한 제안과 시뮬레이션.

물론 성능이야 조금 올라가겠지.  -_-;; 그렇지만 기본적으로 성능이 떨어질 다수의 사용자가 있는 상황에서는 비동기 클락이 큰 의미가 없기 쉽상이고, 그 상황에서 평균치도 아니고 제일 느린 사용자에 끌려갈 수 밖에 없는 lock-step이란건 -_-;;

논문 전체에 대한 내 평가는,

• 동기화 방법을 정리하고, 각각의 취약점을 설명해준 것은 좋다
• 2-phased lock-step 자체도 의미는 있다 — 치팅을 피하는 것
• 하지만 기본적으로 딜레이가 커지는 lock-step의 문제가 2배로 커진다
• 셀로 쪼개고 비동기 lock-step을 해도 근처에 있는 사람 중 가장 딜레이가 큰 사용자의 딜레이에 영향을 받고, 그 영향이 2배가 된다

라는 점 때문에, 높은 점수를 주기는 좀 힘들었다. 뭐 일단은 제목가 저널에 낚였으니 -_-a

그리고 상대적으로 널리 쓰이는 방법 중 하나인 event-locking에 대한 소개가 없는 것도 좀 감점(…). 근데 이 방법은 시간 속이기라는 잘 알려진 치팅이 있긴하니까…

여튼 동기화 방식 최근에 정리하면서 느낀건 세상엔 쉬운일이 없다…

1. INFOCOM 2001 논문은 웹 상으로 공개되어 있으며 IEEE/ACM Trans. on Net. 2007년 2월 분량은 ACM portal (유료 혹은 가입된 곳에서 사용 가능) 에서 볼 수 있다
2. 참고로 IEEE/ACM Transcactions on Networking은 네트웍 쪽 최고의 저널, INFOCOM은 거의 저널급(..) 논문들이 자주나오는 상당히 급수가 높은(…) 컨퍼런스다. 무슨 컨퍼런스 페이퍼가 11장이야 Orz
3. 해슁된 값을 전송한단 소리. collision을 계산할 만큼 시간이 없으니 md5나 그 이전 variant들을 써도 될듯

관련 글:

1. 엄한 곳에서 뒤통수 얻어 맞기
2. 리뷰: Clean Code

평소에 프로그래밍할 때 C++/python/lua 정도를 쓰고 설정 같은 걸 lua/xml로 빼는 형식으로 주로 작업했었는데 이번에 해야했던 일은 서버는 (native) C++로, 클라이언트는 ActionScript 2.0으로 동작하는 녀석을 수정하는 일이었다.

내게 주어진 수정범위는 서버 전체 — 인터페이스와 동작 구조만 유지하는 범위에서 — 그리고 클라이언트가 통신에 사용하는 일부 코드였다. 그리고 주어진 자료는 프로토콜 문서와 서버 코드, 클라이언트의…껍데기쯤 되는 소켓 통신 부분^[1]

팀에서 간단한 회의를 거친 결과 서버의 전면 개보수 + 클라이언트 소켓 부분을 서버에 맞게 수정하되 프로토콜은 유지한다라는 것. 그리고 이 프로젝트는 나 혼자 진행하게 되었다. 여튼 내가 생각하기에 내 문제였던 녀석들을 요약해보고자 한다.

의사 소통 문제

프로젝트 진행 초기에 내가 내렸던 의사 결정 중에 하나가 일종의 primary key비슷한 역할을 하는 변수의 타입을 변경한 것 이었는데 — 나는 원래 프로젝트 팀에서 내린 결정이 일종의 defect라고 생각했다 — 이게 기존 legacy 코드^[2] 랑 문제가 생겨서 내 작업을 일정 부분 수정해야 했다.

아무래도 이런건 내가 의사소통을 잘못했다고 밖엔…

이종 언어 문제

처음 겪었던 문제, 그리고 끝까지 발목을 잡았던 문제는 익숙하지 않은 언어 — ActionScript 2.0 — 에서 불거져나온 이것 저것들이었다. 내가 홍민희 님의 블로그에서 “워드의 메타프로그래밍” 이란 글 — 불편한 언어를 사용할 때 그냥 사용하는게 아니라 자신에게 편의를 줄 수 있게 언어에 추가로 빌딩블럭을 쌓아 “중력을 줄여가는/언어의 장애를 줄이는” 프로그래밍을 하자는 것 — 을 일찍 볼 수 있다거나, 혹은 애자일 블로그 내용을 기억하고 있었다면^[3] 참 좋았을텐데 불행히도 그렇게 일이 돌아가진 않았고, 전에 언급했던 것 처럼 C++에서 모든 프로젝트를 최대한 진행시키고, 해당 코드 베이스를 ActionScript에 반복하는 작업을 했다.

지금 다시 하라고 하면 ActionScript 코드에 더 많은 계층을 추가하지 않을까 싶다. 현재는 패킷을 받고, 이에 대한 이벤트를 전달하고, 패킷을 해석하는 계층만 있다 — 즉 프로토콜을 받아서 처리하는 콜백을 부르는 정도까지의 추상화.

테스트 케이스들도 C++쪽에 집중되어 있고… ActionScript 쪽의 제대로된 테스트 케이스도 오늘의 ASUnit 쪽으로 코드 테스트를 옮김으로써 제대로 작성된듯하다…

테스트 주도 개발

TDD(테스트 주도 개발;Test Driven Development)를 시작한건 작년 말 / 올해 초 정돈데 일단 C++ 쪽 코드 작성에서는 제대로 효과를 발휘한듯 하다. 개략적으로 defect를 찾고나서 이를 코드 베이스에 테스트 케이스로 반영하고 / 수정하고 / 다시 커밋하는데 평균적으로 1일 이하의 시간이 걸린 것 같다. 손으로 테스트 하지 않는데에서 상당히 빠른 코딩/컴파일/테스트/리포트 주기를 겪게 된 것도 같고. 다만 ActionScript 쪽의 TDD는 좀 야매였다고 생각해야한다 — .fla 파일에 assert 비슷한 함수를 만들고 그 함수에서 실패할 때마다 특정 메시지 형태로 찍게 하는 수준이었다. 지금이야 ASUnit으로 옮겨서 그런데로 볼만한 수준으로는 자동화 된 듯 하다.

UTF-8 문제

이종 언어 개발 쪽이랑 겹치는 문젠데, ActionScript 2.0에선 문자열의 bytes 길이^[4] 를 바로 얻지 못하고, 그것 때문에 패킷 생성에 오류가 생기는걸 생각하지 못해서 문제가 생겼다. 사실 이건 ActionScript쪽에서 테스트를 제대로 했으면 괜찮았을텐데, C++ 쪽 테스트에서 잘 되는 것만 믿고, 그걸 포팅한 AS 2.0 코드를 제대로 된 테스트 케이스 확보도 없이 넘어간게 크나큰 패인. 덕분에 어제 오늘은 회사에서 일해야 했다…

여튼 요약.

1. 의사 소통이 가장 중요 — 의사 소통하기 쉬운 환경 / 코드베이스도 필요
2. 프로젝트에서 쓰는 언어의 중력을 줄여라 — 프로젝트에서 쓰는 언어가 맘에 안들면, 자신에게 우호적인 환경으로 바꿀 수 있도록 하자
3. TDD에 맞는 툴을 우선 확보하자 — mtasc와 ASUnit을 일찍 알았으면 C++에서 테스트하려던 욕구가 줄었을 텐데

다음 프로젝트 회고는 언제하게 될까 -_-a

1. 이게 만악의 근원이었던 것 같은 기분도 들지만
2. 문제는 나는 이 코드를 받지도 못했단 말이다 Orz 클라이언트 코드 중 극히 일부(껍데기?)만 받았으니…
3. 저 글을 읽었을 당시엔 별 감흥이 없었는데… 지금은 뼈에 사묻힘(?)
4. 문자 수 길이랑 대비되는 개념. 예를 들어 “한글”이란 단어는 문자 수 길이로는 2지만, UHC(cp949 or euc-kr)에선 바이트 길이로 4, UTF-8에서는 바이트 길이로 6이다. 즉 의미론적인 길이가 문자수 길이고, 바이트 길이는 메모리에서 표현되는 길이

관련 글:

1. 프로그래머의 일상: 다시 ActionScript 삽질