« Previous : 1 : 2 : 3 : 4 : 5 : 6 : 7 : 8 : ... 10 : Next »

본인이 지금까지 게임 포함 고전 소프트웨어에 대해 글을 잔뜩 올린 것은 그래도 플랫폼은 PC 한정인 편이었다. 운영체제는 응당 16비트 도스/윈도이다.
하지만 그보다 더 옛날 8비트.. 아무래도 롬 베이직을 빼면 롬 카트리지를 꽂아서 게임밖에 할 게 없었던 더 옛날 컴퓨터에 대한 추억도 없는 건 아니다.

본인은 난생 처음 접한 개인용 컴퓨터가 286 AT인 관계로, 저 컴퓨터는 친구 집에서 어깨 너머로 구경만 했지 개인적으로 소장한 경험은 없었다.
그런 플랫폼용으로 프로그램 개발은 어떻게 했을까? 16비트도 모자라서 8비트이면 int도 char과 크기가 같을까? 몇만 바이트밖에 안 되는 허접한 메모리로 어떻게 저런 게임을 만들 수 있었을까? 1980년대 초니까 C 컴파일러조차도 없이 그냥 기계어/어셈블리 직통 코딩을 했을까?

그런 컴퓨터와 아예 8비트 아케이드 게임기와의 관계는 어떠했을까? 그리고 MSX인지 뭔지는 무슨 규격이지? 난 그런 건 전혀 모른다.
그러고 보니 일본이 유난히도 이런 플랫폼용 게임을 많이 만들었던 것 같다. 이 글에서 소개하는 5개의 게임도 다 일제이다.
하지만 본인은 정작 일본에서 동전 품절 현상을 일으킬 정도로 대성공을 거뒀다는 슈퍼마리오는 전혀 접한 적이 없었다. 그리고 황금도끼나 보글보글도 PC 도스용을 접했지 오락실용은 접한 적이 없다. 오락실용이 더 완성도가 높고 재미있는데도 말이다.

1. 남극 탐험

사용자 삽입 이미지

영어 원제는 Antarctic Adventure로, 1984년에 일본 코나미에서 MSX용으로 개발했다.
구멍과 바다표범을 요리조리 피하면서 펭귄을 잘 달리게 하는 게 목표이다. 구멍에 빠지거나 바다표범에 부딪히면.. 주인공인 펭귄이 죽거나 다치지는 않지만.. '지연'이 발생해서 제한 시간 안에 도착을 못 하고 미스가 난다.

BGM은 잘 알다시피 다른 음악이 아니라 스케이터 왈츠라는 고전 음악이다.
그리고 레벨을 클리어하면 가상 세계가 아니라 현실에서 남극 기지를 보유하고 있는 국가들의 국기가 뜨는데, 이는 이 게임이 완전한 허구의 게임성보다는 일종의 교육용으로 개발되었기 때문이다.
늘 드는 생각이지만, 주행 거리 단위는 km를 m로 거의 1/1000에 가깝게 너프시켜도 모자랄 판에 뻥튀기가 너무 심하다.

2. 캐슬 엑설런트

사용자 삽입 이미지

1985년에 일본 아스키 사에 MSX 및 여타 플랫폼용으로 개발한.. 일단은 아케이드 게임이지만 슈파플렉스처럼 퍼즐 요소가 굉장히 강하다. "도미솔미 파레솔~~ 도미솔미 파레도" 요런 BGM이 유명하다. 참고로 아스키는 MSX 규격을 제정하는 데 동참했던 그 회사이다.

얘가 게임 메카닉면에서 여타 게임들과 다른 점은.. 점프가 단순히 일시적인 추진력으로 공중에 떴다가 즉시 떨어지는 게 아니라... 일종의 제트팩을 몇 초간 동작시키는 것과 같다는 점이다. 그리고 다른 방으로 들어가면 각종 기물이나 적들의 위치가 원상복귀되어 버린다는 것도 비현실적이다. 단, 없애 버린 기물이나 적이 다시 생기지는 않는다.

이 게임은 레벨이라는 개념이 없으며, '캐슬'을 구성하는 가로 10*세로 10 총 100개의 방 전체가 거대한 단일 레벨이다. 그리고 지형과 기물, 각종 열쇠 조합을 이용한 굉장히 까다로운 퍼즐을 풀어야 공주가 있는 방까지 갈 수 있다. 주인공은 각종 움직이는 트랩이나 적에게 걸리면 HP 없이 바로 죽는다. 그리고 무기가 없어서 적은 움직이는 기물이나 트랩을 이용해서만 죽일 수 있다.
난 당연히 엔딩은 못 보고 포기했지만, 그래도 뭔가 중세풍의 성 안에서 각종 보석을 먹는 게 잠시나마 재미있긴 했다.

3. 덱스더(Thexder)

사용자 삽입 이미지
우리말로 표기와 영어 스펠링이 굉장히 헷갈려서 그 동안 검색을 하고 싶어도 못 하곤 했다. 원제품의 로고타입을 보면 T가 영락없이 C처럼 적혀 있기도 해서 더욱 혼란스러웠다. 게다가 Dexter라는 이름도 있다.
그런데 PC용에는 포팅을 한 기업인 '1987 시에라 온라인'이라는 문구가 뜬다는 걸 기억을 되살려서 역추적 후 검색에 성공했다.

친구 집에서 패미컴용을, 그리고 나중에 초딩 시절에 개인적으로 PC DOS용도 해 봤다. PC용은 극악의 종횡비를 자랑하는 CGA 640*200 16색 그래픽 모드에서 실행되었다. 물론 원작은 1985인가 86년에 Game Arts라는 일본 기업에서 개발되었으며, 그 당시 수십~수백만 카피가 팔렸을 정도로 굉장히 히트 치고 성공한 작품이라고 한다.

게임 주인공은 이족보행과 비행 기능을 모두 갖춘 로봇이다. 아케이드 게임으로서는 아주 드물게 각도를 목표물을 자동 조준하여 총을 쏘는 기능이 있다. (이것 말고 자동 조준을 하는 게임으로는 난 툼 레이더밖에 못 봤다~!)
비행 모드에서는 덩치가 좀 더 작아지고 낙하· 추락을 안 하게 되지만 자동 조준을 못 하며 중간에 정지를 할 수 없다는 제약이 생긴다.

이런 상태에서 던전 안의 수많은 장애물· 몬스터들을 죽이거나 피하면서 던전을 빠져나가는 게 게임의 목표다. 게임을 잘 못하면 적들이 너무 많이 나와서 걔네들에게 다구리 당하다가 게임오버 된다.
SF스러운 느낌이 나면서 한편으로는 단조 특유의 구슬픈 느낌이 나는 BGM도 인상적이다.

4. 마피 (Mappy)

사용자 삽입 이미지

1983년에 일본 남코에서 개발한 아케이드 게임으로, 동작 플랫폼이 위의 둘과는 좀 다르다. 위키백과에서도 MSX가 아니라 '아케이드'라고만 소개하고 있는데, 그래서 그런지 본인 역시 이건 동전을 넣어서 사용하는 동네 문방구의 오락기로만 구경해 봤다.
주인공은 쥐이고 적들은 고양이인데, 고양이를 피하면서 아이템들을 모두 모아야 한다.

고양이를 직접 공격해서 죽일 수는 없으며, 문을 적절한 타이밍에 열어서 기절시킬 수만 있다. 그리고 굉장히 특이한 규칙이 있는데, 봉봉 패드를 타고 점프 내지 낙하 중일 때, 다시 말해 발이 땅에 닿지 않은 상태일 때는 고양이와 닿아도 죽지 않는다. 요 타이밍을 잘 이용해야 한다.
그런데 안전하다고 해서 봉봉 패드만 계속 연달아 타고 있으면 안 된다. 그러면 패드가 나중에 끊어져서 화면 아래로 떨어지기 때문이다.

E단조의 BGM 멜로디도 20년 가까이 기억 속에 봉인되어 있었는데 본인은 아직까지 정확하게 기억하고 있다. 신기하다.
그리고 정식 오락실도 아니고 마치 뽑기 기계처럼 비치된 '동네 문방구의 오락기'라고 하니까 또 추억이 돋는다. 요즘은 그런 용도의 게임은 스마트폰 게임이 다 대체해 버렸으며, 3, 40대 아저씨들이나 옛날 추억을 살리려고 에뮬레이터와 롬 파일을 구해서 PC에서 게임을 즐기는 지경이 됐다.

일본에서는 패미컴(family), 퍼스컴(personal) 등.. 한국 같았으면 그냥 알파벳 이니셜을 그대로 썼을 텐데 영어 단어를 제멋대로 뚝뚝 잘라 내서 말은 참 잘 만든다는 생각이 들었다.

5. 요술나무 (Magical Tree)

남극탐험과 마찬가지로 코나미에서 1984년에 MSX용으로 개발한 작품이다. 제목을 까맣게 잊어버린 상태였는데 구글에서 MSX tree climbing game이라고만 쳤더니.. 이거 뭐 내가 원하는 답이 즉시 튀어나와서 기억을 복원할 수 있었다. 역시 무서운 구글.

사용자 삽입 이미지

이건 깃털 달린 모자를 쓴 귀여운 인디언 소년이 주인공으로 나오고, 나무를 수직으로 끝도 없이 타고 오르는 게 목표인 게임이다. 9개의 스테이지를 거치면서 설정상 총 2004m를 올라가야 한다. 한라산보다 약간 더 높구나.
게임 BGM을 말하자면, 평소에는 F장조 파~도 파~도 파라솔파도... 요렇게 시작하는 명랑한 멜로디 6마디가 무한 반복된다. 아, 한 스테이지에는 화면의 중앙에 나무 기둥이 있는 보통 모드가 있고, 중앙 대신 좌우 양 끝에 나무 기둥이 있는 특별 모드가 있다. 특별 모드에서는 반음 간격의 뚜두뚜두...만 반복되면서 뭔가 위기 상황인 듯한 분위기가 난다.

주인공을 방해하는 건 무슨 게처럼 수평 비행을 하는 부엉이, 번개를 떨어뜨리는 먹구름, 그리고 시도 때도 없이 튀어나오는 애벌레 등이다. 아이템으로 칼과 활이 있는데 이건 점수만을 줄 뿐 무기가 아니다. 이 게임엔 주인공에게 무기를 사용한 공격은 없으며 단지 사과를 떨어뜨리고 굴려서 적을 없애는 시스템만이 존재한다.

끝도 없이 높이 솟은 나무 위에 성이 있는 게 '재크와 콩나무' 동화 같은 느낌이 든다.

Posted by 사무엘

2015/01/27 08:26 2015/01/27 08:26
, , ,
Response
No Trackback , 4 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1055

Trackback URL : http://moogi.new21.org/tc/trackback/1055

Comments List

  1. 근성인 2015/01/27 20:19 # M/D Reply Permalink

    맨위 빼고 다 모르겠다..

    1. 사무엘 2015/01/27 23:55 # M/D Permalink

      PC 게임도 아니니 저 게임들이 돌아가는 기계 자체를 실물로 못 봤을 가능성이 높을 것이야~~ ㅋㅋ
      (오랜만이군 반갑다?)

  2. 김 진 2015/01/28 00:36 # M/D Reply Permalink

    남극탐험과 덱스더 재밌게 했어요. 덱스더는 PC판이었는데 공격을 하면 에너지가 소모돼서 보충을 못 하면 난감했던 기억이네요.

    1. 사무엘 2015/01/28 10:35 # M/D Permalink

      아..! 중요한 특징을 당연히 언급했으리라고 생각했는데 본문에서 빠뜨렸군요.
      그렇습니다. 덱스더는 총을 오랫동안 쏘고 있으면 총알이나 다른 에너지가 아니라 자기 HP를 잃지요.
      체력 회복 아이템을 먹는 것조차도 총을 쏴야 가능한데 거 참 특이한 시스템입니다.

      그리고 벽으로 막혀 있어서 직선으로 닿는 게 불가능한 목표물에다가는 조준을 안 하게 하거나, 최소한 조준 대상을 수동으로 바꾸는 기능을 넣을 수는 없는지 궁금하다는 생각이 들었습니다.
      그래도 제일 유명한 건 남극탐험이군요. ^^

Leave a comment

본인은 이 블로그의 옛날 글들을 보면 알 수 있듯, 어린 시절의 추억이 담긴 옛날 고전 게임들을 회상하는 걸 매우 좋아한다.
본인이 어릴 때에 생각한 가장 typical한 게임은 사람 또는 최소한 두 팔 두 다리가 달린 캐릭터가 2차원 던전을 뛰어다니면서 적을 죽이는 액션/아케이트 장르였다. 그래서 주 관심사도 페르시아의 왕자나 황금도끼 같은 부류였는데..

하루는 오랜 기억 속에 봉인되어 있던 약간 색다른 게임이 되살아난 관계로 별도의 글을 좀 쓰게 되었다. 바로 슈파플렉스이다.

사용자 삽입 이미지사용자 삽입 이미지

이 게임은 통상적인 액션/아케이드라고 보기에는 맵 구조가 단순하고 주인공의 묘사가 더 기하학적(?)이며 퍼즐의 비중이 매우 높다. 주인공이 대놓고 동그란 공 모양인 건 Bumpy's Arcade Fantasy 말고는 쟤 정도밖에 기억이 안 난다.

사용자 삽입 이미지
슈파플렉스는 간단한 규칙에 비해 게임성과 중독성이 대단히 뛰어나서 그야말로 시대를 초월한 명작이라 칭송을 받고 있으며, 외국에서는 오늘날까지도 수천 개의 custom level들이 나돌고 있다고 한다.

