1-1. Scene:Update(elapsed) 함수를 가급적 사용하지 않는다.

이 함수는 매 프레임마다 호출되므로,
여기에 복잡한 코드가 들어가게 되면 전체적으로 게임이 매우 느려진다.

정말 필요한 것이 있다면 아주 적은 기능만 넣도록 한다.
솔직히 좀더 연구하면 Scene:Update() 말고도 대체할 수 있는 방법이 얼마든지 있다.


1-2. for, while 루프 반복은 최소화 한다.

for, while 루프는 아무리 많아도 100~200회 정도만 수행하도록 한다.
왜냐하면 게임을 개발할 수록, 이것이 점차 게임을 느려지게 만들기 때문이다.

1000번 이상 넘어가는 루프가 발생한다면, 알고리즘을 개선하든가...
게임의 기획을 다시 고려해보는 것이 좋다.

만약 1000번 이상 넘어가는 루프를 이용하다보면...
점차 게임 기능이 늘어날 수록, 이 루프를 자주 이용하는 상황이 오게 되는데
나중에 게임이 완성할 때쯤에 이것 때문에 다시 갈아 엎는 상황이 올 것이다.


1-3. Clone() 으로 복제된 Graphic 오브젝트들은 반드시 메모리 관리를 해야 한다.

게임오븐으로 많은 양의 오브젝트를 처리하려다 보면,
캐릭터나 몬스터를 위해 Clone() 함수로 여러 개의 그래픽 오브젝트를 만들 것이다.

이 때 Clone() 으로 복제된 오브젝트들은 반드시 관리해줘야 한다.
더 이상 사용되지 않는 그래픽 오브젝트들은 RemoveChild() 를 호출하여
Scene 에서 삭제하고, RemoveObject() 를 호출하여 메모리상에서 삭제해줘야 한다.

만약 이 작업을 해주지 않고 무작정 Clone() 호출하면 점차 게임이 느려질 것이고,
점차 메모리를 많이 잡아 먹게 될 것이다.

가급적이면 이러한 메모리 관리를 위해서 별도로 Memory Pool 을 만드는 것을 추천한다.


1-4. 화면에서 보이지 않는 오브젝트들은 아예 만들지 않거나, 삭제해버린다.

화면에서 더 이상 보여지지 않는 오브젝트들은 삭제해버리는 것이 낫다.

화면에 없더라도 Parent -> Child 관계로 묶여진 Graphic 오브젝트들은 항상 내부적으로
이벤트 처리 대상으로 남아 있기 때문이다.

그리하여 화면에 없더라도 많은 오브젝트가 존재하면 결국 게임을 느려지게 만드는 것이다.


1-5. 네트워크 통신에서 주고 받는 회수는 줄이고, 대신에 데이터 크기를 늘리는 쪽이 낫다.

이것은 게임오븐이 아니라 일반적인 네트워크 통신에서도 통용되는 것이다.

게임의 기능별로 패킷을 디자인해서 각각 패킷을 주고 받게 처리한다.
이 방법은 구조적인 측면에서나, 추후에 기능 확장면에서도 유리하다.

그러나 이러한 패킷들의 일부는 같은 시점에 2~3개 패킷이 동시에 보내질 경우도 있다.
이러한 것들은 아예 하나로 묶어서, 한번에 데이터를 보내도록 수정하는 것이 좋다.

이렇게 주고 받는 회수를 줄이면 응답 속도가 빨라질 뿐만 아니라
네트워크 대역폭을 절약할 수 있다.


1-6. 네트워크 통신에서 데이터 개수가 많으면 아예 문자열로 만들어서 한번에 보낸다.

20~30개의 반복되는 값들을 msg:SetValue() 함수를 20~30번 호출해서 데이터를 설정할 수도 있다.

이 경우에 데이터 개수가 많으면 아예 이들 값들을 문자열로 변환해서 한번에 보내고,
데이터를 받는 쪽에서 문자열을 파싱해서 값을 추출하는 것이 좋다.

