Making M & F

이제 Mobile을 개발할때는 , Multi-platform에 대한 고려는 매우 중요한 사항으로 인식이 되고 있는 것 같다.

http://programmers.stackexchange.com/questions/121529/what-language-should-i-use-for-making-a-cross-platform-library

http://www.sersc.org/journals/IJSEIA/vol4_no3_2010/5.pdf

http://readme.skplanet.com/?p=9699

http://www.juce.com/

Mobile 을 개발하다보면, 공통적인 기능에 대한 Module or Library를 개발해야 될 필요성을 느끼게 된다. 하지만, Mobile Platform(Android/iOS/Win Phone/etc)을 고려하면, 어떤 언어로 개발하는게 좋을까? 그리고 추후 소스 관리를 어떻게 하는게 효과적일까? 등을 고민하게 된다.

그래서, 몇몇 Mobile open source를 조사하여 보았다.

대부분 C/C++로 개발을 하고, 해당 platform으로 코드를 옮겨서 target building을 한다.

예; http://pocoproject.org/

하지만, Visual studio 2015에서는 코드를 옮기는 과정 자체도 줄여서, 라이브러리를 빌드하게 하였다. it's very awesome!!!

https://www.visualstudio.com/en-us/features/cplusplus-mdd-vs.aspx

MS의 노력에 감사 ^^

Microsoft 2015 conference를 보면서, MS의 mobile 시장에 대한 노력을 다시 한번 느껴 볼수 있다. 특히, Visual studio 2015에서는 Object-C를 컴파일 가능하게 하고, 거기에 iOS의 기본 Framework(Foundation/UIKit)을 어느정도(?) 지원한다는 것은 놀랍다.

이 부분에 대한 장점을 조금 자세히 설명하면, 아래와 같다.

만약, Unreal Engine을 가지고 게임을 개발하고 있다면, 대부분 Window 환경의 PC에서 개발을 하고, Unreal engine Build tool을 통해, iOS 실행파일을 자동으로 deploy하게 될것이다. 그런데, 만약 사용하고자 하는 업체의 라이브러리가 iOS뿐이 지원하지 않는다면(즉, xxxx.a or xxx.framework 형태), 윈도우 개발 환경에서는 사용을 할수가 없게 되어, iOS를 빌드하기 위해서는 XCode상에 다시 한번 개발 작업후, 빌드를 해서, deploy를 하게 된다. 그런데, 이번 VC 2015에서는 이러한 번거로운 작업을 하지 않게 되어, 개발과정에서의 효율성이 좋아 졌다. (하지만, 언제나 그렇치만, 반드시 테스트는 충분히 더 해보아야 한다.)

https://channel9.msdn.com/Events/Build/2015/3-610

http://egloos.zum.com/fericia/v/3028857

[Tech] AlaaS(Artificial Intelligence as a Service)

몇 년전 MSN을 통해, chatbot을 경험 했을때의 느낌은 "So what"이 었다. 하지만 이번 Amaznoe 이 chat bot을 적용하여서, 매출을 엄청나게 늘었다는 기사를 보았을때, 기술적인 발전도 중요하지만, 서비스 타이밍도 중요함을 다시 한번 느끼게 된다.

IT 신조어(?)의 정리 링크

(1) full stack developer

http://www.hanbit.co.kr/network/view.html?bi_id=1997

http://rapapa.net/?p=2514

(2) glowth hacker

http://alleciel.com/2015/04/29/dentsu-growth-hacking-1/

개발 언어에서 format string 처리는 익숙(?)해지는데 시간이 걸리는데, 아래의 사이트를 보면, 그 시간을 줄일수 있을 것으로 생각되어 공유 함.

http://pyformat.info

사업적인 비교

http://www.ciokorea.com/news/24649?page=0,0

메신저를 연결하면 어떨까? 하는 생각을 한적이 있었는데, 이미 미국의 스타트업에서 시작을 한곳이 있군요.ㅠㅠㅠ

http://www.bloter.net/archives/221546

https://layer.com/about

페이스북과 비교해서 생각해여 보면, 무서운 생각이 드네요.

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

파일 크기가 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