이 게임의 명목상 배경은 컴퓨터 내부=_=;;이다. 주인공은 저 붉은 공 모양의 입 큰 캐릭터이다. 주인공은 던전 안에서 좌우상하 마음대로 드나들 수 있기 때문에 던전의 전체 시점이 좌우전후인 것 같지만, 실제로는 그렇지 않다. 중력이 아래로 작용하고 있다. 그리고 일부 소수 레벨은 주인공에게도 중력이 걸리기 때문에 위로 한없이 자유롭게 올라갈 수가 없다.

게임의 기본적인 목표는 던전 안을 돌아다니면서 위험물에 걸려 죽지 않고, '인포트론'이라고 불리는 아이템을 모두 먹어서 모은 뒤 출구로 빠져나가는 것이다. 초록색 기판은 주인공만이 먹어서 없앨 수 있는 일종의 지형인데(적은 이걸 못 없앰), 이게 없어지면 그 위에 있던 돌덩어리와 인포트론은 아래로 떨어진다. 떨어지는 물체에 맞으면 주인공이건 적이건 다 죽는다.
(여담이지만, 주인공이 녹색 기판을 먹으며 이동 중일 때는 눈을 소복소복 밟는 듯한 찰진 소리가 들린다.)

슈파플렉스의 모티브는 팩맨과 분명 비슷한 점이 많다. 하지만 지형을 먹어 없애서 장애물을 아래로 떨어뜨릴 수 있는 것은.. 1983년에 개발된 완전 옛날 게임인 Digger와도 비슷한 것 같다.
혹시 Digger 아는 분 계시는지? 본인은 초딩 시절에 컴퓨터 학원에서 디스켓 넣어서 흑백 모니터 XT 컴퓨터로 저걸 돌려서 해 봤다. 얘는 주인공이 무슨 자동차처럼 생겼으며, 한 화면에서 보석을 다 먹기만 하면 자동으로 레벨이 끝난다.

사용자 삽입 이미지

물론 슈파플렉스는 Digger보다야 머리 써야 하는 복잡한 요소가 훨씬 더 많다.
돌과 인포트론이 막 복잡하게 섞여 있는 곳에서 뭘 까딱 잘못 건드리면 죽거나, 인포트론이 돌 사이에 파묻혀서 내가 먹을 수 없게 되는 게 많다. 마작으로 치면 무작정 짝이 맞다고 해서 아무렇게나 가까운 패를 없애다가 나중에 게임을 풀 수 없는 지경이 되는 것과 비슷하다.

이런 장르를 별로 안 좋아하는 사람이라면 게임 하다가 너무 골치 아파서 스트레스만 잔뜩 받을 법도 한데.. 덕후들은 오히려 이런 데에 완전 열광한다.
엔하위키 아니랄까봐 각 레벨과 게임 특성에 대해서 아주 자세히 설명돼 있다. 역시 거기 글 쓰는 사람들은 덕력이 장난이 아니다.

PC 통신 시절에 내가 알고 지내던 내 또래의 어느 컴덕/프로그래머는 슈파플렉스의 중독성을 극찬하던 매니아였으며, 도스용으로 슈파플렉스 레벨 에디터를 자작하기도 했다. =_=;;
하긴 별도의 복잡한 트리거나 이벤트가 별로 없이 정말 사각형 격자 데이터만으로 레벨이 만들어지니 데이터가 압축/암호화만 돼 있지 않다면 레벨 에디터를 만드는 건 어렵지 않았겠다.

이 게임의 백미는 돌더미들이 하나씩 순서대로 떨어지면서 좌우로 균형 있게 데굴데굴 굴러서 차곡차곡 쌓이는 모습이다. 이런 게임 메카닉은 어떤 알고리즘으로 구현되었을지가 프로그래머로서 무척 신기하게 느껴진다.

나와 비슷한 또래의 사람이라면 옛날 비디오 게임에 대한 추억을 하나 이상씩은 다 갖고 있는 모양이다. 그래서 웹툰 작가 가스파드는 작년 가을부터 <전자오락 수호대>라는 작품을 연재하기 시작했는데..
다들 알다시피 이건 뭐 예고편부터가 일개 웹툰 퀄리티가 아니었다. 도대체 무슨 약 빨고 이런 걸 창조해 냈는지? 천재라고밖에 생각할 수 없다.

그리고 여담이지만, 퍼즐보다는 더 현실성을 추구한 아케이드 게임에서도 아래로 떨어지는 중력을 왜곡하는 효과는 종종 등장한 경우가 있다.
페르시아의 왕자는 7단계 끝부분에서 초록색 물약을 먹어서 잠깐 낙하산 효과가 나며, 퀘이크 1의 비밀 레벨은 주인공을 포함한 모든 동체들이 중력이 1/n토막 나서 꽤 높은 점프가 가능하다.
물론 지구상에서 그걸 실제로 구현하는 건 제트팩 같은 것이라도 달지 않는 이상 불가능할 것이다. 아니면 달 같은 다른 작은 행성으로 가든가.

Posted by 사무엘

2015/01/17 08:25 2015/01/17 08:25
,
Response
No Trackback , 8 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1051

Trackback URL : http://moogi.new21.org/tc/trackback/1051

Comments List

  1. Lyn 2015/01/18 15:58 # M/D Reply Permalink

    둘다 옛날생각이 풀풀 나는 게임이네요 ㅎㅎ

    1. 사무엘 2015/01/19 09:30 # M/D Permalink

      옛날 게임과 옛날 자동차 회상하는 거 전 아주 좋아합니다. ^^

    2. Lyn 2015/01/20 18:35 # M/D Permalink

      전 게임엔 영 재능이 없어서 한번도 저 두 게임을 클리어해보지 못했네요 ㅡㅡㅋ

    3. 사무엘 2015/01/20 22:40 # M/D Permalink

      저도 회상하는 것만 좋아한댔지, 잘한다고는 절대로 얘기 안 했습니다~! ^^
      슈파플렉스 저걸 어떻게 혼자서 엔딩을 봅니까. 저 역시 게임 잘 못 합니다. 특히 퍼즐류는..;;

  2. 김 기윤 2015/01/21 14:25 # M/D Reply Permalink

    옛날 게임이면 이것저것 만이 해봤는데, 트랜스포트 타이쿤을 빼고는 (정작 이것도 샌드박스류라, 일단은 2030년으로 끝을 내고도 무한대로 추가플레이가 가능하지만) 엔딩을 본 게임이 없네요.

    옛날에 했었던 게임이면, 범피, 볼피드, 너구리, 고인돌, 브릭스2, 외 기타 등등등등 꽤 많았는데 말이죠orz

    1. 사무엘 2015/01/21 19:37 # M/D Permalink

      생각보다 도스 게임들을 많이 접하셨군요. DLL을 만든 적이 없으신 건 new 같고, 도스 게임은 old 같음. ^^

  3. ujinyang 2015/05/05 20:42 # M/D Reply Permalink

    슈파플렉스 나오기 몇년전에 ROCKFORD 라는 게임을 재밌게 했었는데,
    슈파플렉스는 몇판해보니 완전 판박이라 더는 안했던 기억이 있습니다.
    지금 생각나서 찾아보니까, BOULDER DASH 타입으로 분류하네요.
    http://en.wikipedia.org/wiki/Boulder_Dash
    아직도 이런류의 비슷한 게임이 나오나 봅니다. 연대표가 있네요.

    1. 사무엘 2015/05/06 07:36 # M/D Permalink

      아하, 팩맨· Digger보다도 더 유사한 동일 장르 기존 게임이 있었군요. 알려 주셔서 고맙습니다. ^^

Leave a comment

1.
우리나라가 옛날보다는 소프트웨어 불법복제에 대한 경각심이 좀 생겼고 불시단속도 강화된 관계로..
기업들 역시 대기업· 중소기업을 막론하고 직원들의 컴퓨터에 혹시 불법복제 소프트웨어가 깔려 있는지 자체 단속을 하는 편이다.
그런데, 그런 소프트웨어 자체를 생산하는 일을 하는 IT 기업에서는 추가적으로 민감한 물건이 더 있다.
자사가 개발하는 제품의 내부에 혹시 오픈소스 솔루션이 예기치 않게 들어가지 않느냐 하는 것이다.

당장 돈을 안 들이고 원하는 문제를 쉽고 빠르게 해결할 수 있다고 해서 출처 명시 없이, 혹은 라이선스가 요구하는 사항을 이행하지 않고 그런 솔루션들을 자기 소스 코드에다 불쑥 집어넣었다가는..
글쎄, 그 회사와 회사 제품이 완전 듣보잡 마이너 내수급이라면 별로 문제되지 않고 넘어갈지 모른다.
그러나 외국으로도 널리 널리 쓰이고 돈을 빗자루로 긁어모으는 인기 프로그램이라면 얼마 못 가 당연히 걸리고 발목 잡히게 된다.

왕년에 병역비리 내지 논문 표절을 저지른 사람이 나중에 고위 공직자가 되려 할 때 청문회에서 탈탈 털리듯이 말이다.
오픈소스를 표방하는 자유 소프트웨어라고 해서 저작권이 전혀 없는 게 아니기 때문이다. 아무나 완전히 제멋대로 고치고 이득을 챙겨도 되는 '인류 공용 자산'급인 public domain이 아니다.

방대한 분량에 복잡한 로직을 가진 소프트웨어는 설령 소스 코드가 있다 해도 누가 함부로 찔끔찔끔 고칠 수 있는 물건이 아니다. 그래서 그런지 설령 컴파일된 바이너리이고 소스 코드가 없다 하더라도, 여기에 어떤 오픈소스 솔루션이 무단으로 포함되었는지 정도는.. 오픈소스 진영에서 매의 눈으로 감시해서 다 적발해 낸다. 컴파일된 바이너리 코드의 패턴 분석을 정교하게 하는 듯.

그래서 그렇게 자기는 이윤을 챙기면서 엔진 내부에 무료 오픈소스를 무단으로 사용한 양심불량 소프트웨어는 hall of shame 같은 데에 올라서 업계에서 국제적으로 망신을 당하며,
GPL 라이선스 급의 오픈소스를 잘못 따다가는 그걸 사용한 프로그램 전체에 대해 소스 공개라는 형벌(?)을 당하게 된다. 실제로 그런 소스 공개형을 당한 사례도 몇 건 있다. 물론, 프로그램 소스만 공개이지 그 소프트웨어 제품에 사용된 각종 데이터나 리소스까지 죄다 공개는 아니기 때문에 완전한 기술 유출은 아니다.

대기업의 경우, 자사 직원들만치 꼼꼼하게 감시하지는 않는 하청업체로부터 납품받은 소스에 이런 지뢰가 들어있어서 골탕을 먹는 경우가 있는 모양이다. 그래서 납품 계약을 할 때부터 그 솔루션에 오픈소스 저작권 문제가 확실하게 없다는 걸 확인시키며, 문제가 생길 경우 이런 책임을 지우겠다는 식으로 얘기를 하는 걸 본인은 업계에서도 경험했다.

여담이지만, 요즘은 응용 언어학에서 다루는 말뭉치(코퍼스)에도 저렇게 저작권 바람이 불고 있다.
그래서 국립 국어원에서도 21세기 세종 계획 성과물로서 세종 말뭉치를 배포하다가.. 저작권이 문제가 되는 데이터를 빼고 분량이 다소 감소한 말뭉치를 새로 배포하기 시작했다. 그 얘기를 들으면서 IT업계의 오픈소스 얘기가 문득 떠올랐다.

2.
요번 학기에 학교에서 오픈소스와 관련된 세미나 수업을 들었다. 오늘날 IT 업계에서 오픈소스라는 트렌드가 차지하는 비중을 더욱 절실히 알 수 있었다. 자유 소프트웨어는 무엇이고 오픈소스 소프트웨어는 무엇인지, 그리고 리눅스 진영과 리처드 스톨먼 진영의 차이는 무엇인지 예전에는 거의 관심이 없었고 아는 게 없었는데 이제 좀 어렴풋이 알게 되었다. 유익했다.

오늘날은 정말로 거의 모든 분야에서 github, sourceforge 같은 오픈소스 진영의 저작물을 이용하지 않고는 실용적인 프로그램을 만들기가 대단히 어렵거나 가성비가 안 맞아 의미가 없는 지경이 되었다. 그 오픈소스 진영에서 활동한 이력은 만천하에 공개된 자기 스펙과 자산이 되기 때문에, 당장 소프트웨어의 무료 공개로 인한 금전 손실 이상의 이득이 돌아온다는 말에는 공감이 됐다.

확실히 IT 업계에서 경력을 쌓는 방식의 패러다임이 바뀌긴 했다. 내 지인 중에서도 이 바닥에서 워낙 유명한 사람이 있다. 그 친구는 이런 수업 따위는 들을 필요가 없거나, 아니면 나처럼 따로 자료 찾으며 과제를 낑낑대며 할 필요조차 없이, 평소에 하던 오덕질을 갖고 학점 따위 그냥 날로 먹는 게 가능했을 것이다.

내게 오픈소스라는 건, 이거 소스 코드 하나쯤은 공개해 버려도 내 밥줄에 아무 지장 없고 그것보다 더 나은 것 정도는 얼마든지 또 만들어 낼 수 있고, 이 프로그램의 UI, 데이터 파일들을 업계 표준 관행으로 굳히는 효과까지 노릴 수 있는 괴수들의 전유물일 뿐인 것 같다. =_=;; 물론 그런 진영에서 기여를 하는 프로그래머들이 매우 고마운 대인배인 건 사실이지만, 일단은 무슨 희생, 헌신, 자선 행위라기보다는 “가진 자의 여유” 구도라는 것이다.

