기록공간

한 개체가 여러 분야를 서로 커플링 없이 다룰 수 있게 한다. 플랫포머 게임을 만든다고 해보자. 슈퍼 마리오 게임을 만든다고 하자. 그러면 마리오를 대표하는 클래스를 하나 만들어서 여기에 주인공이 게임에서 하는 모든 것들을 넣는 게 당연하다. 주인공을 조장해야 하니 컨트롤러 입력 값을 읽어 행동으로 바꿔야 한다. 지형이나 발판(플랫폼) 같은 레벨과도 상호작용할 수 있도록 물리 및 충돌 처리도 필요하다. 주인공이 화면에 나와야 하니 애니메이션과 렌더링도 넣어야 한다. 당연한 소리처럼 들린다. 점점 엉망진창이 되어간다는 느낌이 든다. 분야가 다른 코드는 서로 격리해야 한다고 배웠을 것이다. 워드 프로세서를 예로 든다면 인쇄 코드가 문서를 열고 저장하는 코드에 영향을 받으면 안 된다. 게임은 사무용 소프트웨어..

클래스 하나를 인스턴스 별로 다른 객체형으로 표현할 수 있게 만드어, 새로운 '클래스들'을 유연하게 만들 수 있게 한다. 의도 개발 중인 판타지 RPG에서, 포악한 몬스터 무리를 구현해야 한다고 해보자. 몬스터는 체력, 공격력, 그래픽 리소스, 사운드 등 다양한 속성이 있지만 여기서는 체력과 공격 속성만을 고려한다. 모든 몬스터에는 체력 값이 있다. 체력은 최대 체력에서 시작해 피해를 입을 때마다 조금씩 줄어든다. 몬스터에게는 공격 문구(attack string) 속성도 있다. 몬스터가 영웅을 공격할 때, 이 공격 문구는 유저에게 표시된다. 기획자는 '용'이나 '트롤'같이 몬스터 종족(breed)을 다양하게 만들고 싶어 한다. 각 종족은 몬스터의 특징을 나타내고, 던전에는 같은 종족 몬스터가 여러 마리 ..

"상위 클래스가 제공하는 기능들을 통해서 하위 클래스에서 행동을 정의한다" 아이들을 누구나 슈퍼히어로가 되고 싶어 하지만, 안타깝지만 현실적으로 봤을 때 실현 불가능하다. 이런 아이들이 슈퍼히어로를 가장 그럴싸하게 체험할 수 있는 수단이 바로 게임이다. 기획자는 게임으로 뭐든 만들 수 있다고 생각하는 사람들이기 때문에, 슈퍼히어로 게임에서는 수십 개가 넘는 다양한 초능력을 선택할 수 있어야 한다. 먼저 Superpower라는 상위 클래스를 만든 후에 초능력별로 이를 상속받는 클래스를 정의하려고 한다. 기획서를 나눠서 받은 프로그래머들이 구현을 마치고 나면 수십 개가 넘는 초능력 클래스가 만들어져 있을 것이다. 유저가 어릴 때 꿈꿔왔던 어떤 초능력이라도 모두 쓸 수 있는 풍부한 게임 월드를 제공하고 싶다...

개발에서 게임분야는 재미있을지는 몰라도, 절대 쉽지 않다. 요즘 게임을 만들기 위해서는 엄청난 양의 소스 코드를 구현해야 한다. 심지어 유통사에서 품질을 엄격히 심사하기 때문에 버그나 크래시가 나는 경우 출시가 불가능해진다. 또한 플랫폼의 성능도 최대한 뽑아내야 한다. 게임은 다른 소프트웨어보다 성능이 중요하다. 성능이 나오도록 하기 위해서는 불가피하게 최적화 작업이 필요하다. 게임 개발은 성능과 안전을 위해 C++과 같은 중량 언어(Heavyweight language)를 사용한다. 이런 언어는 하드웨어 성능을 최대한 끌어낼 수 있는 저 수준 표현과 버그를 막거나 회피하기 위한 시스템을 함께 제공한다. 게임 개발자 되기 위한 비용은 만만치 않다. 몇 년간 집중 훈련이 필요하고, 그런 후에도 엄청난 규모..

