Mono for Unreal Engine

공식 사이트: http://mono-ue.github.io/

 

Mono for Unreal Engine Unreal Engine 4(UE4)에서 로직을 C#으로 기술할 수 있도록 하는 플러그 인.

 

UE4는 최신 기술을 사용한 고품질 그래픽을 표현하는 것이 가능한 게임 엔진.

이용하는 데 필요한 것은 19$/month이고 학생이라면 GitHub Student Developer Pack으로 무료.

 

UE4에서 로직을 기술하는 방법으로는 블루 프린트라고 하는 독자적인 시스템과 C++이 있지만, 이 플러그 인에 의해 C#으로도 로직을 기술할 수 있게 되었다.

 

Mono for Unreal Engine 자체는 UE4의 서브 스크립션을 가지고 있으면 무료지만 어째서인지 전화 번호와 주소 입력을 요구하고 있다.

개인 정보를 입력하는 이유는 궁금하지만 UE4에서도 C#를 쓸 수 있다는 것은 좋다.

 

 

 

Paradox Engine

공식 사이트: http://paradox3d.net/

 

Paradox Engine OROCHI Yebis 등 미들웨어로 유명한 실리콘 스튜디오의 게임 엔진.

완전히 무료.

공식 사이트에 접속하면 커다랗게 Create cross-platform games in C# 이라고 적혀 있다.

Paradox EngineUnity와 비슷하게 게임 화면을 보면서 요소의 배치 등을 할 수 있는 것은 아니다.

어디까지나 개발은 코딩이 주를 이룬다(일단 로드맵에는 A full scene editor이 있다).

Paradox Engine을 실행하면 Paradox Studio라는 툴이 켜진다.

Paradox Studio는 에셋(화상이나 음성 등)을 관리하는 기능이 주를 이루고 있다.

프로젝트를 작성하면 Visual Studio와 같은 형식의 sln파일이 생기므로 코드를 Visual Studio에서 관리, 에셋을 Paradox Studio에서 관리 라는 형태로 개발이 가능.

 

, 특징으로는

async/await대응

  일부의 비동기 처리의 메소드는 await을 붙여서 호출 할 수 있게 되어 있다.

저 레벨 API 접근

  DirectX OpenGL의 저 레벨 API에 접근할 수 있다.

확장 HLSL

HLSL을 확장한 언어로 쉐이더를 편리하게 다루기 쉽다.

 

참고로 올해 오픈 소스 버전이 출시 되었고, 바이너리판과 오픈 소스 버전으로 서로 라이센스가 다르다.

바이너리판에서 만든 게임은 로열티 무료로 특별히 조건이 없다.

오픈 소스 버전은 GPLv3이므로 소스로부터 빌드한 Paradox Engine에서 만든 게임은 GPLv3으로 소스를 공개할 필요가 있다.

 

 

 

출처: http://qiita.com/jag5X/items/68606bfbb768019a8354

 

 

저작자 표시
신고
by 흥배 2015.01.20 08:00

이전 회사에서 만들었던 게임은 작년말까지는 UI 부분을 Lua 스크립트로 제어하였습니다.

(최종적으로는 Lua 스크립트를 덜어내고 다른 UI 미들웨어를 사용하게 되었습니다)


WOW에서 LuaUI에 사용한 것이 많이 알려지면서 여러 회사에서 고려하고 있는 것으로 알고 있습니다.

저희의 경우도 WOW의 영향 및 요즘 트랜드가 UI에 스크립트를 사용하는 것이라서 제작 초기에 별 고민 없이 UI 사용에 Lua를 사용하기로 했습니다(이것이 결국 개발 도중 큰 문제가 되었습니다, -_- ).


저는 예전에 MMORPG 게임을 만들 때 퀘스트 부분을 Lua 스크립트를 사용했을 때 스크립트 작성자가