데이터 개수가 많을 때 문자열로 만드는 것이 데이터량을 줄일 수 있을 뿐더러,
프로그램 코드나 데이터 구조가 좀더 정리가 될 것이다.

이 때, 문자열 변환할 때는 Serializable 클래스를 사용하기 보다도
string.format("%04x", val) 처럼 직접 문자열을 만드는 것이 좋다.

Serializable 클래스가 만드는 문자열은 최적화되지 않아서 문자열이 길어지기 때문이다.


1-7. 게임 진행 중간에 이미지 파일 로딩은 가급적 피한다.

게임 중간 진행하다가 이미지를 대량으로 로딩하는 경우가 있을 수 있다.
이것은 절대로 피해야 한다.

이미지를 로딩하는 순간, 프로그램이 멈춰버리고 순간적으로 CPU를 점유해버린다.

이런 현상이 자주 발생하면 윈도우 운영체제는 이 프로그램은 CPU를 많이 잡아먹는 녀석으로 분류해버린다.
그리고 우리의 똑똑한(?) 운영체제는 앞으로 게임 프로그램의 실행 시간(CPU time)을 많이 주지 않는다.

일반적으로 게임이 원활히 실행하기 위해서는 일정 수준의 CPU time이 필요하다.
그런데 위와 같은 상황이 발생하면, CPU time을 확보하지 못해서
게임이 점차적으로 느려지고, 나중에는 바보가 될 것이다.

심각한 수준까지 온다면 로딩하는데 5초면 되었던 것이
1분이 지나도 로딩이 끝나지 않을 수도 있다.


1-8. 게임 진행 중간에 이미지 로딩을 할 경우, 이미지를 나눠서 로딩하도록 coroutine을 사용하라.

루아의 coroutine은 가벼우면서도 관리하기 쉽도록 만들어져 있다.
덕분에 사용하는데도 수월하다.

게임 진행 중에 이미지가 필요하는 시점이 오기 전에,
미리 조금씩 이미지를 로딩하도록 coroutine 을 만든다.

for 루프로 이미지를 1000개 읽어들인다고 가정할 경우,
이미지 5~10개 읽고난 후에 coroutine.yield(-1) 호출해주고,
나머지는 다음 번에 로딩하도록 하는 것이다.


[마무리]
솔직히 말하자면, 게임오븐으로 만들어진 루아 게임은 빠르지도 않을 뿐더러,
메모리도 많이 먹는 편이다.

항상 최적화에 염두해야 좀더 게임을 규모있게 만들 수 있을 것이다.

신고

10월 15일자로 클로즈 베타 시작되었네요.

장르별로 게임을 모아보면 다음과 같습니다.

전체: 20개
---------
퍼즐: 11개
캐주얼: 4개
교육: 3개
액션: 1개
슈팅: 1개

퍼즐과 캐주얼 장르가 압도적입니다.

개발기간이랑 플랫폼 특성을 고려해보면 당연한 것일까요?

참고: http://idogame.hangame.com/betatester.nhn?m=bug
신고

'GameBusiness' 카테고리의 다른 글

닌텐도 2DS 의 시장공략  (0) 2013.09.09
아이폰과 안드로이드  (0) 2009.11.07
아이두게임 게임 오픈 일정 변경  (0) 2009.11.03
아이두게임의 개발자 지원  (0) 2009.10.23
아이두게임 클로즈 베타 시작  (0) 2009.10.19

NHN의 DevView 2009 에서 게임오븐 제작 사례로 강의했었습니다.

주요 내용은 다음과 같습니다.

게임오븐으로 만들 수 있는 게임에 대해서 고민해보고,
게임오븐으로 온라인 게임을 개발할 때 성공적인 게임을 개발하기 위해 고려해야할 점을
적어보았습니다.

그리고 마지막으로, 보다 규모있는 게임을 만들기 위한 노력에 대해서 데모 시연을 했습니다.

참고: http://deview.naver.com/

신고

티스토리 툴바