"객체별로 한 프레임 단위의 작업을 진행하라고 알려줘서 전체를 시뮬레이션한다." 우리는 플레이어가 되어 보석을 훔치는 퀘스트를 진행하고 있다 가정해보자. 보석은 오래전에 죽은 왕의 유골에 놓여 있다. 플레이어는 왕의 장엄한 무덤 입구로 다가갔고, 함정이 있었지만 공격을 받지 않았다. 또한 언데드 전사는 입구를 지키고 있지 않았다. 그냥 무덤으로 들어가 보석을 가져왔다. 게임은 끝났고, 플레이어는 퀘스트를 완료했다. 뭔가 이상하지 않은가? 무덤에는 무찔러야 하는 경비병이 지키고 있어야 한다. 해골 병사를 되살려 문 주위를 순찰하게 만들자. 코드를 간단하게 만들면 다음과 같을 것이다. while(true) { // 오른쪽으로 간다. for(double x = 0; x < 100; ++x) { skeleton..

"게임 시간 진행을 유저 입력, 프로세서 속도와 디커플링한다." 게임 루프 패턴은 모든 게임에서 사용하며, 어느 것도 서로 똑같지 않고, 게임이 아닌 분야에서는 그다지 쓰이지 않는다는 점에서 전형적인 '게임 프로그래밍 패턴'이다. CPU와의 인터뷰 과거의 프로그램은 한참 기다려야 결과를 볼 수 있었다. 이를 배치 모드 프로그램이라고 한다. 프로그램은 모든 작업이 끝나면 멈췄다. 그렇기 때문에 과거 프로그래머들은 컴퓨터실에 가서 코드를 밀어 넣으면 결과가 나올 때 까지 몇 시간 기다리는 식으로 디버깅이 오래 걸렸다. 즉각적인 피드백을 원했던 프로그래머들은 대화형 프로그램을 만들었다. 초기 대화형 프로그램 중에는 게임도 있었다. 당신은 작은 벽돌 건물 앞 막다른 길에 서 있다. 주변에는 숲이 있다. 작은 물..

"여러 순차 작업의 결과를 한번에 보여준다." 본질적으로 컴퓨터는 순차적으로 동작한다. 컴퓨터의 능력은 굉장히 큰 일을 작은 단계로 쪼개어 하나씩 처리할 수 있는데 있다. 하지만 사용자 입장에서는 순차적으로 혹은 동시에 진행되는 여러 작업을 한 번에 모아서 봐야 할 때가 있다. 예를들어, 게임에서 렌더링은 꼭 필요하다. 유저에게 보여줄 게임 화면을 그릴 때는 멀리 있는 산, 언덕, 나무 등 전부를 한번에 보여준다. 이때 화면을 그리는 중간 과정이 보이면 몰입할 수가 없다. 장면은 부드럽고 빠르게 업데이트되어야 하고 매 프레임이 완성되면 한 번에 보여줘야 한다. 이중 버퍼는 이런 문제를 해결한다. 들어가기에 앞서서 컴퓨터가 화면을 어떻게 그리는지부터 살펴 보자. 컴퓨터 그래픽스 작동 원리 컴퓨터 모니터 같..

"객체의 내부 상태에 따라 스스로 행동을 변경할 수 있게 허가하는 패턴으로, 이렇게 하면 객체는 마치 자신의 클래스를 바꾸는 것처럼 보입니다. (GoF의 디자인패턴, p395)" 이번 장에서는 상태 패턴을 다루지만 좀 더 근본 개념인 유한 상태 기계(Finite State Machine : FSM)도 언급한다. 그러다 보니 계층형 상태 기계(Hierarchical State Machine)와 푸시다운 오토마타(Pushdown Automata)도 언급한다. 상태 기계는 AI나 컴파일러 개발자라면 익숙한 개념인 만큼 이러한 분야들에 자주 쓰이고 있다. 상태 기계는 알아두면 좋기 때문에, 다른 분야에서는 어떻게 활용 가능한지 살펴보도록 하겠다. 추억의 게임 만들기 간단한 플랫포머(슈퍼마리오 같은 게임)를 만든..