또한, 마냥 다 공개하는 게 능사만은 아닐 텐데.. “경쟁자가 따로 이득을 보기 vs 경쟁자를 원천 견제하고 차단하기”라는 결말의 차이가 어떤 과정에서 생기는지 궁금하다. 가령, IBM은 하드웨어계의 오픈소스라 할 수 있는 PC 규격을 내놓았고 그게 결국 세계를 평정하긴 했지만, 이 때문에 정작 자기는 아무 이득도 못 보고 PC 사업에서 손을 떼게 됐단 말이다.

id 소프트웨어에서도 둠과 퀘이크의 소스를 공개하긴 했지만, 그래도 해당 세대의 기술이 충분히 한물 갈 정도로 굉장히 나중에 공개하지 않았던가. 물론, 엔진을 유료로 판매하기도 하는데 소스를 돈 주고 산 업체들이 손해를 보지 않게 하려고 좀 늦게 공개하는 것도 있긴 하지만 말이다.
오픈소스가 과연 개발자와 사용자가 모두 윈윈 할 수 있는 소프트웨어 생태계로 계속 명맥이 유지되는 게 가능할지 지켜볼 일이다.

아 그리고, 이 모든 사실에도 불구하고 <날개셋> 한글 입력기는 완성품을 복사해서 사용하는 것만 무료이지 여전히 소스 비공개 사유 소프트웨어이다. 물론 오픈소스 저작물을 사용한 것도 최소한 C++ 코드 내부엔 전혀 없다. 거기 들어있는 모든 모듈의 모든 기계어 코드는 한 치의 예외 없는 100% 자작이다.
전세계에 한국어와 한글이 쫙 퍼져 있고 세벌식 자판이 주류 글자판이 돼서 누구나 이런 응용 한글 입력 엔진의 필요를 느끼고 있고 사용자가 왕창 많고 거기에 다른 형태의 돈줄까지 있다면야 내가 거기에 공개적으로 기여를 해서 오픈소스계에 등단(?)할 수도 있겠지만.

시장과 수요 자체가 극도로 마이너한데... 공개해 봤자, 한글 IME를 연구하는 일부 극소수 오덕들에게나 좋은 일을 하게 되고, 내가 노력을 보상받는 길도 없고, 날개셋의 리눅스나 맥 버전을 뚝딱 책임감 있게 만들어 줄 사람이 있는 것도 아닌 와중에..
무작정 오픈소스화는 현실에 맞지 않는다고 여겨진다. 오픈소스 진영이 있다고 해서 모든 프로그래머가 흙 파서 먹고 살 수 있는 건 아니다.  8.0 정도가 나온 뒤부터는 내 프로그램의 장기적인 생존 방법에 대해서도 슬슬 생각을 해 봐야겠다.

3.
저건 나름 학점이 붙은 과목이기 때문에, 세미나만 있는 있는 게 아니라 과제도 있었다. 관심이 가는 오픈소스 프로젝트를 하나 선정해서 그에 대해 조사를 하고, 관심이 있으면 자그마한 오타 수정이라도 직접 하나 contribute를 해 보라는 것.

그래서 평소에 프로그래밍 언어에 대한 관심이 무진장 많으며, 나보고도 줄곧 이것저것 다른 언어를 익혀 보라고 권유를 하던 대한민국 오픈소스 진영의 거물이자 프로그래밍의 천재 T모 군의 도움을 받았다. (IOCCC 입상자 ㅋㅋㅋㅋ) 권유의 대상도 예전부터 파이썬, D, 자바스크립트로 계속 바뀌어 오다가 요즘은 Rust로 정착했다.

Rust는 모질라 재단에서 자체 개발한 새로운 절차형 시스템 프로그래밍 언어이다. Java/C# 같은 언어는 full-time 쓰레기 수집기가 갖춰진 별도의 가상 기계에서 동작하는 반면, 이 언어는 그런 형태의 쓰레기 수집기가 없이 C++과 동급의 네이티브 코드로 컴파일되는 언어이다. 메모리 관리 수준은 걍 Windows RT의 C++/CLI와 비슷한 급이 되겠다.

웹 브라우저 렌더링 엔진을 만드는 단체가 웬 PL을 새로 만들게 되었는지는 나름의 이유가 있다. 렌더링 엔진도 응당 GPU와 멀티코어의 도움을 받아야 할 터인데 여러 페이지들이 자연스럽게 멀티코어를 활용하는 게 아니라 단일 페이지가 멀티코어를 적절히 활용하게 만들자니 C/C++로 만들어진 기존 코드들은 답이 없는 지경이었나 보다.

또한 C/C++은 알다시피 빌드 시간이 매우 길고 컴파일러가 잡아 주지 못하는 메모리 관련 버그에 무방비로 노출되어 있는 등, 대형 프로젝트의 진행에 전통적인 한계와 약점도 적지 않다. 그래서 대형 프로젝트의 개발과 유지에 적당한 새로운 언어를 찾았는데 마땅한 대안이 없자 언어를 직접 고안하게 되었다.

이 언어는 모질라 재단에 소속되어 있던 개발자인 Graydon Hoare가 개인적으로 설계하던 언어를 재단이 인수하여 발전시킨 것이다. 지금은 모질라 재단뿐만 아니라 삼성전자도 Rust의 개발을 후원하고 있다고 한다.
아직도 활발하게 개발되고 있어서 0.12까지 나왔는데.. (12는 소수점이 아니라 그냥 정수. 0.2보다 최신 버전임) 긴 베타 기간을 거친 후, 가까운 미래에 Rust의 1.0 정식 버전이 나올 예정이라 한다.

즉 멀티코어 병렬 처리 편의와 자동 메모리 관리, 그리고 성능을 만족시킬 목적으로 만들어진 언어라는 뜻인데, 구글에서 비슷한 시기에 개발한 Go라는 언어하고도 경쟁 구도인 듯하다. 하지만 둘은 패러다임이 좀 다른 언어이다.

Rust에서 모든 값은 그 값이 대입된 변수나 구조체 필드, 넘겨받은 함수 인자 등의 이름에 귀속된다. 이름은 자기에게 귀속된 값에 대한 소유권을 가지며, 다른 이름으로 값을 대입하면 그 이름으로 소유권이 이전된다. 예를 들어, 다른 언어에서 a = b와 같은 대입 연산은 b의 값을 a로 복사하거나, b가 가리키던 객체를 a도 함께 가리키겠다는 의미를 갖는 데 반해, Rust에서는 b가 가지고 있던 값을 a로 이동시킨다는 의미가 된다. C++로 치면, C++11에서 첫 도입된 R-value reference type과 개념적으로 비슷하다.

만약 함수의 리턴값을 받지 않는다던가 하는 일로 인해 소유권을 넘겨주지 못한 채로 이름이 사라지게 되면, 거기에 귀속되었던 값도 함께 사라지면서 그 값을 담았던 메모리도 해제되게 된다. 프로그래밍 언어 이론의 관점에서 보자면, binding과 object의 생명 주기를 일치시킨 셈이다.

Rust 컴파일러는 컴파일 단계에서 소유권이 어떻게 이전되는지를 모두 추적할 수 있으며, 필요한 메모리 할당 및 해제 코드를 컴파일 중에 정확한 위치에 삽입한다. 이런 방법으로 Rust는 런타임 오버헤드가 없는 안전한 메모리 관리를 이루어 낸다.
일단 대충 이 정도 조사하면서 그쪽 진영에서 뜨고 있는 이슈와 작업 진행 방식들을 조사해 봤다.

Posted by 사무엘

2014/12/14 08:34 2014/12/14 08:34
, , ,
Response
No Trackback , 4 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1039

Trackback URL : http://moogi.new21.org/tc/trackback/1039

Comments List

  1. 김재주 2014/12/14 14:36 # M/D Reply Permalink

    누군지 알 것 같군요 ㅋㅋ T는 예전에 쓰던 닉네임의 앞글자죠?

    Rust는 C언어가 바라보는 기계 추상화를 그대로 사용하면서도 Functional Language들의 특징을 가지고 있습니다. 보통 Functional Language들에서는 값을 한번 바인딩하면 이 변수는 불변값이라 고칠 수 없고 이를 바꾸고 싶다면 함수 호출을 해서 State 자체를 변경해야 하는 식의 접근방법을 가지고 있었는데 Rust의 객체 모델도 어떤 의미에서 비슷하죠. 함수형 프로그래밍 언어로 작성된 프로그램을 거의 그대로 옮길 수 있는 것도 그 때문이고요. 불변값이라면 당연히 다른 이름으로 바인딩되는 일이 없을 테니까요.

    지금까지 수많은 프로그래밍 언어들이 등장하고 서로 장점을 흡수하며 발전해왔는데, Scala나 Python 같은 일부 언어를 제외하고는 상업적으로는 별로 성공하지 못했죠. 오픈소스 계에서 제 나름대로 큰 규모인 모질라 재단에서 밀어주고 있는 Rust는 성공할 수 있을지 궁금하네요.

    1. 사무엘 2014/12/14 20:00 # M/D Permalink

      네, 본문에서 언급하지는 않았지만 Rust는 단순 데이터 병렬처리/절차형 특화 언어 이상으로 함수형 프로그래밍 속성이 강하더군요.
      파이썬, 스칼라 역시 학교 수업 때문에 간단한 프로그램을 짜는 용도로 잠깐 써 봤습니다. 스칼라는 자바스크립트와 비슷하다는 생각을 했고요.
      제가 어쩌다가 T모 같은 엄청난 괴수와 아는 사이가 됐는지 참... ^^;;

  2. eson 2014/12/26 13:28 # M/D Reply Permalink

    한글립력기 개발자 이신가 보네요. 그리고 오픈소스에 대한 고민도 많으신 것 같습니다.
    그리고, 적으신 것 처럼, 오픈소스화 하는 것이 마냥 능사는 아닙니다.
    오픈소스를 해서 좋을 분야가 있고, 해서는 안될 분야가 있을 겁니다.
    경쟁자만 좋게하는 호구가 되지 않기 위해서는, 많은 고민과 전략적인 추진이 필요하겠죠.
    특히, 명성/실력 외에 뭔가 경제적 이득이 필요하다고 생각한다면,
    큰 수정 없이 바로 사용할 수 있는 코드를 오픈소스화 하는 것은 지양해야 될 겁니다.
    코어에 해당하는 부분만 오픈소스화 하고 사용될 제품에 커스터마이징을 해야 하는 수준까지 하는 것이 맞을 것이구요.
    IBM 을 예로 드셨는데, IBM 은 오픈소스라기 보다 표준화라고 보시는게 맞을 겁니다.
    오픈소스와 표준화는 다른 부분도 많고 비슷한 부분도 많은데,
    비슷한 부분을 짚어 본다면, 오픈하고 나서 지속적으로 관리 하면서 주도권을 계속 가질려는 노력이 필요하다는 겁니다.
    그런 점에서, 오픈소스를 한다는 것이 어렵다고 말하는 것이구요.

    1. 사무엘 2014/12/26 14:49 # M/D Permalink

      오옷.. 여러 조언에 감사드립니다. 꽤 고수 프로그래머의 포스가 느껴지는데요. ^^

Leave a comment

1.
비교적 최근에 알게 된 건데..
C/C++에서 default문은 굳이 case의 맨 마지막에 있지 않아도 된다. =_=;;;
그래서 case 1: .. default: ... case 2: 이런 식으로 라벨들이 따라오고 일부 항의 끝에 break까지 생략되어 있다면 생각보다 꽤 기괴한 로직을 구현할 수도 있다.

뭔가 발상의 전환이 느껴진다. 어떻게 활용 가능한지는 더 생각을 해 봐야겠다.
물론 파스칼의 case else문은 그렇지 않으며, 반드시 맨 마지막에 와야 한다.

2.
컴퓨터에서 부동소수점은 연산을 하는 게 까다로워서 하드웨어적인 도움을 진작부터 받아 왔다. 하지만 연산뿐만 아니라 이미 있는 수를 10진법 형태의 문자열로 나타내거나 문자열로부터 역변환하는 것도 생각보다 몹시 어렵다. 에니악 같은 초창기 컴퓨터가 괜히 굉장한 비효율을 감수하고라도 10진법 기반으로 설계되었던 게 아닌가 싶다.

