• 2006-02-10

    파일럿 무비

    오늘 한 달동안 작업한 테크니컬 데모의 중간 버전을 프리젠테이션을 위한 동영상으로 만들어서 (한달동안 두명이서 한 것이라는 코멘트를 잊지 말라는 당부와 함께) 미국에 넘겼다. 화질, 코덱, 용량, 업로드 같은 사소한 문제 때문에 삽질을 조금 했지만 어쨌든 무사히 넘길 수 있었다. 디자이너가 없어서 이전 버전의 리소스를 거의 그대로 사용했고, 카메라 연출 같은 건 신경도 쓰지 못해서 좀 아쉽긴 하다.

    어쨌든 시간이 좀 남았길래 저녁 무렵 사원들을 모아놓고 완다와 거상 예약판의 부록으로 따라온 이코와 완다의 파일럿 무비를 함께 관람하는 시간을 가졌다. 게임을 모르는 사람도 있어서 파일럿 무비와 최종 게임 동영상도 함께 보면서 이야기를 나누었는데, 만족스럽진 않았지만 어쨌든 다음 갈 길에 대한 합의를 볼 수 있었다.

    대체로 기능 구현만을 근근히 마친 프로토타입을 개발하고 이를 실제로 시연하면서 경영진에게 게임의 특징을 하나씩 보여주는 게 보통인데, 파일럿 무비의 경우 처음부터 동영상으로 편집할 것을 감안해서 목표로 하는 게임성을 선택적으로 구현할 수 있기에 꽤 매력적인 것 같다. 그리고 보여주고 싶은 것만 보여줄 수 있으므로 게임의 비전에 대한 공유가 프로토타입 시연보다 더욱 효과적일 것이다. (참고로, 시연자가 잘못하면 보는 사람이 뭘 봐야 할지 모르게 될 수도 있다 -_-) 시연하면서 다운될 것도 걱정하지 않아도 되고, 갓 들어온 신참 교육용으로도 무지 좋으며, 나중에 게임이 대박이 나면 부록 DVD에 이 영상을 넣을 수도 있다!!

    앞으로 예상하는 개발 프로세스는 대충 이렇다. 일단 새 엔진을 이용한 테크니컬 데모를 통해서 기술적인 방향을 공유하고, 프로토 타입 대신 파일럿 무비를 제작해서 게임성을 공유한 다음, 실질적인 제작에 들어간다는 것이다. 그때까지는 어쩔 수 없이 하드 코딩을 해야겠지만, 개발 도중 의견 충돌 때문에 엎어버린다든지, 낙하산 때문에 배가 산으로 간다든지 하는 위험을 줄일 수 있을테니 어찌 선택하지 않을 수 있으랴...

    더 관심이 있는 사람은 서관희님의 관련글을 참고하시길...

    ps. 동영상 편집의 세계는 멀고도 험하다.

  • 2006-02-05

    Ogre for PSP

    http://www.ogre3d.org/images/M_images/ogrebtn.png PSP에서 3D 프로그래밍을 하는 법을 검색하다가 우연히 Ogre3D 엔진이 PSP로 포팅된다는 이야기를 Ogre 포럼에서 찾아냈다. PPC 포팅을 담당한 개발자가 하는 김에 PSP포팅도 맡겠다는 이야기인 듯한데... 2월 내에는 나오지 않을까 하는 희망을 품어본다. SDL 특히 pygame이 포팅된다는 소문도 들리는 시점에, Ogre3D까지 포팅이 되면 결국 PSP에서는 python으로도 3D 프로그래밍이 가능해진다는 소리가 되는 셈이다.

    그나저나 OGRE를 보고도 /오우거/ 대신 글자 그대로 장난삼아 읽던 /오그레/라는 발음이 연상되어 큰일이다;;

    ps. LuaPlayerPSPGL 기반으로 재작성되고 있는 중인데, 3D보다는 2D쪽 기능에 한정될 것 같다.

  • 2006-02-02

    ALTER TABLE ALTER COLUMN

    총 15개의 통계 테이블의 리팩토링이 드디어 오늘 끝났고, 내일 테스트만 무사히 통과하면 다음 작업으로 넘어갈 수 있을 것 같다. arithmetic overflow 로 인해 모든 numeric 관련 로직을 계산 컬럼으로 추출해내고 하나씩 검증하는데 이틀이나 날려 먹었던 것이다. 실제로 이백라인에 가까웠던 프로시저가 거의 30% 정도로 분량이 줄었고 각 쿼리문들 역시 간단한 DDL 로 바뀌게 되었는데, 솔직히 너무 허탈하다. :(  

    테스트가 성공리에 끝이 나면, 이제 남은 이슈는 본섭 패치를 얼마나 손쉽게 자동화할 것인가? 이다. 변경된 프로시저의 경우 drop - create 로 해결할 수 있지만, 계산 컬럼으로 바꾸는 것은 녹녹치 않았다. 문제는 한번도 관리되지 않았던 DEFAULT constraint 들 때문인데...

    • ALTER TABLE ALTER COLUMN 으로 일반 컬럼을 계산 컬럼으로 바꿀 수 없다
    • 결국 DROP COLUMN + ADD COLUMN 으로 해결해야 한다
    • DROP COLUMN 을 하려면 의존 관계가 없어야 한다
    • 그런데 바꿔야할 모든 컬럼들이 DEFAULT 제약조건을 가지고 있었고, 얘네들의 이름이 모두 랜덤이다. -_-

    일단 DBA 와 상의해봐야 되겠지만 어째 해결책은 없을 듯하다. 따라서 오늘의 결론은

    "모든 DEFAULT 제약 조건에 이름을 붙여라"

  • 2006-02-01

    computed column & divide by zero

    A = ( C != 0 ? B/C : 0 )

    이러한 수식으로 구성된 계산 컬럼은 TSQL에서는 아래와 같이 표현할 수 있다.

    [A] AS ( case when [C] = 0 then 0 else [B]/[C] end )

    문제는 B 나 C 가 여러 컬럼으로 이루어지거나 또 다른 계산 컬럼일 경우이다. TSQL에서는 계산 컬럼이 다른 계산 컬럼을 내포할 수도 없고, 사용자 정의 함수를 포함할 수도 없기 때문에, 울며 겨자먹기로 중복 코드를 허용해야만 한다. 덕분에 오늘 현업에 들어온 이래, 가장 긴 계산 컬럼을 만들어볼 수 있었다.

    (case when ([AB] + [BB] + [HBP] + [SF] = 0) then 0.0 else (convert(numeric(9,3),([H] + [BB] + [HBP])) / ([AB] + [BB] + [HBP] + [SF])) end + case when ([AB] = 0) then 0.0 else (convert(numeric(9,3),([H] + [B2] * 2 + [B3] * 3 + [HR] * 4)) / [AB]) end)

    계산 컬럼의 내포가 되었다면 단순히 A+B 정도로 끝날 수도 있었고, 사용자 정의 함수만 지원했어도 SafeDiv(...,...)+SafeDiv(...,...) 정도로 줄일 수 있었는데.. 쩝.

    그런데 아래의 SET 옵션을 잘 이용하면 divide by zero를 우회함으로써 수식을 간단하게 표현할 수 있다. 어차피 계산 컬럼은 SELECT 에서만 사용되기 때문에 관련 SELECT 쿼리 앞뒤에 잘 지정하면 될 듯하지만, 이런 것도 된다는 것이며 추천하지는 않는다.

    SET ARITHIGNORE ON -- 에러 메시지 출력 안함

    SET ARITHABORT OFF -- 종료하는 대신 NULL 삽입

    [A] AS (ISNULL(A/B,0.0))

    상황에 따라서는 SET ANSI_WARNING OFF 도 함께 지정해줘야 하는 경우도 있으므로 유의하기 바란다. 관련 사항을 테스트해준 floyd, icebreak 님께 감사를~

  • 2005-12-28

    OS 재설치후 소스세이프가 바보가 될 때

    파일을 체크아웃 받은 상태에서 OS 를 새로 설치할 때, 컴퓨터 이름을 이전과 같이 해야 한다. 소스세이프는 체크아웃된 위치를 컴퓨터 이름과 working folder 를 조합해서 사용하기 때문에, 컴퓨터 이름이 다르다면 다른 곳에 체크아웃을 했다고만 나온다.

    *괜히 삼성카드 홈페이지에서 연말정산 서류 플러그인을 설치하다가 애꿎은 OS만 날려먹었다. 소송해버릴까.. *