Elegant Universe



category       : 음악 (music)

price       : 무료(Free)

language       : English/한국어

creator    : Elegant Universe 

version : 2.1 >=

6) 나만의 앨범 공유 가능(향후, 추가 요소)

---

앨범 뷰
Album View

만든 곡 리스트. 

+곡 만들기를 통해, 새로운 루프 뷰로 이동할 수 있음.

Created a list of songs.
'+ New Song' can be moved into a new loop view.

앨범 뷰(해당 곡 클릭 시) 
Album View(When clicked each song) 

만든 곡을 재생할 수 있음. 

편집 클릭 시 해당 곡의 루프 뷰로 이동, 삭제도 물론 가능.

 

Can play the song you made.
Clicking the 'Edit' button, move into the loop view of the song, of course, you can delete.

[클릭 시 액션]

왼쪽)

빨간 버튼 ㅡ 해당 트랙 뮤트(mute)가능.

녹색 타이틀 ㅡ 해당 트랙 에디트 다이얼로그 표시

+추가 버튼 ㅡ 저장된 비트 추가 가능

재생 버튼 ㅡ 배열된 음악 재생

저장 버튼 ㅡ 해당 음악 저장

오른쪽)

매트릭스를 쉽게 터치해서 리듬을 배열.

+비트 만들기 버튼 ㅡ 새로운 비트 뷰로 이동.

[Actions to clicked] 

해당 타이틀 클릭 시, 트랙 추가 됨.

파란 재생 버튼 클릭 시, 해당 비트 재생.

When clicked the title, added track.
When clicked the blue play button, played the beat.

해당 트랙 에디트 가능한 다이얼로그.

음량 조절 및 팬 조정 가능,

편집 버튼 ㅡ 해당 비트 뷰로 이동. 비트 뷰에서 저장 시 바로 편집된 비트 적용됨.

트랙 삭제 버튼 ㅡ 해당 트랙 삭제 됨.

확인/취소 버튼 ㅡ 에디트 된 트랙 적용/취소

In dialog, you can edit to the track.
Adjust volume or pan.
Edit button - moved into the beat view.  It applies when you save the edited beat in beat view.

자유롭게 터치를 통해 비트 생성

옵션) 초기화: 비트 뷰 초기화

저장: 해당 비트 저장

비트 편집: 해당 비트 편집 다이얼로그 표시

To Freely touch, make beat.
option) Clear: initialize the beat

Store: store the beat

Edit Beat: show the dialog edit to the beat.

비트 뷰 (옵션 > 비트 편집 클릭 시)
Beat View ( option > when clicked 'edit beat' )

 

악기(음색)과 음정을 변경할 수 있는 다이얼로그

In dialog, you can modify instruments or music pitch.


비트 뷰 ( 편집 다이얼로그 > 악기 선택 클릭 시)
Beat View ( Edit Beat Dialog > when clicked prompt to select instruments.

 주요특징:

1. 소리 리듬 생성
2. 색깔 변경에 따른 음색 변화
3. 리듬 비트 패턴 저장

android market:

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에만 의존하여 진행하다 보니, 코드의 복잡도가 점차 증가하면서, 상호 간의 수정 코드가 뒤얽히게 되었고, 이는 출시 후 유지보수 단계에서 절정을 이루었다. 변수 명, 코딩 규칙, 문서화 등이 분명히 확립되지 않은 상태에서 뒤늦게 상대방의 코드를 분석하려고 하니 쉽지 않았고, 향후 업데이트 및 유지 보수에 있어 어려움이 예상되었다. 그래서, 뒤늦게 서로의 코드를 분석하는 시간을 가지려고 노력해보았지만, 결국, 이 문제는 해결하기가 어려웠고, 사전에 정의 내려야 하는 규칙에 대한 협업 프로세스의 교훈을 새롭게 얻을 수 있었다.

-개발 프로세스의 문제

http://mashupkorea.com/2009/vote_detail?id=665

[참여기간]

2008년 12월 1일 ~ 2009년 2월 28일

[개요]

각자의 관심지역에 해당되는 이슈를 손쉽고 재밌게 알 수 있는 매쉬업 어플리케이션

[상세설명]

¢  어떻게 ? 사람들의 관심도가 적고 많음에 따라 다양한 음악으로 표현되고 그 지역의 실시간 핫 이슈를 볼 수 있다.

¢  지도 + 음악 + 뉴스

¢  두 RIA의 조우 : FLEX + Silverlight

¢  FLEX를 통한 Sound Modulation의 적용

¢  소리로 사용자의 관심 같은 무언가를 표현할 수 있을까?

[시스템 구조]

(1)   뉴스 API를 통해 정보를 취합하고, 태그 추출

(2)   이를 실버라이트의 지도 API와 연동하여, 정보 출력

(3)   해당 정보의 크기에 따라, 조작된 음악 재생

[Hot News 추출 방식]

(1)   지도 단에서 전송되는 위치 정보를 뉴스 API와 연계

(2)   뉴스의 제목 리스트를 태그 추출 시스템으로 전송

(3)   추출된 태그를 다시 API로 전송

(4)   지역에 맞는 Hot News 정보 추출

[Sound Control 방식]

뉴스 Point의 크기에 따라 변조가 일어나고, 시끄러운 음악 재생.
  

[발생문제/해결방법]

-플래시-실버라이트 연동 문제

플래시와 실버라이트를 직접 연동하기가 어려운 문제가 있었다. 플래시와 실버라이트를 연동하는 것은 아직 생소한 작업이라 해결책을 강구해보았다. 결정적으로, 자바스크립트를 활용하는 것으로 돌파구를 해결하였는데, 플래시와 실버라이트 모두 자바스크립트로 외부와 연동하게끔 구성되어 있으므로, 웹 페이지 내에 조그마한 버튼을 숨겨놓고, 실버라이트에서 버튼을 클릭하는 액션을 통해 플래시에게 정보를 전달하는 방식으로 문제를 해결하였다.

-음원 로드 속도 문제

음원 자체가 큰 파일이고 이를 API를 통해 로드하여 재생하는 속도가 많이 느린 문제가 있었다. 이를 해결하기 위해, 처음부터 기본적인 음원을 로드하고, 해당 지역에 맞는 음원을 재생할 때, 변조할 수 있도록 바꾸어서 해결하게 되었다.

-API 의존성 및 저작권 문제

이 서비스의 지도는 야후 맵의 Tile 이미지를 패킷 분석을 통해 빼내어 실버라이트로 포팅 시킨 것으로 저작권 관련 문제가 있었다. 차선책으로 MS의 버추얼 어스, 구글 맵 등을 고려해보았지만, 이처럼 이 서비스의 분위기를 자아내기가 어려워서 그대로 사용을 하게 되었는데, 며칠 후에 경로가 막히는 바람에 사용할 수가 없게 되었다. 이를 통해 API 에 따른 의존성 문제를 알 수 있었는데, 문맥 추출 API인 trynt API 또한, 서비스가 중단되는 바람에, 이를 직접 태그를 추출하는 알고리즘으로 대체해야만 했다.