행사 리뷰

KGC2012 후기

여러분께 KGC2012에서 제가 들은 강연에 대해서 설명해드리겠습니다 🙂 일단 먼저, 여기에 작성할 때 강연 내용에 대한 순서는 꽤 뒤죽박죽으로 되어 있음을 미리 알아주세요. 그리고 ESC 한번 잘못 눌러서 날아갔기 때문에 중간 중간 빼먹은거 있을 수 있습니다.

1. 인디 게임 개발 시 주의할 점 – 허민구, Dev Arc

인디 게임 개발의 특징으로는, 주로 소수 인력으로 개발된다는 점, 그 때문에 유연성이 높고 개발 속도가 빠르다는 점, 문서보다 대화로 게임을 개발한다는 점, 팀원간의 신뢰가 바탕이 되어 개발이 진행된다는 점이 있습니다.

문서보다 대화로 개발에 대한 이야기를 풀어나가지만, 정말 꼭 필요해서 개발자가 요구하는 문서는 작성해서 공유합니다. 대화로만 이야기를 풀 수는 없기 때문입니다.

소수 인력으로 개발하기 때문에 게임의 스케일을 제대로 잡고 개발을 해야 합니다. 이 강연에서는 100명이 Skyrim을 개발하는 것과, 3명이 Angry Birds를 개발하는 것으로 비교하여 설명을 했는데, 100명이 Angry Birds를 개발하면 놀게 되는 사람이 생기고, 3명이 Skyrim을 개발하면 몇 년이 걸려야 개발을 완료할 수 있을지 장담을 할 수가 없지요. 때문에 너무 큰 스케일의 게임은 개발하지 않을 것을 권장하며, 처음에 스케일을 크게 잡고 중간 중간 크기를 키우는 것도 나쁘지 않지만, 과하게 키우는 것은 자제해야 합니다.

또한 인디 게임은 장기 목표 및 단기 목표를 확실하게 잡고 개발해야 합니다. 물론 이는 일반적인 게임들도 마찬가지이지만, 인디 게임은 스케일이 작은 게임을 만드는 만큼 다른 게임들에 비해 단기 목표를 더 확실하게 잡고 시작해야 합니다. 때문에 게임의 전체 구조를 제대로 파악하고 있어야 합니다.

또한 어떤 일에 대한 결정은 되도록 빠르게 해야 합니다. 강연에서는 자신이 글로벌 게임 잼과 홍익대 게임 잼에 참가했으나 아이디어 결정이 너무 늦어져서 둘 다 완성을 못했다는 것을 예로 들었습니다. 즉, 어떤 일에 대한 분기, 예를 들어 이 기능을 추가하느냐 마느냐에 대해 빠르게 결정하자는 것이고, 기능을 추가한다면 빠르게 그에 대한 대책을 마련하고, 기능을 추가하지 않는다고 하더라도 나중에라도 추가할 수 있다는 것입니다.

게임의 초기 기획도 중요합니다. 맨 처음 나온 프로토타입이 재미가 없으면 여러 요소를 붙여도 재미가 없으니 빠르게 다른 게임을 기획하라는 이야기를 했습니다. “이거 재미가 없는데 상점에서 아이템 업그레이드 하는거 붙이면 재밌지 않을까?”라는 등의 의견이 나와서 기능을 추가해도 재미가 없다는 결론이므로 재미없는 프로토타입이 나오면 재빠르게 아이디어를 교체하라고 했습니다.

강연 중간에 인디 게임 개발할 때에는 사운드 찾는 것이 가장 어려운 일이므로 어떻게 써도 상관이 없는 사운드들이 공개되어 있는 FreeSound라는 사이트를 소개해주었습니다.

2. 는 안들음. 대신 Unity3D 부스에서 미니 세션 “Unity3D로 2D 게임 만들기” 들음.

세션을 진행해주신 분은 Unity3D를 개발한 Unity Technology Korea에 입사한지 얼마 안 되신 분이라는 듯 했습니다. 세션을 시작하기 전에 간단하게 먼저 미리 만들어두셨던 “대포로 과녁 명중하는 게임”을 시연해주셨습니다. 이 때까지만 해도 그 세션 듣고 있는 사람 저 포함해서 두 세명, 나머지 전부 Unity3D 관계자 분들 ㄷㄷ…

