Making M & F

앱 크기는 게임의 성공에 큰 영향을 줍니다.

파일 크기가 25M를 넘어서면 다운로드가 급감한다는 보고서도 있습니다. 이미 히트친 게임이 아닌 이상 앱 크기를 줄이는 것은 성공에 필수입니다. 어떻게 용량을 줄여야 할까요?

——————————————————————————-

앱 크기에 가장 큰 용량을 주는 것은 텍스처 이미지들입니다. 먼저 게임 엔진들이 어떻게 텍스처 이미지를 처리하는지 기술적인 측면을 살펴 보겠습니다.

텍스쳐는 패키지 빌드시 비디오램에 올릴 수 있는 형식으로 변환됩니다. 이 텍스쳐는 압축을 할 수도 있고 하지 않을 수도 있습니다. (패키지 빌드시 비디오램에 올리는 형식으로 변환되는 이유는 비디오램에 올리는 속도때문입니다. 원본 이미지를 올리며 GPU가 변환하면 비디오 램에 올라가는 속도가 느립니다.)

텍스쳐를 압축하는 경우 S3사가 개발하고 기본 특허를 가지고 있는 GPU를 통한 여러가지 손실 압축 알고리즘으로 압축합니다. (GPU에 의해 압축된 텍스쳐는 빈도수에 따라 압축한 알고리즘이 아니므로 빈도수에 따르는 알고리즘으로 다시 한번 압축하여도 용량이 감소합니다.)

(S3사는 여러차례 인수되어 지금 어느 회사가 소유하고 있습니다. 어느 회사인지… 검색해 봐야 겠군요.)

게임 엔진들은 이 리소스들을 다시 한번 무손실 알고리즘(빈도수에 따라 압축하는 알고리즘)을 통해 압축하여 패키지파일을 만들어 냅니다. (대부분 zip 라이브러리를 사용하여 압축합니다. 유니티가 사용하는 패키징시 사용하는 알고리즘의 정체는 모릅니다만 압축은 한번 더 해야하는게 옳습니다. iOS 앱용 빌드시는 압축 하지 않을 수도 있습니다. 왜냐하면 아래…)

iOS앱의 경우 xcode가 다시 한번 더 압축합니다. (터미널에서 a.app을 a.app.zip으로 바꾸면 zip 유틸리티를 통해 압축을 풀 수 있습니다.)

*** 패키징시 파일 형식이 변환되므로 png, jpg, psd등의 원본 파일 형식은 최종 패키지 파일 크기에 영향을 주지 않습니다 ***

——————————————————————————-

텍스처 기술적인 면을 보면 앱의 용량을 줄이는 방법은 크게 세가지가 있습니다.

1. 텍스쳐를 압축하는 방법.
2. 이미지 색상 깊이를 줄이는 방법.
3. 이미지 크기를 줄이는 방법.
* 1 번과 2번은 알고리즘에 따라 서로 배타적일 수도 있습니다.

——————————————————————————-

텍스처 압축시 각 디바이스 지원의 문제도 있습니다.

4년이내에 출시한 모든 iOS 디바이스들의 GPU는 택스쳐 압축을 지원합니다. 모두 텍스처 압축을 지원하므로 고민이 적습니다. (이전 모델들은 개발해보지 않아서 모릅니다. 스펙 문서를 보면 되겠지만 중요하지 않고 귀찮아서 패스 합니다.)

문제는 안드로이드입니다. 텍스쳐 압축을 지원하는 다비이스도 있고 지원하지 않은 디바이스도 있습니다. 모든 안드로이드 디바이스를 지원하려면 텍스쳐 압축을 하지 말아야 합니다.

다른 선택지로 텍스처 압축을 지원하지 않는 디바이스를 제외할 수도 있습니다. 대부분의 하이엔드는 텍스쳐 압축을 지원하고, 저가형 모델들은 지원하지 않는다고 볼 수 있습니다. 각 디바이스를 테스트 하여 압축을 지원하는지 확인하고 압축을 하지 않으면 지원 단말기에서 제외할 수도 있습니다. 테스트 후 스펙 문서에서 GPU 모델을 확인해 보면 알 수도 있습니다.

저가형 안디로이드 디바이스는 다른 스펙상으로 하이엔드 게임을 구동하기에도 좋지 않습니다.

늑대: “저 포도는 분명히 시어서 못먹을꺼야.”

——————————————————————————

다음은 사람의 인지적 특성을 살펴 보겠습니다.

게임을 플레이하는 사람은 눈에 들어오는 시각 정보를 중요도에 따라 압축한다고 합니다. 사람의 시각은 가장 중요한 지점을 보며 중요하지 않은 부분은 보지 않는다고 합니다. 어느 정도 게임에 숙달된 사용자는 이미지를 보지 않고 기호처럼 인식한다고 합니다.

