69. Unity 팁 1

 - 게임을 각 챕터마다 다운받게 하는 것

장점 : 끝까지 하는 사람이 아니면 다 받아가지 않기 때문에 서버비 절감

단점 : 개발도상국의 경우 인터넷 연결될 때 쫙 받기 때문에 플레이가 막히는 문제

 - NGUI, UGUI 차이점

환생킹은 NGUI. 차기작은 UGUI.

과거엔 NGUI가 좋았고 업뎃은 계속 되고있지만 이제 UGUI가 더 좋아져버림.

NGUI는 퍼포먼스가 딸린다고 함. 만들기는 쉬운데 최적화가 매우 어려움.

이제는 UGUI.

UGUI를 공부하는 방법 : 에셋 스토어에서 유니티 테크놀로지라고 검색. 그 다음 유니티가 만들어 올린 게임 데모 프로젝트 패키지를 보고 거기 있는 UI를 보고 공부해서 따라하라. 그게 가장 훌륭한 공부 방법. 직접 만든 사람이 그렇게 샘플을 만들었기 때문. 그걸 보고 따라 만들어보고 공부해보면 된다. 하이에라키 구조는 이렇게 했구나. 이걸 이렇게 하는구나. 하는 식으로. 

캔버스를 하나만 두고 다 합치는 사람이 있는데, 캔버스 분리는 몹시 중요. 한 캔버스에 있는 걸 하나만 바꿔서 그려도 그 캔버스는 통째로 다시 렌더링. 게임에 사용하지 않는 캔버스는 당장은 꺼야함. 몹시 중요.

캔버스를 상점처럼 그렇게 하나로 묶는게 있다면 그걸 분리하는 게 좋을까, 아니면 하나로 하는 게 좋을까. = 프로파일러로 돌려보면서 그때그때 판단해 쪼개거나 말거나 하는 게 좋음. 캔버스를 추가하면 발생하는 비용이 있기 때문에 정말 그때그때 달라서 어느 정도만 담되 보여줄 게 정말 많으면 느려짐. 느려지면 쪼개고, 느려지는 게 발견되지 않으면 그냥 하나로 묶어도 됨.

 - 해킹 차단 방법

모바일 게임 기준 3가지 부류로 나뉨.

1. 돈을 버는 방식

 - 유료 게임. => 막아야 함. 게임을 사는 사람이 없어지기 때문.

 - 무료 게임인데 게임 안 과금 요소가 별로 없고 광고로 수익. => 문제가 생겨도 인앱 결제가 크지 않으니 환불이 가능함.

 - 무료 게임인데 인앱 결제를 유도. => 문제가 생기면 어마어마한 인앱 결제비를 환불해야 할 것.

메모리 해킹을 막기 위해서는 변수를 암호화. 강사님은 int를 암호화한 sInt라는 애를 사용(직접 만든 secure int) => 이건 인터넷 치면 나옴. 암호화 강도가 나뉨. 강도가 세면 느리므로 적당히 암호화 방법을 골라서 하면 됨.

https://www.appsealing.com/kr/ => apk를 뜯을 수 없게 암호화해주는 사이트. 다만, 일정 유저 수 미만은 무료고 유저가 많아지면 유료가 됨. 여기 외에도 이런 서비스가 여러 곳 있음. 참고로 sealing은 되게 유료화되어도 저렴하고 게임 유저가 많은데 이거 낼 돈 없으면 그 게임은 접어야 됨. 대신 완전 대박나는 게임이라면 처음부터 일정 가격을 내는 nprotect 등을 알아보는 게 좋음.

게임에서 로컬로 클라이언트에 데이터를 저장을 할 때에는 키와 값을 둘 다 암호화하고 저장. 복호화할 때 변조가 된다면 데이터를 싹 날리면 됨. 데이터는 원래 클라이언트에 저장하면 안 됨. 그럼 해킹을 당하기 쉬우니 위험.

서버 파트가 해킹되는 건 데이터가 주고받는 부분에서 패킷을 뜯어 고쳐 보내거나, 허위 패킷을 보내는 방식. 이걸 막으려면 패킷에 위변조 체크할 로직을 넣어야 함.