일단 Main Camera 설정을 해주셨는데, Perspective를 Orthographic으로 변경해주셨습니다. GROW Game Team 분들은 아시리라 믿습니다만, 원근 투영을 하는 카메라를 직교 투영을 하도록 변경해서 게임 객체가 멀리에 있던 가까이에 있던 크기가 같도록 보이게 만들어 주었습니다.

그리고 화면에 Far 이미지와 Near 이미지를 놓아 배경을 만들어 주었고, 여기에 두 개의 이미지를 그룹화해서 대포를 만들고 과녁도 만드셨습니다.

과녁에는 Component->Physics->Rigidbody를눌러 Rigidbody 컴포넌트를 붙여주었고, Use Gravity를 체크하여 물리 연산을 하되, 중력을 적용하도록 만들어 주었습니다. 실행해보면 밑도 끝도 없이 과녁이 떨어져버리기 때문에 맵의 하단 부분에 보이지 않는 객체를 하나 만들어주어 Rigidbody 적용하고 Use Gravity 체크를 꺼주었습니다.

대포는 포탄을 발사해야 하기 때문에 포탄 이미지 만들고 Rigidbody 붙여주고 중력 켜주어 Preset을 만들어 주었습니다. 대포에 스크립트를 작성하는데, Preset으로 만든 포탄을 붙여 키를 누를 때마다 생성하도록 만들어주었습니다.

이 다음부터는 몇 가지 코드 작성해서 게임 완성해서 시연하고 미니 세션 들은 사람들한테 책도 주고 그랬습니다.

3. C#에서 메모리 관리가 힘드세요? – 조명근, 엔도어즈

일부 내용은 이미 알고 있던 내용들입니다만, 새로 알게 된 내용들도 있었습니다.

먼저, C#에서 Garbage(이하 가비지)를 생성하는 것을 최소화하기 위해 여러 권장책을 말씀해주셨습니다.

1) 문자열 조합 코드에서 + 연산자를 사용하지 말고 StringBuilder 클래스를 사용하여 만들어주거나 String.Format 함수를 이용하여 만들어줄 것.
2) 메서드 안에서 클래스를 new를 해주지 말고, 가능하다면 클래스 대신 구조체로 만들어서 new를 하고, 매번 같은 클래스를 만들어준다면 멤버 변수로 만들어주어 Cache와 비슷한 기능을 하도록 만들어줄 것.
3) Boxing을 줄어주어야 하는데, 주로 Collection에서 발생하므로 일반 Collection 대신 Generic Collection을 쓸 것.

C#에서 클래스와 구조체의 차이는 지금 작성해드리자면 레퍼런스 타입이냐 밸류 타입이냐의 차이입니다. 그리고 그 사이에서 변환이 발생할 때 Boxing과 Unboxing이 발생하게 되고요.

그러면, 게임을 구동하다보면 메모리가 늘어나는 현상이 있는데, 아래와 같은 이유로 발생합니다.

! 의도하지 않은 참조
– 두 군데 이상에서 참조한 다음, 한 군데에서만 참조를 해제했을 경우에는 참조가 남아있기 때문에 가비지 컬렉션이 되지 않습니다.
– 상호 참조한 경우도 각각 적어도 참조가 1 이상이므로 가비지 컬렉션이 되지 않습니다.
– 때문에 WeakReference 클래스를 사용해주는 것이 좋습니다.

WeakReference는 설명하자면 좀 긴데, 단순히 설명해드리자면 참조 카운트가 0일 경우에 자동으로 null을 넣어서 가비지 컬렉션이 됐는지 쉽게 알아볼 수 있는 클래스입니다. 멤버 속성으로 Target이라는 녀석을 가지고 있는데, WeakReference 객체를 생성하여 이 Target에 관리하고 싶은 객체를 넣어주면 참조 카운트가 0이 되어서 가비지 컬렉션이 됐을 때 Target에 자동으로 null이 들어가게 되어 쉽게 확인이 가능합니다.

원하는 시점에 메모리를 해제하고 싶을 때가 분명 있습니다. 이럴 때는 IDisposable 인터페이스를 상속받아 Dispose 메서드를 구현해주어 이 Dispose 메서드 안에 메모리 해제 코드(null 대입, Native 객체 삭제 등)를 작성합니다. Dispose 메서드가 호출되었다고 해서 객체 자체가 free나 delete처럼 메모리 해제가 되는 것은 아니지만, 명시적으로 메모리를 정리한다는 점에서 많이 사용해주는 것이 좋습니다.