비 프로그래머라서 코딩 실수로 고생하는 것을 본 경험이 있어서 초기에 제가 경험 했던 것에 대한 이야기를 기획자와 클라이언트 프로그래머에게 했습니다. 그러나 UI 스크립트와 관련된 사람들은 한귀로 듣고 흘려버렸고, 저는 제가 주 담당자가 아니고 알아서 잘 하겠지 라는 생각에 이후 주의 깊게 살피지 않았습니다. ( 여러 이유는 있었지만 안일하게 제가 꼼꼼하게 확인하지 않고 너무 맡겨 놓은 것이 지금도 가장 큰 후회가 되는 것입니다. )

 

개발하면서 이 스크립트에 발목이 잡혀서 개발 속도가 제대로 나오지 않아서 꽤 애를 먹었고 여러 부작용이 있었습니다.( 정확하게 말하자면 Lua라는 스크립트 언어보다는 개발 시스템쪽 문제입니다 ).

 


제가 경험했던 문제는 다음과 같습니다.


1. 개발 기간이 긴 프로젝트가 아닌데 스크립트 개발까지 같이 해야 된다.

 - 캐주얼 게임으로 개발 기간이 긴 게임이 아니고 경험이 부족한 개발자가 개발하기 때문에 게임 자체 구현에도 생각 이상으로 시간이 많이 걸렸는데 스크립트 부분까지 초기 완성 이후 계속 추가 작업을 하게 되어 부족한 시간이 더 부족하게 되었음.

2. 스크립트 사용에 대한 가이드 라인을 만들지 않고 무턱대고 개발을 시작했다.

- UI 스크립트에 어떤한 기능이 필요한지 명확하게 정하지 않고 큰 윤곽만 잡은 후 개발. 초기 개발 이후 스크립트를 사용할 사람이 피드백을 제대로 전달하지 않음. UI 스크립트 개발자는 바쁘다는 핑계로 편의성이 극히 나쁜 스크립트 사용 방법을 개선해 주지 않음.

3. 스크립트 코드의 품질이 떨어지고, 디버깅이 어렵다.

- 스크립트 코딩을 비 프로그래머가 하다보니 구조가 엉망이 코드가 만들어져서 유지보수에 아주 좋지 않았음. 스크립트 사용 편의성이 거의 고려되어 있지 않아서 UI 구현에 꽤 많은 코딩을 해야되고 까다로움.  Lua로 만들어져서 스크립트 코드에 버그가 있을 때 화면이나 파일에 로그를 찍고 그것으로 버그를 찾고 수정하려고 하니 버그가 발생하면 잡는데까지 C++ 코드를 사용한 것보다 훨씬 더 많은 시간이 소요 되었음.

4. 개발 도중 테스트를 대충한다.
- 이유는 클라이언트에서 게임 콘텐츠 구현 후 이것을 기획으로 넘겨서 UI 스크립팅을 하 여 최종적으로 끝나는 형태가 되다보니 클라이언트에서 테스트 할때 게임 내에 로그를 찍는 것으로 테스트 확인하여 결과를 제대로 확인하지 않았음( 이런 문제와 더딘 개발 속도 문제 때문에 후반에는 클라이언트 파트에서 스크립트까지 다 하는 것으로 변경되었음 ).

5. 구현 완료 기간을 지키기가 힘들다.

- 게임 콘테츠 구현 시 클라이언트 파트에서는 UI 스크립트에서 호출할 기능을 만든 후 테스트 하고 기획에 넘기면 기획자가 UI 스크립팅을 하는 것으로 하나의 구현이 끝나는 방식이었음. 그래서 클라이언트에서 UI 스크립트에서 호출해서 사용할 기능을 제대로 구현하지 못하면 클라이언트 <-> 기획자간에 여러번 주고 받아야 되고, 도중에 어느 한쪽이 갑자기 다른 일이 생기면 딜레이가 생겨 버림.

6. 기획서가 나오지 않음.
- 기획자 한명이고 이 사람이 UI 스크립팅 작업을 하면 이것을 하느라 정작 기획서를 작성하지 못함.
또 기획서를 제대로 만들지 못했을 때 UI 스크립팅 작업이 많아서라고 핑계를 되고 넘어가버림.




UI를 스크립트로 뽑아서 게임을 개발하는 것이 처음이라면 아래의 것을 주의했으면 합니다.

