쉬운 것은 올바르다

목표와 방법

(조순현) — Sat, 06 Mar 2010 14:20:58 +0900

When I am working on a problem, I never think about beauty. I think only how to solve the problem. But when I've finished, if the solution isn't beautiful, I know it's wrong. - Buckminster Fuller

사람들은 흔히 방법을 목표보다 중요하게 생각합니다. 그러나 어떤 방법을 쓰든지 목표를 이루는 게 가장 중요합니다. 어떤 행동이 목표에 크게 영향을 주지 않는다면, 그 행동의 방법에 매달리는 것은 좋지 않습니다.

예전에 볼링을 하러 간 적이 있습니다. 참고로, 저는 볼링을 거의 안 해 봐서, 잘 못했습니다. 어쨌든, 주위를 둘러 보니, 자세나 기술이 좋은 사람이 꽤 있었습니다. 선수 뺨치는 자세를 보여 주는 사람도 있었고, 회전을 많이 줘서 던지는 사람도 있었습니다. 하지만, 점수가 가장 높았던 사람은, 자세가 어설프고 공도 직구로만 굴리며 공을 떨어뜨릴 때 꽤 큰 소리가 나는 사람이었습니다.

그 사람을 자세히 관찰해 보니, 두 가지 부분만 신경쓰는 듯했습니다. 하나는 힘이고, 또 하나는 핀을 맞추는 위치입니다. 그 두 가지만큼은 누구보다도 정확했습니다. 다른 사람이 자세나 회전처럼 점수에 크게 영향을 주지 않는 부분에 신경쓰는 동안, 그 사람은 점수에 가장 큰 영향을 주는 두 가지 부분만 신경쓰고 있던 것입니다. 그러니 점수가 당연히 높게 나올 수밖에 없었습니다.

목표는 방법보다 언제나 우선합니다. 그것을 염두에 둘 때, 목표를 효율적으로 이룰 수 있습니다.

폴리곤 수를 줄이는 미들웨어(Middleware)

(조순현) — Sun, 14 Feb 2010 21:33:00 +0900

사용해 본 적은 없지만, 이런 것들이 있다기에 정리해 둡니다.

Simplygon, Action3D, Polygon Cruncher

요즘은 폴리곤 수가 그다지 문제되진 않는 것으로 알고 있습니다만, 그래도 어느 정도 최적화는 필요하겠죠.

게임용 라이팅(Lighting) 미들웨어(Middleware)

(조순현) — Sun, 14 Feb 2010 01:50:10 +0900

실제로 사용해 보진 않아서 잘 모르지만, 대략 다음과 같은 것이 있나 봅니다.

RTTGroup, Turtle, Beast, Lightsprint

Beast와 관련된 설명 자료는 The Unique Lighting of Mirrors Edge와 Beauty from the Beast: Using Global Illumination to Enhance the Visual Quality of Your Game에서 더 볼 수 있습니다.

Lightsprint는 실시간 global illumination을 지원하는군요. 성능이 얼마나 나올지는 모르겠지만, 독특한 미들웨어네요. 조명 전처리 때문에 생기는 레벨 디자인 확인 지연을 없앨 수 있다는 점에서는 가치가 있겠습니다.

참고로, Image-Based Lighting도 좀 더 섬세한 정적 조명을 표현하는 방법입니다. 하지만, 그래픽 아티스트가 이미지를 일일이 뽑아 내야 한다는 단점이 있습니다. 맥스 스크립트 등을 활용하면 좀 더 쉬워질 수는 있지만, 그렇다 해도 자동화가 상당히 어렵습니다. 그래서 이런 미들웨어를 활용해 정적 조명 전처리를 완전히 자동화하는 게 생산성 측면에서 더 나은 것 같습니다.

가시성 최적화 미들웨어(Middleware)

(조순현) — Sun, 14 Feb 2010 01:44:41 +0900

Umbra Software라는 곳에서 가시성 최적화 미들웨어를 판매하고 있네요. 비슷한 미들웨어가 더 있을 것 같은데, 찾아 보진 않았습니다.

여유 자금이 있다면 이런 미들웨어를 구입해서 가시성 최적화 문제를 해결하는 게 좋은 것 같습니다. 레벨 디자인 단계에서부터 레벨 디자이너가 가시성 최적화를 고민하는 것도 한 가지 방법일 것입니다. 하지만, 게임 개발자는 사용자에게 즐거움을 줄 만한 창의적인 일을 해야 하는 것이고, 기술적인 문제에 대한 고민에 노력을 많이 투자하는 것은 좀 아깝습니다.

게임 엔진은 게임 개발의 결과물이어야 합니다

(조순현) — Wed, 27 Jan 2010 20:02:44 +0900

엔진을 만들 때, 많이 실수하는 부분이 있습니다. 그건 바로 엔진을 먼저 만들고, 엔진을 이용해 게임을 만드는 것입니다. 기본적인 것을 먼저 구현하고 그 위에 부가적인 요소를 올리는 게 처음엔 맞는 것처럼 보입니다. 하지만, 실제로 작업해 보면 반대라는 것을 알게 됩니다.

게임을 만들 때엔 다른 것은 생각하지 말고, 게임을 만드는 데에만 집중해야 합니다. 게임을 만들고 나면 자연스럽게 재활용 가능한 기본적인 부분이 보이고, 그걸 따로 정리하면 엔진이 되는 것입니다. 그런데 하나의 프로젝트만으로는 어디까지가 엔진이 돼야 할지가 명확하지 않습니다. 여러 게임을 개발해 보면 각 게임의 컨텐츠와 무관한 코드를 좀 더 명확히 알 수 있게 됩니다.

