Dirty Coding Tricks @ Gamasutra

게임 제작 관련 웹사이트인 가마수트라에 아주 재미있는 기사가 하나 올라왔네요. 일명 '더러운 코딩 속임수'라는 제목으로, 데드라인에 몰린 게임 프로그래머들이 어떻게든 기일을 맞추기 위해 사용한 임시 방편들에 대한 이야기인데요, 더욱 무서운 것은, 모두 실화들이라고 합니다 --a

실제 기사는 위 링크를 따라가면 보실 수 있고 (영어입니다), 시간과 영어의 압박을 느끼시는 분들을 위해 아래에는 제가 재미있다고 생각한 몇 개의 요약을 올려 봅니다.


아, 주의 사항으로, 프로그래밍을 안 해 보신 분들에게는 재미가 없는 얘기도 다소 있습니다.



* Shoot Me From My Good Side 얼짱 각도로 찍어줘

- 모 멀티플랫폼 게임의 PS2 버전에 대한 작업 중, 1스테이지 도입부에서 때때로 게임이 얼어버리는 현상이 발생함. 불행히도 이는 디버깅 정보가 없는 디스크 릴리즈 버전에서만 발생
- 코드 수정->디스크 굽기->게임 실행하여 버그 확인의 과정이 굉장히 오래 걸림
- 이 과정 중에서, 누군가가 카메라 각도가 오른쪽 90도로 잡혀 있을 때는 버그가 발생하지 않는다는 것을 발견
- 데드라인이 다가오면서, 결국 최종 버전에 카메라 각도를 오른쪽 90도로 고정한 채로 출시
- 이와 관련된 고객 불만사항은 접수된 바 없음 -_-


* Identity Crisis 정체성의 위기

- 그 전까지 잘 돌던 게임의 최종 빌드를 만들었는데, 게임이 얼어버림
- 문제는 게임 데이터를 관리하는 시스템에서 발생. 모든 데이터 파일의 ID는 64비트로, 파일명의 CRC32 해시와 실제 데이터 내용의 CRC32 해시의 조합으로 생성. 이 시스템으로 수만 개의 파일을 2년간 관리했으나 지금까지 전혀 문제가 없었음
- 근데 이번에 다른 데이터 파일과 한 텍스트 파일이 우연하게도 같은 ID를 갖게 된 것이었고, 그걸 덮어쓰면서 문제가 발생
- 데드라인은 다음날 아침, 밤새 자원 관리 시스템을 고친다 하더라도, 그것이 문제없이 잘 돌 수 있으리라는 보장은 없음. 모두 절망함
- 어떻게 해결했냐고? 문제가 된 텍스트 파일을 열어서, 파일 마지막에 빈 칸을 하나 넣은 후 다시 저장하여 해결함. 푸헉-_-


* Driving Under the Influence 음주운전
- 다른 사람이 짠 소스 코드를 보는 도중, 다음 코드를 봄

//**************************************************
// Function: AGameVehicle::Debug_GetFrameCount
//
//! A very hacky method to get the current frame count; the variable is protected.
//!
//! \return The current frame number.
//**************************************************
UINT AGameVehicle::Debug_GetFrameCount()
{
BYTE* pEngineLoop = (BYTE*)(&GEngineLoop);
pEngineLoop += sizeof( Array ) + sizeof(
DOUBLE );
INT iFrameCount = *((INT*)pEngineLoop);
return iFrameCount;
}

- 더욱 웃긴건, 같은 오브젝트에 프레임 카운트를 되돌려주는 함수가 분명 존재하고 있었음
- 원 코드를 쓴 사람은, 제정신이 아니었음이 분명함-_-


* 10-Tative Code
- 게임 개발 막판에, 10레벨에서 숨겨져야 하는 오브젝트가 존재했는데, 레벨 전체를 뜯어 고치거나 체크섬을 사용하기는 싫었음
- 그래서 다음 코드를 사용함

if( level == 10 && object == 56 )
{
HideObject();
}

- 약 1년후, 우리 엔진을 사용하는 한 아트 담당자가 10레벨로 오브젝트를 옮긴 후 레벨에 안 나타난다고 불평함. 흠, 과연 왜 그런 현상이 일어났을까나?-_-