1. UI에서 어느 범위까지 스크립트가 관여할 것인지 명확하게 정해야합니다.
2. UI 표현에 어떤한 기능이 필요한지 세세하게 정한다.
3. UI 스크립트 개발자와 코딩을 하는 사람은 초기 완성 이후 긴민할게 협조하여 계속 개선해 나가야한다.
4. 기획자가 한 명이고 이 사람이 UI 스크립팅을 해야 되는 상황은 절대 피해야한다(기획서가 안나온다).
5. Lua 코딩이 쉽다고 하더라도 비 프로그래머의 코딩 실력을 절대 믿으면 안된다(구현을 못하던가 버그를 만드는 것보다 구조를 엄청나게 복잡하고 만들고 구현에 급급한 코딩을 해서 유지보수가 어려워진다).



ps :
생각 이상으로 UI를 코드에 하드코딩하는 것이 더 좋을 수 있습니다. -_-
요즘 유행하는 스케일폼에 대하여 너무 환상을 가지는 분들이 적지 않은데 이것도 잘 계획하여 사용하지 않으면 아주 피곤해집니다.
저작자 표시
신고
by 흥배 2009.04.06 00:38

이름을 대면 게임 해본 사람들은 알만한 중박 이상 성공한 온라인 게임 몇 개의 성공 스토리를 들어보니 클로즈 베타 서비스를 하기 전까지는 회사에서 버림 받던 팀이던가, 상업적인 성공은 꿈도 꾸지 않았던가, 언제 팀이 해체될지도 모른다는 불안한 상황에서 게임을 만들었다고 합니다.

그러나 이렇게 좋지 않은 상황이 오히려 아래와 같은 좋은 개발 여건이 형성되어 좋은 게임을 만들 수 있었습니다.

 

 

1. 만들 게임에만 집중할 수 있다.

만약 회사에서 주목하는 팀이었다면 사장님부터 시작해서 여러 군데서 이런저런 이야기로 게임 개발에 관여를 자주 하여 배가 산으로 가는 상황이 벌어지지만 관심을 가시는 외부 사람이 없으므로 외부 외압 없이 개발자들이 생각하는 것을 기준으로 집중해서 만들 수 있어 처음 생각했던 것에만 집중하여 정확하게 만들 수 있었습니다. 또 꼭 성공해야 된다는 부담이 없었기 때문에 결과(상업적인 성공)에 집착하지 않고 만들고 싶은 것에 집중할 수 있었습니다.

 

 

2. 높은 열정과 애자일한 개발 환경

회사 상부에서는 뭘 만들고 있는지 알기를 원하지도 않으므로 개발자 자신들이 만들고 싶은 것을 만들 수 있고, 자신이 하고 싶은 것을 하니 아주 열정적으로 일을 하게 됩니다.

그리고 회사의 지원이 없어서 소수의 인원으로 팀이 구성되어 의사소통이 아주 빨라서 계획과 실천이 쉽고 빠르게 이루어지고, 서로 해야 될 일을 미루지 않으며 협업 능력이 높아집니다.

어떤 프로세스가 없이 Agile 개발환경이 만들어졌습니다.

 

 

3. 블루오션의 게임을 만든다.

회사에서 돈 벌기를 바라지도 않으므로 현재 가장 많은 사람들이 즐기는 게임만을 만들지 않아도 됩니다. 오히려 현재 별로 서비스 되고 있지 않는 게임 장르를 선택하여 만들 수 있습니다.

회사는 많은 돈을 벌기를 원할 때는 많은 사람들이 플레이 하는 게임 장르의 게임을 만듭니다. 그러니 당연히 레드오션의 게임을 만들게 됩니다. 그러나 회사에서 처음부터 돈을 벌 것이라고 생각도 하지 않기 때문에 기존에 없는 게임을 만들어도 내버려둡니다. 자연스럽게 블루오션에 속하는 게임을 만들 수 있었습니다.

 

 

4. 최고가 아닌 최선의 게임을 만든다.

회사의 지원도 없어서 대작 게임을 만들 수 없기 때문에 유저가 원하는 모든 것을 다 만족하는 것을 만들 수 없습니다. 여러 가지 중 유저가 가장 원하는 것, 현재 서비스 되는 게임 중 없는 것을 찾아서 만듭니다.