Unity3D에서의 경우, Mono에 내장된 구형의 가비지 컬렉터를 사용하고 있습니다. 따라서 GC.Collect가 자동으로 호출되었을 때 순간적으로 멈춤 현상이 발생할 수 있습니다. Asset 메모리는 Unity3D가 관리합니다. 이 Asset들은 기본적으로 Native 코드로 되어있기 때문에 관리되지 않는 메모리 데이터라서 Mono에서 따로 관리해주지 않습니다.

또한 Unity3D의 Asset 관리나 Mono의 가비지 관리 모두에서 사용중인 메모리가 순간적으로라도 늘어났다고 하더라도 다시 메모리가 줄어들지 않습니다. Leak은 아닙니다만, Unity3D에서 사용중인 메모리 할당용 공간(Heap)이 그만큼 늘어나있는 것입니다. 따라서 잦은 메모리 생성을 자제하고, Pool이나 Caching을 사용하는 것을 권장하며, 적절한 때에 메모리를 정리해주는 것이 좋습니다. Asset의 경우 Resources.UnloadUnsedAsset 함수를 호출하면 사용하지 않는 Asset은 메모리에서 내려줍니다만, 호출 시 보통 멈춤 현상이 있습니다.

4. 효출적인 멀티플랫폼 제작 : 콘솔에서 모바일까지 – 류태영·장진만·황순재·이세훈, 쿠노인터렉티브

국내에서 몇 안되는 콘솔 게임기용 게임 제작 회사인 쿠노인터렉티브에서 멀티플랫폼 게임 개발에 대한 이야기를 해주었습니다.

먼저, 개발에 앞서서 생각해야 했던 것으로 시장 환경, 퍼블리셔, 인력수급, 디자인 등이 있었는데, 각 플랫폼 시장에 대해서도 생각을 해봐야 했고, 퍼블리셔마다 요구하는 컨텐츠가 달라서 그것도 생각을 해봐야 했고, 플랫폼 개발 가능한 인력도 필요했고, 가능한 많은 장치에 쉽게 적용할 수 있는 게임 디자인도 고려해야 했다고 합니다.

본격적으로 개발에 들어갈 때에는 PC부터 개발할 지, 콘솔부터 개발할 지에 대해 고민했고, 당시 Unity3D는 콘솔 게임기를 지원하지 않았기 때문에 PC부터 개발을 했었는데, 딱히 어느것 부터 개발하든 상관은 없다고 말씀해주셨습니다. 또한 콘솔 게임기 SDK의 경우 한 개만 구매해도 충분히 개발이 가능하다고 하셨는데, PC에서 개발한 후 콘솔 게임기용으로 빌드해서 실행해보는 것만으로 충분했다고 합니다. 또한 엔진을 사용중일 때, 개발 지원을 받고 싶을 경우 모바일이나 PC의 경우 인터넷의 포럼들에 문의를 하거나 검색을 하면 금방 해결할 수 있지만, 콘솔 게임기의 경우 엔진의 전용 페이지에서만 콘솔 개발자들에게만 문의를 허용해서 난감했다고 하셨던거 같습니다만, 기억이 잘 안나네요.

또한 플랫폼마다 폴리곤 개수에 제한이 걸렸는데, 초기에 작성했던 모델이 계속되는 FPS 저하로 인해 300 폴리곤까지 내려간 예시를 들어주셨습니다.

셰이더의 경우 Unity3D의 경우에는 내장 셰이더가 콘솔 게임기에서 동작을 하지 않았고, 모바일의 경우에는 안드로이드에서 파편화 때문에, 특히 GalaxyS에서 의도되지 않은 결과를 출력해주었다고 합니다.

TRC(Technical Requirement Checklist)의 경우에는 일정에 반드시 고려를 해야 하고, 이 TRC 때문에 온라인게임과 같은 패치가 불가능하다고 했습니다. TRC가 뭐냐하면 쉽게 말해서 iOS나 Android, Windows Phone의 각각의 마켓에서 요구하는 앱에 대한 가이드라인이라고 생각하시면 됩니다. 이 TRC를 제대로 확인하지 않아서 리젝으로 인해 출시하지 못하는 경우도 있다고 합니다. 일정에 고려를 해야 한다는 말은, TRC에 맞게 고치는 일정이 필요하다는 이야기입니다.