엔진을 개발하고 싶다면, 게임을 먼저 개발해야 합니다. 그게 훌륭한 엔진을 만드는 방법입니다.

컴퓨터 그래픽스에서 앨비도우(Albedo)의 뜻

(조순현) — Tue, 19 Jan 2010 00:07:49 +0900

앨비도우는 반사율인데, 일반적으로 분산광에 대한 반사율을 말합니다. 그래서 분산 텍스쳐 (diffuse texture)를 앨비도우라고도 부릅니다. 그런데 때로는 반사광에 대한 반사율도 specular albedo라고 부를 때가 있어서, 혼란스럽습니다. 용어는 되도록 하나로 통일되면 좋겠습니다.

즉흥적인 결정을 피할 것

(조순현) — Sun, 17 Jan 2010 21:20:12 +0900

결정을 서둘지 말라. 하룻밤을 자고 나면 좋은 지혜가 생긴다. - 푸시킨

게임 개발을 하다 보면, 어떤 일을 결정해야 할 때가 잦습니다. 그런데 이런 상황에서 주의 깊게 생각해 보지도 않고 결정을 내리는 것은 좋지 않습니다. 생각은 즉흥적으로 할 수 있지만, 그 생각을 실제 행동으로 옮기는 것엔 신중해야 합니다. 왜냐하면 한 번 행동으로 옮긴 것을 되돌리는 것은 생각을 바꾸는 것보다 훨씬 어렵기 때문입니다. 즉흥적인 결정 뒤엔 언제나 후회가 뒤따릅니다.

게임 재미에 대한 연구의 필요성

(조순현) — Sun, 17 Jan 2010 21:08:20 +0900

게임을 개발하다 보면, 사용할 기술에 대해 어느 정도 시간을 갖고 연구할 때가 있습니다. 그런데 신기하게도, 만들 게임의 재미에 대해 연구하는 사례는 거의 못 본 것 같습니다.

다른 게임을 참고하면서 필요한 시스템을 기획하는 것은 흔한 일입니다. 그런데 정작 그 시스템이 왜 재미있는지, 어떻게 해야 더 재미있을지, 그리고 자신의 게임에 접목했을 때 어떤 일이 일어날 것인지를 기획자뿐만 아니라 팀원 전체가 함께 고민하는 일은 드뭅니다. 더 나아가서, 다른 게임에 없는 재미있는 시스템에 대해 고민하고 함께 토론하는 문화는 정말 드뭅니다.

게임은 기술이 주가 아니라 재미가 주가 돼야 합니다. 최신 기술을 연구할 시간에 재미에 대해 더 연구하는 게 훨씬 이득입니다.

C++에서 비트 연산자를 쓸 때엔 우선순위를 항상 생각할 것

(조순현) — Sun, 17 Jan 2010 20:59:09 +0900

C++을 어렵게 느껴지게 하는 것 중 하나로 연산자 우선순위가 있습니다. C++ 연산자 우선순위는 어떤 자연스러운 규칙에 의해 이해할 수 있는 게 아닙니다. 언어 제작자가 자신이 좋아하는 방식대로 정해 놓았을 뿐이고, 언어를 배우는 사람은 이해가 안 돼도 따라야 하는 규칙일 뿐입니다.

특히 비트 연산자의 우선순위는 상당히 의문스럽습니다. <<나 >>와 같은 비트 연산자는 ==, <=, >=, 그리고 !=와 같은 비교 연산자보다도 우선순위가 낮습니다. 그래서 비트 연산자를 괄호로 묶어 주지 않으면, 예상과 전혀 다른 동작을 할 때가 잦습니다.

비트 연산자가 있는 코드가 제대로 동작하지 않는다면, 연산자 우선순위를 꼭 확인해 봐야 합니다.

데이터 수동 입력을 줄이기 위해서 네이밍(Naming)을 활용할 것

(조순현) — Sun, 17 Jan 2010 20:45:26 +0900

네이밍이 무엇인지 아는 사람은 많지만, 네이밍을 어떻게 활용해야 좋을지 아는 사람은 드문 듯합니다. 데이터 관리에서 네이밍이 효과를 제일 발휘할 때는, 손으로 입력하는 것을 줄이는 것입니다.

예를 들어, 아이디가 A라는 무기가 있다고 하겠습니다. 이 무기의 이름은 big sword이고, 메쉬는 big_sword_mesh.mesh, 아이콘 이름은 big_sword_icon.tga입니다. 이 무기를 관리하려면 위의 값을 따로 입력해서 어딘가에 파일로 저장해 두어야 합니다. 무기가 한 두 개라면 상관 없겠지만, 무기 수가 늘어날수록 관리해야 할 데이터가 계속 늘어나게 됩니다. 더 큰 문제는 데이터가 늘어나면 그만큼 실수도 늘어난다는 것입니다.

위의 예에서 발생하는 문제를 쉽게 해결하려면 네이밍을 사용하면 됩니다. 메쉬는 .mesh를, 아이콘 이름은 .tga를 아이디에 붙여서 표현한다라고 정하면, 별도의 파일에 메쉬 이름과 아이콘 이름을 기록할 필요가 없습니다. 위의 예에선 각각 A.mesh, A.tga가 되겠습니다. 아이디 대신에 무기의 이름을 활용하면 이해하기 더 쉽겠지만, 파일 이름으로 표현하기 어려운 이름이 많으므로 논의를 통해 결정하는 게 좋습니다.

프로젝트 관리의 핵심은 덜 중요한 일에 자원을 적게 할당하고, 더 중요한 일에 자원을 많이 할당하는 것입니다. 네이밍은 그런 일을 가능하게 하는 방법 중 하나입니다.