다양한 것을 만들 필요가 없으므로 개발 기간은 짧아집니다. 유저가 뭘 원하는지 철저하게 분석하고 그것에 집중하므로 다른 게임과의 차별 점이 생기고 유저의 만족도도 높아집니다.

 

 

5. 운도 좋았다.

개발자들의 노력에 더하여 개발 외적인 부분에서 타이밍이 좋았던 것도 있었다.



성공 스토리를 들어보면 왜 좋은 게임을 만들 수 있었는지 충분히 이해가 갑니다.

성공의 조건이 많이 갖추어져 있었기 때문입니다.

 

그러나 과연 두 번째도 처음처럼 성공을 할 수 있을까에 대해 의문이 있습니다.

처음에 좋은 게임을 만들기 위한 조건을 가지기 위해 확실한 개발 프로세스를 갖추어서 한 것이 아니라 하다 보니 갖추어졌기 때문에 과연 두 번째도 처음처럼 성공을 위한 조건을 갖출 수 있을까에 대해서 의문이 생깁니다.

 

두 번째는 회사로부터 필요 이상의 관심을 받아서 여러 의견을 들어야 되고, 회사의 핵심 팀이 되어 대작 게임을 만들게 되어 팀원이 많이 늘었는데 예전에 작은 인원이 있을 때처럼 팀 관리를 하여 의사소통이 막힐 위험이 커졌고, 개발자 자신들도 두 번째는 처음보다 더 큰 성공을 원하고 약간의 자만감도 생겨서 모든 것을 다 있는 게임을 만들려는 욕심을 가지게 될 확률이 높습니다.

 

 

처음에는 성공의 조건을 우연에 의해서 만들었다면 두 번째는 계획적으로 만들어야 됩니다.


신고
by 흥배 2009.03.21 13:08

