IT/모바일
제공 : 한빛 네트워크
저자 : Andrea O. K. Wright
역자 : 주재경
원문 : Creating Games in Ruby (Part 2)
이 글의 첫 번째 부분은 Ruby로 만든 게임을 하는 것이 게임을 만드는 것만큼 재미 있을까? 적절한 시간 내에 동작이 이루어 지지 않아 너무 느리게 동작하지는 않을까? 하는 의문으로 시작했다. 이런 질문을 제기한 몇 가지 이유들을 살펴보고 Ruby 게임 개발에 필요한 모든 것을 살펴보는 것을 시작으로 이 질문에 답변을 시작하고자 한다. 저 수준 라이브러리로 시작해서 고 수준의 프레임웍으로 진행할 것이다. 이 논의는 이번 글에서도 계속 될 것이다. 그리고 이 글의 서두에서 제기한 질문을 다시 돌이켜 보는 것으로 결론을 내리고자 한다.
Gosu
Co-Creators: Julian Raschke & Jan Lucker
Lead Developer: Julian Raschke
SWIG(Simplified Wrapper and Interface Generator)와 C++ 작성된 Gosu는 Ruby용 C++확장을 생성하는데 사용된다. Gosu개발에 사용된 언어가 C++라 해서 Ruby버전이 그리 관계가 없다는 것을 의미하는 것은 아니다. Ruby본래의 모습을 가지고 있지 않은 어느 것도 SWIG를 통해 조절된다.
Gosu는 잘 연마되어 있고 컴팩트하다. 개발팀은 게임을 만드는데 필요한 모든 것을 포함 시키는 것을 목표로 했다. 지원하는 모든 기능은 이미 있는 응용프로그에서 필요한 기능이며 또한 여기에서 시험했다. 이론상으로 유용한 것이 있다 해서 추가 되지는 않았다.
코드 이면의 디자인에 대한 근거를 유지하면서 Gosu는 시작하는데 필요한 모든 것을 제공하는 심사숙고한 튜토리얼을 제공하고 있다. 완전히 다 보는데 한 시간도 채 걸리지 않으며 마지막 부분에서는 게임을 개발할 준비가 되어 있을 것이다.
최종 튜토리얼이 아래에 있다. 우주선을 별과 부딪히도록 조종하면 별은 없어지고 점수를 얻는다.
그림1. Gosu로 패키징된 튜토리얼
경험있는 Gosu개발자 조차도 Gosu의 윈도우 클래스를 사용하고 내장된 서비스를 이용하는 것으로 시작한다. 아래에 메인 윈도우에 대한 코드가 있다.
Gosu는 아주 간단하기 때문에 많은 개발자들이 팀을 이룬 적시 개발용으로 잘 만들어 졌음을 알고 있다. Gosu개발에 참여한 Julian Raschke와 Florian Gross, Alexander Post가 함께 참여하여 팀을 이뤄 만든 게임 비디오 클립이 아래에 있다. 이것을 만드는데 72시간이 걸렸다. 아래 버전은 협력이 끝난 후 좀 수정 되었다.
이 게임의 목적은 초콜릿을 미끼로 하여 침대로 자러 가는 마귀 할멈을 유혹하는 것이다. 마우스 커서가 요정이며 초콜릿 바를 클릭하면 작은 초콜릿 바가 손에 나타난다. 잠들어 있는 마귀 할멈에게 매운 고추를 주거나 괴물 장난감으로 그녀를 위협하면 그녀는 붉게 변하고 앞길을 가로 막는 것이 무엇이든 공격한다. 물웅덩이를 얼음 다리로 만들고 싶거나 훨훨 타오르는 가마솥을 식히기 위해 그녀가 얼음 탄을 쏘도록 해야 할 때에는 그녀에게 아이스 크림을 주면 된다. 어떤 레벨에서는 거미로 그녀를 위협해서 거미를 때려 날려 버린 뒤 전기 스위치를 켜도록 해야 한다.
Gosu는 외부 라이브러리와 쉽게 통합 될 수 있도록 만들어 졌다. Scott Lembcke의 2D 물리 라이브러리 Chipmunk와 Gosu가 어떻게 통합되는 지를 보여주는 튜토리얼도 함께 패키징 되어 있다. Chipmunk는 C로 작성되어 있지만 Ruby로 묶여 배포 된다. Chipmunk는 충돌할 때 자연의 물리법칙에 따라 동작하도록 하기 위해 가상의 질량을 갖는 sprites로 만들어져 있다. 튜토리얼은 충돌검출을 위해 Chipmunk사용법 뿐만 아니라 Gosu가 다른 것들과 얼마나 잘 동작하는지도 보여준다.
Dirk Johnson이 작성한 Gosu/Chipmunk통합 튜토리얼은 시작 지점으로 Gosu의 우주선 튜토리얼을 사용한다. 향상된 Chimpmunk 버전에는 원래 Gosu튜토리얼 과는 많은 변화가 있었다. 응용프로그램을 시작할 때는 거의 원래의 버전과 동일하게 동작 하는 것 같다. 충돌결과를 보기 전에 별은 사라진다. Chipmunk에서 가장 멋진 것은 정형화된 2D sprite가 자연스럽게 움직이는 것이라고 생각한다. 우주선을 별 가까이로 조종하면 별이 사라지는 코드에 주석을 달아 Gosu/Chipmunk통합 튜토리얼을 수정했다. 이런 방법으로 우주선과 별이 부딪힐 때 어떤 일이 일어나는지를 알 수 있다. 그리고 별의 간격을 좀더 조밀하게 하고 한 쌍의 Chipmunk 로고를 추가 했다. 아래의 비디오 클립에서 Gosu와 Chipmunk를섞어 놓으면 무슨 일이 일어나는 지를 알 수 있다.(비디오 클립을 보려면 스크린 샷을 클릭)
사용자들이 게임도 중 배경을 동적으로 수정하도록 기능을 요청하여 RMagick에 대한 통합이 최근에 Gosu로 이루어 졌다. 아래의 비디오 클립은 RMagick없이는 불가능한 특수 효과를 사용하는 예제를 보여 주고 있다. RMagick은 워터마크나 폴라로이드로 찍은 사진을 흉내 내는 것과 같은 10여 개의 특수 효과를 적용하고 이미지를 조합하거나 변형하는데 사용되는 ImagMagick의 Ruby버전으로 이루어져 있다.
비교를 위해 첫 번째 글에서 살펴본 RUDL 라이브러리로 패키징된 한 쌍의 스크린 샷이 아래에 있다. 화면에 폭파 구멍이 있다는 면에서 비슷하다. 장남감 병사 대신에 탱크가 있다. 작은 네모 상자가 탱크이다. remove_dirt메서드는 발사체가 떨어진 곳을 검정색 원으로 랜더링하여 흙이 없어진 것처럼 만든다. 단지 검정색 배경으로 만들어 버린다. ImagMagick기반으로 구현하면 이러한 제한이 없어진다. Rmagick통합은 많은 가능성을 열어둔다.
그림2. Pocket Martion Sofware의 Brian Palmer가 만든 RUDL로 패키징된 데모게임의 한 장면
지구나 별에 있는 검정 테두리로 된 분화구처럼 보이게 하는 Gosu데모 코드가 아래에 있다. Circle과 fill은 검정색 원을 만들고 shadow는 흐릿해진 원을 만든다. 코드의 두 번째 부분은 이 모양이 효과를 완성하기 위해 RMagick의 composite메서드와 어떻게 연결되어 사용되는지를 보여 주고 있다. 탱크에서 발사한 되면 프로그램은 배경(@rmagick_images)를 구성하는 조각에 대한 루틴을 돌고 폭발한 부근에 무엇이 있는지를 결정한다. 두 번째 코드 블록의 호출 순서는 배경 조각 각각이 맞았는지에 맞춰져 있다. 그림자는 Atop플래그를 composite메서드에 넘겨줘 배경 이미지에 나타난다. 다음으로 DstOutcompositeOp플래그가 좀더 작고 부드러운 분화구 이미지를 추가하기 위해 전달된다. DstOutcompositeOp플래그는 이미지의 크기와 모양에 해당하는 영역이 삭제되어야 함을 나타낸다.
그림3. circle()과 shadow()를 호출하여 생성한 원과 그림자
그림4.속이 빈 원과 속이 찬 원으로 된 영역
Gosu최근 버전은 표준 Gosu튜토리얼에 대한 또 다르게 변화된 기능을 가지고 있다. 그림5의 새로운 데모에는OpenGL로 만들어진 3D배경이 포함되어 있다. Gosu는 OpenGL API로부터 개발자들을 보호하고 배경 화면의 랜더링을 위해 오랫동안 OpenGL을 사용했다. 지금은 개발자들이 2D게임에 3D효과를 추가하기 위해 선택적으로 OpenGL API를 사용할 수 있다.
그림5. 3차원 배경을 가진 표준 Gosu 튜토리얼
아래의 첫 번째 코드는 OpenGL API호출이 새로운 gl 메서드로 전달 될 수 있음을 보여주고 있다. OpenGL API호출 대부분은 exec_gl메서드로 감춰져 있으며 이 메서드는 임의의 높이로 반복해서 같은 텍스쳐를 보여주는 것으로 산 처럼 보이게 한다.
그 밑의 코드는 exec_gl코드에서 발췌 했다. 배경은 일반적인 꼭지점을 가지는 여러 개의 삼각형으로 만들어진다. 한 번 이상 같은 꼭지점에 대해 연산을 하는 glVertex3d대신에 GL_TRIANGLE_STRIP OpenGL API가 사용된다. GL_TRIANGLE_STRIP을 사용해 3개 혹은 그 이상의 꼭지점을 선언하면 OpenGL은 이 들 모두를 삼각형 면으로 연결한다. 이 코드는 응용프로그램에 정의된 4개의 꼭지점들 중 하나만 보여주고 있다. 배경화면을 스크롤 하는 것은 여러 개의 GL_TRIANGLE_STRIPS로 구성된다.
Ogre.rb
Creator and Lead Developer: Jason Roelofs
Shattered Ruby
Co-Creators and Co-Lead Developers: Martyn Garcia and Mikkel Garcia
OpenGL을 사용한 3D코드에서 왜 사람들의 좀더 복잡한 모양과 장면을 위해 3D 모델링 소프트웨어를 사용하는 이유를 알 수 있을 것이라 생각한다. 3D모델의 모든 특징을 가지고 있는 Ruby 프로젝트 2개를 살펴보고자 한다. 3D그래픽 랜더링 엔진 Ogre.rb와 Ogre.rb에 내장되어 있는 3D 게임 개발 프레임웍 Shattered Ruby가 그것이다.
Ogre.rb는 OGRE에 대한 Ruby랩퍼이다. OGRE는 객체기반의 그래픽 랜더링 엔진(Object-Oriented Graphics Rendering Engine)을 의미한다. 한 장면에 3D모델과 텍스쳐 그리고 다른 종류의 그래픽 관련 내용을 조합하는데 사용된다. 바람, 비, 연기, 사진과 같은 폭발 그리고 복잡한 빛에 관한 테크닉등과 같이 특수 효과를 나타내는 여러 가지가 있다.
Ogre.rb에는 일반적인 장면 관리자를 설정하고 클래스 변수에 영향을 미치는 도우미가 있어서 테스트를 위해 새 윈도우를 생성할 필요가 없다.
아래에 Ogre.rb로 만들어진 간단한 장면에 관한 비디오 클립이 있다.(클립을 보기 위해서 그림을 클릭). 이 것은 실제로 OGRE로 만들어진 데모들 가운데 하나로 Ruby로 만들어져 있다. 초록색의 머리는 3D 모델의 예이다. 마우스나 화살표 키를 이용하여 화면을 돌아 다닐 수 있고 뒤쪽 혹은 옆면에서 머리를 볼 수 있다. 앞이 정면인 것은 아니다. 정교하고 상세하게 360도에 걸쳐 랜더링 되어 있다.
OGRE는 C++로 만들어져 있으며 Ogre.rb의 저자 이자 개발 리더인 Jason Roelofs는 처음에 Ruby의 C++확장 생성에 도움을 얻기 위해 SWIG를 사용했다. SWIG는 클래스 안에 클래스를 감싸 안는 것을 지원하지 않기 때문에 주요 부분에 대한 랩핑 작업을 마친 후 Ogre.rb로는 더 이상 나아갈 수 없다는 것을 알았다. 또 다른 바인딩 전략을 조사한 후 그는 Ogre.rb개발을 보류하고 luabind와 Boost.Python의 틀 내에서 Ruby/C++ 호환 프로그램을 만들고자 했다. 새로운 툴셋을 사용하여 Ogre.rb를 다시 만들고자 계획했다.. 동시에 그는 최근까지 발표된 Ogre.rb에 대한 지원도 지속할 것이다.
Shattered Ruby는 Ogre.rb로 만들어진 Ruby on Rails에 영감을 받은 3D 게임 개발 프레임웍이다.
Shattered Ruby의 저자이자 개발 리더인 Martyn과 Mikkel Garcia는 Ruby on Rails방식으로 3D게임 개발의 모든 면에 대해서 논할 수 있는 길을 알아 냈다. 예를 들면 Rails와 Shattered는 다를 뿐만 아니라 오히려 정반대라는 것을 지적 했음에도 Shattered to Rails로 비유되는 Martyn이 관리하는 Shattered Ruby 포럼에 올라온 글이 있다.
Shattered는 응용프로그램 디렉토리 구조에서 발견되는 미디어 파일이 어디에 있고 무엇이 이들을 호출하는지 View와 Model사이의 관계와 View에서 생성된 객체가 어떻게 그룹화 되는지에 대한 가정을 통해 장면 서술에 관련한 코드를 획기적으로 줄일 수 있다.
벡터는 x,y,z좌표를 넘겨줘 일반적으로 생성된다. 방향의 변화를 서술하는 심볼을 지원하는 to_v가 추가 된 심벌에 핵심 확장을 제공하는 Shattered를 좋아한다.
게임 이름과 명령어 shatter를 입력하여 게임 만들기를 시작한다. Shattered Ruby는 Ruby on Rails에 익숙한 모든 사람에게 매우 친숙한 다음과 같은 구조를 생성한다.
그림6. Shattered Ruby 디렉토리 구조
script/generate actor와 actor의 이름을 입력하면 View코드와 Model코드가 생성된다. Actor는 View와 Model로 구성된다. Model은 게임 로직과 사용자 입력 핸들러를 포함하고 있다. Model에서 View에 있는 것과 같은 이름을 가진 메서드가 호출되면 View의 메서드는 대응되는 Model메서드의 동작이 끝난 후 자동으로 호출된다. 3D checker를 플레이 하고 crown이 특정 checker의 Model에서 호출된 경우 crown 정의된 checker의 View에서 자동으로 호출된다.
OGRE스크립트는 3D 모델에 대한 위치와 빛 설정 텍스쳐를 조절하는 데 사용된다. 수 작업으로 이를 하기에는 어렵다. Shattered Ruby는 OGRE포맷으로 스크립트를 생성하기 위해 erb를 사용하기 위한 매커니즘을 제공한다.
아래에 자동으로 스크립트를 만들어 내는 Shattered 템플릿에 대한 보기가 있다.
리팩토링의 가장 주요한 이유중의 하나는 Ogre.rb를 사용하는 Shattered 개발자들에게 모든 것을 지원하기 위함이다. 프레임웍이 처음 작성 되었을 때 Shattered의 게임 DSL에 필요한 Ogre.rb기능 중 몇 가지에 대한 랩퍼만이 Shattered로 패키징 되었다. Shattered블로그에서 Mikkel은 Ruby on Rails의 방법으로 이 결정을 설명하고 있다. 그는 Shattered와 Ogre.rb는 ActiveRecord와 Rails와 비슷하다고 설명하고 있다. Rails개발자들이 ActiveRecord의 지원이 없을 때 직접적으로 SQL을 사용하는 것 처엄 Shattered개발자들은 Shattered가 박스 외부의 것을 제어하지 못할 때 Ogre.rb를 바로 사용할 수 있다. 이러한 점에서 Shattered Ruby개발은 최근 버전인 Ogre.rb 0.2와 완벽하게 통합된다. 작년에 Shattered Ruby 위키에 있는 아래의 튜토리얼에 따라 3D 테트리스를 만드는 것이 가능했다.
그림7. Shattered Ruby로 만든 테트리스
Shattered Ruby 튜토리얼이 언제 업데이트 되는지 차기 버전이 언제 나오는지를 최선의 방법은 Shattered Ruby Google Group에 가입하는 것이다.
Shattered Ruby의 다음 버전은 지난해의 단순한 리팩토링 버전만은 아닐 것이다. 개발자 버전에서 이미 확인된 물체가 앞 뒤로 움직임에 따라 볼륨이 자동으로 증가 감소하는 3D 사운드기능, Chipmunk 물리 라이브러리 사용을 위한 고 수준의 도우미 기능, 3D공간에서 HTML문법으로 GUI를 만드는데 필요한 Navi 라이브러리등 새로운 기능이 있다.
Railgun
Creator and Lead Developer: David Koontz
Shattered Ruby처럼 Railgun은 Rails같은 개발 경험을 제공하는 것을 목표로 하는 3D 프레임웍이다. 이 것은 JRuby기반으로 자바로 작성된 3D 게임 프레임웍 JMonkeyEngine을 감싸고 있다. 아직 초기 상태에 있지만 충분히 지켜볼 만한 흥미 있는 프로젝트라 생각한다.
만든이는 Swing GUI를 만드는데 JRuby에서 영향을 받은 Monkeybar를 만들기도 한David Koontz이다.
The GGZ Gaming Zone Project
Founders: Brent M. Hendricks and Rich Gade
Developed and Maintained by an International Team
GGZ Gaming Zone은 게임 프로그래밍 언어로서 Ruby의 잠재적인 성장과 게임 영역에서 Ruby의 성장으로 인해 최근에 Ruby를 지원하기 시작했다. KDE와 Gnome둘 모두에 대한 공식 온라인 게임 개발 플랫폼으로서 GGZ는 대 부분의 리눅스 배포판에 패키징 되어 있다.
GGZ는 GNU처럼 반복적인 의미를 가진 머리 글자이다. 실제 GGZ가 8년 전에 만들어 졌을 때 초창기에 Gnu Gaming Zone혹은 GGZ로 불리워 졌다. GGZ를 만든이들은 GNU 프로젝트의 한 부분이 되기를 바랐지만 나중에 이를 포기하고 GGZ Gaming Zone이라는 이름으로 결정했다.
GGZ는 게임 개발자들을 위한 많은 유용한 자료를 가지고 있다. 네트웍용 게임, 자리예약의 사인에서부터 최고 점수를 저장하는 서비스를 제공하는 라이브러리 등이 그것이다. GGZ에는 십여 개의 게임과 플레이어 랭킹과 토너먼트 계획과 같은 정보 엑세스를 위해 RESTful API를 사용하는 게임 커뮤니티를 위해 디자인된 웹 포털 또한 있다. 포털 소프트웨어는 GGZ 커뮤너티 사이트에서 실행되며 여기에서 현재의 토너먼트 계획을 알 수 있다. Spade가 특히 유명하다. 정기적인 Spade토너먼트가 있다.
GGZ 커뮤너티 사이트에 인스톨된 게임을 하기 위한 계정을 위한 사인도 그 무엇도 설치할 필요도 없다. 단지 손님으로 로그온 한 후 Play Now 버튼을 누르기만 하면 된다. 컴퓨터에 GGZ 소프트웨어를 설치하고 시작 클라이언트가 실행되고 있는 경우라면 설치된 게임을 하기 위해 GGZ 커뮤너티 서버를 선택할 수 있으며 자신의 로컬 머신으로 GGZ서버를 선택할 수도 있으며 친구의 컴퓨터나 혹은 전세계의 GGZ서버가 실행되고 있는 어떤 것도 서버로 선택할 수 있다.
GGZ로 패키징된 클라이언트는 기본적으로 게임을 시작할 수 있는 채팅 클라이언트 이다. 클라이언트는 가상 테이블의 상태에 관한 정보를 제공하고 시작이 가능한 게임 리스트를 보여준다. 가상 테이블은 게임이 진행 중 인지 혹은 사람들이 게임을 위해 다른 사람들을 기다리고 있는지를 보여준다. 여러 사람이 하는 게임을 시작한 경우 어떤 자리가 누구에게 할당되고 어떤 자리가 누구를 위해 예약되어 있고 컴퓨터에게는 어떤 자리가 할당 되는지를 지정해야 한다. 게임자로 혹은 지켜보는 이로 게임에 참여할 수 있다.
GGZ로 패키징된 게임이 아래에 있다. GGZ게임 코드는 일반적으로 게임서버 코드와 게임 클라이언트 코드로 분리된다. GGZ는 여러 게임에서 하나 이상의 클라이언트를 제공한다. 3가의 아주 다른 형태의 틱택토 클라이언트가 아래에 있다. 여러 개의 전 처리부가 있는 경우 클라이언트는 사용자로 하여금 이중 하나를 선택하도록 한다.
그림8. GGZ로 배포된 게임
GGZ가 같은 게임에 대해 여러 개의 클라이언트를 지원과 여러 개의 게임 서버 지원을 용이하게 하는 아키텍쳐가 아래에 있다.
그림9. GGZ 아키텍쳐
GGZ는 메시지 타입을 정의하고 클라이언트와 서버 사이의 통신을 위해 각 메시지를 동반해야 하는 데이터 종류를 서술하는 프로토콜을 발표했다. 예를 들면 GAME_SPECTOR_SEAT는 클라이언트가 관찰자로 게임에 참가하길 원하는 사용자를 가리키는 게임 클라이언트에게 송신할 수 있는 메시지 타입이다. 이 프로토콜은 자리 고유번호(정수)와 플레이어 이름(문자열)이 GAME_SPECTOR_SEAT메시지와 함께 송신되어야 함을 규정한다.
게임 클라이언트와 게임 서버 사이와의 통신 이외의 모든 것에 대해 GGZ는 메시지 송신에 사용되는 넷트웍 프로토콜과 GGZ가 정한 프로토콜 모두를 감싼 유틸리티 라이브러리를 제공한다. 이 라이브러리는 다이어그램에서 초록색으로 강조되어 표시된다. GGZ에는 C가 우선 언어로 사용되었지만 이 라이브러리를 위한 Ruby버젼 또한 있다. Ruby C확장 가운데 하나를 위한 고 수준의 순수한 Ruby랩퍼 뿐만 아니라 Ruby바인딩은 붉은 색으로 강조된다.
각 게임은 게임 클라이언트와 게임 서버사이의 통신을 위해 다른 프로토콜을 사용하므로 GGZ는 모든 게임에 사용될 미리 패키징된 라이브러리를 제공할 수는 없다. 대신에 제공하는 것은 ggzcomgen으로 불리는 유연한 코드 생성 유틸이다. XML문서로 게임 프로토콜을 정의하고 명령라인 인자로 넷트웍 프로토콜을 정하면 유틸은 넷트웍에 적절한 데이터 타입을 전송하기 위해 약속된 넷트웍 프로토콜을 사용하는 게임 프로토콜에 있는 메시지에 대한 메서드를 포함하는 파일을 생성한다. 생성된 넷트워킹 코드는 net.rb처럼 나타나며 붉은색으로 강조된다. 유틸은 Ruby뿐만 아니라 Python과 C소스도 함께 생성한다.
코드 생성자 ggzcommgen자체는 Ruby로 작성되어 있으므로 붉게 강조된다. Ruby로 작성된 GGZ의 유일한 부분이다.
GGZ의 Ruby바인딩은 대 부분 지난 6개월 내에 추가되었다. 개념 검증을 위해 GGZ개발 리더인 Josef Spillner는 QtRuby를 사용하여 기본적인 틱택토 클라이언트와 Rubytoe로 불리는 틱택토 게임 서버를 만들었다.
그림10. QtRuby로 만든 틱택토
실험적인 Ruby 클라이언트와 실험적인 Ruby 서버 모두 아주 기본적이긴 하지만 이 것들은 전체 GGZ Ruby 패키지에 대한 잠재력을 나타내고 있다. Pygame과 긴밀하게 관련되어 있는 GGZ Python 패키지가 있다. GGZ개발자들은 이 시리즈에서 커버 가능한 프레임웍중의 하나를 Ruby 게임 프로그래밍 프레임웍으로 통합 하는 것에 대해 고려하고 있다.
Ruby게임 개발 자료 조사에 대한 결론을 내리고자 한다.
Ruby로 작성한 게임을 하는 것이 Ruby로 프로그래밍 하는 것 만큼 재미 있을 수 있을까? 게임이 적절한 시간 안에 이뤄져야 하는 동작에서 브레이크가 너무 많이 걸려 너무 느리게 동작하지는 않을까? 게임 세계에서 루비가 적절한 것으로 대우 받을 수 있을까?
첫 번째 글의 시작 부에서 약속한 대로 Ruby의 garbage collector가 정말로 게임을 실행을 느리게 만드는지를 포함한 성능 문제가 개발자들이 Ruby게임 개발 프레임웍으로 게임을 개발하거나 게임을 하는 것에 걸림돌이 되는지에 대해 설명하고자 한다. 그리고 또한 상업 비디오 게임 시장에서 Ruby의 상태에 대해서도 말하고자 한다.
이 이슈의 어떤 것들도 이 글에 소개한 게임 프레임웍의 개발자들에게 걸림돌이 되지는 않는다.
현재 동작하는 것 보다 대략 10배 정도 더 빠른 정도로 Ruby 프로그램을 동작하도록 하는 잠재력을 가진 작업에서 Ruby로 된 여러 개의 구현물이 있다. Ogre.rb를 만든 Jason Roelofs는 Ogre.rb나 Shattered Ruby1.0버전이 준비될 무렵 까지는 Ruby성능의 획기적으로 나아질 것으로 믿긴 하지만 Ruby1.8.6버전에서는 아직도 가비지 컬렉션으로 인한 심각한 지연 현상을 경험하고 있다고 말한다.
Ruby Shattered를 만든 Martyn과 Mikkel Garcia는 모든 프레임에 대해 강제로 가비지 컬렉션을 수행한다. 가비지 컬렉션은 더 이상 그들에게 화면을 멈추게 하는 원인이 아니다.,
Gosu를 만든 Julian Raschke는 최근에 10초마다 가비지 컬렉션을 호출 하도록 Gosu를 수정 하려고 했다. 그러나 그는 이 것이 만들어 내는 큰 문제를 생각하지 못한 이유로 최근 릴리즈에 앞서 이 코드를 제거했다. 최근 릴리즈에서 Gosu성능 향상에 대한 작업을 진행 했지만 가비지 컬렉션은 그가 고려한 큰 문제가 아니었다.
최근까지도 멀티미디어 회사가 Gosu의 Ruby버젼 사용 시작을 멈추지 않았다. 그 회사는 Thinking Pictures이다.
누가 Ruby 게임 개발 프레임웍으로 상업적인 비디오 게임을 만들고 있는지를 말할 수는 없지만 Ruby게임 개발 프레임웍이 비록 시작 단계이긴 하지만 상업적으로 사용되고 있다고 말할 수는 있다.
플레이를 시작하려면 "시작"을 클릭하시오.
Andrea O.K. Wright는 Fort Washington에 있는 컨설팅회사 Chariot Solution에서 그녀의 동녀들과 함께 매주 화요일 점심시간을 이용해 Ruby관련 모임을 이끌고 있다. 그녀는 RubyConf 2007이외의 여러 컨퍼런스에서 루비용 게임 개발에 관해 발표했다.
저자 : Andrea O. K. Wright
역자 : 주재경
원문 : Creating Games in Ruby (Part 2)
이 글의 첫 번째 부분은 Ruby로 만든 게임을 하는 것이 게임을 만드는 것만큼 재미 있을까? 적절한 시간 내에 동작이 이루어 지지 않아 너무 느리게 동작하지는 않을까? 하는 의문으로 시작했다. 이런 질문을 제기한 몇 가지 이유들을 살펴보고 Ruby 게임 개발에 필요한 모든 것을 살펴보는 것을 시작으로 이 질문에 답변을 시작하고자 한다. 저 수준 라이브러리로 시작해서 고 수준의 프레임웍으로 진행할 것이다. 이 논의는 이번 글에서도 계속 될 것이다. 그리고 이 글의 서두에서 제기한 질문을 다시 돌이켜 보는 것으로 결론을 내리고자 한다.
Gosu
Co-Creators: Julian Raschke & Jan Lucker
Lead Developer: Julian Raschke
SWIG(Simplified Wrapper and Interface Generator)와 C++ 작성된 Gosu는 Ruby용 C++확장을 생성하는데 사용된다. Gosu개발에 사용된 언어가 C++라 해서 Ruby버전이 그리 관계가 없다는 것을 의미하는 것은 아니다. Ruby본래의 모습을 가지고 있지 않은 어느 것도 SWIG를 통해 조절된다.
Gosu는 잘 연마되어 있고 컴팩트하다. 개발팀은 게임을 만드는데 필요한 모든 것을 포함 시키는 것을 목표로 했다. 지원하는 모든 기능은 이미 있는 응용프로그에서 필요한 기능이며 또한 여기에서 시험했다. 이론상으로 유용한 것이 있다 해서 추가 되지는 않았다.
코드 이면의 디자인에 대한 근거를 유지하면서 Gosu는 시작하는데 필요한 모든 것을 제공하는 심사숙고한 튜토리얼을 제공하고 있다. 완전히 다 보는데 한 시간도 채 걸리지 않으며 마지막 부분에서는 게임을 개발할 준비가 되어 있을 것이다.
최종 튜토리얼이 아래에 있다. 우주선을 별과 부딪히도록 조종하면 별은 없어지고 점수를 얻는다.
그림1. Gosu로 패키징된 튜토리얼
경험있는 Gosu개발자 조차도 Gosu의 윈도우 클래스를 사용하고 내장된 서비스를 이용하는 것으로 시작한다. 아래에 메인 윈도우에 대한 코드가 있다.
class MainWindow < Gosu::Window
def initialize(width, height, fullscreen)
super
end
def update
# Change display attributes, if necessary.
end
def draw
# Display calls go here.
end
def button_down(id)
# Buttons are keys, mouse buttons, and
# game pad controls.
end
end
Gosu는 장면의 이면에서 처리하기 때문에 응용프로그램 수준에서 이벤트 큐을 설정하거나 메인 게임루틴을 시작할 필요가 없다. Gosu는 메인 윈도우의 update메서들 호출한 다음 모든 프레임에 대해 draw메서드를 호출한다. 사용자가 키보드의 키를 누르거나 마우스 버튼을 누르면 button_down 콜백이 호출된다.
Gosu는 아주 간단하기 때문에 많은 개발자들이 팀을 이룬 적시 개발용으로 잘 만들어 졌음을 알고 있다. Gosu개발에 참여한 Julian Raschke와 Florian Gross, Alexander Post가 함께 참여하여 팀을 이뤄 만든 게임 비디오 클립이 아래에 있다. 이것을 만드는데 72시간이 걸렸다. 아래 버전은 협력이 끝난 후 좀 수정 되었다.
이 게임의 목적은 초콜릿을 미끼로 하여 침대로 자러 가는 마귀 할멈을 유혹하는 것이다. 마우스 커서가 요정이며 초콜릿 바를 클릭하면 작은 초콜릿 바가 손에 나타난다. 잠들어 있는 마귀 할멈에게 매운 고추를 주거나 괴물 장난감으로 그녀를 위협하면 그녀는 붉게 변하고 앞길을 가로 막는 것이 무엇이든 공격한다. 물웅덩이를 얼음 다리로 만들고 싶거나 훨훨 타오르는 가마솥을 식히기 위해 그녀가 얼음 탄을 쏘도록 해야 할 때에는 그녀에게 아이스 크림을 주면 된다. 어떤 레벨에서는 거미로 그녀를 위협해서 거미를 때려 날려 버린 뒤 전기 스위치를 켜도록 해야 한다.
Gosu는 외부 라이브러리와 쉽게 통합 될 수 있도록 만들어 졌다. Scott Lembcke의 2D 물리 라이브러리 Chipmunk와 Gosu가 어떻게 통합되는 지를 보여주는 튜토리얼도 함께 패키징 되어 있다. Chipmunk는 C로 작성되어 있지만 Ruby로 묶여 배포 된다. Chipmunk는 충돌할 때 자연의 물리법칙에 따라 동작하도록 하기 위해 가상의 질량을 갖는 sprites로 만들어져 있다. 튜토리얼은 충돌검출을 위해 Chipmunk사용법 뿐만 아니라 Gosu가 다른 것들과 얼마나 잘 동작하는지도 보여준다.
Dirk Johnson이 작성한 Gosu/Chipmunk통합 튜토리얼은 시작 지점으로 Gosu의 우주선 튜토리얼을 사용한다. 향상된 Chimpmunk 버전에는 원래 Gosu튜토리얼 과는 많은 변화가 있었다. 응용프로그램을 시작할 때는 거의 원래의 버전과 동일하게 동작 하는 것 같다. 충돌결과를 보기 전에 별은 사라진다. Chipmunk에서 가장 멋진 것은 정형화된 2D sprite가 자연스럽게 움직이는 것이라고 생각한다. 우주선을 별 가까이로 조종하면 별이 사라지는 코드에 주석을 달아 Gosu/Chipmunk통합 튜토리얼을 수정했다. 이런 방법으로 우주선과 별이 부딪힐 때 어떤 일이 일어나는지를 알 수 있다. 그리고 별의 간격을 좀더 조밀하게 하고 한 쌍의 Chipmunk 로고를 추가 했다. 아래의 비디오 클립에서 Gosu와 Chipmunk를섞어 놓으면 무슨 일이 일어나는 지를 알 수 있다.(비디오 클립을 보려면 스크린 샷을 클릭)
사용자들이 게임도 중 배경을 동적으로 수정하도록 기능을 요청하여 RMagick에 대한 통합이 최근에 Gosu로 이루어 졌다. 아래의 비디오 클립은 RMagick없이는 불가능한 특수 효과를 사용하는 예제를 보여 주고 있다. RMagick은 워터마크나 폴라로이드로 찍은 사진을 흉내 내는 것과 같은 10여 개의 특수 효과를 적용하고 이미지를 조합하거나 변형하는데 사용되는 ImagMagick의 Ruby버전으로 이루어져 있다.
비교를 위해 첫 번째 글에서 살펴본 RUDL 라이브러리로 패키징된 한 쌍의 스크린 샷이 아래에 있다. 화면에 폭파 구멍이 있다는 면에서 비슷하다. 장남감 병사 대신에 탱크가 있다. 작은 네모 상자가 탱크이다. remove_dirt메서드는 발사체가 떨어진 곳을 검정색 원으로 랜더링하여 흙이 없어진 것처럼 만든다. 단지 검정색 배경으로 만들어 버린다. ImagMagick기반으로 구현하면 이러한 제한이 없어진다. Rmagick통합은 많은 가능성을 열어둔다.
그림2. Pocket Martion Sofware의 Brian Palmer가 만든 RUDL로 패키징된 데모게임의 한 장면
지구나 별에 있는 검정 테두리로 된 분화구처럼 보이게 하는 Gosu데모 코드가 아래에 있다. Circle과 fill은 검정색 원을 만들고 shadow는 흐릿해진 원을 만든다. 코드의 두 번째 부분은 이 모양이 효과를 완성하기 위해 RMagick의 composite메서드와 어떻게 연결되어 사용되는지를 보여 주고 있다. 탱크에서 발사한 되면 프로그램은 배경(@rmagick_images)를 구성하는 조각에 대한 루틴을 돌고 폭발한 부근에 무엇이 있는지를 결정한다. 두 번째 코드 블록의 호출 순서는 배경 조각 각각이 맞았는지에 맞춰져 있다. 그림자는 Atop플래그를 composite메서드에 넘겨줘 배경 이미지에 나타난다. 다음으로 DstOutcompositeOp플래그가 좀더 작고 부드러운 분화구 이미지를 추가하기 위해 전달된다. DstOutcompositeOp플래그는 이미지의 크기와 모양에 해당하는 영역이 삭제되어야 함을 나타낸다.
if not @crater_image then
@crater_image = Magick::Image.new(50, 50)
{self.background_color = "none"}
gc = Magick::Draw.new
gc.fill("black").circle(25, 25, 25, 0)
gc.draw(@crater_image)
@crater_shadow = @crater_image.shadow(0,0,5,1)
end
그림3. circle()과 shadow()를 호출하여 생성한 원과 그림자
@rmagick_images[index].composite!(@crater_shadow, center_x - 35, center_y - 35, Magick::AtopCompositeOp) @rmagick_images[index].composite!(@crater_image, center_x - 25, center_y - 25, Magick::DstOutCompositeOp)
그림4.속이 빈 원과 속이 찬 원으로 된 영역
Gosu최근 버전은 표준 Gosu튜토리얼에 대한 또 다르게 변화된 기능을 가지고 있다. 그림5의 새로운 데모에는OpenGL로 만들어진 3D배경이 포함되어 있다. Gosu는 OpenGL API로부터 개발자들을 보호하고 배경 화면의 랜더링을 위해 오랫동안 OpenGL을 사용했다. 지금은 개발자들이 2D게임에 3D효과를 추가하기 위해 선택적으로 OpenGL API를 사용할 수 있다.
그림5. 3차원 배경을 가진 표준 Gosu 튜토리얼
아래의 첫 번째 코드는 OpenGL API호출이 새로운 gl 메서드로 전달 될 수 있음을 보여주고 있다. OpenGL API호출 대부분은 exec_gl메서드로 감춰져 있으며 이 메서드는 임의의 높이로 반복해서 같은 텍스쳐를 보여주는 것으로 산 처럼 보이게 한다.
그 밑의 코드는 exec_gl코드에서 발췌 했다. 배경은 일반적인 꼭지점을 가지는 여러 개의 삼각형으로 만들어진다. 한 번 이상 같은 꼭지점에 대해 연산을 하는 glVertex3d대신에 GL_TRIANGLE_STRIP OpenGL API가 사용된다. GL_TRIANGLE_STRIP을 사용해 3개 혹은 그 이상의 꼭지점을 선언하면 OpenGL은 이 들 모두를 삼각형 면으로 연결한다. 이 코드는 응용프로그램에 정의된 4개의 꼭지점들 중 하나만 보여주고 있다. 배경화면을 스크롤 하는 것은 여러 개의 GL_TRIANGLE_STRIPS로 구성된다.
def draw
gl do
glClearColor(0.0, 0.2, 0.5, 1.0)
glClearDepth(0)
glClear(GL_COLOR_BUFFER_BIT|GL_DEPTH_BUFFER_BIT)
@gl_background.exec_gl
end
...
end
def exec_gl
info = @image.gl_tex_info
...
0.upto(POINTS_Y - 2) do |y|
0.upto(POINTS_X - 2) do |x|
glBegin(GL_TRIANGLE_STRIP)
z = @height_map[y][x]
glColor4d(1, 1, 1, z)
glTexCoord2d(info.left, info.top)
glVertex3d(-0.5 + (x - 0.0) / (POINTS_X-1),
-0.5 + (y - offs_y - 0.0) / (POINTS_Y-2),
z)
...
glEnd
end
end
end
Gosu가 ruby-opengl 라이브러리로 통합되어 있는 반면 RUDL 예제는 이전 Ruby/OpenGL 라이브러리를 사용하기 때문에 Gosu의 OpenGL API메서드 이름이 첫 번째 문서의 RUDL예제에서 사용한 이름과 달라 보인다. 구조화 된 OpenGL API호출 방법은 RUDL과 Gosu의 예제와 동일하다.
Ogre.rb
Creator and Lead Developer: Jason Roelofs
Shattered Ruby
Co-Creators and Co-Lead Developers: Martyn Garcia and Mikkel Garcia
OpenGL을 사용한 3D코드에서 왜 사람들의 좀더 복잡한 모양과 장면을 위해 3D 모델링 소프트웨어를 사용하는 이유를 알 수 있을 것이라 생각한다. 3D모델의 모든 특징을 가지고 있는 Ruby 프로젝트 2개를 살펴보고자 한다. 3D그래픽 랜더링 엔진 Ogre.rb와 Ogre.rb에 내장되어 있는 3D 게임 개발 프레임웍 Shattered Ruby가 그것이다.
Ogre.rb는 OGRE에 대한 Ruby랩퍼이다. OGRE는 객체기반의 그래픽 랜더링 엔진(Object-Oriented Graphics Rendering Engine)을 의미한다. 한 장면에 3D모델과 텍스쳐 그리고 다른 종류의 그래픽 관련 내용을 조합하는데 사용된다. 바람, 비, 연기, 사진과 같은 폭발 그리고 복잡한 빛에 관한 테크닉등과 같이 특수 효과를 나타내는 여러 가지가 있다.
Ogre.rb에는 일반적인 장면 관리자를 설정하고 클래스 변수에 영향을 미치는 도우미가 있어서 테스트를 위해 새 윈도우를 생성할 필요가 없다.
아래에 Ogre.rb로 만들어진 간단한 장면에 관한 비디오 클립이 있다.(클립을 보기 위해서 그림을 클릭). 이 것은 실제로 OGRE로 만들어진 데모들 가운데 하나로 Ruby로 만들어져 있다. 초록색의 머리는 3D 모델의 예이다. 마우스나 화살표 키를 이용하여 화면을 돌아 다닐 수 있고 뒤쪽 혹은 옆면에서 머리를 볼 수 있다. 앞이 정면인 것은 아니다. 정교하고 상세하게 360도에 걸쳐 랜더링 되어 있다.
OGRE는 C++로 만들어져 있으며 Ogre.rb의 저자 이자 개발 리더인 Jason Roelofs는 처음에 Ruby의 C++확장 생성에 도움을 얻기 위해 SWIG를 사용했다. SWIG는 클래스 안에 클래스를 감싸 안는 것을 지원하지 않기 때문에 주요 부분에 대한 랩핑 작업을 마친 후 Ogre.rb로는 더 이상 나아갈 수 없다는 것을 알았다. 또 다른 바인딩 전략을 조사한 후 그는 Ogre.rb개발을 보류하고 luabind와 Boost.Python의 틀 내에서 Ruby/C++ 호환 프로그램을 만들고자 했다. 새로운 툴셋을 사용하여 Ogre.rb를 다시 만들고자 계획했다.. 동시에 그는 최근까지 발표된 Ogre.rb에 대한 지원도 지속할 것이다.
Shattered Ruby는 Ogre.rb로 만들어진 Ruby on Rails에 영감을 받은 3D 게임 개발 프레임웍이다.
Shattered Ruby의 저자이자 개발 리더인 Martyn과 Mikkel Garcia는 Ruby on Rails방식으로 3D게임 개발의 모든 면에 대해서 논할 수 있는 길을 알아 냈다. 예를 들면 Rails와 Shattered는 다를 뿐만 아니라 오히려 정반대라는 것을 지적 했음에도 Shattered to Rails로 비유되는 Martyn이 관리하는 Shattered Ruby 포럼에 올라온 글이 있다.
Shattered는 응용프로그램 디렉토리 구조에서 발견되는 미디어 파일이 어디에 있고 무엇이 이들을 호출하는지 View와 Model사이의 관계와 View에서 생성된 객체가 어떻게 그룹화 되는지에 대한 가정을 통해 장면 서술에 관련한 코드를 획기적으로 줄일 수 있다.
# from an Ogre.rb demo
class SkyPlaneApplication < Application
def create_scene
scene_manager.set_ambient_light ColourValue.new(0.5,
0.5, 0.5)
plane = Plane.new
plane.d = 5000
plane.normal = -Vector3.UNIT_Y
scene_manager.set_sky_plane(true,
plane,"SpaceSkyPlane", 10000, 3)
light = scene_manager.create_light("MainLight")
light.set_position(20, 80, 50)
dragon = scene_manager.create_entity("dragon",
"dragon.mesh")
scene_manager.root_scene_node.attach_object(dragon)
end
end
# using Shattered Ruby to define the above scene...
class SkyPlane
light "Mainlight",
:position => (20,80,50)
end
class Dragon
end
Shattered는 코드 크기를 줄일 뿐 아니라 좀 더 표현력 있게 코드 작성을 재밌게 할 수 있다.
벡터는 x,y,z좌표를 넘겨줘 일반적으로 생성된다. 방향의 변화를 서술하는 심볼을 지원하는 to_v가 추가 된 심벌에 핵심 확장을 제공하는 Shattered를 좋아한다.
게임 이름과 명령어 shatter를 입력하여 게임 만들기를 시작한다. Shattered Ruby는 Ruby on Rails에 익숙한 모든 사람에게 매우 친숙한 다음과 같은 구조를 생성한다.
그림6. Shattered Ruby 디렉토리 구조
script/generate actor와 actor의 이름을 입력하면 View코드와 Model코드가 생성된다. Actor는 View와 Model로 구성된다. Model은 게임 로직과 사용자 입력 핸들러를 포함하고 있다. Model에서 View에 있는 것과 같은 이름을 가진 메서드가 호출되면 View의 메서드는 대응되는 Model메서드의 동작이 끝난 후 자동으로 호출된다. 3D checker를 플레이 하고 crown이 특정 checker의 Model에서 호출된 경우 crown 정의된 checker의 View에서 자동으로 호출된다.
OGRE스크립트는 3D 모델에 대한 위치와 빛 설정 텍스쳐를 조절하는 데 사용된다. 수 작업으로 이를 하기에는 어렵다. Shattered Ruby는 OGRE포맷으로 스크립트를 생성하기 위해 erb를 사용하기 위한 매커니즘을 제공한다.
아래에 자동으로 스크립트를 만들어 내는 Shattered 템플릿에 대한 보기가 있다.
material < %= name % >
{
technique
{
pass
{
lighting off
texture_unit
{
texture < %= texture % >
}
}
}
}
Martyn과 Mikkel은 작년에 시작한 리팩토링의 막바지에 있다. Shattered Ruby Wiki에 있는 튜토리얼의 대부분은 이 변화를 반영해야 한다.
리팩토링의 가장 주요한 이유중의 하나는 Ogre.rb를 사용하는 Shattered 개발자들에게 모든 것을 지원하기 위함이다. 프레임웍이 처음 작성 되었을 때 Shattered의 게임 DSL에 필요한 Ogre.rb기능 중 몇 가지에 대한 랩퍼만이 Shattered로 패키징 되었다. Shattered블로그에서 Mikkel은 Ruby on Rails의 방법으로 이 결정을 설명하고 있다. 그는 Shattered와 Ogre.rb는 ActiveRecord와 Rails와 비슷하다고 설명하고 있다. Rails개발자들이 ActiveRecord의 지원이 없을 때 직접적으로 SQL을 사용하는 것 처엄 Shattered개발자들은 Shattered가 박스 외부의 것을 제어하지 못할 때 Ogre.rb를 바로 사용할 수 있다. 이러한 점에서 Shattered Ruby개발은 최근 버전인 Ogre.rb 0.2와 완벽하게 통합된다. 작년에 Shattered Ruby 위키에 있는 아래의 튜토리얼에 따라 3D 테트리스를 만드는 것이 가능했다.
그림7. Shattered Ruby로 만든 테트리스
Shattered Ruby 튜토리얼이 언제 업데이트 되는지 차기 버전이 언제 나오는지를 최선의 방법은 Shattered Ruby Google Group에 가입하는 것이다.
Shattered Ruby의 다음 버전은 지난해의 단순한 리팩토링 버전만은 아닐 것이다. 개발자 버전에서 이미 확인된 물체가 앞 뒤로 움직임에 따라 볼륨이 자동으로 증가 감소하는 3D 사운드기능, Chipmunk 물리 라이브러리 사용을 위한 고 수준의 도우미 기능, 3D공간에서 HTML문법으로 GUI를 만드는데 필요한 Navi 라이브러리등 새로운 기능이 있다.
Railgun
Creator and Lead Developer: David Koontz
Shattered Ruby처럼 Railgun은 Rails같은 개발 경험을 제공하는 것을 목표로 하는 3D 프레임웍이다. 이 것은 JRuby기반으로 자바로 작성된 3D 게임 프레임웍 JMonkeyEngine을 감싸고 있다. 아직 초기 상태에 있지만 충분히 지켜볼 만한 흥미 있는 프로젝트라 생각한다.
만든이는 Swing GUI를 만드는데 JRuby에서 영향을 받은 Monkeybar를 만들기도 한David Koontz이다.
The GGZ Gaming Zone Project
Founders: Brent M. Hendricks and Rich Gade
Developed and Maintained by an International Team
GGZ Gaming Zone은 게임 프로그래밍 언어로서 Ruby의 잠재적인 성장과 게임 영역에서 Ruby의 성장으로 인해 최근에 Ruby를 지원하기 시작했다. KDE와 Gnome둘 모두에 대한 공식 온라인 게임 개발 플랫폼으로서 GGZ는 대 부분의 리눅스 배포판에 패키징 되어 있다.
GGZ는 GNU처럼 반복적인 의미를 가진 머리 글자이다. 실제 GGZ가 8년 전에 만들어 졌을 때 초창기에 Gnu Gaming Zone혹은 GGZ로 불리워 졌다. GGZ를 만든이들은 GNU 프로젝트의 한 부분이 되기를 바랐지만 나중에 이를 포기하고 GGZ Gaming Zone이라는 이름으로 결정했다.
GGZ는 게임 개발자들을 위한 많은 유용한 자료를 가지고 있다. 네트웍용 게임, 자리예약의 사인에서부터 최고 점수를 저장하는 서비스를 제공하는 라이브러리 등이 그것이다. GGZ에는 십여 개의 게임과 플레이어 랭킹과 토너먼트 계획과 같은 정보 엑세스를 위해 RESTful API를 사용하는 게임 커뮤니티를 위해 디자인된 웹 포털 또한 있다. 포털 소프트웨어는 GGZ 커뮤너티 사이트에서 실행되며 여기에서 현재의 토너먼트 계획을 알 수 있다. Spade가 특히 유명하다. 정기적인 Spade토너먼트가 있다.
GGZ 커뮤너티 사이트에 인스톨된 게임을 하기 위한 계정을 위한 사인도 그 무엇도 설치할 필요도 없다. 단지 손님으로 로그온 한 후 Play Now 버튼을 누르기만 하면 된다. 컴퓨터에 GGZ 소프트웨어를 설치하고 시작 클라이언트가 실행되고 있는 경우라면 설치된 게임을 하기 위해 GGZ 커뮤너티 서버를 선택할 수 있으며 자신의 로컬 머신으로 GGZ서버를 선택할 수도 있으며 친구의 컴퓨터나 혹은 전세계의 GGZ서버가 실행되고 있는 어떤 것도 서버로 선택할 수 있다.
GGZ로 패키징된 클라이언트는 기본적으로 게임을 시작할 수 있는 채팅 클라이언트 이다. 클라이언트는 가상 테이블의 상태에 관한 정보를 제공하고 시작이 가능한 게임 리스트를 보여준다. 가상 테이블은 게임이 진행 중 인지 혹은 사람들이 게임을 위해 다른 사람들을 기다리고 있는지를 보여준다. 여러 사람이 하는 게임을 시작한 경우 어떤 자리가 누구에게 할당되고 어떤 자리가 누구를 위해 예약되어 있고 컴퓨터에게는 어떤 자리가 할당 되는지를 지정해야 한다. 게임자로 혹은 지켜보는 이로 게임에 참여할 수 있다.
GGZ로 패키징된 게임이 아래에 있다. GGZ게임 코드는 일반적으로 게임서버 코드와 게임 클라이언트 코드로 분리된다. GGZ는 여러 게임에서 하나 이상의 클라이언트를 제공한다. 3가의 아주 다른 형태의 틱택토 클라이언트가 아래에 있다. 여러 개의 전 처리부가 있는 경우 클라이언트는 사용자로 하여금 이중 하나를 선택하도록 한다.
그림8. GGZ로 배포된 게임
GGZ가 같은 게임에 대해 여러 개의 클라이언트를 지원과 여러 개의 게임 서버 지원을 용이하게 하는 아키텍쳐가 아래에 있다.
그림9. GGZ 아키텍쳐
GGZ는 메시지 타입을 정의하고 클라이언트와 서버 사이의 통신을 위해 각 메시지를 동반해야 하는 데이터 종류를 서술하는 프로토콜을 발표했다. 예를 들면 GAME_SPECTOR_SEAT는 클라이언트가 관찰자로 게임에 참가하길 원하는 사용자를 가리키는 게임 클라이언트에게 송신할 수 있는 메시지 타입이다. 이 프로토콜은 자리 고유번호(정수)와 플레이어 이름(문자열)이 GAME_SPECTOR_SEAT메시지와 함께 송신되어야 함을 규정한다.
게임 클라이언트와 게임 서버 사이와의 통신 이외의 모든 것에 대해 GGZ는 메시지 송신에 사용되는 넷트웍 프로토콜과 GGZ가 정한 프로토콜 모두를 감싼 유틸리티 라이브러리를 제공한다. 이 라이브러리는 다이어그램에서 초록색으로 강조되어 표시된다. GGZ에는 C가 우선 언어로 사용되었지만 이 라이브러리를 위한 Ruby버젼 또한 있다. Ruby C확장 가운데 하나를 위한 고 수준의 순수한 Ruby랩퍼 뿐만 아니라 Ruby바인딩은 붉은 색으로 강조된다.
각 게임은 게임 클라이언트와 게임 서버사이의 통신을 위해 다른 프로토콜을 사용하므로 GGZ는 모든 게임에 사용될 미리 패키징된 라이브러리를 제공할 수는 없다. 대신에 제공하는 것은 ggzcomgen으로 불리는 유연한 코드 생성 유틸이다. XML문서로 게임 프로토콜을 정의하고 명령라인 인자로 넷트웍 프로토콜을 정하면 유틸은 넷트웍에 적절한 데이터 타입을 전송하기 위해 약속된 넷트웍 프로토콜을 사용하는 게임 프로토콜에 있는 메시지에 대한 메서드를 포함하는 파일을 생성한다. 생성된 넷트워킹 코드는 net.rb처럼 나타나며 붉은색으로 강조된다. 유틸은 Ruby뿐만 아니라 Python과 C소스도 함께 생성한다.
코드 생성자 ggzcommgen자체는 Ruby로 작성되어 있으므로 붉게 강조된다. Ruby로 작성된 GGZ의 유일한 부분이다.
GGZ의 Ruby바인딩은 대 부분 지난 6개월 내에 추가되었다. 개념 검증을 위해 GGZ개발 리더인 Josef Spillner는 QtRuby를 사용하여 기본적인 틱택토 클라이언트와 Rubytoe로 불리는 틱택토 게임 서버를 만들었다.
그림10. QtRuby로 만든 틱택토
실험적인 Ruby 클라이언트와 실험적인 Ruby 서버 모두 아주 기본적이긴 하지만 이 것들은 전체 GGZ Ruby 패키지에 대한 잠재력을 나타내고 있다. Pygame과 긴밀하게 관련되어 있는 GGZ Python 패키지가 있다. GGZ개발자들은 이 시리즈에서 커버 가능한 프레임웍중의 하나를 Ruby 게임 프로그래밍 프레임웍으로 통합 하는 것에 대해 고려하고 있다.
Ruby게임 개발 자료 조사에 대한 결론을 내리고자 한다.
Ruby로 작성한 게임을 하는 것이 Ruby로 프로그래밍 하는 것 만큼 재미 있을 수 있을까? 게임이 적절한 시간 안에 이뤄져야 하는 동작에서 브레이크가 너무 많이 걸려 너무 느리게 동작하지는 않을까? 게임 세계에서 루비가 적절한 것으로 대우 받을 수 있을까?
첫 번째 글의 시작 부에서 약속한 대로 Ruby의 garbage collector가 정말로 게임을 실행을 느리게 만드는지를 포함한 성능 문제가 개발자들이 Ruby게임 개발 프레임웍으로 게임을 개발하거나 게임을 하는 것에 걸림돌이 되는지에 대해 설명하고자 한다. 그리고 또한 상업 비디오 게임 시장에서 Ruby의 상태에 대해서도 말하고자 한다.
이 이슈의 어떤 것들도 이 글에 소개한 게임 프레임웍의 개발자들에게 걸림돌이 되지는 않는다.
현재 동작하는 것 보다 대략 10배 정도 더 빠른 정도로 Ruby 프로그램을 동작하도록 하는 잠재력을 가진 작업에서 Ruby로 된 여러 개의 구현물이 있다. Ogre.rb를 만든 Jason Roelofs는 Ogre.rb나 Shattered Ruby1.0버전이 준비될 무렵 까지는 Ruby성능의 획기적으로 나아질 것으로 믿긴 하지만 Ruby1.8.6버전에서는 아직도 가비지 컬렉션으로 인한 심각한 지연 현상을 경험하고 있다고 말한다.
Ruby Shattered를 만든 Martyn과 Mikkel Garcia는 모든 프레임에 대해 강제로 가비지 컬렉션을 수행한다. 가비지 컬렉션은 더 이상 그들에게 화면을 멈추게 하는 원인이 아니다.,
Gosu를 만든 Julian Raschke는 최근에 10초마다 가비지 컬렉션을 호출 하도록 Gosu를 수정 하려고 했다. 그러나 그는 이 것이 만들어 내는 큰 문제를 생각하지 못한 이유로 최근 릴리즈에 앞서 이 코드를 제거했다. 최근 릴리즈에서 Gosu성능 향상에 대한 작업을 진행 했지만 가비지 컬렉션은 그가 고려한 큰 문제가 아니었다.
최근까지도 멀티미디어 회사가 Gosu의 Ruby버젼 사용 시작을 멈추지 않았다. 그 회사는 Thinking Pictures이다.
누가 Ruby 게임 개발 프레임웍으로 상업적인 비디오 게임을 만들고 있는지를 말할 수는 없지만 Ruby게임 개발 프레임웍이 비록 시작 단계이긴 하지만 상업적으로 사용되고 있다고 말할 수는 있다.
플레이를 시작하려면 "시작"을 클릭하시오.
Andrea O.K. Wright는 Fort Washington에 있는 컨설팅회사 Chariot Solution에서 그녀의 동녀들과 함께 매주 화요일 점심시간을 이용해 Ruby관련 모임을 이끌고 있다. 그녀는 RubyConf 2007이외의 여러 컨퍼런스에서 루비용 게임 개발에 관해 발표했다.
TAG :
이전 글 : 유즈케이스 다이어그램(2)
다음 글 : LILO와 GRUB 부트로더
최신 콘텐츠