하드웨어적인 해킹(디도스 등)은 분야가 아니라 잘 모르신다고 함.

그래도 뚫는 사람은 수동으로 다시는 게임 못하게 차단을 함.

 - 다중 모바일 디바이스 대응. (NScreen 대응법)

테스트 외에는 방법이 없다. 기기를 확보해서 테스트하고 안드로이드면 디벨롭먼트 빌드를 체크하고 오토뭐시기 프로파일러를 체크한 후 연결해서 빌드하면 프로파일러를 통해서 확인해야함. 그냥 유니티 에디터에서 감지가 안되던 게 그럴 때 감지 되는 경우가 많다.

스마트폰 테스트 베드라는 곳이 있음. 거기에 예약하고 테스트하면 에러를 줄일 수 있음. 근데 같은 모델에서도 어떤 애는 되고 어떤 애는 안되는 경우가 발생.. 그래서 완벽히 해결할 수는 없다.

대신 이렇게 하면 이런 건 알 수 있다. 애플은 기기가 몇 없어서 문제가 거의 없음. 보통 앱 올릴 때 검사도 철저해서 터지면 그냥 어떤 폰이든 다 터짐. 문제가 터지는 건 주로 구글이 문제. 보통 에러 나면 어떤 기기에서 에러가 나는지가 오는데, 에러가 과하게 나는 기기는 그냥 구글 플레이 콘솔 가서 그 기기가 다운이 안되는 걸로 막아둬야 함.

그걸 방치하면 평점이 계속 깎이므로 막는 게 차라리 나음.

스크린 대응법은 개발사마다 방법이 다름.

자기가 생각하는 메인 디바이스의 해상도를 잡음. 16:9라는 식으로. 스크린.위드, 스크린.헤이트로 로직을 만들어야 함.

근데 만약 예상한 애보다 더 긴 기기에서 켠다. 그러면

방법 1 : UI를 각 방향 끝에 맞춰서 붙임. 길어진다고 보면 됨.

방법 2 : 예상한 해상도보다 길다란 기기면 위 아래를 검은색이나 어떤 문양이든 뭐든을 메움. 잘라낸다고 보면 됨.

방법 3 : 요즘은 1+2로 어느 정도는 늘어나고 그 외에는 자르는 식이 많이 보이고 있음.

옆으로 늘어나는 경우도 같음.

캔버스나 이미지의 사이즈보단 카메라의 확대 정도를 바꿈(오쏘그래픽을 반으로 줄이는 식). 그게 경험 상 제일 편했다고 함.

 - 파일 입출력

파일 스트리밍에셋 같은 걸 해도 됨.

보통 파일 입출력할 때 많이 쓰는 건 레벨디자인 시트나 텍스트 번역 파일 등을 불러올 때 사용하는 편.

텍스트, 엑셀, xml, csv, json 등 여러 방식이 있는데 이건 골라 쓰면 됨.

그리고 얘들은 Resources 안에 있어야 함. 여기에 없으면 씬에 연결 안되어있는 경우 빌드할 때 안 들고 감.

보통 리소스 폴더 안에서 리소스.로드 식으로만 해야 함. 아니면 경로가 꼬이는 경우가 많음. 에디터에서는 되도 빌드하고 나면 안가져가는 것도 많고. 모바일에서는 그게 안먹힘. 리소스 폴더는 그냥 필수다.

 - 파티클

필요한 건 체크하고 필요 없는 건 꼭 체크 해제할 것. 계속 업데이트되고 있으니 공부하는 것 외에는 밥이 없다.

파티클은 반드시 메테리얼을 따로 써야 함. 드로우 콜을 낮추기 위함. 한 파티클이 복사되어 여러개 쓰이는 건 상관 없는데, 여러 파티클이 같은 메테리얼을 쓰면 드로우 콜이 늘어난다.

안에서 많이 쓰는 기능은 입자의 수나 퍼지는 모양, 방향성 조정하는 기능. 물론 수많은 기능을 자기가 찾아서 여러 번 써보며 바꿔보고 익히는 수밖에 없다.

파티클은 풀링이 필수적이다. 로드하는데 시간이 걸리는 탓.