엔진이 모든 세세한 기능을 제공하지 않아서 콘솔 게임기용 게임 제작의 경우 적어도 한 명 정도는 콘솔 게임 개발 경험이 있어야 개발이 가능하다고 했습니다.

모바일화 작업을 할 때에는 폴리곤 수도 낮추고 UI도 수정하고 퍼블리셔의 요구사항도 체크를 하고, 최적화도 수행해주어야 한다고 했습니다. 사실 4번의 경우에는 제대로 듣질 않아서 맞게 정리를 했는지 잘 모르겠네요.

5. DirectX11.1과 함께하는 윈도우8 게임 개발 – 김동훈, 곰즈 게임 스튜디오

Windows 8용 게임을 개발하기 위해서는 DirectX11.1, C++/CX, Visual Studio 2012, 추가적으로는 HTML5 또는 C#도 공부해야 합니다. 즉, 공부할 것이 많습니다.

또한 동작하는 하드웨어도 다양한데, 데스크탑과 노트북을 포함하여 태블릿에서도 동작하고 입력 하드웨어로는 펜도 있는 등 정말 다양한 하드웨어에서 Windows 8이 구동됩니다. 즉, 입력 기기가 다양하기 때문에 이에 대한 고려를 해주어야 합니다.

Windows 8 스타일 게임의 특징은 터치 위주의 UX를 가지고 있고, 무조건 전체 화면으로 동작한다는 점, 다른 앱과의 상호작용이 가능하다는 점입니다.

Windows 8 이전의 게임들의 경우에는 데스크탑 모드에서 동작하게 되며, 이 중 Unity3D로 개발된 게임은 조만간 Windows 8용으로 빌드가 가능하게 됩니다.

게임 프로그래밍 가능한 언어와 기술로는 XAML, DirectX, Javascript, C#, C++/CX 등이 있고요.

작동되는 원리는 Windows 8의 시작화면(타일 화면)에서 게임 구동을 하면 스플래시 화면이 뜨고, 게임이 실행되게 됩니다. 여기서 스플래시 화면에서 5초 이상 머물게 되면 리젝 사유가 되고요. 함수의 흐름으로 보자면 Initialize -> SetWindow -> Load -> Run -> 종료 순으로 됩니다. 이 함수들은 Visual Studio 2012에서 템플릿을 이용하여 프로젝트를 생성하면 기본적으로 제공하는 함수들입니다.

C++/CX에 대해 이야기하자면 사용하지 않을 수가 없다고 합니다. 물론 C++로 개발할 때의 얘기지만요. 하지만 참조 카운팅을 관리할 필요가 없어서 편리하고, C++과 문법이 비슷합니다(애초에 C++에 일부 문법 추가라서…).

프로세스 생명 주기를 관리할 때는 Suspend와 Resume이 매우 중요한데, Windows 8 앱은 세 가지 상태로 나눌 수 있습니다. Running App, Suspend App, Terminated App의 세 가지인데, Running App은 화면에 구동되고 있는 앱, Suspend App은 실행은 되고 있지만 화면에 표시되지 않는 앱, Terminated App은 종료된 앱입니다. 게임이 Running App 상태에서 다른 창을 열어서 Suspend App 상태가 되면 게임 루프가 진행되지 않습니다. 또한 Suspend App에서 Running App으로 돌아올 때에는 Load 함수가 호출되므로 이 Load 함수 구현 시 새로 시작한 앱인지 Resume 하는 앱인지 검사해야 하며, 그런 처림 없이 무조건 새로 시작한 앱으로 처리하면 다른 앱 열었다가 다시 게임 열면 처음부터 시작합니다.

Windows 8 앱의 경우 개발시 async와 await을 엄청 많이 쓰는데, 게임의 경우 보통 File I/O에서만 사용하며, 이 async에 대해서는 “황현동”님의 블로그에 자세히 설명되어 있다고 합니다. 나중에 질문 나온 것중 하나인데, async 안쓰고 File I/O 사용해도 중간에 잠시 멈춘다던가 하는 느낌만 없으면 보통 리젝되지는 않는다고 합니다. 물론 File I/O 작업할 때 눈에 띄게 프리징 발생하면 리젝 ㅋ