이와 관련된 정보는 printing float numbers 같은 키워드로 구글링을 하면 얻을 수 있다.
이 작업은 어떤 f * 2^e에 대해서 f' * 10^e' <= f * 2^e < (f'+1) * 10^e'가 성립하는 최소의 f'/e'를 찾는 것인데, 결국 컴퓨터 프로세서가 기본 단위로 처리 가능한 범위를 넘는 big number 연산까지 필요할 정도라고 한다.

2진법 부동소수점은 1/2^n이 아닌 사실상 거의 모든 소수들이 순환소수로 표현되어 뒷부분이 잘린다. 0.1, 0.3 이런 소수도 컴퓨터에서 표현되는 형태는 순환소수라는 뜻이다. 순환소수를 화면에 출력할 때는 그래도 10진법 유한소수인 것처럼 표시하는 것이니 컴퓨터에서 부동소수점은 본질적으로 100% 정확한 정밀도가 보장되지 않는 셈이다.

3.
Visual C++ 201x는 200x에 비해서 매우 강력해진 인텔리센스, 새로 디자인된 IDE, C++1x 언어 기능 같은 게 부각되는 편이다. 하지만 그것 말고도 IDE가 매우 편리해진 면모가 최소한 둘 있는데...
이제 IDE의 버전이 올라갈 때마다 프로젝트 파일을 매번 강제로 업그레이드 하지 않아도 되고, 그리고 컴파일러 툴킷을 직접 고를 수 있게 된 점이다.

이로써 IDE가 개별 프로젝트나 빌드 툴과는 좀 더 독립한 구도가 됐다.
이것은 딱히 새로운 기능 추가가 아님에도 불구하고 옛날에 도스 시절에 멀티부팅 기능이 추가된 것만큼이나 매우 편리해진 조치이다. (autoexec.bat / config.sys에 일종의 조건부 실행 로직을 추가하여, 부팅 configuration을 직접 고를 수 있는 것)

4.
본인은 예전에 precompiled header에 대해서 글을 쓴 적이 있다. 그때에도 언급했지만, 본인은 성질이 좀 급한 관계로 PCH 없이 소스 코드가 엄청난 분량의 인클루드 반복 때문에 컴파일 속도가 굼뜨는 걸 못 참는다.
그런데, 프로젝트 전체를 분석하면서 중복 인클루드로 판단되는 파일들을 자동으로 감지해 주는 기능이 있으면 좋지 않을까? 그것들을 stdafx.h로 대체하고 그 파일에다가 인클루드들을 몰아 넣는 것이다. 물론, 빈번하게 인클루드되긴 하지만 수정도 빈번하게 되는 편이기 때문에 pch에다 넣어서는 안 되는 것 판단은 사람이 하면 된다.

이건 마치 데이터베이스에서 테이블과 쿼리들을 분석하면서 자주 쓰이는 테이블 내지 애트리뷰트는 인덱스를 넣는 최적화 기능과 비슷한 구석이 있는 것 같다.

5.
자동차의 특성이 컴퓨터 소프트웨어의 특성과 매우 비슷하다고 여겨지는 점이 몇 가지 있다.

  • 내릴 때 실내등이나 각종 라이트가 완전히 꺼졌는지 확인하고, 블랙박스는 장시간 주차시 자체 전원 차단 기능이 켜져 있는지 확인해야 한다. → 메모리 leak 예방과 개념적으로 일치한다.
  • 급발진: 아주 희귀한 상황에서 갑자기 발생하는 치명적인 버그에 해당한다.
  • 자동 vs 수동 변속기: 옛날이라면 컴파일러가 자동 생성한 코드 vs 수제 어셈블리 코드.. 정도와 대응하고, 지금이라면 managed vs native 코드와 대응하는 듯하다. 요즘은 자동 변속기도 어지간한 수동 조작에 뒤쳐지지 않을 정도로 효율이 굉장히 좋아졌으니 말이다.

6.
세상에는 분야를 불문하고 여러 단체가 공동으로 뭔가 통합 작품이나 프로토콜을 만드는 경우가 있다. 따지고 보면 킹 제임스 성경도 성공회와 청교도가 연합해서 작업한 그런 통합 작품이다.
하지만 그런 통합 작품이 실질적인 통합을 이루지 못하고 그냥 기여를 가장 많이 한 단체의 전유물로 전락해 버리는 경우도 있다. 그런 예를 몇 가지 들어 보자면 다음과 같다.

  • HFT 통합 글꼴: 지금은 아래아한글밖에 안 쓰는 완전 옛날 유물이 됐다.
  • 공동번역 성서: 에큐메니컬 성경이라지만 현실은 역시 천주교 전용 성경일 뿐이다.
  • 타이젠 OS: 당초 취지와는 달리, 컨소시엄을 구성하던 협력사들은 다 빠져나가고, 사실상 삼성 전자밖에 관심이 없는 모바일 OS가 됐다.

삼성은 예전에도 아래아한글과 MS 워드가 뻔히 있음에도 불구하고 수익성과는 별개로 훈민정음을 오랫동안 밀었다.
그런 것처럼 모바일 OS 하나 정도는 우리가 자체 기술을 갖고 있어야 한다는 차원에서 타이젠을 꾸준히 미는 듯하다. 안드로이드와 iOS의 텃새에도 불구하고 정말 막대한 자금을 투자하여 타이젠 앱 프로그래머를 육성하는 중이다.

7.
비주얼 C++이 컴파일러, IDE, 디버거 등 모든 차원에서 64비트를 완벽하게 자체 지원하기 시작한 건 2005부터이다.
그런데 나는 그 시절부터 굉장히 궁금했던 게...
devenv IDE는 예나 지금이나 32비트 프로그램임에도 불구하고 어떻게 64비트 바이너리를 아무 제약 없이 바로 디버깅 하고 메모리 내부를 잘도 들여다볼 수 있느냐 하는 것이었다.

운영체제 차원에서 64비트와 32비트가 서로 얼마나 격리되어 있는지는 이 바닥에 짬밥깨나 있는 프로그래머라면 누구나 잘 알 테고. 그러니 결론은 하나. 별도의 64비트 EXE를 띄워서 IPC(프로세스 간 통신)를 하지 않고서는 이 정도의 자연스러운 연계는 절대 가능하지 않다는 것이었다.

확인해 보니 이 예상이 맞는 듯하다. 32비트 프로그램을 디버깅 할 때는 안 그러는데 64비트 프로그램을 디버깅 할 때는 msvsmon이라는 일종의 64비트짜리 원격 디버그 호스트 프로그램이 같이 뜬다. 그리고 디버깅이 끝나면 얘도 실행이 종료된다. EXE 크기가 수MB에 달하는 결코 작지 않은 프로그램이긴 한데, 얘가 뭔가 하는 일이 많은 것 같다.

8.
끝으로.. 시간 복잡도, 공간 복잡도라고 하면 전산학에서나 다루는 무슨 뜬구름 잡는 개념처럼 들리기 쉬운데, 현실에서도 의외로 간단한 예가 있다.

먼저, 자전거를 잠그는 자물쇠로는 열쇠 방식이 있고 숫자 다이얼 방식이 있다.
전자는 열쇠만 있으면 금방 자물쇠를 딸 수 있다. 후자는 번거로운 열쇠를 챙기지 않아도 되지만 원하는 숫자까지 다이얼을 맞추고, 다시 잠김 모드로 옮기는 시간이 오래 걸린다.

나는 프로그래머로서 이걸 경험할 때마다 시간/공간의 tradeoff라는 생각이 들곤 한다. 열쇠 자물쇠는 열쇠라는 공간이 필요하고 열쇠를 분실하지 않게 주머니 관리를 잘 해야 하지만, 열고 잠그는 건 배열 테이블을 참조하듯이 O(1) 시간 만에 즉시 끝낸다.
숫자 자물쇠는 열쇠가 없어도 되어 심리적으로 편하지만, 다이얼을 맞추기 위해 마치 매번 탐색을 하고 연결 리스트의 노드를 찾듯이 O(n) 시간 작업을 매번 해야 하기 때문이다.

옛날에 브라운관 모니터가 어느 수준 이상의 대형화가 도저히 불가능하고 LCD 모니터에 밀려 도태한 주 이유가..
바로 화면 크기 n에 따른 공간 복잡도가 O(n^3)이나 되었기 때문이다. 무게나 가격까지 그 정도로 급격하게 증가했고.
색감이 좋다고는 하지만, 그래도 전자총을 뒤에서 화면 크기만큼이나 거리를 두고 쏴 줘야 하니, 화면의 크기가 커질수록 어마어마한 양의 공간을 잡아먹는 것을 감당할 수가 없었다.

그리고 지구본(지구의)도 생각난다.
알 만한 분들은 이미 다 아시겠지만, 메르카토르 도법 평면 지도에는 아프리카 대륙은 실제보다 굉장히 작게 나오고, 그린란드 내지 러시아는 말도 안 되게 면적이 부풀려져 있다.

왜곡 없이 둥근 지구 위에서 세계 각국의 위치에 대한 실질적인 공간 감각을 키우는 데는 지구본 만한 게 없다. 그리고 지구본이 비치된 책상 앞에서 누가 머리 싸매고 있으면 왠지 간지 나고 멋있어 보이기도 하나..

지구본 얘도 크기에 따른 공간 복잡도가 O(n^3)인 부피를 차지하는 물건이고, 안 쓸 때 딱히 접거나 분해해서 부피를 축소시키는 방법도 여의치 않다 보니 실용성이 떨어진다.
현실적으로는 입체 효과까지 지원하는 구글 어스 같은 지도 어플이 대안이지만.. 그래도 이런 건 실물이 아쉽기도 하다. (어플은 여러 사람이 한 지구의 여러 지점을 한데 공유하면서 서로 비교할 수 없음)

다시 프로그래밍 얘기로 돌아오자면, 현실에서는 단순무식한 알고리즘이 O(n^2) 정도의 복잡도가 나오는 게 약간 머리를 굴림으로써 O(n log n) 정도로 최적화되는 경우가 많은 듯하다. 정렬이 대표적인 예이고, 그 외에도 빠른 푸리에 변환이라든가 최장 증가 수열 찾기 문제도 이런 범주에 속한다.

그리고 단순무식하게 접근했을 때 지수함수 복잡도가 되는 게, 다이나믹 프로그래밍으로 중간 계산 결과를 저장함으로써 메모리 복잡도 O(n^2), 시간 복잡도 O(n^2) 내지 O(n^3)이 되는 경우가 많다.
아예 O(n)으로 간단하게 줄어드는 건 피보나치 수열이나 팩토리얼을 구하는 것처럼 문제 자체가 극도로 단순한 경우밖에 없을 것이다.

Posted by 사무엘

2014/11/19 08:22 2014/11/19 08:22
, ,
Response
No Trackback , 4 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1030

Trackback URL : http://moogi.new21.org/tc/trackback/1030

Comments List

  1. Lyn 2014/11/21 15:02 # M/D Reply Permalink

    아 지저분한 C++ ㅋㅋ

  2. Lyn 2014/11/21 15:04 # M/D Reply Permalink

    CRT 시절에

    http://tinman.co.kr/board/bbs/board.php?bo_table=NEWS&wr_id=516#.VG7VqlWsVaw

    이런 기술이 있었다면 수명이 더 길어졋을지도 ㅎㅎ
    물론 lcd만큼 얇게 만들긴 무리겠지만요

    1. 사무엘 2014/11/21 15:47 # M/D Permalink

      1. C++은 정말 계속해서 기괴한 문법 용례가 뒤늦게 발견되더군요. ㅎㅎ
      2. 오옷~ 아주 짧은 거리에서도 왜곡 거의 없이 엄청난 양의 시야를 담아 내는 초광각 카메라...가 입력 버전이라면
      저 프로젝터는 출력 버전이네요!

    2. 김재주 2014/11/26 17:02 # M/D Permalink

      오, 재미있는 기술이네요.

      저런 기술을 응용하면 HMD(헤드마운트디스플레이)의 가장 큰 단점인 큰 픽셀 크기 문제를 해결하는 데도 도움이 될 것 같은데요?

      그러고 보니 소니도 HMD 선도 기업 중 하나네요. 조만간 엄청난 물건이 튀어나올지도 모르겠어요.

Leave a comment

고전 게임 황금도끼에 대해서 아주 오래 전에 글을 쓴 적이 있었는데 또 내용을 첨언할 게 생겼다.
그 글은 이 블로그가 생기기도 전, 제로보드 시절에 썼던 글이니 시기로는 2009년이나 그 이전의 정말 옛날 글이다.

황금도끼는 오락실용 원판이 나온 이후로 다양한 플랫폼으로 이식되었다.
그 중 Mega Drive/Genesis 판(게임기용?)은 레벨을 좀 더 추가하고 Duel이라는 결투 모드를 넣는 등 게임 시스템에 변화를 좀 넣었는데, PC(도스)용 버전은 바로 이 버전에서 파생되어 나왔다. 원판이 1989년에 나왔고 PC용이 그 이듬해에 나왔다는 것은 페르시아의 왕자와 일치하는 내력이다.

Mega Drive/Genesis에서 추가되고 PC용에서도 도입된 결투 모드는 스토리(아케이드)를 따라 진행되는 정식 게임이 아니라, 주인공이 고정된 arena에서 정해진 적들과 PvP를 벌이는 일종의 대전 게임이다. 첫 레벨에서는 그냥 잡몹 한두 마리만 나오지만, 레벨이 올라갈수록 보스급 몬스터가 등장하면서 진행이 어려워진다.

결투 모드에서는 아케이드 때와는 달리 몹도 체력이 화면에 나온다. 정확히는 화면에 존재하는 모든 몹들의 체력의 합임. 덕분에 적을 얼마나 더 두들겨 패야 이번 레벨을 끝낼 수 있는지를 얼추 알 수 있다.

사용자 삽입 이미지

사실, MMORPG나 전략 시뮬, 아니면 아예 1:1 대전 액션 게임 같은 장르 말고 통상적인 액션/아케이드형 게임에서 내가 싸우고 있는 몹의 체력을 알 수 있는 게임은 별로 없다. 페르시아의 왕자는 적과 싸우는 것은 1:1 대전 컨셉을 표방했기 때문에 친절하게 적의 HP가 화면에 나오는 것일 테고, 황금도끼도 아케이드가 아닌 결투 모드에서는 그런 컨셉을 추구하여 적의 HP를 표시해 주는 것 같다.

단, PC용의 경우, 해골 두 마리가 등장하는 레벨 9 이상부터는 주인공과 몹들의 HP가 화면에 안 나오기 시작한다. 화면에 아무 정보도 표시되지 않으며, 이 덕분에 부하가 좀 줄어들어서 게임의 진행이 약간 빨라지기도 한다.

사용자 삽입 이미지

Mega Drive/Genesis 판에서는 레벨이 올라갈수록 날이 점점 어두워져서 밤이 되는 효과가 있으나, PC용은 그런 것도 없다. 아무튼...
그렇게 레벨 13까지 가면 빨간 기사와 빨간 뚱보에 잡몹 둘까지.. 총 4마리나 되는 몬스터가 나타난다.

사용자 삽입 이미지

그런데 문제는 이 레벨을 깬 다음이다. 무슨 파일이 없는지 다음 디스크를 넣으라는 메시지와 함께 게임 진행이 중단된다.
이건 뭐 취소할 수도 없고 프로그램을 종료할 수도 없다. 황금도끼를 돌리고 있는 도스 에뮬레이터를 강제 종료하는 수밖에 없다.

사용자 삽입 이미지

도대체 왜 이러는 것일까?
혹시 프로그램 배포에 문제가 있는 게 아닌가 싶어서 국내외 여러 곳에서 서로 다른 황금도끼 파일을 구해 봤지만, 파일 구성은 변한 게 없으며 레벨 13 이후에 저렇게 진행이 중단되는 건 여전했다.

그럼에도 불구하고 유튜브를 뒤져 보면, 황금도끼 PC판에서 레벨 13 이후에도 결투를 진행하는 플레이 동영상이 존재한다. 세상에! (☞ 링크 클릭. 2분 58초부터)
레벨 14는 아케이드 레벨 6의 보스인 Death Adder 주니어와 부하 해골 두 마리이며, 레벨 15는 아케이드 마지막 레벨의 최종 보스인 그 시커먼 Death Adder와 부하 해골 두 마리이다. 그리고 이게 결투의 마지막이다.

이 사람은 어떻게 해서 레벨 14와 15까지 잠금해제를 한 걸까?

결론부터 말하자면, 뜻밖에도 인터넷에 굴러다니는 황금도끼 배포본에 일부 파일이 누락됐거나 문제가 있는 건 아니다.
레벨 14~15의 리소스도 다 준비돼 있는데 프로그램 자체에 버그가 있어서 그걸 제대로 인식을 못 한 거라고 한다.
외국의 어느 리버스 엔지니어링/해커 팀에서 해당 프로그램을 기계어 코드를 일일이 분석하면서 디버깅한 끝에 그 버그가 무엇인지를 알아냈다. 이 문서를 참고하시라.

황금도끼 PC판은 gold.exe라는 실행 파일이 lzexe라는 과거의 16비트 도스용 실행 파일 압축기로 압축되어 있다.
그런데 저 글을 쓴 해커는 unlzexe가 있는 줄 모르고, 실행 파일 내부에 들어있는 압축 해독 루틴과 압축된 데이터를 읽고 따라가면서 그냥 근성으로 실행 파일의 로직을 추적했다고 한다.;; 8086 어셈블리와 도스 인터럽트 API에 통달한 사람이라면 최소한 80년대 이전생의 old timer일 텐데, unlzexe를 모르는 것도 신기하다만... 아무튼 괴수.

물론, 그 lzexe를 만든 사람도 괴물인 건 두 말할 나위가 없고 말이다. (ioccc 입상자이며, lzexe는 그가 겨우 고등학생일 때 만든 작품이다.. 쩝~)

자, 저 문서의 내용을 요약하면 이렇다.
문제의 원인은 레벨 14로 갈 때 프로그램이 잘못된 파일 이름을 요청한다고 한다. 파일 이름에 아스키 코드 4번 제어 문자가 들어있다고 하니 이는 명백한 오류이다.

역추적을 해 보면 드디어 레벨별로 소환할 몬스터 정보가 담긴 테이블에까지 도달하는데..
레벨 14와 15를 보면 비정상적인 값이 들어있다. 메모리의 내용을 강제로 일관성 있게 수정해 주니 놀랍게도 모든 결투 레벨이 정상적으로 진행된다.

이런 걸 찾아내다니 저 해커에게 경의를 표하는 바이다. 정말 안 되던 걸 되게 만든 사람이다.
SI가 가리키는 값을 보면 남자 여자 소형 잡몹은 따로 처리해 주는 게 없고, 0xA는 그 chicken leg 탈것이고 0xB+0x10은 붉은 용, 0xB+0x11은 푸른 용이다. 0x6은 대머리 보스, 0x3은 해골, 0x8은 칼 든 기사 보스, 그리고 0x7은 Death Adder의 스프라이트에 대응한다는 걸 알 수 있다.

저 메모리 테이블은 다행히 황금도끼의 실질적인 실행 파일에 해당하는 axe.dat에 고스란히 들어있다. unlzexe로 얘의 압축을 푼 뒤, 메모리를 패치하듯이 잘못된 값이 들어있는 부분(오프셋이 대략 0xFFxx대에 있음)을 고치면.. 레벨 14~15가 모두 잠금해제된 황금도끼를 즐길 수 있다~!

옛날에 게임 위저드 32를 이용해서 주인공의 HP를 강제로 늘리거나 심지어 값이 바뀌지 않는 무적 상태를 만들어 놓고 게임을 즐긴 적도 있다. HP 한 칸이 내부 HP 4에 대응하는 형태이기 때문에 비교적 쉽게 메모리 주소를 찾을 수 있었다.
지금도 그런 해킹 프로그램이 있다면 저 테이블을 메모리에서 찾아내서 결투 모드 버그 정도는 런타임 때 고칠 수 있을 듯하다.

디버깅을 할 줄 알면 이런 것도 다 가능하다는 걸 알 수 있었다.

Posted by 사무엘

2014/08/27 08:38 2014/08/27 08:38
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1000

Trackback URL : http://moogi.new21.org/tc/trackback/1000

Leave a comment

캡챠 이야기

요 근래부터 이 블로그에도 국내외 광고 스팸 댓글이 급증하고 있어서 대책이 좀 필요한 것 같다.
옛날에는 외국 발 스팸 트랙백이 아주 가끔 걸리는 듯했는데 요즘은 트랙백은 없고 그냥 닥치고 쓰레기 댓글뿐이다.
일단 영어만 들어있는 텍스트는 무조건 차단하고, 요주의 키워드와 IP는 블랙리스트로 등록해 추가로 차단하고 있는데도 가끔은 그런 필터를 통과한 놈들이 게시되곤 한다. 그런 건 내가 보이는 족족 수동으로 제거하는 중이다.

옛날에 제로보드 시절엔 비로그인 사용자가 댓글/답변을 올릴 때 캡챠를 입력하게 하는 플러그인 내지 소스 추가 패키지가 있어서 본인 역시 제로보드 게시판을 운영할 땐 그걸 유용하게 썼었다. PHP 코드만 돌아가는 게 아니라 리눅스용 실행 파일이 서버에서 실행되어 캡챠 이미지(PNG)를 실시간으로 생성해 냈다.
TextCube용으로도 그런 플러그인이 없을 리는 없겠지. 조만간 도입해야 할지도 모르겠다.

여기서 캡챠란 무엇인지 모르시는 분을 위해 설명하자면..
사용자가 서버로 보내는 게시물 내지 회원가입 신청이 봇/매크로/오토 같은 컴퓨터가 생성한 게 아니라 진짜 사람이 하는 게 맞음을 입증하기 위해, 사람만이 판독할 수 있게 비비 꼬아 놓은 랜덤하고 이상한 글자· 그림이 의미하는 값을 입력받는 인증 장치를 말한다.
gotcha!와 비슷한 어감 때문에 좀 얍삽하다는 심상이 느껴지는데, CAPTCHA는 나름 영단어 이니셜이다.

기계가 인식할 수 없는 이미지를 기계가 생성해 낼 수 있을까?
패턴인식 기술의 발달로 인해 어지간히 허술한 캡챠를 기계가 인식하여 뚫는 기술도 발달하고, 그에 맞서.. 진짜 사람조차 인식 못 할 정도로 난해하지 않으면서 적당히 기계만 엿먹이기에 충분할 정도로 어려운 캡챠를 생성하는 기술을 개발하는 것도 만만찮은 수준이다.

(첨언하자면, 오늘날은 무질서로부터 질서를 도로 찾아서 복구하는 기술이 매우 경이로운 수준이다.
물리적으로 어지간히 손상을 준 하드디스크로부터도 최대한 데이터를 복구해 낸다거나, 심각하게 BLUR된 이미지로부터도 놀라울 수준으로 원래 이미지를 복원한다거나. 캡챠를 뚫는 것도 그런 맥락에서 살펴볼 수 있을 듯하다.)

도스 시절에 '맥스'라는 유사 채팅 프로그램이 있었는데 혹시 기억하는 분 계시는지?
얼굴이 안 보이는 공간에서 어떤 사람이 상대방과 채팅을 했는데, 대화 상대가 패턴이 뻔한 '봇'이 아니라 진짜 사람이 맞는지를 같은 사람이 분간할 수 없었다면 그 대화를 생성한 AI는 '튜링 테스트'를 통과했다고 간주된다.
그런데 캡챠는 역으로 컴퓨터가 이 입력이 진짜 사람이 맞는지를 판단하는 것이므로, 일종의 '역방향 튜링 테스트'에 가까운 셈이다.

스팸 게시물을 막기 위해 도박, 성 등 여러 불건전한 분야의 금지어들을 지정해 놓은 게시판이 많다.
그런데 게시물에 금지어가 우연히 포함되었다고 해서 아무 설명도 없이 없이 글의 등록을 거부하면..
진짜 사람이 그런 거부를 당했을 때 그 사람을 굉장히 화나게 만들 수 있다.

또한 반대로 'xxx는 금지어입니다'라고 매번 친절하게 알려 주면.. 스패머들은 그 피드백 결과를 바탕으로 금지어만 교묘하게 피해가는 스팸 게시물을 만들어 뿌리게 된다. 이 역시 딜레마다.

따라서 둘을 절충하는 방법으로는...
일단은 캡챠 같은 거 없이 깔끔하게 글을 접수한 뒤,
본문이 금지어가 포함돼 있거나 특정 패턴을 만족하여 광고글로 의심되면... 그때는 금지어 같은 광고글 의심 판정 근거를 노출하는 대신, 가만히 캡챠만 좀 입력해 보라고 friendly하게 추가 요청을 하는 게 바람직하지 않은가 싶다. 한 마디로 말해 선패턴 후캡챠 전략인 것이다.

그게 익명 사용자에게 당장 깔끔한 첫인상을 주며,
사용자가 댓글을 올리지 않고 그냥 글을 읽기만 하는데도 복잡한 이미지 프로세싱이 필요한 캡챠를 매번 생성하는 것보다 서버 부담도 줄이는 일거양득 방법일 것이다.

특정 패턴이란 굳이 단어가 아니어도 되고 NLP 기술이 아니어도 된다. 지나치게 URL 링크가 많은 글, 특수문자가 한글과 너무 지저분하게 뒤죽박죽 섞여 있는 글만 찾아도 된다. 이 정도만 돼도 스패머가 제아무리 금지어 필터를 피하려고 잔머리를 굴린들 광고글 따위는 모조리 걸러낼 수 있다.

사이버 공간에서 이런 광고 댓글 스패머는 국제 민폐요 인터넷 트래픽을 좀먹는 공해덩어리 떨거지들이다.
하지만 겨우 얘네들 때문에 게시판을 회원만 글을 올릴 수 있게 바꾼다거나, 심지어 누가 올려 놓은 글은 관리자가 일일이 사전 검열(?)한 뒤에야 공개 게시한다거나 하는 건.. 빈대 잡으려다 초가삼간 다 불태우는 수준의 극단적인 짓일 것이다. 아무쪼록 인간과 기계의 경계를 허물기도 하고 강화하기도 하는 기술의 발달이 절실하다.

이미 널리 알려져 있기도 하겠지만, 캡챠로부터 유래된 재미있는 발상이 있다.
포털 사이트 같은 델 가입할 때, OCR 프로그램이 제대로 인식하지 못한 어떤 책 스캔 이미지 조각에 든 문자열을 캡챠하고 같이 입력하게 한다. 그래서 캡챠를 맞게 입력한 여러 사람들이 동일한 이미지 조각에 대해 일치하는 문자열을 입력했다면, 그 이미지에 담긴 텍스트는 그게 맞다고 데이터를 수집하는 것이다.

캡챠 타이핑과 동시에 real-world 캡챠도 같이 타이핑하여 전세계 네티즌들이 힘을 합쳐 문헌의 전산화(?)에 기여하게 하는 것이다. 일명 '리캡챠 프로젝트'라고 한다. 구글, 페이스북, 아마존 등 세계 유수의 사이트들이 리캡챠 엔진을 활용 중이라고 한다.

Posted by 사무엘

2014/08/16 08:22 2014/08/16 08:22
, ,
Response
No Trackback , 7 Comments
RSS :
http://moogi.new21.org/tc/rss/response/996

Trackback URL : http://moogi.new21.org/tc/trackback/996

Comments List

  1. 김재주 2014/08/16 14:00 # M/D Reply Permalink

    구글 맵의 건물번호 및 번지 인식용 신경망의 정확도가 사람을 뛰어넘었죠. 이걸 활용해서 같은 구글의 리캡챠를 완전 무력화할 수 있는 봇이 나와서 화제가 됐었습니다.

    그리고 구글의 보이스 캡챠도 구글의 음성 검색 기능에 무력화되어 팀킬 제국(...)의 악명을 드높인 바 있습니다

    1. 사무엘 2014/08/16 18:54 # M/D Permalink

      창과 방패를 동시에 만드는 외계인 고문 기업이다 보니 그런 일도 있군요.. ㄷㄷㄷ

  2. Lyn 2014/08/22 07:29 # M/D Reply Permalink

    맥스...

    초딩시절에 참 신기해 했었죠. 최근엔 맥스 개발자와 같이 일하는 (뭐 만나거나 그런건 아니고 어쩌다보니 온라인상으로 ...) 상황도 벌어지지만요

    1. 사무엘 2014/08/22 08:52 # M/D Permalink

      Lyn 님은 개발자 인맥이 도대체 어디까지입니까~!!! ^^

    2. Lyn 2014/08/22 09:04 # M/D Permalink

      맥스 개발자 분이 지금 모바일 게임프로그래머시라 ^^; 같은 분야에 있으니 이런 신기한 일도 생깁니다.

      과거 같은 Borland 계열 툴을 사용했었다는 이유도 있구요.

  3. 세벌 2014/09/02 19:25 # M/D Reply Permalink

    여긴 제가 만든 사이트보다 침입자가 많군요. 제가 만든 http://sebul.co-story.net/q2a/ 에 외국발 스팸( 한글 한 글자도 안 들어간 쓰레기 글)이 종종 올라오기에, 한글이 포함되지 않은 글은 쓰기 안되도록 코드를 살짝 바꾸었더니 그 후로는 스팸이 없네요. :)

    1. 사무엘 2014/09/03 11:14 # M/D Permalink

      요즘은 한 달쯤 전에 비해서는 좀 잠잠해졌습니다. 스패머들이 기세가 꺾였는지, 아니면 서버 호스팅 업체에서 자체적으로 차단 조치를 취했는지는 모르겠습니다.
      스팸 댓글 얘기는 아닙니다만, 하도 악성 트래픽이 들끓어 대니까 일부 호스팅 업체는 secure 접속이 아닌 FTP/텔넷 같은 건 아예 외국 발 접속을 무조건 막아 버리기도 했지요.

Leave a comment

노트북 PC에서 가장 흔하게 발생하는 잔고장의 양대 산맥은 (1) 액정 화면 접촉불량과 (2) 키캡 빠짐이라 해도 과언이 아닐 것이다.

본인이 개인용 노트북 PC를 사용한 지가 15년이 넘었고 지금 쓰는 맥북은 제 5대 컴퓨터인데,
예전에 쓰던 노트북들은 쓴 지 1년 남짓 되면 저런 잔고장이 어김없이 발생하곤 했다.
물론, 언제나 새 노트북만 쓴 게 아니라 중고나 준중고를 쓴 것도 있기 때문에, 품질이 원래부터 안 좋아서 그랬던 것일 수도 있다.

(1)은 화면을 편 각도에 따라서 붉은 세로줄이 나타났다가 사라진다거나, 화면이 아예 꺼진다거나 하는 등 굉장히 성가신 증상이다. 이것 때문에 서비스센터 들러서 수리 받느라 신경 쓰이고 시간· 돈이 낭비되는 것도 과거엔 상당한 수준이었다.

(2)도 노트북 키보드가 데스크톱 PC 키보드보다 약해서 발생하는 고질적인 문제인 듯.
자주 누르는 편인 화살표, 엔터, space, shift 같은 게 잘 빠졌으며 가끔은 문자 키가 빠지기도 했다. 키캡이 없어도 해당 키를 누르는 것 자체는 가능하지만, 빠른 타자와 원활한 컴퓨터 사용에는 애로사항이 꽃핀다.
빠진 키캡 한두 곳만 수리가 되지는 않는 경우가 많다. 그래서 키캡이 대여섯 개쯤 빠질 때까지 컴을 더 쓰다가, 나중에 한꺼번에 키보드 기판을 교체하곤 했던 것 같다. 돈 몇만 원 정도는 깨진다.

그런데.. 지금 쓰는 맥북은.. 쓴 지 2년이 넘었지만. 위의 잔고장이 지금까지 전혀 발생한 적이 없다. 엔터 키가 약~간 달랑달랑거리긴 하지만 그래도 키캡이 완전히 빠진 건 없다. 잡느님의 손길이 담긴 품질 덕분인 걸까? 놀랍다.
맥북은 한번 병원 치료를 받으면 일반 놋붉에 비해 수리비가 작살나게 깨진다는 게 겁나긴 했었지만, 아직까지 A/S를 받을 일 자체가 전혀 없었다.
(참고로 난.. 흔들리는 교통수단 안에서도 쓰고 몇 번 떨어뜨린 적도 있고, 노트북 PC를 시도 때도 없이 험악하게 혹시시키며 쓰는 편이다.)

따라서 애플케어를 구입 안 한 게 현재로서는 결과적으로 이익이었다.
난 비록 맥북으로도 95% 이상의 시간은 맥OS가 아닌 Windows만 쓰며 지내지만 맥북의 이런 품질은 만족스러우며 인정할 만하다.

다만, 세월 때문인지 배터리 용량은 예전보다 확실히 줄어들었다. 2시간 남짓이면 간당간당하다. 배터리는 아직 구경도 못 해 봤다.
그리고 얼마 전엔 맥북을 쓴 지 2년 3개월 만에 처음으로 기능 고장을 경험했다. 본체나 LCD 쪽은 아니고, 전원 어댑터가 문제가 발생했다.

여기저기서 전선의 피복이 슬슬 벗겨지면서 속의 금속선들이 드러나 보이기 시작했다. 벗겨진 부분에다가는 테이프를 감았으며, 노출 부위 때문에 감전이나 화재 사고가 날까 두려워서 잘 때나 부재 중일 때는 전원 플러그를 빼 두기 시작했다.
그러더니 나중엔 컴퓨터 본체와 연결하는 목덜미 부분이 너무 너덜너덜해진 나머지 거의 두 동강 나다시피하면서 결국 단선됐다. 전원을 연결해도 본체에 전원 공급이 되지 않기 시작했다. 컴퓨터 본체는 이제 2시간짜리 시한부 인생으로 전락했다.

어댑터 전선에 피복이 벗겨지면서 고장이 이런 식으로 발생하는 노트북 컴은 맥북이 처음이다. 그런데 다른 맥북/아이폰 사용자에게 물어 보니, 애플 제품은 그런 식으로 전원 어댑터 내지 충전기가 망가지는 건 생각보다 흔한 일이라고 한다.

어댑터 자체는 이상이 없고 전선만 망가진 건데 어째 물건을 재활용할 수는 없나 궁금하다. 물론, 콘센트 쪽 전선이 아니라 컴퓨터에다 꽂는 쪽의 전선이다 보니 어댑터와 분리가 가능하지도 않고 가능하지는 않을 것 같다.

지금은 어댑터를 새로 구입해서 상황을 마무리 지었지만, 약 3~4일 동안 내 컴을 못 쓰면서 좀 불편하게 시간을 보냈다. 다음부터는 좀 불편하더라도 컴퓨터 본체와 어댑터 선이 언제나 같은 높이와 평행한 각도가 유지되게 해 놓고 써야겠다. 목덜미 부근엔 수축 튜브를 감아 주고, 전선을 둘둘 감아서 가방에 넣는 것도 굉장히 조심해서 해야 할 것 같다.

* 다음은 여담.

1. 맥 OS가 의외로 굉장히 유용한 경우가 있는 걸 본인이 얘기한 적이 있나 모르겠다. 바로 학교 안에서이다.
Windows의 경우 컴퓨터의 속도를 한 반쯤 깎아내리는 엄청난 백신, 보안 솔루션 등을 강제로 설치해야만 교내 무선 인터넷 이용이 가능한 반면, 맥 OS는 그런 것 전혀 없이도 바로 인터넷 이용이 가능하기 때문이다. 아주 편리하고 좋다.

2. Windows 진영에서는 Metro라는 이름을 안 쓰는 게 마음에 안 들던데, 애플 진영에서는 매킨토시로도 모자라서 Mac이라는 이름까지 왜 빼 버렸나 궁금하다.. 자기 정체성을 가장 잘 분명하게 보여 주는 명칭을 빼 버리고 그냥 OS X...;;;

3. 그러고 보니, 플래시가 깔려 있지 않은 맥 OS의 사파리 브라우저에서 유튜브 동영상이 나오고 있어서 깜짝 놀라서 살펴봤더니.. 말로만 듣던 HTML5 기반 동영상이다. 우와~ 물론 비스타+IE9 구닥다리에서 실행해 보니 여전히 플래시다. 브라우저에 따라 기술을 알아서 판별하는 듯하다.

솔직히 플래시든 뭐든 인터넷으로부터 패킷을 받아서 하드웨어 가속으로 동영상을 틀어 준다는 기본 원리는 똑같다. 단지, 동영상을 해독하고 재생하는 기계어 코드가 예전에는 플래시 ActiveX라는 일종의 private한 영역에 있었던 반면, 이제는 그게 통일된 규격으로 웹브라우저에 있다는 차이만이 존재할 뿐이다. 웹 표준은 기술 자체가 아니라 기술을 담는 그릇의 규격에 대한 논쟁인 것이다.

Posted by 사무엘

2014/07/08 08:29 2014/07/08 08:29
,
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/982

Trackback URL : http://moogi.new21.org/tc/trackback/982

Comments List

  1. 김재주 2014/07/10 15:48 # M/D Reply Permalink

    애플 제품들은 비싼 대신에 QA는 확실히 하는 편인 것 같습니다. 뭐 동급 사양의 삼성 제품과 비교한다면 그렇게 택도 없이 비싼 것 같지 않기는 하지만... 삼성은 A/S 정책이 가격에 포함되어 있는 걸 생각해 보면 비싸긴 비싸요.

    2.
    Mac OS X라고 하면 아무래도 기존의 낡은 매킨토시와의 연관성이 떠오르기 때문이 아닌가 싶습니다. 옛 매킨토시와 OS X는 기반부터가 완전히, 전혀 다른 운영체계이고 현재는 호환성 레이어도 제거된 상황이니까요.


    3.
    HTML5 요소들도 과거 HTML이, 그리고 Javascript가 그랬던 것처럼 브라우저마다 파편화가 되고 있는 게 아닌가 하는 생각을 합니다. 태그 자체는 표준으로 정의가 되어 있지 브라우저에 따라서 지원 정도가 달라요. 이게 단순히 구현이 덜 된 정도 문제가 아니라 각 브라우저들의 정치적 판단에 따라 넣고 빼고...

    예를 들어서 구글 크롬은 H264 영상을 원래 지원하다가 구글에서 VP8 코덱을 내놓으면서 지원 코드를 삭제했습니다. 명목상으로는 H264가 오픈 소스 코덱이 아니고 각종 특허들이 달려 있어서 추후 로열티를 제공해야 하기 때문에 오픈 소스인 VP8만 지원하겠다는데, 사실 진짜 이유는 누구나 다 알고 있죠.

    그래서 같은 웹킷 기반인 사파리에서는 H264만 지원하고, 크롬에서는 VP8만 지원하죠 -_-; 파이어폭스는 H264만 지원하던가 그랬을 텐데 아마 태그 지원이 완전치 못했던 걸로 기억합니다.

    1. 사무엘 2014/07/10 22:02 # M/D Permalink

      1. 그렇군요. ^^ 제가 써 본 노트북 PC들 중에 이 기간 동안 본체에 이 정도로 잔고장이 전혀 발생하지 않은 물건은 맥북이지만, 전원 어댑터의 선이 저렇게 어이없게 사망한 물건도 맥북입니다. ㅎㅎ
      수 년 뒤에 제6대 노트북을 장만하게 되면 또 맥북을 쓸지 아니면 일반 노트북으로 돌아갈지를 고민하게 될 듯하네요.

      2. 그런데 새 이름이 옛 이름보다 고유명사스럽지가 못해 보여서 불만입니다. ^^
      그나저나 10(X)이라는 저 번호가 또 바뀌는 날이 있으려나 궁금해지기도 합니다.

      3. 흠, 그것도 그냥 공통 태그만 표준으로 제정된다고 끝이 아니었군요. ㄷㄷ
      하긴 웹 표준이 이제 동영상 압축 포맷에까지 관여해야 하는 세상이 왔습니다.

Leave a comment

* 에구. 나 완전 고전 게임 덕후 인증이다. ㅎㅎ

1.
옛날의 액션/아케이드 게임 중에는 주인공을 죽게 하는 각종 트랩들이 적(몬스터)에게도 동일하게 적용되는 게 있고, 그렇지 않은 게 있다. 동일하게 적용되는 게 더 공정하고 현실 고증에 더 충실한 시스템이겠지만, 그 경우 적의 AI를 더 똑똑하게 만들어야 게임성이 성립할 테니 개발자에게는 더 큰 난관이 된다. 안 그러면 적을 정당하게 싸워서 죽이는 게 아니라 AI 헛점을 이용해서 트랩으로 죽이는 꼼수가 너무 횡행하여 게임 밸런스가 무너질 것이다.

이런 한계로 인해 id에서 개발한 둠, 퀘이크 등의 몬스터는 용암이나 화학 용액 같은 데에 들어가도 체력을 잃지 않으며 물에 들어가도 익사하지 않는다. 그 대신 잘 알다시피 자기끼리 팀킬을 벌이는 몬스터 내전(monster infighting)이 있을 뿐이다. 둠에서는 몬스터들이 정말 무식한지라 내전이 정말 잘 벌어졌지만, 퀘이크에서는 몬스터와 주인공 사이에 다른 몬스터가 일직선으로 있을 때는 공격을 안 하게 일말의 AI 개선이 이뤄졌다.

위험한 데이브에서는 몬스터는 트랩 같은 건 쌈싸먹으며 잘만 날아다니고..
과거의 툼 레이더 게임들은 주인공이 혼자 트랩 퍼즐을 풀어야 하는 구역과 몬스터와 싸우는 구역을 완전히 철저하게 분리하여 논란의 여지를 차단한 사례에 가깝다.
Rick Dangerous 2는 이 점에서 독특하다. 몬스터도 미사일, 전깃줄 같은 트랩에 걸리면 얄짤없이 죽을 뿐만 아니라, 이렇게 죽이는 게 전기총(50점), 폭약(100점) 같은 주인공의 일반적인 공격으로 죽이는 것보다 점수도 더 높게 준다(150점).

자, 서론이 너무 길어졌는데.. 페르시아의 왕자는 잘 알다시피 로토스코핑 기법으로 스프라이트를 만들었을 정도로 극도의 현실성을 추구한 게임이다. 악당도 딱히 초현실적인 괴물이 아니라 그저 검을 든 똑같은 인간이며, 이들을 상대로도 가시와 톱날 같은 트랩은 똑같이 동작한다. 악당 역시 트랩에 걸리면 피투성이가 되어 끔살당한다.

악당을 죽이는 방법으로는 (1) 칼 공격으로 HP를 다 깎아서 죽이는 가장 평범한 방법 외에도,
(2) 2층 이상의 높이에서 추락사시키기. 주인공은 이 경우 HP 하나만 잃지만, 악당은 의외로 즉사한다. 그 대신 악당은 1층 높이에서 떨어졌을 때 주인공처럼 무릎을 굽혀 엎드리지 않으며 바로 자세를 잡는다. 일당일단? 그리고 악당이 지금보다 아래 화면으로 떨어진 경우, 시체가 남지 않는다.
(3) 가시 꼬챙이가 있는 곳으로 떨어뜨리기. 한 층 높이에서만 떨어져도 주인공이든 악당이든 다 죽는다.
(4) 허리 자르는 쇠톱날.. 더 이상의 자세한 설명은 생략한다.

악당을 죽이고 나면 '빰 빠밤 빰' 하면서 승전 멜로디(?)가 흘러나온다. 칼로 찌르든, 떨어뜨리든 어떻게 죽이든지 말이다.
그런데... 페르시아의 왕자에서 악당을 (3)번, 즉 가시에다 밀어넣어 죽인 뒤에 승전 멜로디를 들은 적이 있으신 분 손..??
난 한 번도 없다. 20년 전부터 지금까지 이걸 대수롭지 않게 여기고 넘어가곤 했는데, 갑자기 문득 이상한 점이 느껴진다.

페르시아의 왕자 레벨에서 악당을 (3)번처럼 죽이는 건 레벨 2, 4, 8, 9(두 번), 11에서 총 6군데가 가능하다. 특히 마지막 레벨 11의 경우, 아예 왼쪽과 오른쪽에 모두 가시 트랩과 절벽이 존재하니 악당을 재미있게 요리하는 맛이 더욱 쏠쏠하다.

사용자 삽입 이미지사용자 삽입 이미지
사용자 삽입 이미지사용자 삽입 이미지
사용자 삽입 이미지사용자 삽입 이미지

악당을 정상적인 (1)번 방식으로 죽였을 때는 승전 멜로디가 무조건 나온다. (2)나 (4) 같은 트랩으로 죽였을 때는 아주 가끔 음악이 안 나오기도 했던 것 같다.
그 반면 (3)은... 지금까지 한 번도 나온 적이 없었다.
어떤 방식으로 죽든 악당의 HP가 0이 되어 전투가 끝나고 주인공이 칼을 집어넣을 때 승전 멜로디를 연주하면 될 텐데.. 로직을 상황별로 다 따로 처리했나? 그리고 저기서만 if문이 하나 실수로 빠진 건지? 진실은 그 당시 코딩을 했던 프로그래머만이 알 수 있을 것으로 보인다.

2.
자, 이제부터는 가시 말고 톱날 얘기가 줄곧 나올 것이다.
페르시아의 왕자의 일부 던전에는.. 톱날을 통과해 들어간 뒤에 곧바로 칼을 뽑고 악당과 싸워야 하는 곳이 있다. 레벨 4에서 처음으로 등장한다.
그런데 적과 싸우기 시작했을 때는 게임 진행이 조금 느려지고, 심지어 톱날의 톱질 주기도 약간 길어지는 것 같다.

이것은 시스템 성능 같은 다른 외부적인 문제일 뿐, 게임 메카닉 자체가 느려지는 건 아니다.
페르시아의 왕자는 참 좋은 게, ESC를 눌러서 게임을 일시 정지시키고 나서 계속 ESC를 누르면 게임을 한 프레임 단위로 천천히 진행시킬 수가 있다.
이걸로 측정을 해 보면, 톱날의 톱질 주기는 언제나 15프레임으로 동일하다. 전투 중일 때든, 평시든 말이다.

그리고 심지어 톱날이 여러 개 연달아 동작할 때도 동일하다.
각각의 톱날이 한 번씩 연달아 톱질한 뒤에 첫 톱날의 다음 주기가 시작되기 때문에 주기가 좀 길 것처럼 느껴지기 쉬운데, 그렇지 않다.

원작 게임에서야 톱날이 한 층에 가장 많이 등장하는 게 레벨 3의 대형 물약이 있는 방이다. 3개짜리가 최다이다.
유튜브 같은 데서 톱날이 5개가 넘게 있는 이상한 방을 가 보면, 모든 톱날들이 15프레임 안에 한 번씩 순회를 하는 게 불가능하다. 이런 데서는 뒤쪽의 톱날이 미처 톱질을 하기 전에 15프레임을 다 채운 앞쪽 톱날이 또 톱질을 시작한다.
게임 메카닉이 이러하다는 걸 알 수 있다.

3.
또한, 톱날은 주인공이 톱날과 같은 층에 진입한 경우 곧장 동작한다.
그런데 주인공이 그 층에서 다른 이유로 인해 죽어 버리면, 톱날은 일반적인 경우 동작을 멈춘다. 가령, 그 층에 있는 악당과의 전투에서 져서 죽거나, 칼을 뽑지 않은 상태에서 악당의 칼빵을 맞아 죽은 경우 말이다. 톱날이 있는 층에 주인공이 추락사를 했다면 톱날은 역시 더 동작하지 않는다.

하지만 주인공이든 악당이든 누군가가 그 톱날 자체에 찍혀 죽었다면 톱날은 계속 동작한다. 다시 말해 누군가를 한번 죽인 적이 있는 톱날은 그 층에서 주인공이 추락사하든 악당의 칼에 맞아 죽든, 주인공이 그 층에 어떤 형태로든 있다면 계속 동작한다.

사용자 삽입 이미지
내가 치트까지 써 가면서 다양한 상황에서 테스트를 해 보니 대략 그러하다. 알고리즘 차원에서 이런 미묘한 차이도 존재한다는 게 흥미롭지 않은가?

4.
그리고.. 주인공이 톱날이 존재하는 층에 있긴 한데, 추락하느라 잠시 지나는 형태라면 톱날은 어떻게 동작할까?
톱날은 이때도 반응한다. 레벨 9에서는 심지어는 주인공이 아니라 악당이 떨어지는데도 톱날이 한번 동작하니, 참 놀랍지 않을 수 없다. 아래 그림을 보시라.

사용자 삽입 이미지

그 반면, 주인공이라 해도 이렇게 지나갈 때는 톱날이 동작하지 않는다. megahit 치트를 써서 천천히 떨어지게 하는 낙하산 효과를 줬는데도 톱날이 동작하지 않는다.

사용자 삽입 이미지사용자 삽입 이미지
이런 걸 보면, 톱날의 동작 여부에는 우리가 흔히 생각하는 것보다 더 복잡한 로직이 들어간 건지도 모른다. 심지어 던전의 지형별로 톱날의 동작 여부를 제어하는 메타데이터가 수작업으로 들어간 건 아닌지?

5.
아까도 잠깐 얘기했던 레벨 3으로 돌아간다. 여기는 알다시피 최대 HP를 늘려 주는 대형 물약이 있지만, 그 길목을 저렇게 톱날이 무려 3개가 가로막고 있다.

사용자 삽입 이미지

페르시아의 왕자에서 레벨 3은 중간 waypoint가 존재하는 유일한 레벨이기도 하다. 죽으면 얄짤없이 처음부터 시작하는 게 아니라, 타임어택 절벽 관문은 통과한 뒤의 시점부터 시작한다는 뜻. 페르시아의 왕자 2야 각 레벨이 워낙 방대해진 관계로 waypoint가 존재하는 레벨이 더 생긴 편이지만, 1에서는 레벨 3이 유일했다.

레벨 12에도 그림자 인간과 합체하고 나서 Jafar를 만나기 직전 위치에 일종의 waypoint가 있긴 하지만, 이건 내부적으로는 완전 별도인 레벨 13으로 간주된다. 그렇기 때문에 레벨 3의 waypoint와는 약간 성격이 다르다.
관문을 통과하기 전에 대형 물약을 먹었다면, 그렇게 해서 늘어난 HP도 다음에 waypoint에서 게임을 다시 시작할 때 반영된다.

그런데, 여기에 약간의 버그 내지 exploit가 있다.
waypoint에서 게임을 다시 시작하면, 레벨 3의 모든 요소들이 원래대로 되돌아간다. 딱 하나, 그 타임어택 절벽 관문의 한쪽에서 우리가 도움닫기를 위해 밟아 떨어뜨려 없애던 발판만 계속 없는 채로 남아 있다.

그것만 빼고 나머지는 전부 원상복귀. 심지어 타임어택 절벽을 넘기 전에 먹었던 대형 물약도 다시 생긴다.
그렇기 때문에 다음 레벨로 넘어가는 관문을 열고 해골도 처지한 뒤, 다시 그 방으로 돌아와서 대형 물약을 먹으면.. 이론적으로 레벨 3에서 대형 물약을 두 번 먹어서 HP를 2개나 확장하는 게 가능해진다.

레벨 3 시작 → 대형 물약 → 타임어택 관문 통과 → 그 뒤 Ctrl+A 눌러서 waypoint 지점부터 게임 재시작. 예전에 대형 물약 먹은 게 반영됨 → 되돌아와서 대형 물약 또 먹음 → 클리어

물론 실제로 이렇게 하는 건 시간이 너무 많이 걸리는 노가다이기 때문에 현실성은 별로 없지만..
이건 아마 조던 메크너(오리지널 게임 설계자, Apple II용 개발자)와 랜스 그루디(도스용 게임 포팅 개발자)조차 그 당시 예상을 못 했던 꼼수일 것이다.
차라리 waypoint 이후에 도달하는 위치에다 대형 물약을 놔 뒀다면 이런 exploit가 틈탈 여지가 없었을 텐데.

자, 이런 글을 보니 나도 도스박스 깔아서 페르시아의 왕자를 실행해 보고 싶은 생각이 드시지는 않는가?

Posted by 사무엘

2014/06/29 08:21 2014/06/29 08:21
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/979

Trackback URL : http://moogi.new21.org/tc/trackback/979

Comments List

  1. 김진 2014/06/29 13:29 # M/D Reply Permalink

    이런 신기한 게 있었군요. 당시 여러 번 즐기면서도 몰랐던 것이 많네요. 이제는 조던 메크너의 소스코드가 공개되었으니 애플2 어셈을 알면 분석할 수도 있겠지만 만만치 않겠네요 :)

    1. 사무엘 2014/06/29 15:51 # M/D Permalink

      그 코드를 읽을 수 있는 사람은 (거의) 없을 테고..ㅎㅎㅎ
      원판을 PC 도스로 포팅한 랜스 그루디 옹에게는 옛날 소스가 없으려나 궁금합니다. PRINCE.EXE는 MS C로 빌드됐거든요.