사람의 시야는 60도라고 합니다. 이중 사람이 자세히 볼수 있는 망막은 5(2도였던가?)도 정도 밖에 되지 않는다고 합니다. 나머지 영역은 흐리게 보입니다. 눈의 근육을 사용하여 시점을 빠르게 바꾸니 전체 시야가 자세히 보이는 것처럼 보인다고 합니다.

앱의 용량을 줄이기 위해 사람의 시각이 처리하는 특성을 활용할 수 있습니다.

——————————————————————————-

추가적으로 고려해야 할 점은 압축 알고리즘의 특성과 이미지들의 특성입니다.

텍스처 압축시 주의할 점은 S3가 특허를 가진 텍스처 압축 알고리즘들은 손실 압축이라는 점입니다. 알파 채널을 무시하는 셰이더 사용시에 눈에 크게 띄지 않으나 알파 채널을 Blend하는 셰이더에서는 눈에 띌 수 있습니다. (나무잎이나 스프라이트 처럼 투명값이 사용되면 눈에 띕니다.)

색상의 특성도 있는데 단색의 텍스쳐는 저해상도에서도 나빠 보이지 않습니다.

——————————————————————————-

*** 유니티에서 텍스처를 선택하면 인스펙터에서 타겟 디바이스(플랫폼)에 따라 해상도와 압축을 지정할 수 있습니다 ***

——————————————————————————-

앞에서 언급된 특성들을 사용하여 대상에 따라 다음과 같이 적용해 볼 수 있습니다.

1. 알파값이 적용되지 않으면 텍스처를 압축합니다. 알파값이 사용되면 중요도를 고려합니다.
2. 주인공이나 적 보스는 품질을 중시하고, 중요도가 낮은 적은 낮은 해상도를 적용합니다.
3. 타이틀의 캐릭터나 로고는 품질을 중시합니다.
4. 로고의 배경과 로고를 분리하여 로고 배경을 늘리거나 반복하여 렌더링하면 용량을 줄일 수 있습니다.
5. 스카이박스는 캐릭터등에 비해 단조로운 변화를 가집니다. 플레이어가 자세히 살피지도 않습니다. 해상도를 낮추고 압축을 하여도 눈에 잘 띄지 않습니다.
6. 모바일에서 밉맵을 끕니다.
7. 내용을 고려하여 노말맵(범프맵), 반사맵(환경맵) 해상도를 낮춥니다.
8. 단조로운 거리가 먼 배경은 유저가 자세히 살피지 않습니다. 해상도를 낮추고 압축을 하여도 좋습니다.
9. 일반 흔하게 반복적으로 배경도 사용자가 보지 않습니다. 텍스처도 압축을 하고 해상도를 낮춰도 괜찮습니다.
10. 배경의 랜드마크는 품질을 살려 줄 수도 있습니다.
11. 파티클에 사용되는 단색 텍스쳐는 해상도를 낮추고 압축을 하여도 크게 눈에 띄지 않습니다.
12. 터레인 텍스처는 터레인에 적용되는 실제 크기를 고려하여 해상도를 낮춥니다.
13. 2D의 경우에도 관절을 사용한 애니메이션을 고려해보는 것도 좋습니다.
14. 레벨 디자인시 모듈들을 조립하여 사용합니다. 다만, 증가한 정점으로 렌더링 성능에 영향이 있을 수 있습니다.

출처: http://booiljoung.tumblr.com/post/116430900313

최근 Facebook이 messanger platform을 개발자에게 오픈하여, 그 기능을 자세하게(?) 살펴보고 있다. 그러던 중, MQTT와 XMPP에 대한 궁금증이 생겨 살펴보다, 조금이나마 도움이 될것으로 생각되어 링크를 공유 합니다.

http://www.quora.com/Why-didnt-Facebook-Chat-Message-use-XMPP-Jabber-like-other-IMs

http://www.quora.com/What-protocols-are-used-in-implementation-of-messengers-like-Google-Talk-and-Facebook-Messenger-Are-they-built-on-top-of-HTTP

Google도 새로운 메신저인 hangout 부터는 XMPP에 대한 지원을 않하는 방향으로 가는군요.

https://www.eff.org/deeplinks/2013/05/google-abandons-open-standards-instant-messaging

스팀의 Greenlight은 개발 초기부터 사용할수 있는 효과적인 마케팅 방법이자, 적극적으로 유저들의 피드백을 받아 들일수 있는 방법

게임 초기 디자인 부터, 사용자 커뮤니티를 통해 적극적인 홍보 및 needs를 받아 들여, 성공의 가능성이 높게 접근 할수 있을 것으로 보임

https://steamcommunity.com/workshop/browse/?appid=765&browsesort=pending&browsefilter=pending&p=1

2015년 3월 25일 Facebook이 매달 약 600 million(약 6억명)이 사용하는 Messanger platform 을 개발자에게 개방 했다. 아울러 연동을 위한 SDK도 함께 개발을 하였다. 