쉐이더는 걍 유니티 기본 쉐이더(모바일이면 모바일용.)를 써도 됨. 왜냐면 쉐이더는 C#이 아니라서 그 언어를 배워야하고, 언어 난이도가 상당히 높다.

자기가 쉐이더 제작을 오래 공부한 게 아니면 만드는 건 비추, 에셋에서 평가 좋은 걸 쓰자.

모바일에선 메테리얼의 쉐이더를 모바일-파티클-알파블랜드를 가장 많이 씀

 - 애니메이션

2D는 스프라이트 애니메이션과 스파인(Spine) 애니메이션으로 나뉨.

스프라이트 애니메이션은 스프라이트를 프레임별로 쪼개서 가지고, 이어서 재생하는 방식. 자연스러운 연출에는 좋지만 동작 하나를 위해 많은 텍스쳐를 써야하고 메모리를 많이 차지함. 그리고 리소스 로드하는 시간도 길어짐. 개발 기간도 오래걸림. 그림을 되게 많이 그려야하기 때문. 뛰는 동작 한 번을 위해 16번 그려야하는 일이 생김.

스파인 애니메이션은 캐릭터를 하나로 그린 후 관절? 같은 식으로 하나하나 분리한다. 하지만 자연스럽게 하는 건 어려움. 하지만 스프라이트에 비해 성능적인 면이든 용량적인 면에서 우세. 허나 스프라이트에 비해 연출력에서 밀림.

 그래서 스프라이트 애니메이션과 섞어서 하이브리드로 사용하는 경우가 많음.

3D는 맥스로 만들어 fbx로 추출하고, 유니티로 가져와서 씀. 방식은 이렇게 나뉨.

레거시 방식 : 가장 최초의 방식. 애니메이션을 맥스 등에서 구워서 그대로 재생. 다른 동작은 불가능.

제네릭 방식 : ??레거시랑 무슨 차이인가.

휴머노이드 방식 : 리깅을 해두면 다른 애한테도 공유해서 쓸 수 있음. 규약? 을 지킬 수 있으면 키 차이가 나고 뭐가 어떻게 달라도 똑같은 애니메이션을 사용 가능하다고 함.

https://www.mixamo.com => 몸체를 만들고 리깅을 하고 애니메이트 해주는 곳. 어도비에 인수된 사이트. 디자이너 없이 이 사이트 이용해서 만들고 대박 난 게임도 있음.

3D를 만들 때 본의 갯수를 28개 이하로 만들지 않으면 렉이 걸리던 문제가 있었음. 이게 버그인지 아니면 설계 자체가 원래 그런건지는 모름.(지금도 그런지는 모름. 유니티 4때의 경험.)

 - 모바일 출시를 위한 필수 SDK 세팅 <- 되게 중요 핵중요 겁나 중요 오늘 말하는 것 중 제일 중요.

1. 게임센터(구글 플레이 게임 센터, 애플 게임 센터)

: 로그인(유저들의 고유 식별자를 알 수 있음), 데이터 백업(미니게임 같은 거면 간단하게 게임 센터에서 백업 가능. 커지면 별도 서버 필요), 리더보드, 업적(구글 플레이에서는 업적을 딸 때마다 플레이 레벨이 오름. 이걸 노리는 사람들도 있어서 넣는 게 중요) 등

2. In App Purchase

: 예전엔 자바로 네이티브하게 해야했지만 요샌 인앱결제가 에셋 스토어에 있음. 유니티가 제공함. 그래서 에셋스토어에서 다운로드하거나 서비스 탭에서 이용. 두 방법이 약간 다른 걸로 앎.

3. 광고 모듈

: 동영상 광고(애드몹, 유니티 애드 등. 되게 하는 곳이 많음), 전면 광고(애드몹), 배너 광고(애드몹), 오퍼월 광고(이건 요즘 잘 안씀)

=> 강사님은 이걸 잘 안쓰시는데, 인앱 결제 위주 게임인 탓. 하지만 인앱 결제만 두면 무과금 유저가 박탈감을 느끼므로 광고를 하나 보면 리워드를 주는 식으로, 사람들이 매일매일 들어오게 하는 용도. 그래서 추천하는 업체가 베스트라는 건 절대 아님.