Leave a comment

1.
아래아한글의 역대 버전 중, 96과 97은 실행되면서 스플래시 화면이 나올 때 짤막한 효과음(음악 멜로디)이 나오던 전무후무한 버전이었다.
96은 경쾌한 사과나무.wav (도~~ 미파솔..로 시작하는)이었고 97은 그것 말고도 여러 종류의 음향이 더 추가되었다. 물론 워디안 이후 후대부터는 그런 것 없고. 이런 것도 다 일시적인 유행이었다.

오늘날은 아예 Windows조차도 8부터는 로그인 로그아웃 소리가 없어졌다.
먼 옛날 3.x 시절에 사운드 카드가 지원된 이래로, 시작 효과음은 그 유명한 tada.wav부터 시작해 뭐가 들어가도 들어갔는데.. 완전히 없어진 건 8이 처음이다.

응용 프로그램을 실행하는 게 옛날만치 그렇게 막 유세 떨 일이 아니게 되어서 그런 것 같다.
설치 프로그램이 원래 전체 화면을 차지하는 형태이다가 조그마한 마법사 대화상자로 바뀐 것도 비슷한 맥락일 것이고 말이다.

2.
지금이야 MS Office 제품들이 리본 UI를 사용하여 인터페이스가 여타 프로그램과는 완전히 다른 형태로 바뀌었지만..
먼 옛날, Office 95 시절이 문득 생각난다.
Windows 95의 출시에 맞춰서 완전히 32비트로 포팅된 첫 버전이었으며, 동시에 Office가 운영체제의 표준 메뉴 인터페이스를 사용하던 마지막 버전이었다.
다만, 약간의 애드립이 생각지 못한 곳에 있었는데.. 아래 스크린샷에서 프로그램 상단의 타이틀/캡션 바 영역을 보시라.

