StarCity

2010.12.17 02:53





친구들과 게임하러 가기~
http://appstore.nate.com/Main/View?apps_no=1315   

[참여기간]

2010 7 1 ~ 2011 3 30

 
 
[개요]

우주 도시를 컨셉으로한 소셜 시뮬레이션 게임

 

[상세설명] 

팀 리드 개발자로서, 클래스 설계, 클라이언트 단의 중심 시스템 개발, 서버와의 연동, 소셜 컨테이너 연동, 서버 세팅과 운영 등의 작업을 맡았다.

1.     클래스 설계: 건물, NPC, 지형과 같은 객체들을 분류하고 클래스를 생성했고, 공통되는 성질에 따라 상위 클래스로 묶어서, 하위 클래스가 상속받을 수 있도록 하였다. Data 정보들을 서버와 연동하고 Single-tone Pattern으로 쉽게 가지고 쓸 수 있도록 하였고, 서버와 연동하는 Model 부분과 UI 부분을 분리하고 Model 에서 서버와의 통신을 마친 후, Observer Pattern 형태로 UI단에 이벤트를 알려주는 방식으로 구성하였다. 마찬가지로, sound, event, popup 등의 manager를 두어서 독립적으로 호출하여 사용할 수 있도록 하였다.

2.     중심 시스템 개발: 게임 시스템으로서, isometric한 타일과 우주 배경을 배치하고, 그 위에 건물들을 서버의 연동된 정보대로 배치시키는 알고리즘으로 개발하였고, 건물을 설치, 이동, 회전, 제거하는 액션, NPC의 배치, 이동 시스템 등의 주요 시스템을 개발하였다.

3.     서버와의 연동: 클라이언트의 정보 값을 저장하고, 이 값을 서버로 보내고 반환 받는 연동 방식을 개발하였고, 클라이언트 메모리 상에 값이 저장되거나, 서버로 값을 전송할 경우, MD5 형태로 암호화를 적용하였다. 서버와의 전송 포맷은 XML로서, XML을 파싱 하고, 각 클래스에 값을 저장하는 방식으로 개발하였다.

4.     소셜 컨테이너 연동: 앱스토어에서 실행하게 될, 구글 오픈소셜 형태의 컨테이너를 구성하였는데, 친구 프로필, 정보, 초대, 쪽지 등의 액션을 자바스크립트로 구성하였고, 이를 플래시 단과 연동하는 부분을 개발하였다.

5.     서버 세팅과 운영: 웹 서버, DB 서버, load balancer 서버, memcached 서버, File 서버 등을 세팅하고 연동하였으며, 주기적으로 로그와 트래픽을 확인하고 문제를 해결하는 운영을 했다.

  

[발생문제/해결방법] 

-객체 우선순위 알고리즘 문제

이 게임을 개발하면서, 초기에 까다로웠던 부분이 건물과 NPC 같은 객체의 앞, 뒤를 결정하는 우선순위 알고리즘 문제였다. 도시 지형 자체가 isometric 형태이고, 건물의 크기가 다르고, NPC가 움직이다 보니, 실시간으로 서로의 앞뒤 인덱스를 계산하여 바꿔줄 필요가 있었다. 단순한 Bubble Sorting으로는 해결이 쉽지 않았고, 이는 건물의 가로 폭과 세로 폭의 끝 점의 x, y 값을 배열에 저장하고, 이를 근접한 객체와 비교하여 우선순위를 결정함으로써, 전체적인 객체의 우선순위를 최종적으로 결정할 수 있었다.

 

-Client Performance 문제

이 게임에 등장하는 NPC 객체는 각 프레임마다 움직이는데, 이에 따른 퍼포먼스 문제가 일어났다. NPC 객체 및 다른 애니메이션이 포함된 무비클립 객체가 많이 생성 될수록 프레임 속도가 느려지고, 퍼포먼스가 저하되는 문제가 있었다. 또한, CPU와 메모리 점유율에도 영향을 미쳐 저사양의 컴퓨터에는 어플리케이션이 작동 중지될 만큼의 큰 점유율이 문제가 되었다.

이를 해결하기 위해, 여러 테스트를 거쳐, 무비클립의 애니메이션을 최대한 줄이고, 무비클립이 아닌 Image 형태의 포맷으로 변환하여 플래시의 내장된 그래픽 클래스를 이용하는 방식으로 리소스를 크게 줄일 수 있었다. 이는 하나의 객체를 기존의 생성하는 방식을 재사용하는 방식으로 바꾼 것이다. 또한, 메모리의 점유율의 큰 부분을 차지하는 부분이 Object를 기본 Array에 저장할 경우라는 사실을 알게 되어, 이를 Vector 형태로 수정함으로써, 점유율을 낮출 수 있었다.

 