4. 분석

: 스테이지 식 게임에서 어떤 스테이지에 어떤 사람이 있는가에 대한 통계 분석. 5~6탄 넘어갈 때 플레이어 수가 반토막된다. 하면 5탄이 넘나 어렵거나 간헐적으로 버그가 발생한다던가 하는 게 있을 수 있는 거임.

=> 무료 사이트 추천 (TapJoy, IGAWorks ADBrix, Flurry, Firebase). 무료인데 다 괜찮은 편. 허나 정확하거나 깊은 분석엔 한계가 있음. 추가로 Tabjoy는 현재 들어오는 플레이어에게 Push Message를 보내는 게 몹시 간단. 지금 들어온 사람에게 보석 주기 이런거 할 때 되게 편하게 되어있음. 소문이지만 구글 광고 + Firebase가 궁합이 잘 맞다고 함. Firebase는 구글이랑 하는거라 앞으로 더 유리할 확률이 높음.

=> 유료 사이트 추천 (Adjust) 좋긴 좋은데 요금이 몹시 비쌈.

5. 소셜

: Facebook, Twitter. 로그인, 친구 초대, 스샷 공유 같은 기능 사용.

6. 네이버 플러그

: 카페(자국 한정으로 있으면 몹시 편함). 이건 네이버에 게임 심사를 신청해 승인을 받아야 함. 우리나라 서비스할 때 (소셜적으로 전략이나 질문, 자랑 등 교류를 나눌만한 게임이라면 필수라 볼 수 있음)

 - 서버는 어떻게 해야하는가?

1. 데이터 저장 서버

: 유저 데이터 저장

2. 실시간 플레이 서버 => 작은 개발사에서는 엔진을 쓰지 않고서는 거의 불가.

: 유니티 기본 엔진, Photon 등. 매칭 시스템이 들어가려면 유저가 많아야 함. 작은 규모의 개발사에서는 정말 비추. 돈만 날리는 일이 될 것.

데이터 저장 서버의 구조는 다음과 같다.

웹 방식) 유니티 -> PHP, JSP -> MySql => 만들기 쉬움. 유저가 많아지면 서버가 느려지므로 그에 대한 대비를 직접 다 해둬야 함. 유저가 있건 없건 서버가 항상 켜져있어야 함. 서버 늘릴 때가 힘듦

아마존 Lambda & DynamoDB 방식) 유니티 -> Lambda 서버(C, Java) -> DynamoDB => Lambda는 꺼져있다가 요청이 있으면 켜지고, 요청이 한동안 없으면 꺼짐. 물론 처음 켜질 때는 약간 느릴 수 있으나 켜진 후엔 무척 빠름. DynamoDB는 서버 늘릴 때 병렬적으로 늘려주는 걸 알아서 해주고, 속도도 빠름. 유니티-Lambda 교신법과 Lambda-DynamoDB 교신법을 알면 적용 가능. 물론 서버에 대한 약간의 지식은 필요. 거기다 중개자가 필요없는 상황이면 DynamoDB랑 유니티를 바로 연결해도 됨.

포톤은 실시간보다 턴제 게임이 적합.

 - 제가 겪은 문제점

어떻게 해야 더 뽑기를 기분 좋게 할까. 매출의 80%는 극소수가 올린다.

 - 최적화

최적화를 해야 할 부분이 있다. 최적화를 잘하려면 엔진에 대한 이해도가 높아야 함. 내가 만드는 게 왜 느려지는 가에 대한 이해. 

프로파일러의 기능들을 완벽히 이해해야 잡을 수 있다.

fps는 60~100 사이를 유지할 수 있게 할 것. 60 근처도 안 됨. 가능한 100에 가깝게 낮추려 노력할 것.

1. 코딩 상의 문제

: 불필요한 재귀호출, 반복이 들어가는 경우. 델리게이트가 과하게 들어가는 경우. 유니티에서 SendMessage는 무척 느리다거나 하는 것.

2. 구조 문제(씬 로딩, 물리 등)