온라인 서버 제작자 모임(http://cafe.naver.com/ongameserver)에서 2009.01.19 ~ 2009. 01.31일까지 현재 온라인 게임 서버의 개발 및 서비스를 할 때 사용하는 OS에 대한 설문 조사를 했습니다.

85명이 참여 해 주셨습니다.

 

아주 많은 수의 개발자가 설문에 참여한 것은 아니지만 각 OS 사용 비율은 한국 게임업계의 상황과 거의 비슷하리라 생각합니다.

 

* 개발은 현재 개발 중인 게임의 게임 서버를 실행할 OS이고, 운영은 서비스 중인 게임의 게임 서버를 실행하고 있는 OS를 말합니다.



사용자 삽입 이미지

신고
by 흥배 2009.03.21 13:02

'온라인 게임서버 프로그래밍 벤치마크' 라는 책에 있는 내용을 간단하게 정리해 보았습니다.

자세한 내용은 책을 보세요 ^^

 

 

 

1. 소켓 이벤트 핸들링

 

IOCP > Overlapped Callback > select > WSAAyncSelect > WSAEventSelect

순서로 좋다고 합니다.


제 기억으로 2003년까지만 하더라도 IOCP 방식의 유용성에 대한 논란이 있었지만 이후 Windows 에서 대용량 서버를 만들 때 당연히 사용하는 방식이 되었습니다.

 

책에서 보니 1000명 이하에서는 select 방식도 성능이 괜찮았습니다. 1000명 이하의 접속을 처리할 때는 단순한 개발 및 멀티 플랫폼 대응을 위해 select 방식을 사용하는 것이 좋겠습니다.

 

WSAAyncSelect는 제 생각보다 성능이 좋지 않더군요. WSAEventSelect 보다 성능이 더 좋지 못하지만 WSAEventSelect는 성능도 괜찮고 사용 방법도 간편한데 접속이 64개밖에 되지 못하는 단점이 있습니다.

온라인 게임에서 클라이언트 측 소켓은 WSAEventSelect 방식을 사용하는 것이 좋겠습니다.

 

 

 

2. Accept 방식

 

AcceptEx + Pooling 이 제일 좋다고 합니다.

그렇지만 단순하게 접속 성능 테스트에서는 AcceptEx + No Pooling과 별 차이가 없지만 Pooling을 하면 Accept 부분을 빨리 처리할 수 있기 때문에 TimeOut 발생 확률을 줄일 수 있다고 합니다.

 

WSAAccept + Loop는 접속 처리 성능은 좋으나 동시 접속 수가 많을 때 TimeOut이 발생할 확률이 높다고 합니다.

 

 

 

3. 데이터베이스 인터페이스

 

작년까지만 하더라도 이 부분에서 제가 착각하고 있었던 것이 OLEDB ODBC 보다 빠를 것이라고 생각했는데 그렇지 않고 반대라는 것을 알게 되었습니다.

가볍고 속도를 중시할 때는 ODBC 방식이 좋고, ADO는 사용은 편하지만 성능상으로는 ODBC, OLEDB, ADO 중 가장 좋지 못합니다.

 

 

 

4. Nagle

 

수치적으로 No Nagle이 더 좋게 나오지만 사용하는 환경에 따라 꼭 좋다고만 할 수 없을 것 같습니다.

신고
by 흥배 2009.03.21 12:56

'SendLogMail'은 근래에 제가 만든 유틸리티입니다.

기능은 지정된 시간마다 게임서버의 로그 파일을 분석하여 제가 원하는 로그 Text를 메일로 보내줍니다(현재는 하루에 4번 메일이 옵니다).


이것이 필요한 이유는 게임 서버를 개발할 때 클라이언트의 버그나 서버의 버그로 로그 파일에 에러 로그가 남습니다. 그런데 게임 서버는 다른 컴퓨터에서 실행하고 있기 때문에 특별한 문제가 나타나기전까지는 로그 파일을 보지 않기 때문에 게임서버에서 에러 로그를 찍고 있는지 모르는 경우가 많습니다.


로그를 메일로 보내는 기능은 Log4Cxx 같은 로그 라이브러리를 사용하면 쉽게 사용할 수도 있지만 이것은 지정 로그레벨 단위로 메일을 보내기 때문에 제가 원하는 것이 아니었습니다. 저는 에러나 로그 레벨을 떠나서 제가 지정한 특정 단어와 관련된 로그를 특별한 시간마다 모아서 메일로 보내 주는 것을 필요로 했습니다.


개발 언어 : C#

Tool : Visual Studio 2008

기간 : 다른 개발을 하면서 틈틈히 만듬.

사용자 삽입 이미지


사용자 삽입 이미지


사용자 삽입 이미지



신고
by 흥배 2009.03.21 12:51

많은 곳에서 테스트 해 보지 않아서 정확하게는 모르겠지만

Windows XP에서 '비스타 타블렛 미니'라는 타블렛 주변 기기의 드라이버를

설치하면 게임 브리오(2.X)로 만든 게임이 제대로 실행이 되지 않습니다.

( 다른 엔진으로 만든 게임들은 잘 됩니다 )


게임 브리오 엔진의 Input 부분을 생성할 때 내부에서 무한 루프에 빠져 버린다고 합니다.

게임 브리오로 만든 게임을 다 테스트 해 보지는 않아서 100% 확실 하다고는 말 할 수

없으며 특히 Input 부분은 게임 브리오 엔진에서 제공해주는 것을 사용하지 않는다면

문제가 없을 수도 있습니다.


또 Window Vista에서는 '비스타 타블렛 미니'의 드라이버를 설치하지 않아도 되기 때문에

문제가 없습니다.


사용자 삽입 이미지

신고
by 흥배 2009.03.21 12:42

게임서버는 많은 수의 유저가 접속하기 때문에 실시간으로 많은 일을 막힘 없이 처리해야 됩니다.

게임서버가 처리 하는 일은 네트웍으로 받은 패킷을 처리하는 것도 있지만 유저나 어떤 객체를 정기적으로 조사 해야 되는 것이 있습니다. 보통 정기적으로 조사해야 되는 것들은 게임서버의 최대 동접자 수에 따라 크기가 커집니다. 크기가 큰 일을 막힘 없이 처리하기 위해서는 나누어서 처리 하면 좋습니다.

 

요즘은 많은 곳에서 Thread가 중요하다는 이야기를 많이 해서 Thread를 이용하는 것을 생각하는 분도 있겠지만 전 아직까지는 Thread는 언제나 제일 마지막 방법으로 생각하고 있습니다.    이유는 Thread는 아직까지는 High Risk Low Return이기 때문입니다.

 

Thread 없이 처리하는 방법 중 가장 간단한 방법은 많은 일을 한번에 처리하지 않고 나누어서 처리하는 것입니다.

 

예전부터 AI 작업을 처리할 때 Frame마다 나누어서 처리하는 방법이 있었는데 이와 비슷합니다.

게임이 초당 Frame이 만약 30 Frame이라면 30 Frame이 끝나기 전에 1 – 5 Frame에는 A AI 처리, 6 – 10 Frame에는 B AI 처리이런 식으로 30 Frame이 끝나기 전에 모든 AI 작업을 다 끝내어 복잡한 AI 작업을 끝냅니다.

게임서버에서도 이와 비슷한 방법을 사용합니다.

 

게임서버에서 정기적으로 해야 되는 일중 유저의 상태를 계속 조사해야 되는 것이 있습니다.

만약 최대 동접수가 10000명인 경우 이것을 매번 모두 조사하는 것보다 나누어서 조사하면 한번에 다하는 것과 처리 결과는 같으면서 성능은 올릴 수 있습니다.

 

10000명의 유저를 한번에 처리할 때

void CheckAllUserState()

{

for( int i = 0; i < 10000; ++i )

{

      …………

      Users[i].CheckState();

      ………

}.

}

 

 

한번에 2000명씩 나누어서 처리를 한다면

void CheckAllUserState()

{

// StartNum LastNum은 지역변수가 아닙니다.

………..

StartNum += 2000;

if( StartNum >= 10000 )

{

StartNum = 0;

}

 

  LastNum += 2000;

if( LastNum > 10000 )

{

     LastNum = 2000;

}

 

for( int i = StartNum; i < LastNum; ++i)

{

    …….

    Users[i].CheakState();

…….

}

}

신고
by 흥배 2009.03.21 12:24
1. 기획 문서를 그래픽 디자이너나 프로그래머들이 잘 본다.
- 경험이 짧은 기획자들은 자신이 만든 기획서를 프로그래머나 그래픽 디자이너가 잘 볼 것이라는 생각을 하는데 대다수 그렇지 않습니다.
보통 기획자가 만든 문서는 본인이 보면 전혀 이상할 것이 없겠지만 다른 사람이 볼 때는 암호 수준까지는 아니라도 결코 쉽게 볼 수가 없습니다.

문서를 보면 내용 흐름이 엉망진창이고 중요한 사항을 문서에서 잘 안보이는 곳에 살짝 적어놓고, 어떤 사항에 대해서 찾으려면 찾기도 힘들어 문서를 보다가 짜증이 나기도 합니다.
그기다 이런 문서가 기획이 변경이 되어 문서 내용이 바뀌면 어느 부분이 어떻게 바뀌었는지 찾기는 더 힘들어지고..
그래서 문서를 보는 것보다 직접 기획자에게 물어보는 것이 훨씬 빠르고 정확해서 기획 문서를 보기보다는 기획자에게 직접 물어보고 일하는 사람이 적지 않은것 같습니다.



2. 자신의 팀에서 만드는 게임을 자주 한다.
게임을 만드는 개발자도 게임을 할 때는 한명의 게이머가 됩니다. 아무리 자신의 팀에서 만든 게임이라도 재미없으면 하기 싫어집니다. 그리고 일 하느라 게임 할 시간 내기도 쉽지 않고...
또 개발 도중 게임은 계속 업데이트 되는데 플레이할 때 자동으로 반영되지 않고 모든 파일을 모두 다시 받아서 설치하던가, 아니면 수동으로 필요한 파일을 복사해야 된다면 귀찮아서 안 합니다.

팀원들이 만들고 있는 게임을 하게 하려면 게임이 재미도 있어야 되고, 버그도 없어야 되고, 업데이트도 편해야 됩니다.
그래서 최소한 자주 팀의 사람들에게 배포 하여 관심을 유도하고, 배포 되는 버전은 최대한 버그가 없도록 하고(있다면 빨리 수정하고), 패치도 자동으로 이루어져 게임을 간편하게 할 수 있게 해야 됩니다.



3. 회사(팀) 홈페이지를 최소한 하루에 한번은 접속한다.
하루에 네이버나 싸이를 100번 가더라도 자신이 근무하는 회사나 팀의 홈페이지에는 한번도 안 가는 사람이 꽤 있습니다. 그래서 회사에서 사내 홈페이지를 운영할 때는 사람들이 오도록 흥미로운 내용이나 중요한 것이 있어야 됩니다.
또 회사 컴퓨터 웹브라우저의 시작 페이지가 사내 홈페이지가 되도록 하는 등의 약간의 강제성도 있어야 하루에 한번이라도 홈페이지에 방문합니다.


신고
by 흥배 2009.03.21 12:07

온라인 게임은 서비스가 끝날 때까지 계속 업데이트가 해야 되기 때문에 패치 시스템은 필수 입니다.

그런데 이 패치 시스템은 게임을 서비스 할 때부터 필요한 것이 아니고 그전에 개발을 하는 도중에도 필요합니다.

 

게임을 서비스 하기 이전에 해당 개발팀의 개발자들은 자신들이 개발을 한것의 그때그때 만들어진 상태를 볼 수 있어야 됩니다(스케줄 표나 말로 듣는 것보다 만들어진 게임을 보는게 확실하죠).

현재까지 구현된 것을 보면 현재 어느 정도까지 개발 되었는지를 즉각 알 수 있고, 개발자 자신들이 유저가 되기 때문에 버그를 찾아 내던가 개선 사항을 찾고 건의 할 수 있습니다.

 

개발을 해보면 긴 기간에 걸려 구현 되는 것도 있지만 보통은 짧은 기간에 끝나는 구현이 많습니다. 만약 패치 시스템이 없다면 뭔가 새로운 것이 구현되거나 수정할 때마다 매번 클라이언트 전체 파일을 배포하던가, 바뀐 부분만을 어떻게 설치 해야 되는지 설명과 함께 개발자들에게 통보하여 반영해야 됩니다.

 

이렇게 되면 배포 하는 사람도 귀찮고, 개발을 하고 있는 개발자들도 뭔가 바뀔 때마다 수동으로 지우고 다시 설치하려고 하면 귀찮아서 자신이 만들고 있는 게임이지만 잘 하지 않게 됩니다.

 

이렇게 되면 게임의 구현 상태에 대해서 제대로 알고 있는 사람은 일부의 사람만 알게 되고, 아주 쉽게 찾을 수 있는 버그를 못 찾고 넘어 갈 수도 있고, 팀 내에서 좋은 아이디어를 듣기가 힘들어집니다.

 

 

사내에서 만들고 운용할 패치 시스템은 정식 서비스를 하는 것이 아니기 때문에 필요한 기능만 있어도 되고, 개발이 쉬워지기 때문에 짧은 시간에 쉽게 만들 수 있습니다.

그러니 미루지 말고 어느 정도 클라이언트가 구현되어 돌아가게 되는 시점에서 패치 시스템을 구현한 후 게임이 변할 때 즉시 배포를 하여 개발자들에게 피드백을 받기도 하고, 제대로 일이 진행 되고 있다는 안심을 심어 주어야 합니다.

 

 

Ps : 만약 패치 시스템을 만들 시간이 없다면 클라이언트 자체를 서브버전으로 관리하여 업데이트 내용을 배포 할 수도 있습니다. 다만 이것도 매번 서브버전 클라이언트로 업데이트를 한 후 게임을 해야 되는 불편함이 있기 때문에 일부는 사용하지 않을 수도 있습니다. ^^;;

개발자들은 자신이 만드는 게임이라도 냉정하게 비판하고, 불편하면 멀리하게 되는 경우가 많은 것 같습니다.

신고
by 흥배 2009.03.21 03:05
| 1 |