-Server Performance 문제

게임을 출시한 후, 사용자가 많이 유입하면서 큰 부하와 로딩 속도가 큰 문제점으로 대두되었다. 시뮬레이션 게임의 특성상, 일반 웹서비스와 달리 DB와 데이터를 동기화하는 작업이 많다보니, 수많은 DB Call이 일어나고 있었고 그에 따른 IO 병목과 쿼리 검색 속도가 비효율적으로 늘어나서 피크 시간대에는 게임을 거의 실행하기 어려운 상황까지 이르렀다.

이를 해결하기 위해, 불필요한 DB Call을 줄여나가면서, 되도록이면 웹서버나 클라이언트에서 처리할 수 있도록 변경하였다. 또한, memcached 서버를 기존 보다 전방위적으로 활용하여 자주 변하지 않는 데이터들은 캐쉬 서버로 Call할 수 있게끔 수정하였다. 이렇게 테스트를 점차 해나가면서 퍼포먼스가 정상 궤도로 돌아올 수 있었다.

 

-Server Hosting 문제

호스팅 서버 문제 또한 운영에 발목을 잡았다. 이 게임을 운영하기 위한 호스팅 서버는 처음에는 일반 서버 호스팅 이었지만, 국내의 클라우드 호스팅 사에서 제공하는 IaaS(Infrastructure as a Service) 형태의 서버로 바꾸게 되었다. 아직 문서화가 제대로 정립되지 않은 신규 서비스이다 보니, 서버 설정에 어려움을 느꼈고, 기본적인 플랫폼부터 모니터링 툴까지 모두 설치를 해나가야 했다.

하지만, 하나의 서버 인스턴스를 손쉽게 복사할 수 있고, 서버 활용률에 따라 코어를 Scaling 할 수 있는 장점 덕분에 같은 작업을 반복할 필요가 없었고, 이에 따른 클라우드 호스팅의 장점을 이해할 수 있었다.

 

-개발 협업의 문제

클라이언트 개발자들이 개발 협업과 관련한 경험이 부족한 상태이다 보니, 초기 개발을 같이 진행 하는데 있어서 어려운 점이 있었다. 이를 보완하기 위해 SVN을 도입하여, 한 개발자가 source commit하면, 그 파일을 update하고 동기화시키는 방식으로 협업을 진행하였다.

또한, 역할 분담을 위해 클래스를 설계하고, 시스템, UI, 서버와의 통신 부분으로 나누어 진행하였지만, 각 파트 간의 중첩되는 부분이 필연적으로 생겼다. SVN에만 의존하여 진행하다 보니, 코드의 복잡도가 점차 증가하면서, 상호 간의 수정 코드가 뒤얽히게 되었고, 이는 출시 후 유지보수 단계에서 절정을 이루었다. 변수 명, 코딩 규칙, 문서화 등이 분명히 확립되지 않은 상태에서 뒤늦게 상대방의 코드를 분석하려고 하니 쉽지 않았고, 향후 업데이트 및 유지 보수에 있어 어려움이 예상되었다. 그래서, 뒤늦게 서로의 코드를 분석하는 시간을 가지려고 노력해보았지만, 결국, 이 문제는 해결하기가 어려웠고, 사전에 정의 내려야 하는 규칙에 대한 협업 프로세스의 교훈을 새롭게 얻을 수 있었다.

 

-개발 프로세스의 문제

기획과 디자인, 개발의 삼박자를 맞추기 위하여, 여러 프로세스를 도입하여 진행했지만, 여러 난항이 많았다. 특히, 일정 산정에 대한 문제가 컸다. 개별 파트 별로 정해진 계획을 수립하는 것으로 맞춰진 프로세스에서 구체적으로 다른 파트가 무슨 작업을 하는지 알기가 어려웠고, 이를 해결하기 위해, Scrum 이라는 프로세스를 도입하여, 자신의 세부 작업을 나열하고 일정을 산정한 후, 하루마다 자신의 작업한 부분을 공유함으로써, 작업의 진전 속도를 알 수 있도록 하였다. 또한, 출시 후의 버그 관련 리포트를 받기 위해, BugZilla 라는 툴을 이용하여 공유하였고, 이를 종합적으로 기록하고 일정을 산정하기 위해 Redmine 이라는 오픈소스 툴을 이용하였다. 하지만, 이런 툴에 무작정 의존하는 것보다 필요에 따라 참고하고 유동성 있게 계획을 수립하는 것이 더 좋은 방법이라고 느꼈다. 
저작자 표시
신고
Posted by Ssirius

카테고리

전체 (92)
Programming (13)
Digital Nomad (2)
Projects (7)
Sound (14)
Travel (45)
Think (9)

달력

«   2017/12   »
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31            

티스토리 툴바