: 유니티 옵션 값을 잘 설정해야 함. 예를 들어 아군과 적군이 섞여있는 데 공격하는 뭐가 지나가면 콜라이더가 엄청 불림. 레이어로 완전 다 분리해줘야 함. 에디트-프로젝트세팅-피직스를 눌러서 나오는 건 다 이해해야 함.

  씬을 로딩하거나 할 때 불필요한 오브젝트가 있다던가, 풀링을 자기 플레이타임을 고려해서 짜지 않았다던가. 풀링 매니저도 분리해서 일시적인 풀링을 해줘야하는 아이나 몇 분짜리 풀링이 필요한 아이 등을 다 만들어야 함.

  이벤트성 스테이지의 풀링은 시간 제약을 걸어야 함. 이런 식으로 구조를 잘못 잡으면 독이 된다. 풀러에 들어가는 오브젝트 수 등에 따라 어떻게 풀링을 해야하는 지가 갈린다.

  씬과 씬을 넘어갈 때 양 씬의 메모리가 다 적재된다. 이런 것도 주의해야 하고, 스크립트가 불리는 순서 등도 잘 알아야 함.

3. 가비지 문제

: 중요. 메모리에서도 속성에 따라 종류가 갈림. 가비지 컬렉터는 부하가 심함. 애시당초 가비지가 생기지 않게 코딩을 하려 해야 함. 그렇게 해도 가비지가 생길 수 밖에 없는데, 어떻게든 최소화하고 의도치 않을 때 가비지 콜렉터가 불리게 하지 말고 의도적으로 불러야 함. 화면이 새까매질 때마다 불러준다던가 하는 식. 대강 몇 분마다 가비지 콜렉터가 불리니까 알아서 몇 분마다 게임에 문제 없을 시점에 수동으로 가비지 콜렉터를 부른다. 대신 여기서 중요한 건 가비지가 어디서 쌓이느냐. 박싱 언박싱 등에서 많이 생기는데 이건 알아서 공부해야할 부분이다.

4. 렌더링 문제

: 메인 디바이스를 정하고 그 디바이스에서 렉이나 발열 등 원활한 플레이가 가능할 때까지 반복해서 확인해야 함.

5. 메모리 문제

: 텍스쳐 아니면 오디오 문제. 근데 오디오가 많이 차지하는 경우는 별로 없고 텍스쳐가 겁내 많이 든다. 나는 이 기종으로 할건데 어플당 허락된 메모리가 이 기종은 얼마이다. 근데 거기다 광고나 이런 걸로 메모리를 먹으니 그런 것도 여유롭게 계산해야 함. 안쓰는 에셋들은 그 자리에서 바로바로 해제해줄 것.

언리얼은 아트웍 기능. 때깔이 좋다.

유니티는 기본 용량을 먹음. 

코코스는 정말 캐주얼한 게임일 때. 컨텐츠보다 레벨 디자인으로 승부를 보는 게임이면 코코스를 추천.

모바일에서는 픽스드업데이트가 고정된 프레임에 찍어주니까 더 빠른 경우가 많음. (부하가 있으면 문제가 생기긴 함. 부하가 안생길 때 기준.)

모바일에서는 업데이트 다 빼고 픽스드 업데이트 추천

엔진이 어떻게 돌아가는지 공부가 필요. setpass call도 확인해야하고..

포톤 챗의 주의사항

1. 포톤에서 채팅 필터로 욕 차단 하려고 했는데 안됨(3개월 전 이야기) 돈만 비쌈.

2. 포톤 챗도 리전을 설정할 수 있음. 같은 채널이어도 리전이 다르면 연결 x

3. 포톤 채널의 버전이 바뀌면 같은 채널이고 같은 리전이어도 서로 연결 불가.

4. 채널에 몇 명이 있는지 알 수 없음

5. 방에 쪽수 제한도 없음

스프라이트 아틀라스 만드는 법 => 사용했던 스프라이트가 아틀라스에 들어가있으면 자동으로 연결되는 듯

: 크리에이트-스프라이트아틀라스 한 다음 프로젝트 세팅-에디터 에서 스프라이트 패커를 아틀라스로 설정한 후 스프라이트들이 들어있는 폴더를 컴포넌트 상에서 드래그해서 어찌어찌하면 나오는 것 같음... 이건 찾아봐야 할 듯.