참조: 

https://developers.facebook.com/blog/post/2015/03/25/introducing-messenger-platform-and-businesses-on-messenger/

https://developers.facebook.com/docs/chat#!/docs/messenger

생각 해보자, 매달 6억명이 사용하는 Platform이라? 재미난(?) 생각이 스물 스물 올라온다...ㅋㅋㅋ

Facebook이 messanger platform을 개방하면서, 선보인 약 40여개의 Apps을 살펴 보면, 근래에 이슈가 된 Vine, Periscope, Meerkat 등과 유사한 대한 app을 볼수 있다. 

참조: https://developers.facebook.com/docs/messenger/showcase

그리고, 발표한 자료에서 개인적으로 감동(?) 받은 부분은 아래의 기능이다.

https://messenger.com/business

물론 현재 많이 사용되고 있는 SMS의 기능과 유사하다고 할수 있겠지만, 사용자 에게는 다른 경험을 제공한다고 느껴진다.

개인적으로 페이스북 메신저 내용을 보면서, 무섭다는 느낌이 들었다.

매달 6억 명의 사용자를 가지고 있으면서, 이를 통해 쌓이는 big data 분석은 "I don't know who I am, but Facebook must to be understood who I am" 문구와 같은 현실을 만들어 나가고 있다고 생각한다. 

이를 바탕으로 business 영역으로 넓혀 가고 있는 Facebook이 만들어 가는 생태계가 기회?인지, 아니면, 또다른 절망?을 줄지 앞으로의 행보가 궁금해진다.

개인 방송국 시대가 열렸다. 난 무엇을 방송할까?

http://www.theguardian.com/technology/2015/mar/26/twitter-periscope-live-video-app-meerkat

http://theconversation.com/the-good-and-bad-of-social-video-broadcasting-social-media-enters-a-new-phase-39478

여러 종류의 DB를 사용하며 SQL 쿼리를 작성시, 조금씩 쿼리가 다른점이 있어 헷갈릴 때까 있다. 그리고, 때때로 쿼리 syntax가 기억이 가물가물해서 웹서핑을 하는 경우가 있는데, 아래의 사이트는 이런 고민을 한번에 해결해 주는 것 같아 공유 합니다.

http://sqlzoo.net/wiki/SQL_Tutorial

Working set을 살펴 보기 전에 작업 관리자(Task Manager)를 살펴보자.

위를 보면, Working Set(작업 집합), Page fault(페이지 펄트)를 확인 할수 있다.

쉬운 이해를 위해 Questions 을 가지고 시작해보자.

1) Working Set 값이 높으면 좋은 것인가? 나쁜 것인가?

2) Page fault 값이 높으면 좋은 것인가? 나쁜 것인가?

(답변)

1) 좋다? 나쁘다?를 말할 수 없다. 왜냐면 Working set 값이 높다는 것은 해당 Process가 addressing하는 physical memory가 많다는 것이다. 그러나, 만약에 Working set이 계속 증가한다면 프로그램의 문제를 의심해야 함(예: 메모리 릭)

2) 나쁘다. 왜냐면, memory와 hard간에 swap이 빈번하게 발생한다는 것은 프로그램의 성능 및 프로그램 구현상에서 메모리 관리를 잘 못하고 있다는 의미로 해석해도 틀리지 않음.

언제나 그렇지만, MSDN을 찾아 보면 명쾌한 답변이 있음을 확인 할수 있다.

위의 글을 보면, 언제? 왜? Page fault가 발생하고, 이현상에 따라 Working Set이 어떻게 동작하는지 이해 할수 있다.

간단하게 정리하면, Swap에 의해, Page fault가 발생하게 되고, OS는 해당 프로세스의 Virtual address를 관리하는 MMU에 의해 Working set이 증가하게 됨

감사합니다.

CR(0x0D,13), LF(0x0A,10)에 대한 이해

1. 단어 정리

1) Carriage Return: 현재 줄에서 맨처음으로 간다.

2) Line Feed: 현재 위치에서 줄(Line)만 하나 내린다.

* 타자기에서 위의 의미라 유래 되었음.

2. "New  line := '\n' := enter" 에 대한 시스템적 해석 차이

1) Unix/Linux 계열: LF

2) Windows: CR + LF

3) MAC: CR

4) 정규식에서는 CR 또는 LF 중 하나만 있어서 New line으로 인식함

영어 스터디 또는 미드를 보기 위해서 위해, 미국에 있을때는 hulu를 통해서 쉽게 접근 할수 있었으나, 한국에서는 국가 제한에 걸려 불편함(?)이 있다.

이런 저런 방법이 있지만,

http://hola.org 를 설치하고 접근하는게 최선이라고 생각된다.

What's The Developer or Programmer?

- Not coder.

- Not finding problem, but also developing solution about it through Research & Development.