|
@@ -1,7 +1,11 @@
|
|
|
|
+---
|
|
|
|
+title: Defold manual
|
|
|
|
+---
|
|
|
|
+
|
|
# Message passing
|
|
# Message passing
|
|
메세지 전달은 오브젝트간 종속성을 만들지 않으면서 통신할 수 있도록 하는 Defold의 메커니즘입니다. 이 매뉴얼은 이 메커니즘에 대해 자세히 설명하며 **게임오브젝트, 컴포넌트, 컬렉션**에 대한 기본 지식이 있다고 가정하고 설명하도록 하겠습니다.
|
|
메세지 전달은 오브젝트간 종속성을 만들지 않으면서 통신할 수 있도록 하는 Defold의 메커니즘입니다. 이 매뉴얼은 이 메커니즘에 대해 자세히 설명하며 **게임오브젝트, 컴포넌트, 컬렉션**에 대한 기본 지식이 있다고 가정하고 설명하도록 하겠습니다.
|
|
|
|
|
|
-프로그래밍에서 오브젝트나 코드모듈, 컴포넌트간의 [결합](http://ko.wikipedia.org/wiki/결합도)(coupling)을 가능한 느슨하게 만드는 것은 일반적으로 아주 좋은 방법입니다. 다른 오브젝트의 내부동작에 의존하는 오브젝트는 단단히 결합된 것으로 간주되며 이 결합은 종종 코드를 수정하기 어렵게 만들고 추적하기 매우 어려운 버그를 발생시키기도 합니다.
|
|
|
|
|
|
+프로그래밍에서 오브젝트나 코드모듈, 컴포넌트간의 [결합](http://ko.wikipedia.org/wiki/결합도)(coupling)을 가능한 느슨하게 만드는 것은 일반적으로 아주 좋은 방법입니다. 다른 오브젝트의 내부동작에 의존하는 오브젝트는 단단히 결합된 것으로 간주되며 이 결합은 종종 코드를 수정하기 어렵게 만들고 추적하기 매우 어려운 버그를 발생시키기도 합니다.
|
|
|
|
|
|
Defold의 Lua 통합(integration)은 Java, C++, C# 같이 상속을 사용한 클래스 구조로 어플리케이션을 개발하듯이 객체지향을 제공하지는 않습니다. 대신 Defold는 아래와 같이 간단하고 강력한 객체 지향 설계로 Lua의 기능을 확장합니다:
|
|
Defold의 Lua 통합(integration)은 Java, C++, C# 같이 상속을 사용한 클래스 구조로 어플리케이션을 개발하듯이 객체지향을 제공하지는 않습니다. 대신 Defold는 아래와 같이 간단하고 강력한 객체 지향 설계로 Lua의 기능을 확장합니다:
|
|
|
|
|
|
@@ -54,7 +58,7 @@ Defold의 모든 오브젝트는 URL(Uniform Resource Locator)을 통해 고유
|
|
URL의 이 부분은 일반적으로 타겟 게임 오브젝트의 전체 id를 포함합니다.
|
|
URL의 이 부분은 일반적으로 타겟 게임 오브젝트의 전체 id를 포함합니다.
|
|
|
|
|
|
#### fragment
|
|
#### fragment
|
|
-지정된 게임 오브젝트 내의 타겟 컴포넌트의 id입니다.
|
|
|
|
|
|
+지정된 게임 오브젝트 내의 타겟 컴포넌트의 id입니다.
|
|
|
|
|
|
위에서 "hero" 게임 오브젝트의 스크립트에 대한 전체 URL은 아래와 같습니다:
|
|
위에서 "hero" 게임 오브젝트의 스크립트에 대한 전체 URL은 아래와 같습니다:
|
|
|
|
|
|
@@ -298,7 +302,7 @@ local parent = go.get_id("tree")
|
|
msg.post(".", "set_parent", { parent_id = parent })
|
|
msg.post(".", "set_parent", { parent_id = parent })
|
|
```
|
|
```
|
|
|
|
|
|
-부모-자식 계층구조는 에디터에서 설정할 수도 있으며 여전히 동적인 (dynamic) 상태입니다. 예를 들어, 하트가 달린 나무를 만들어 봅시다. 이는 "tree" 오브젝트와 몇 개의 "heart" 오브젝트로 구성되어 있습니다. 또한 나무가 살아가는데 필요한 "pot"도 있습니다. 우선 이 오브젝트들을 부모와 자식관계로 만들기 위해 "hearttree"라고 불리우는 컬렉션에 오브젝트들을 배치합니다. 그리고 나서 "heart" 오브젝트를 "tree" 오브젝트에 드래그 하여 간단히 자식객체로 만들 수 있습니다.
|
|
|
|
|
|
+부모-자식 계층구조는 에디터에서 설정할 수도 있으며 여전히 동적인 (dynamic) 상태입니다. 예를 들어, 하트가 달린 나무를 만들어 봅시다. 이는 "tree" 오브젝트와 몇 개의 "heart" 오브젝트로 구성되어 있습니다. 또한 나무가 살아가는데 필요한 "pot"도 있습니다. 우선 이 오브젝트들을 부모와 자식관계로 만들기 위해 "hearttree"라고 불리우는 컬렉션에 오브젝트들을 배치합니다. 그리고 나서 "heart" 오브젝트를 "tree" 오브젝트에 드래그 하여 간단히 자식객체로 만들 수 있습니다.
|
|
|
|
|
|

|
|

|
|
|
|
|
|
@@ -351,7 +355,7 @@ path나 fragment 부분은 필요 없습니다.
|
|
```
|
|
```
|
|
|
|
|
|
#### Collection Proxies
|
|
#### Collection Proxies
|
|
-Defold가 시작되면 게임 프로젝트 셋팅창의 "bootstrap" 아래의 "main_collection" 항목에 지정된 컬렉션을 자동으로 로드하고 초기화 합니다.
|
|
|
|
|
|
+Defold가 시작되면 게임 프로젝트 셋팅창의 "bootstrap" 아래의 "main_collection" 항목에 지정된 컬렉션을 자동으로 로드하고 초기화 합니다.
|
|
|
|
|
|
별도의 컬렉션에 각기 다른 게임 레벨을 유지해야 하는 등, 서로 다른 컬렉션을 동적으로 불러와야할 경우가 있을 수 있습니다. Defold는 동적으로 로드되는 컬렉션을 위해 컬렉션 프록시(Collection Proxy) 오브젝트를 사용합니다.
|
|
별도의 컬렉션에 각기 다른 게임 레벨을 유지해야 하는 등, 서로 다른 컬렉션을 동적으로 불러와야할 경우가 있을 수 있습니다. Defold는 동적으로 로드되는 컬렉션을 위해 컬렉션 프록시(Collection Proxy) 오브젝트를 사용합니다.
|
|
|
|
|
|
@@ -383,7 +387,7 @@ end
|
|
#### Message chains
|
|
#### Message chains
|
|
게시된 메세지들이 디스패치되고 수신자의 on_message()가 호출되면, 응답 코드를 담아 또 새 메세지를 게시하여 주거니 받거니 하는 것은 일반적인 개발 방식입니다. 당신은 엔진이 디스패치 해야하는 긴 메세지 체인을 구축할 수 있습니다. 이것은 언제 발생할까요?
|
|
게시된 메세지들이 디스패치되고 수신자의 on_message()가 호출되면, 응답 코드를 담아 또 새 메세지를 게시하여 주거니 받거니 하는 것은 일반적인 개발 방식입니다. 당신은 엔진이 디스패치 해야하는 긴 메세지 체인을 구축할 수 있습니다. 이것은 언제 발생할까요?
|
|
|
|
|
|
-짧게 대답하자면 이 디스패치는 즉시 발생합니다. 게임엔진은 메세지들을 처리하는 작업을 시작하고 당신이 새 메세지를 게시하여 큐를 계속 채우더라도 메세지 큐가 비워질 때까지 계속 처리합니다.
|
|
|
|
|
|
+짧게 대답하자면 이 디스패치는 즉시 발생합니다. 게임엔진은 메세지들을 처리하는 작업을 시작하고 당신이 새 메세지를 게시하여 큐를 계속 채우더라도 메세지 큐가 비워질 때까지 계속 처리합니다.
|
|
|
|
|
|
그러나 게임엔진이 메세지큐를 비울 수 있는 횟수는 제한이 있습니다. 이는 긴 메세지 체인을 한 프레임 내에서 효과적으로 제한합니다. 다음 스크립트를 사용하여 각 update() 사이에 엔진이 처리할 수 있는 디스패치 수가 얼마나 되는지 쉽게 테스트 할 수 있습니다.
|
|
그러나 게임엔진이 메세지큐를 비울 수 있는 횟수는 제한이 있습니다. 이는 긴 메세지 체인을 한 프레임 내에서 효과적으로 제한합니다. 다음 스크립트를 사용하여 각 update() 사이에 엔진이 처리할 수 있는 디스패치 수가 얼마나 되는지 쉽게 테스트 할 수 있습니다.
|
|
|
|
|