-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathUnity.txt
More file actions
26 lines (19 loc) · 3.63 KB
/
Unity.txt
File metadata and controls
26 lines (19 loc) · 3.63 KB
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
unity 게임이 스마트폰에서 동작하는 방법
게임 엔진의 원리 :
상속
상속이란 이미 만들어진 클래스를 기반(부모클래스, Base Class)으로 자신만의 새로운 기능을 덧붙여서 새로운 클래스(자식클래스, Derived Class)를 만드는 방법.
그러나 상속이 항상 잘 작동하는 것은 아니다. 예를들어 캐릭터라는 부모클래스와 이를 상속받는 플레이어, NPC, 몬스터 이렇게 3가지 자식 클래스를 만들었다고 해보자. 캐릭터라는 클래스에 체력 시스템, 공격 시스템, 애니메이션이 구현되어 있다고 해보자. 플레이어 클래스에서는 이것들이 상속되는게 문제가 안되지만 체력 시스템과 공격 시스템이 필요가 없는 NPC 클래스에서는 이 시스템들이 상속되면 체력이 깎이고 죽을 수도 있게 되는 문제가 생길 수 있다. 몬스터 클래스도 캐릭터 클래스를 상속 받으니 플레이어와 공통적인 애니메이션을 갖게 되지만 몬스터의 애니메이션을 플레이어의 애니메이션과 다르게 하고싶다면 또 문제가 생길 수 있다(덮어 씌워야 하기 때문에) 따라서 a is b 상속 구조가 아닌 a has b구조로서 원하는 기능만 갖다 붙혀서 포함시키는 방식을 게임 오브젝트-컴포넌트라고한다. 게임 오브젝트는 단순한 빈 껍데기이며, 컴포넌트는 스스로 동작하는 독립적인 부품이다.
MonoBehaviour
유니티에 모든 컴포넌트는 MonoBehaviour 클래스를 상속한다. MonoBehaviour 클래스는 유니티에서 미리 만들어 제공하는 클래스이며 컴포넌트에 필요한 기본 기능을 제공한다. MonoBehaviour 클래스를 상속해서 만든 컴포넌트는 유니티의 제어를 받게 되므로, 컴포넌트는 유니티의 메시지를 들을 수 있다. 게임 컴포넌트들은 서로에게 관심이 없기 때문에(컴포넌트의 독립성), 메시지를 누가 보냈는지는 관심이 없고, 다만 해당 메시지가 원하는 기능을 갖고 있다면 실행할 뿐이다.
렌더링 :
프레임 버퍼(black buffer)는 데이터의 저장공간 같은 건데 이미지를 쓰는 것도 데이터니까 버퍼에 저장된다.
프레임 버퍼도 더블 버퍼링이라는 개념이 적용되는데 더블 버퍼링이 뭐냐면 우리가 게임을 할때 이미지가 보이는게 차곡차곡 보이는게 아니라 뿅하고 보인다. 그이유가 프레임 버퍼에 데이터가 차곡차곡 정리 된 다음에 프론트 버퍼로 바뀐다. 그리고 프론트 버퍼가 디스플레이랑 연결돼서 보인다. 근데 요즘 게임은 화면 전환이 빠른데 그건 트리플 버퍼링을 사용하는건데 말 그대로 2개가 아니라 3개를 사용하는거다.
redering piperine
▼
frame bufeer ← black buffer
▼
front buffer
▼
display
빌드방법 :
일단 File > Build Settings (단축키 : shift + command + B)에 가서 Player Settings에서 옵션좀 조절 한다음에 build버튼 누르고 위치 저장하면 된다. 그리고 ios와 andriod로 나뉘는데 일단 ios는(android도 그렇고) 그냥 build 버튼만 누르는게 아니라 플렛폼을 지정할 수 있는데 그걸로 지정하고 빌드를 하면 빌드한 프로젝트안에 xcode파일이 있는데 그걸열고 핸드폰을 컴퓨터와 연결한 다음에 세모나게 생긴 플레이 버튼 누르면 핸드폰에 저장된다. 그리고 android인데 플렛폼 지정하고(android로) 빌드 버튼 누른다음에 핸드폰과 컴퓨터를 연결하고 그 핸드폰에 빌드 파일을 넣으면 된다.