DirectX 11.1은 Visual Studio 2012에서 SDK를 따로 설치하지 않아도 되며, Windows 8 스타일 게임은 무조건 11.1로 개발해야 합니다. 단, 9~11.1까지는 모두 통합되어 있어서 DirectX9만 지원했던 그래픽카드라도 DirectX11.1이 동작한다고 하며, 하드웨어 시뮬레이션을 통해서 제대로 지원하는지 알 수 있다고 합니다. 이 하드웨어 시뮬레이션은 DirectX ControlPanel에서 적용할 수 있다고 하네요.

또한 성능 동적 체크를 통해서 동작 가능한 그래픽 하드웨어인지 검사도 가능하다고 하고요.

Direct3d와 Direct2D 사용이 가능하고, 이에 대해서는 예제를 확인해달라고 하셨습니다.

Windows 8 게임 개발시에는 1366 * 768 해상도에서 터치 환경으로 테스트하는 것을 권장한다고 하셨습니다. 1366 * 768은 스냅 뷰를 이용할 수 있는 최소한의 해상도인데, 이 스냅 뷰에 대해서는 텍스트로만 설명드리기 어렵네요. 쉽게 말하면 화면을 분할하는 겁니다. 화면은 풀 뷰(Full View), 스냅 뷰(Snap View), 필드 뷰(Field View)로 나눌 수 있는데, 풀 뷰는 화면 전체를 한 앱이 사용하는 방법, 스냅 뷰는 자기 자신이 가로 크기 320 만큼의 화면을 할당 받아 사용하고 다른 앱이 나머지를 사용할 때, 필드 뷰는 스냅 뷰의 반대입니다. 이 상태를 View State라고 하며, 이 View State가 변경됬는지에 대한 여부는 Resize 이벤트가 발생했는지로 알아볼 수 있다고 합니다.

이외에 Landscape와 Portrait도 지원합니다.

시작 화면의 Live Tile을 이용하여 시작 화면에서 동적으로 동작하는 아이콘으로 게임에서의 캐릭터 상태나 소식 등을 전달받을 수 있습니다.

Notification도 받아서 화면에 표시해줄 수 있고요.

Windows 8에서 기본으로 제공하는 Setting Pane이라는 UI를 통해 설정 화면으로 넘어가는 것을 쉽게 할 수 있습니다.

하단이나 상단, 또는 전체 화면으로 표시되는 AppBar를 게임에 이용할 수도 있지만 많이 사용할만한 녀석은 아니라고 하네요.

Share Contract 기능을 이용하여 게임의 어떤 상태를 공유할 수 있다고 합니다. 이 기능은 공개하고 싶은 기능만 API로 운영체제에 알려주면 사용자가 Share 기능 실행 시 알아서 Facebook이나 Twitter 등으로 공유할 수 있도록 한다고 합니다.

입력은 마우스의 경우 터치와 동일하게 이벤트를 받고, C++에서의 경우 키보드는 기존의 Win32 코드의 사용이 가능하다고 합니다.

또한 Windows 8 스타일 게임 개발 시 MonoGame Framework라는 것을 이용하여도 게임을 개발할 수 있는데, XNA와 C#으로 개발할 수 있습니다.

지금까지 만들어진 여러 Windows 8 스타일 게임들을 몇가지 살펴보면 ARMED는 MonoGame Framework로 개발, Birzzle은 Direct2D로 개발, Fruit Ninja는 Direct3D로 개발, Cut the rope는 HTML5로 개발, 뽀로로는 Direct3D와 Direct2D를 혼합해서 개발했다고 하네요.

Windows 8 Store의 경우 패키지 업로드 가능한 용량은 최대 2GB이고, 앱의 배포 시에 가격 정책은 무료, 유료, 체험판, 인 앱 결제를 지원합니다. 가격은 최소 $1.49에서 최대 $999.99를 설정할 수 있고, 수익 배분은 기본적으로 70:30이지만, 일정 수익만큼 벌어들이면 80:20으로 조정된다고 하네요.

하나의 입력 장치에서만 입력이 가능한 경우에 리젝 사유가 된다고 하네요. 예를 들면 가속도 센서만 이용해서 즐길 수 있는 게임의 경우 데스크탑이나 노트북에서는 즐길 수가 없으니까요.

태그 지정됨

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Google photo

Google의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

%s에 연결하는 중

This site uses Akismet to reduce spam. Learn how your comment data is processed.