사용자 삽입 이미지

Office 95 프로그램들은 처음이자 마지막으로 캡션 바를 자체적으로 그렸다.
그래서 Microsoft는 그냥 일반 폰트가 아니라 그 당시 쓰이던 MS 로고타입 형태 그대로 그려졌으며, 검은색에서 짙은 군청으로 바뀌는 그러데이션이 적용되어 있었다.
잘 알다시피, 캡션 바에 그러데이션이 추가된 것은 윈도 98부터이지 95엔 아직 그런 게 없었다. 응용 프로그램이 WM_NCPAINT를 처리하여 직접 그렸던 것이다.

정말 일시적인 유행이었지만 그 시절에 외국 프로그램 중엔 캡션 바를 이 스타일을 따라 그렸던 프로그램도 소수 있었다.

3.
사실 Windows는 GUI 외형이 Mac OS에 비해 매우 단순한 편이었고, 그 대신 색상을 다양한 스타일로 지정할 수 있었다.
그러던 것이 XP 이후부터는 큰 변화가 생겼다. Luna 테마는 파랑-은색-황록이라는 세 색상표만 지원했고, Vista부터는 Aero 창틀의 색깔만 사용자 지정이 될 뿐 나머지 색상은 고정 불변이 됐다. 예전의 재래식 외형은 '고전 테마'라는 legacy로 전락했다.