* Meet My Dog, Patches 제 애완견 '땜질'입니다
- pc용 3인칭 슈팅 게임을 PS1으로 컨버전 하는 중 발생한 일임
- ps1은 부동소수점 지원이 없던 관계로 모든 부동소수점 데이터를 정수로 변환하는 과정이 필요했음. 이 과정에서 충돌점 측정(collision detection)이 완전히 망가짐
- 이로 인해 만들어진 아주 작은 구멍들로 주인공 Damp가 빠져서 나오지 못하는 버그가 무수히 발생
- 처음에는 발견한 구멍들을 하나씩 고쳤지만, 출판사의 플레이테스팅에서 매일같이 수십개의 '구멍'들을 발견하여 보고가 들어옴
- 결과적으로 사용한 코드는 다음과 같음

damp_old = damp_loc;
move_damp();
if (NoCollision())
{
damp_loc = damp_old;
}

- 말하자면, 다음과 같은 일을 하는 코드임

IF (Damp will fall through a hole()) THEN
Don't do it

뎀프가 구멍으로 빠질 것 같으면 -> 하지 말아라-_-

- 결국 이런 식의 '땜질'로 구멍으로 빠지는 주인공은 막을 수 있었지만, 땜질 때문에 또 다른 땜질이 필요해지고, 이로 인해 원래 계획보다 몇 달이 늦어졌고, 그 몇 달은 대부분 하루에 14시간 이상 일해야만 했음
- 교훈: 문제가 발생하면 땜질로 처리하지 말고 버그를 원인부터 철저히 수정하자


* You Wouldn't Like Me When I'm Angry 날 화나지 않게 하는게 좋을거야
- XBOX360용 The Outfit을 개발하던 중 있던 일. 출시 약 3달 전, 게임은 약 5 fps의 속도로 돌고 있었음. 상당히 심각한 최적화가 필요.
- 엔진에도 문제가 있었지만, 가장 큰 요인은 게임의 내용. 모델이 너무 복잡하던가, 일부 셰이더가 너무 계산이 많이 필요하던가, 캐릭터가 너무 많은 스테이지 등. 하지만 약 100여명의 팀원들을 하나하나 설득하여 이런 것들을 줄이는 건 거의 불가능.
- 해결책은 약 한 시간 정도 걸림. 동료 프로그래머 한 명이 내 얼굴을 찍은 그림을 구석에 집어넣음. 게임이 30 fps 이상으로 돌고 있으면 웃는 얼굴이 뜨고, 20 이하로 돌면 점점 화난 얼굴로 바뀌는 형태.
- 이로 인해 속도 문제에 대한 사람들의 생각은 "에이, 프로그래머들이 고칠 거야 아마."에서부터 "흠, 내가 이거 넣으면 닉(글쓴이)이 매우 화낼거야! 최적화를 좀 더 해 봐야겠다."로 바뀜


* The Programming Antihero 프로그래밍 반영웅
- 늦은 90년대 한 pc 게임 프로젝트의 막판, 게임 내용은 다 좋았지만, 메모리 용량을 다소 초과하는 상태였음
- 며칠간 정말 가능한 모든 방법을 동원하여 죽어라 고생하여 메모리 사용을 줄였지만, 여전히 1.5메가 정도가 초과됨
- 이런 상황에서, 팀 내 가장 경험 많은 분 중 한 명이 직접 문제를 해결하겠다고 함. 필자는 또 메모리를 줄이는 고된 시간이 될 것을 예상하고 그의 사무실로 들어감
- 하지만 그는 한 소스 파일을 열고 아래의 코드를 보여줌

static char buffer[1024*1024*2];

- 그리고 이 줄을 지워버림. 문제 해결!
- 놀란 필자에게 고참 프로그래머 왈, 이 2MB의 메모리는 그가 개발 초기에 만들어 놓은 예비 메모리라고 함. 그의 경험상 프로젝트 말기에 메모리를 줄이는 것은 거의 불가능하므로, 사전에 예비 메모리를 확보해 놓았다는 것.
- 그는 사무실 밖으로 걸어 나가 메모리 용량을 만족시키게 했다고 선언, 단번에 영웅이 됨-_-

프로그래밍, 임시방편, 실화

이 글과 관련있는 글을 자동검색한 결과입니다 [?]

• C 포인터, 확실히 알자(1) - 변수와 포인터 by 시즈하