시스템 색상을 customize할 일이 없어졌다. GetSysColor 함수는 원래 수십 가지의 색상 요소들을 제공하지만 응용 프로그램은 사실상 COLOR_WINDOW(TEXT), COLOR_HILIGHT(TEXT), COLOR_BTNFACE 같은 것밖에 사용할 일이 없어졌다. 그리고 사실은, 선택된 아이템을 표시할 때도 COLOR_HILIGHT나 반전(InvertRect)이 아니라 엷은 파랑 효과를 쓰는 게 유행이 됐다.

옛날에 Microsoft Plus! 같은 확장팩이 제공했던 '테마'들은 색상, 마우스 포인터, 효과음을 한데 모은 세트였지만.. 지금은 Windows도 맥 OS처럼 어찌 보면 사용자 선택의 폭을 좁히고 있다. 지금의 외형 자체가 곧 Windows의 정체성과 같다는 점을 더욱 내세우려는 것 같다. 색상표는 이제 사실상 시각 장애자 내지 전력 절약용으로나 의미가 있는 '고대비'밖에 안 남았다.

4.
Windows는 파일/디렉터리 목록을 이름 순으로 정렬해서 표시하더라도 디렉터리(폴더)와 파일은 따로 분류해서 보여주는 반면, Mac OS는 이들을 다 한데 섞어서 보여준다. 디렉터리도 특수한 형태의 파일로 볼 것이냐, 아니면 아무래도 파일과는 개념적으로 다른 존재로 보느냐의 차이 같다.
또한 마우스 휠을 인식하는 대상도 Windows는 키보드 포커스를 받고 있는 창이지만, Mac은 마우스 포인터가 놓여 있는 창이다.

참, 맥OS는 메뉴나 대화상자에 액셀러레이터 키가 전혀 없는 게 굉장히 뜻밖이다.

5.
유튜브나 스마트폰의 동영상 재생 앱 등... 요즘은 이게 유행인지 모르겠지만
대부분의 멀티미디어 재생 컴포넌트들은 Pause(||) 버튼만 있지, 완전 정지 Stop(■) 버튼이 없다.

파일을 열었으면 나중에 반드시 닫아야 한다는 프로그래머스러운 사고방식에 사로잡혀 있는 본인 같은 사람에겐 그런 디자인이 심리적으로 좀 불안하게 느껴지기까지 한다. 정말 Stop이 없어도 될까? 굳이 프로그래머가 아니더라도 옛날 카세트 및 비디오 테이프 재생기 역시 기계적인 특성 때문에 Pause와 Stop은 성격이 상당히 다르기도 했고 말이다.

하지만 리소스 제약 같은 걸 생각하지 말고, 사용자의 입장에서 오로지 틀고 싶을 때 틀고 끄고 싶을 때 끄는 것만 생각하면, 원론적으로야 둘을 굳이 구분할 필요가 없긴 해 보인다.

6.
top-to-bottom과 bottom-to-top이 헷갈릴 때가 종종 있다.
당장 좌표계만 해도 수학에서는 아래에서 위가 y축의 양의 방향이지만.. 컴퓨터 화면에서는 위에서 아래가 y축의 양의 방향이다.

Windows에는 spin, 혹은 up-down이라고 불리는 컨트롤이 있다.
얘는 언제나 위에 있는 ▲ 버튼 혹은 위(↑) 화살표 키를 눌렀을 때 숫자를 증가시키고, 그 반대의 조작을 하면 숫자를 감소시킨다.
안타깝게도 이 동작을 정반대로 바꾸는 방법은 없는 듯하다. 컨트롤의 동작을 교묘하게 서브클래싱하지 않는 이상 말이다.

저 컨트롤은 <날개셋> 한글 입력기의 제어판에서 입력 항목의 배열 순서를 바꾸는 용도로도 쓰이는데..
입력 항목들은 위에서 아래로 오름차순으로 배열되어 있다.
그래서 ↑가 아니라 ↓를 눌렀을 때 숫자가 증가하고 아래로 가게 하고 싶으나 그렇게는 못 하고 있다.
이건 솔직히 사용자를 굉장히 헷갈리게 만들 수도 있는 면모이다.

사용자 삽입 이미지

이 외에도, 노트북의 터치패드를 손가락으로 상하 드래그를 했는데, 위에서 아래로 그었을 때 화면을 위에서 아래로 스크롤시킬지, 반대로 아래에서 위로 스크롤시킬지도 보통은 옵션으로 존재한다.
본인이 선호하는 건 위에서 아래로 그었을 때 화면은 아래에서 위로, 즉, 아래 페이지의 내용을 표시하는 것이다. ↓ 키를 눌렀을 때와 같다. 손가락은 전체 내용에 대한 화면(view)의 상대적인 위치와 같은 것이다.

그러나 손가락의 위치를 지금 표시되어 있는 텍스트의 상대적인 위치와 같은 것으로 본다면.. 소프트웨어의 동작은 저것과는 반대가 되어야 직관적일 것이다. 결국 이것은 사람마다 취향이 다른 답이 없는 문제이다.

Posted by 사무엘

2014/02/15 08:26 2014/02/15 08:26
,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/931

Trackback URL : http://moogi.new21.org/tc/trackback/931

Leave a comment

고전 게임 페르시아의 왕자에 대해서 더는 글을 쓸 일이 없을 것 같았는데 또 하나 글을 쓰게 됐다.
지금까지 까맣게 잊고 지냈던 게임 중 이벤트가 하나 갑자기 떠올랐기 때문이다.

잘 알다시피 페르시아의 왕자에는 주인공의 영혼(?)이 빠져나가는 듯한 이상한 이벤트가 있다.
레벨 4에서 클리어 관문을 열고 나오면 거울이 하나 생겨서 길을 가로막는다.
이 거울을 도움닫기 점프로 깨뜨리면 진행은 가능해진다. 하지만 이때 자기 영혼 내지 그림자? 도플갱어가 빠져나가고 그 과정에서 왕자는 HP가 1로 다 깎여서 죽기 직전의 상태가 된다.

도플갱어의 정체가 무엇인지, 제작자 조던 메크너가 무엇을 의도하고 이런 걸 넣었는지는 모르겠다.
다만, 이 도플갱어가 왕자에게 하는 짓은 결코 호의적이지는 않다.
레벨 6에서 뚱보를 죽인 뒤에 벼랑을 앞두고 서로 만났을 때는, 도플갱어가 문을 쾅 닫아서 왕자를 벼랑 아래로 빠뜨려 버린다.

그 뒤로 도플갱어는 한동안 등장하지 않다가 게임이 끝날 때가 다 된 레벨 12의 꼭대기 층에서야 등장한다. 원수진 것 때문에 서로 칼을 뽑고 대적하지만 그래도 성질 죽이고 칼을 집어넣고 서로 합체를 해야 살 수 있다. 재결합을 한 뒤에는 보상 차원에서인지 전체 체력이 1 증가된다.

이 글에서는 그 전에 레벨 5에서 발생하는 이벤트에 대해서 좀 분석을 해 봤다.
레벨 5에는 전체 체력을 1 늘려 주는 대형 물약이 있다. 그러나 이것은 우리 왕자가 먹을 수 없다. 도플갱어가 먼저 와서 진짜 말 그대로 정확하게 '먹튀'해 버리기 때문이다. 그게 무슨 말이냐고?

사용자 삽입 이미지

자, 옛날에 페르시아의 왕자를 해 본 경험이 있는 분이라면 옛날 생각이 나실 것이다.
1층과 3층에 문이 있는데 물약이 있는 3층 문은 닫혔기 때문에 낮은 1층으로 먼저 들어가야 한다.
1층 문을 진입하는 순간, 발판 때문에 문은 쾅 닫힌다. 왔던 길로 못 돌아간다. 미우나 고우나 “들어올 때는 마음대로였겠지만 나갈 때는 아니란다” 상태가 되고, 어떻게든 저 무시무시한 왕복 톱날 2개를 통과하여 물약을 먹으러 가야 한다.

톱날을 통과하면 곧장 1층과 3층 문을 모두 여는 발판이 우리를 기다리고 있다.
그런데 3층 문이 열리자마자 3층에서는 왕자의 도플갱어가 갑자기 튀어나와서 물약을 쳐묵쳐묵 한 뒤 달아나 버린다.
톱날을 지나면서 힘들게 묘기는 우리가 다 했는데 갑자기 저 녀석이 소중한 물약을 먹튀하다니..

일단, 맵의 디자인이 굉장히 교활하게 돼 있다는 걸 부인할 수 없다.
문을 여는 발판이 하나만 있어도 될 게 굳이 2개씩이나 있다. 왼쪽 것과 오른쪽 것 중에 오른쪽 것은 3층으로 올라가는 과정에서 무조건 밟지 않을 수가 없다. 둘 중 어느 것을 밟더라도 1층과 3층 문이 모두 열린다. 그리고 3층이 열리는 순간 왕자가 미처 3층으로 다 올라가기도 전에 도플갱어가 먼저 달려온다..

결국, 왕자가 3층으로 올라갈 때까지 저 문이 최대한 늦게 열리게 하려면..
두 발판을 밟지 않은 상태에서 왕자가 두 발판을 사이에서 오른쪽이 아닌 왼쪽을 보고 있는 상태를 만들어야 한다.
이게 꽤 어렵다. 그래도 오른쪽의 둘째 톱날의 앞에 바싹 붙어 선 뒤, 오른쪽으로 점프를 하면 왼쪽 발판을 밟지 않고 양 발판의 사이에 설 수 있다.

그 상태에서 3층으로 올라감과 동시에 3층 문이 열리게 하면 그나마 시간을 최대한 벌 수 있으나..

사용자 삽입 이미지

그래도 우리가 도플갱어보다 먼저 물약에 닿는 것은 여전히 불가능하다. 최선을 다해도 결국 위와 같은 차이가 난다는 것을 알 수 있었다.

그 다음으로 본인이 시도한 것은, 3층 문을 열어서 도플갱어가 들어올 때쯤 도로 1층으로 내려가서 문을 닫아 버리는 것이었다. 1층의 닫힘 발판은 1층 문뿐만 아니라 3층 문까지 한꺼번에 닫기 때문이다.

그런데 이것도 엄청나게 어렵다. 아까 저 그림처럼 3층 문을 열지 않은 상태에서 왼쪽을 보고 있는 상태를 먼저 만들어야 하는 데다, 거기에다 추가적인 묘기가 더 필요하기 때문이다.
준비됐으면 발판을 밟아서 3층 문을 연 뒤, 정확한 타이밍을 노려서 2개의 톱날을 도움닫기 점프로 한번에 통과하고 1층으로 떨어져서 닫힘 발판을 밟아야 한다! 타이밍이 안 맞으면 톱날에 찍혀 끔살당한다.

그래도 이것 역시 불가능한 일은 아니다.
그러나.. 그럼에도 불구하고..
악랄한 우리의 도플갱어는 닫힌 철문도 통과하고서 물약을 훔쳐 먹고 유유히 사라지는 걸 알 수 있었다.

사용자 삽입 이미지

이 정도면 정말로 답이 없고 불가능이긴 하다.

2중 톱날은 왕자의 진행 속도를 크게 낮추는 어려운 트랩이다.
레벨 8의 경우, 클리어 관문을 열기 위해서 2중 톱날을 왕복으로 통과해야 한다.
그러고 나니까 철문이 닫혀 있어서 꼼짝없이 갇혔는데, 이때 공주가 보낸 생쥐가 문을 열어 주는 게 원래의 설정이다.
하지만 잘 알다시피 2중 톱날도 아무 거리낌없이 통과하여 철문이 완전히 닫히기도 전에 자력으로 빠져나오는 것도 불가능하지는 않다. 유튜브에서 괴수들의 플레이 동영상을 보면 그런 게 있다.

사용자 삽입 이미지사용자 삽입 이미지
(생쥐가 굳이 출동할 필요가 없다!)

레벨 8에는 그런 플레이가 있는 반면, 레벨 5에서 도플갱어를 따돌리고 대형 물약을 먹는 데 성공했다고 하는 테크닉이나 플레이 동영상은 인터넷에 전혀 존재하지 않는다. 불가능한 일이기 때문이다.

MEGAHIT 치트를 써서 게임을 실행한 뒤, 도플갱어가 등장하는 장면에서 K(현재 화면에 있는 몹을 죽임)를 누르면 도플갱어가 사라진다. 이를 활용하면 레벨 5에서 대형 물약을 먹을 수 있게 되며, 레벨 6에서도 도플갱어가 있는 절벽 건너편으로 올라가는 것도 가능해진다. 하지만 이건 언제까지나 치트를 써서 만들어 낸 결과일 뿐이다.

참고로, 2007년에 나온 3D 리메이크작인 <페르시아의 왕자 클래식>은 이 시스템이 좀 개선되었다.
2층에서 3층 문을 열었다가 1층으로 잽싸게 되돌아와서 그 문을 닫아버리면, 도플갱어는 왔다가 물약을 못 훔치고 되돌아간다. 그래서 레벨 5에서도 대형 물약을 먹고 체력을 늘리는 것이 가능하다!
리메이크작은 톱날이 2개이던 것이 1개로 줄고 왕복 주기도 원작보다 훨씬 더 길기 때문에, 통과하기도 쉽다.

사용자 삽입 이미지

Posted by 사무엘

2014/01/21 08:32 2014/01/21 08:32
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/922

Trackback URL : http://moogi.new21.org/tc/trackback/922

Leave a comment
« Previous : 1 : 2 : 3 : 4 : 5 : 6 : 7 : 8 : ... 10 : Next »

블로그 이미지

철도를 명절 때에나 떠오르는 4대 교통수단 중 하나로만 아는 것은, 예수님을 사대성인· 성인군자 중 하나로만 아는 것과 같다.

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

«   2018/12   »
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31          

Site Stats

Total hits:
1074599
Today:
207
Yesterday:
713