[task] | single_turn [pass] | ⏳ 미판정 [title] | 공동 제작 [question] | 그룹 월드에서 다른 멤버들이 수정 중인 내용을 실시간으로 확인하려면 Cooperation 창에서 어떤 정보를 볼 수 있나요? [answer] | 그룹 월드에서 다른 멤버들의 작업 현황을 실시간으로 확인하려면 **Panels - Cooperation**을 통해 접속된 멤버들의 정보를 볼 수 있습니다. 이 창에서는 해당 월드에 함께 접속 중인 사람들의 **닉네임**과 **메이커 아이디**를 확인할 수 있습니다. 또한, **Local Changes** 창을 열면 내가 Hierarchy나 Workspace에서 Check Out하여 변경한 항목들을 한 번에 모아 볼 수 있으며, 이들을 한꺼번에 **Check In**할 수 있습니다. [followup] | [followup_answer] | [scores] | [judge_reason] | [source_doc] | 함께 제작하는 그룹 월드에서 **Panels - Cooperation**을 누릅니다. 해당 월드에 함께 접속 중인 사람들의 닉네임과 메이커 아이디가 보입니다. ## Local Changes 그룹 월드에서 작업자가 Check Out한 항목을 모아 볼 수 있는 창입니다. Hierarchy, Workspace에서 내가 변경한 항목을 확인하고, 한 번에 **Check In**할 수 있습니다. **Panels - Cooperation - Local Changes**를 눌러 창을 엽니다. ## 복구 모드 그룹 월드의 리비전을 되돌리기나
[task] | two_turn [pass] | ⏳ 미판정 [title] | 확률 정보 공개 [question] | 메이플스토리 월드에서 확률형 아이템을 제작할 때 반드시 준수해야 하는 확률 정보 공개 의무의 범위가 무엇인가요? [answer] | 메이플스토리 월드에서 확률형 아이템을 제작할 경우, 아이템 사용 전에 반드시 사용자에게 확률 정보를 고지해야 하는 의무가 있습니다. 이는 메이플스토리 월드의 확률 정보 공개 가이드를 따르는 것으로, 해당 가이드는 ‘확률형 아이템 확률 정보공개 관련 해설서’의 내용을 기반으로 합니다. 이 의무를 지키지 않을 경우, 최대 월드 이용 제한이 적용될 수 있습니다. 확률 정보 공개 대상이 되는 확률형 아이템은 플레이어가 직접적 또는 간접적으로 유상으로 구매하는 아이템 중, 구체적 종류, 효과 및 성능 등이 우연적 요소에 의해 결정되는 것을 [followup] | 4가지 기본 유형 외에 '천장' 시스템이나 확률 변동이 있는 경우, 구체적인 고지 방법은 어떻게 달라지나요? [followup_answer] | 참고 문서에는 '천장' 시스템이나 확률 변동이 있는 경우의 **구체적인 고지 방법**이 어떻게 달라지는지에 대한 상세한 내용은 포함되어 있지 않습니다. 문서에는 이러한 항목들이 확률 정보 공개 대상이 될 수 있는 **"3종 외 추가 확인 필요 아이템 유형"**으로 분류된다는 사실과, 자세한 확률 정보 공개 대상 및 방법은 **"확률형 아이템 확률 정보공개 관련 해설서"**를 확인해야 한다고 명시되어 있을 뿐입니다. 따라서 천장 시스템이나 확률 변동에 따른 구체적인 고지 방법(예: 천장 도달 시점 명시 방식, 확률 변경 시점 고지 [scores] | [judge_reason] | [source_doc] | # 확률 정보 공개란? 메이플스토리 월드의 모든 크리에이터는 창작한 아이템 내 확률형 아이템을 제공하는 경우 확률 정보 공개 가이드에 따라 아이템 사용 전 사용자에게 고지해야 할 의무가 있습니다. * 메이플스토리 월드의 확률 정보 공개 가이드는 ‘확률형 아이템 확률 정보공개 관련 해설서’의 내용을 따릅니다. 해당 해설서의 내용을 따르지 않을 경우 최대 월드 이용 제한이 적용될 수 있습니다. # 확률 정보 공개 대상 및 방법 아래 항목에 해당할 경우 확률형 아이템 정보 공개 대상이 될 수 있으며, 자세한 확률 정보 공개 대상 및
[task] | instruction_following [pass] | ⏳ 미판정 [title] | 카드 섞기, 선택하기 [question] | SelectCard와 DeselectCard 함수의 내용을 [client only] 실행 공간 지정과 함께 코드 블록 하나로 통합하여 출력하세요. [answer] | ```lua [client only] void SelectCard(Card card) { self.SelectedCard = card card:CardOn() } [client only] void DeselectCard() { self.SelectedCard:CardOff() self.SelectedCard = nil } ``` [followup] | [followup_answer] | [scores] | [judge_reason] | [source_doc] | 1. **CardBoard** 컴포넌트에서 새로운 프로퍼티를 추가하고 프로퍼티 타입을 **Component**로 지정합니다. ```lua Property: [None] Card SelectedCard = nil ``` 2. CardBoard 컴포넌트에서 `SelctCard` 함수를 찾습니다. 매개 변수를 추가하고 타입을 Component로 변경합니다. Component를 **Card**로 지정합니다. ```lua [client only] void SelectCard (C
[task] | code [pass] | ⏳ 미판정 [title] | 스크립트 라이프 사이클 [question] | 월드 실행 종료 시 OnEndPlay와 OnDestroy 함수가 호출되는지 로그를 통해 확인하기 위해 LifeCycle 컴포넌트의 해당 기본 이벤트 함수를 구현한 스크립트를 작성해줘 [answer] | 월드 실행 종료 시 `OnEndPlay`와 `OnDestroy` 함수가 호출되는지 확인하기 위해, 해당 기본 이벤트 함수에 로그 출력을 추가한 스크립트입니다. 참고 문서의 학습 과정 소개에 따르면, 월드를 실행하고 종료하면 `OnEndPlay`와 `OnDestroy` 로그가 순차적으로 남습니다. ```lua Property: [None] Method: [server only] void OnEndPlay() { log("OnEndPlay 실행") } [server only] void OnDestroy() { lo [followup] | [followup_answer] | [scores] | [judge_reason] | [source_doc] | # 학습 과정 소개 기본 이벤트 함수의 라이프 사이클과 플레이할 때의 전체 라이프 사이클을 알아봅시다. 라이프 사이클을 이해하면 특정 함수가 언제 불리는지 예상할 수 있고, 전체 월드의 동작을 고려하며 제작할 수 있습니다. # 기본 이벤트 함수의 라이프 사이클 월드에 필요한 로직을 만들기 위해서는 컴포넌트 스크립트를 만들어야만 합니다. 필요한 컴포넌트 스크립트를 만들 때 호출되는 시점을 예상해 의도한 로직에 맞게 동작할 수 있도록 작성해야 합니다. 라이프 사이클의 개념을 익혀두면 전체 흐름을 파악할 수 있기에 스크립트를 작성
[task] | code [pass] | ⏳ 미판정 [title] | 배지 서비스 활용하기 [question] | OnBeginPlay()에서 GetChildByName()을 이용해 자식 엔티티의 TextComponent를 참조하고, _BadgeService:GetBadgeInfoAsync()의 콜백에서 badgeInfo.Name과 badgeInfo.Description을 해당 TextComponent의 Text 속성에 할당하는 스크립트를 작성해줘 [answer] | 제공된 문서의 예제 코드를 바탕으로, `OnBeginPlay()`에서 자식 엔티티의 `TextComponent`를 참조하고 `_BadgeService:GetBadgeInfoAsync()`의 콜백에서 배지 정보를 갱신하는 스크립트를 작성했습니다. ```lua Property: [None] string BadgeId = "" -- 조회할 배지 ID [None] TextComponent BadgeTitle = nil -- 배지 이름 [None] TextComponent BadgDesc = nil -- 배지 설명 Method: [cli [followup] | [followup_answer] | [scores] | [judge_reason] | [source_doc] | 1. 새로운 **BadgeSlot 컴포넌트**를 생성하고 **BadgeSlot_01**에 추가합니다. 2. 획득한 배지의 이름, 소유 정보, 설명을 가져올 수 있도록 프로퍼티를 추가합니다. ```lua Property: [None] string BadgeId = "" -- 조회할 배지 ID [None] TextComponent BadgeTitle = nil -- 배지 이름 [None] TextComponent Hasbadge = nil -- 배지 소유 정보 [Non
[task] | single_turn [pass] | ⏳ 미판정 [title] | 공동 제작 [question] | Check In 되지 않은 상태에서 다른 맵을 불러오면 안내 창이 나온다고 하는데, 이 경우 미저장된 편집 내용은 어떻게 처리되나요? [answer] | 참고 문서에 따르면, Check In 되지 않은 상태에서 다른 맵을 불러오면 안내 창이 노출됩니다. 하지만 이 안내 창을 통해 미저장된 편집 내용이 구체적으로 어떻게 처리되는지(예: 자동 저장, 폐기, 선택 등)에 대한 설명은 문서에 포함되어 있지 않습니다. 문서에서는 "Check In 되지 않은 항목은 폐기되니 주기적으로 Check In 하는 습관을 들이기를 권장한다"고만 언급하고 있으며, 맵 전환 시의 구체적인 동작 방식을 명시하지 않았습니다. [followup] | [followup_answer] | [scores] | [judge_reason] | [source_doc] | # 학습 과정 소개 다양한 사람들이 함께 모여 월드를 제작할 수 있는 방법에 대해 알아봅시다. ##### 참고 가이드 * [그룹 생성과 멤버 관리](/docs/?postId=1325"target":"_self"}) * [공동 제작 그룹 멤버의 등급과 권한](/docs/?postId=1077) * [LocalWorkspace](/docs/?postId=1165) * [ExtendedScriptFormat](/docs/?postId=1166) # 공동 제작 함께 월드를 제작하기 위해서는 우선 그룹을 형성하고, 멤버 권한을 설정해
[task] | single_turn [pass] | ⏳ 미판정 [title] | 스크립트 라이프 사이클 [question] | 엔티티 이벤트(Entity Event)가 라이프 사이클에 포함되지 않는다는 말은 정확히 어떤 의미이며, 기본 이벤트 함수와의 호출 시점 차이가 무엇인가요? [answer] | 엔티티 이벤트(Entity Event)가 라이프 사이클에 포함되지 않는다는 것은, 기본 이벤트 함수처럼 월드 실행이나 엔티티 생성/소멸 등 **시스템적인 시점 변화에 따라 자동으로 순차적으로 호출되지 않는다**는 의미입니다. 기본 이벤트 함수와 엔티티 이벤트의 호출 시점 차이는 다음과 같습니다. 1. **기본 이벤트 함수 (Basic Event Functions)** * **호출 시점:** 월드의 실행 상태나 엔티티의 생명 주기(생성, 맵 입장/퇴장, 소멸 등)가 변할 때 시스템에 의해 **자동으로** 호출됩니다. [followup] | [followup_answer] | [scores] | [judge_reason] | [source_doc] | # 학습 과정 소개 기본 이벤트 함수의 라이프 사이클과 플레이할 때의 전체 라이프 사이클을 알아봅시다. 라이프 사이클을 이해하면 특정 함수가 언제 불리는지 예상할 수 있고, 전체 월드의 동작을 고려하며 제작할 수 있습니다. # 기본 이벤트 함수의 라이프 사이클 월드에 필요한 로직을 만들기 위해서는 컴포넌트 스크립트를 만들어야만 합니다. 필요한 컴포넌트 스크립트를 만들 때 호출되는 시점을 예상해 의도한 로직에 맞게 동작할 수 있도록 작성해야 합니다. 라이프 사이클의 개념을 익혀두면 전체 흐름을 파악할 수 있기에 스크립트를 작성
[task] | single_turn [pass] | ⏳ 미판정 [title] | 공동 제작 [question] | Check Out을 하지 않고 바로 편집을 시작하면 자동으로 Check Out 된다고 하는데, 이 경우 다른 멤버가 해당 항목을 수정하려고 하면 어떤 상태가 되나요? [answer] | 자동으로 Check Out된 상태에서는 다른 멤버가 해당 항목을 수정하려고 하면 **편집 권한이 차단**됩니다. 구체적으로 다른 멤버에게는 해당 항목이 **"Locked by 닉네임"** 상태로 보입니다. 이 상태에서는 다른 멤버가 해당 항목에 접근하거나 편집할 수 없으며, 현재 편집 중인 멤버가 **Check In**을 수행하기 전까지는 대기해야 합니다. 참고로 엔티티의 경우 편집 단위가 map, ui그룹 단위이므로, 자식 엔티티(예: Entity01)를 편집하면 부모(예: Map01) 전체가 Check Out 되어 같은 방식 [followup] | [followup_answer] | [scores] | [judge_reason] | [source_doc] | # 학습 과정 소개 다양한 사람들이 함께 모여 월드를 제작할 수 있는 방법에 대해 알아봅시다. ##### 참고 가이드 * [그룹 생성과 멤버 관리](/docs/?postId=1325"target":"_self"}) * [공동 제작 그룹 멤버의 등급과 권한](/docs/?postId=1077) * [LocalWorkspace](/docs/?postId=1165) * [ExtendedScriptFormat](/docs/?postId=1166) # 공동 제작 함께 월드를 제작하기 위해서는 우선 그룹을 형성하고, 멤버 권한을 설정해
[task] | instruction_following [pass] | ⏳ 미판정 [title] | 카드 섞기, 선택하기 [question] | OnCardClicked 함수 내 isvalid 체크와 카드 선택 로직을 포함하는 전체 함수 코드를 주석 없이 코드 블록으로만 출력하세요. [answer] | ```lua [client only] void OnCardClicked (Card card) { if isvalid(card) == false then return end local cardboard = self.CardPairGameUI.CardBoard if isvalid(cardboard) == false then return end local oldCard = cardboard.SelectedCard local newCard = c [followup] | [followup_answer] | [scores] | [judge_reason] | [source_doc] | 1. **CardBoard** 컴포넌트에서 새로운 프로퍼티를 추가하고 프로퍼티 타입을 **Component**로 지정합니다. ```lua Property: [None] Card SelectedCard = nil ``` 2. CardBoard 컴포넌트에서 `SelctCard` 함수를 찾습니다. 매개 변수를 추가하고 타입을 Component로 변경합니다. Component를 **Card**로 지정합니다. ```lua [client only] void SelectCard (C
[task] | single_turn [pass] | ⏳ 미판정 [title] | 공동 제작 [question] | 메이커 안에서 복구 모드를 켜기 위한 구체적인 경로가 두 가지라고 하는데, 각각 어떻게 들어가야 하나요? [answer] | 메이커 안에서 복구 모드를 켜기 위한 구체적인 경로는 다음 두 가지입니다. 1. **월드 관리 창에서 복구 모드 켜기** - 로비에서 **만들기**를 선택한 후, 해당 월드 옆의 **[⋯]** 버튼을 클릭합니다. - **월드 관리** 메뉴로 이동하여 **복구 모드 켜기**를 선택합니다. 2. **Cooperation 창에서 복구 모드 켜기** - 메이커 상단 메뉴에서 **Panels - Cooperation**을 선택하여 창을 엽니다. - **Members** 탭에서 **복구 모드 켜기**를 선택합니다. [followup] | [followup_answer] | [scores] | [judge_reason] | [source_doc] | 함께 제작하는 그룹 월드에서 **Panels - Cooperation**을 누릅니다. 해당 월드에 함께 접속 중인 사람들의 닉네임과 메이커 아이디가 보입니다. ## Local Changes 그룹 월드에서 작업자가 Check Out한 항목을 모아 볼 수 있는 창입니다. Hierarchy, Workspace에서 내가 변경한 항목을 확인하고, 한 번에 **Check In**할 수 있습니다. **Panels - Cooperation - Local Changes**를 눌러 창을 엽니다. ## 복구 모드 그룹 월드의 리비전을 되돌리기나
[task] | single_turn [pass] | ⏳ 미판정 [title] | 공동 제작 [question] | Cooperation 기능에서 엔티티의 편집 단위가 map이나 ui그룹 단위라고 하는데, 자식 엔티티 하나만 수정해도 부모 전체가 Check Out 되는 이유가 무엇인가요? [answer] | 제시된 문서에는 자식 엔티티 하나만 수정해도 부모가 Check Out 되는 구체적인 기술적 이유(예: 데이터 구조의 종속성, 충돌 방지 메커니즘 등)에 대한 설명은 포함되어 있지 않습니다. 문서에서 확인할 수 있는 내용은 다음과 같습니다: 1. 엔티티의 편집 단위는 **map, ui그룹 단위**입니다. 2. 자식 엔티티 편집을 시작하면 **부모가 Check Out** 됩니다. (예: `map01`의 `Entity01` 편집 시 `Map01`이 Check Out 됨) 3. Check Out은 편집 권한을 획득하고 다른 이의 편집 권 [followup] | [followup_answer] | [scores] | [judge_reason] | [source_doc] | # 학습 과정 소개 다양한 사람들이 함께 모여 월드를 제작할 수 있는 방법에 대해 알아봅시다. ##### 참고 가이드 * [그룹 생성과 멤버 관리](/docs/?postId=1325"target":"_self"}) * [공동 제작 그룹 멤버의 등급과 권한](/docs/?postId=1077) * [LocalWorkspace](/docs/?postId=1165) * [ExtendedScriptFormat](/docs/?postId=1166) # 공동 제작 함께 월드를 제작하기 위해서는 우선 그룹을 형성하고, 멤버 권한을 설정해
[task] | single_turn [pass] | ⏳ 미판정 [title] | 스크립트 라이프 사이클 [question] | OnUpdate와 OnSyncProperty를 제외한 나머지 라이프 사이클 함수들의 실행 순서를 로그로 확인하기 위해 어떤 테스트 절차를 거치나요? [answer] | `OnUpdate`와 `OnSyncProperty`를 제외한 나머지 라이프 사이클 함수(`OnInitialize`, `OnBeginPlay`, `OnMapEnter`, `OnMapLeave`, `OnEndPlay`, `OnDestroy`)의 실행 순서를 로그로 확인하기 위한 테스트 절차는 다음과 같습니다. 1. **컴포넌트 생성 및 함수 추가** * 새로운 `LifeCycle` 컴포넌트를 생성합니다. * 해당 컴포넌트에 `OnInitialize`, `OnBeginPlay`, `OnMapEnter`, `OnM [followup] | [followup_answer] | [scores] | [judge_reason] | [source_doc] | # 학습 과정 소개 기본 이벤트 함수의 라이프 사이클과 플레이할 때의 전체 라이프 사이클을 알아봅시다. 라이프 사이클을 이해하면 특정 함수가 언제 불리는지 예상할 수 있고, 전체 월드의 동작을 고려하며 제작할 수 있습니다. # 기본 이벤트 함수의 라이프 사이클 월드에 필요한 로직을 만들기 위해서는 컴포넌트 스크립트를 만들어야만 합니다. 필요한 컴포넌트 스크립트를 만들 때 호출되는 시점을 예상해 의도한 로직에 맞게 동작할 수 있도록 작성해야 합니다. 라이프 사이클의 개념을 익혀두면 전체 흐름을 파악할 수 있기에 스크립트를 작성
[task] | code [pass] | ⏳ 미판정 [title] | 스크립트 라이프 사이클 [question] | OnUpdate와 OnSyncProperty를 제외한 기본 이벤트 함수들의 호출 순서(OnInitialize -> OnMapEnter -> OnBeginPlay -> OnMapLeave -> OnMapEnter)를 로그로 추적하는 LifeCycle 스크립트를 작성해줘 [answer] | 기본 이벤트 함수 중 `OnUpdate`와 `OnSyncProperty`를 제외한 나머지 함수(`OnInitialize`, `OnBeginPlay`, `OnMapEnter`, `OnMapLeave`, `OnEndPlay`, `OnDestroy`)의 호출 순서를 로그로 추적하는 mLua 스크립트입니다. 문서에 명시된 순서(`OnInitialize` -> `OnMapEnter` -> `OnBeginPlay` -> `OnMapLeave` -> `OnMapEnter`)에 맞춰 각 기본 이벤트 함수에 로그 출력을 추가했습니다. ```lu [followup] | [followup_answer] | [scores] | [judge_reason] | [source_doc] | # 학습 과정 소개 기본 이벤트 함수의 라이프 사이클과 플레이할 때의 전체 라이프 사이클을 알아봅시다. 라이프 사이클을 이해하면 특정 함수가 언제 불리는지 예상할 수 있고, 전체 월드의 동작을 고려하며 제작할 수 있습니다. # 기본 이벤트 함수의 라이프 사이클 월드에 필요한 로직을 만들기 위해서는 컴포넌트 스크립트를 만들어야만 합니다. 필요한 컴포넌트 스크립트를 만들 때 호출되는 시점을 예상해 의도한 로직에 맞게 동작할 수 있도록 작성해야 합니다. 라이프 사이클의 개념을 익혀두면 전체 흐름을 파악할 수 있기에 스크립트를 작성
[task] | two_turn [pass] | ⏳ 미판정 [title] | 카드 섞기, 선택하기 [question] | CardBoard 컴포넌트에서 카드를 선택하고 해제하는 로직을 구현하려면 어떤 프로퍼티와 메서드를 추가해야 하나요? [answer] | CardBoard 컴포넌트에서 카드를 선택하고 해제하는 로직을 구현하기 위해 추가해야 할 프로퍼티와 메서드는 다음과 같습니다. **1. 프로퍼티 추가** 선택된 카드를 참조하기 위해 `SelectedCard` 프로퍼티를 추가하고, 타입을 `Component`로 지정합니다. ```lua Property: [None] Card SelectedCard = nil ``` **2. 메서드 추가** 카드 선택과 해제를 담당하는 두 개의 메서드를 추가해야 합니다. 두 메서드 모두 `[client only]` 실행 공간으로 설정합니다. * [followup] | `SelectedCard` 프로퍼티의 타입 지정 방법과 `DeselectCard` 함수에서 `nil` 확인 없이 `CardOff()`를 호출할 때 발생하는 예외 처리는 어떻게 해야 하나요? [followup_answer] | 참고 문서에 `SelectedCard` 프로퍼티의 타입 지정 방법은 명시되어 있으나, `DeselectCard` 함수에서 `nil` 확인 없이 `CardOff()`를 호출할 경우 발생하는 예외 처리 방법은 문서에 기술되어 있지 않습니다. 1. **`SelectedCard` 프로퍼티 타입 지정 방법** `CardBoard` 컴포넌트의 `Property:` 블록에서 프로퍼티 타입을 **Component**로 지정하고, 구체적인 컴포넌트 종류를 **Card**로 설정합니다. 초기값은 `nil`로 부여합니다. ```lua [scores] | [judge_reason] | [source_doc] | 1. **CardBoard** 컴포넌트에서 새로운 프로퍼티를 추가하고 프로퍼티 타입을 **Component**로 지정합니다. ```lua Property: [None] Card SelectedCard = nil ``` 2. CardBoard 컴포넌트에서 `SelctCard` 함수를 찾습니다. 매개 변수를 추가하고 타입을 Component로 변경합니다. Component를 **Card**로 지정합니다. ```lua [client only] void SelectCard (C
[task] | code [pass] | ⏳ 미판정 [title] | 배지 서비스 활용하기 [question] | _EntityService:GetEntityByPath("/ui/DefaultGroup/BadgeOpenBtn")를 통해 엔티티를 찾고, GetBadge 이벤트가 발생했을 때 배지 정보를 다시 조회하도록 연결하는 스크립트를 작성해줘 [answer] | 제공된 문서에 포함된 코드 예제를 바탕으로, `_EntityService:GetEntityByPath("/ui/DefaultGroup/BadgeOpenBtn")`를 통해 엔티티를 찾고 `GetBadge` 이벤트 발생 시 배지 정보를 다시 조회하도록 연결하는 스크립트는 다음과 같습니다. ```lua Property: [None] string BadgeId = "" -- 조회할 배지 ID [None] TextComponent BadgeTitle = nil -- 배지 이름 [None] TextComponent HasBadge = nil [followup] | [followup_answer] | [scores] | [judge_reason] | [source_doc] | 1. 새로운 **BadgeSlot 컴포넌트**를 생성하고 **BadgeSlot_01**에 추가합니다. 2. 획득한 배지의 이름, 소유 정보, 설명을 가져올 수 있도록 프로퍼티를 추가합니다. ```lua Property: [None] string BadgeId = "" -- 조회할 배지 ID [None] TextComponent BadgeTitle = nil -- 배지 이름 [None] TextComponent Hasbadge = nil -- 배지 소유 정보 [Non
[task] | code [pass] | ⏳ 미판정 [title] | 스크립트 라이프 사이클 [question] | 엔티티의 `OnBeginPlay`, `OnUpdate`, `OnEndPlay` 라이프사이클 메서드에서 각각 로그를 출력하여 실행 흐름을 확인하는 스크립트를 작성해줘 [answer] | 엔티티의 `OnBeginPlay`, `OnUpdate`, `OnEndPlay` 라이프사이클 메서드에서 로그를 출력하는 스크립트는 다음과 같습니다. ```lua Method: [server only] void OnBeginPlay() { log("OnBeginPlay called") } [server only] void OnUpdate(number delta) { log("OnUpdate called") } [server only] void OnEndPlay() { log("OnEndPlay called") [followup] | [followup_answer] | [scores] | [judge_reason] | [source_doc] | 서버와 클라이언트가 호출되는 전체 흐름을 알아봅시다. 플레이 라이프 사이클은 **제작 중인 월드**와 **출시된 월드**에서 약간의 차이가 있습니다. 가장 큰 차이점은 맵을 불러오는 방식입니다. * **제작 중인 월드**에서 플레이할 때는 10개의 맵을 만들었더라도 플레이어가 있는 맵만 불러옵니다. * **출시된 월드**에서는 플레이어 유무와 상관없이 모든 맵을 불러옵니다. 이와 같은 차이를 알고 있다면 **제작 중인 월드** 또는 **출시된 월드**에서 크리에이터 의도대로 동작하지 않는 무언가가 있을 때, 그 원인이 잘못된
[task] | single_turn [pass] | ⏳ 미판정 [title] | 스크립트 라이프 사이클 [question] | OnInitialize와 OnBeginPlay가 호출되는 순서가 어떻게 되며, 왜 맵 진입 시점인 OnMapEnter가 그 사이에 위치하는 것인가요? [answer] | 제공된 문서를 근거로 `OnInitialize`, `OnBeginPlay`, `OnMapEnter`의 호출 순서와 그 이유를 설명해 드리겠습니다. ### 1. 호출 순서 월드가 실행되고 플레이어가 맵에 진입할 때 기본 이벤트 함수가 호출되는 순서는 다음과 같습니다. 1. **`OnInitialize`** 2. **`OnMapEnter`** 3. **`OnBeginPlay`** ### 2. `OnMapEnter`가 `OnInitialize`와 `OnBeginPlay` 사이에 위치하는 이유 문서에 따르면, 이 순서가 발생하 [followup] | [followup_answer] | [scores] | [judge_reason] | [source_doc] | # 학습 과정 소개 기본 이벤트 함수의 라이프 사이클과 플레이할 때의 전체 라이프 사이클을 알아봅시다. 라이프 사이클을 이해하면 특정 함수가 언제 불리는지 예상할 수 있고, 전체 월드의 동작을 고려하며 제작할 수 있습니다. # 기본 이벤트 함수의 라이프 사이클 월드에 필요한 로직을 만들기 위해서는 컴포넌트 스크립트를 만들어야만 합니다. 필요한 컴포넌트 스크립트를 만들 때 호출되는 시점을 예상해 의도한 로직에 맞게 동작할 수 있도록 작성해야 합니다. 라이프 사이클의 개념을 익혀두면 전체 흐름을 파악할 수 있기에 스크립트를 작성
[task] | code [pass] | ⏳ 미판정 [title] | 스크립트 라이프 사이클 [question] | LifeCycle 컴포넌트를 생성하여 OnInitialize, OnBeginPlay, OnMapEnter, OnMapLeave, OnEndPlay, OnDestroy 함수에 각각 "함수 이름 실행" 로그를 출력하는 스크립트를 작성해줘 [answer] | 제공된 참고 문서에는 `OnInitialize`, `OnBeginPlay`, `OnMapEnter`, `OnMapLeave`, `OnEndPlay`, `OnDestroy` 함수가 기본 이벤트 함수임을 명시하고 있으며, 각 함수 실행 시 로그를 출력하는 예시(`log("함수 이름 실행")`)를 제시하고 있습니다. 요청하신 LifeCycle 컴포넌트 스크립트는 다음과 같습니다. ```lua Method: [server only] void OnInitialize() { log("OnInitialize 실행") } [serve [followup] | [followup_answer] | [scores] | [judge_reason] | [source_doc] | # 학습 과정 소개 기본 이벤트 함수의 라이프 사이클과 플레이할 때의 전체 라이프 사이클을 알아봅시다. 라이프 사이클을 이해하면 특정 함수가 언제 불리는지 예상할 수 있고, 전체 월드의 동작을 고려하며 제작할 수 있습니다. # 기본 이벤트 함수의 라이프 사이클 월드에 필요한 로직을 만들기 위해서는 컴포넌트 스크립트를 만들어야만 합니다. 필요한 컴포넌트 스크립트를 만들 때 호출되는 시점을 예상해 의도한 로직에 맞게 동작할 수 있도록 작성해야 합니다. 라이프 사이클의 개념을 익혀두면 전체 흐름을 파악할 수 있기에 스크립트를 작성
[task] | single_turn [pass] | ⏳ 미판정 [title] | 공동 제작 [question] | LocalWorkspace 방식과 Cooperation 방식 중 어느 쪽을 선택해야 하는지, 월드 규모나 작업자 수 기준이 구체적으로 어떻게 다른가요? [answer] | 제공된 문서에는 두 방식의 선택 기준에 대한 **정량적인 수치(구체적인 월드 크기 평방미터, 정확한 작업자 인원수 등)가 명시되어 있지 않습니다.** 다만, 문서에서 제시하는 선택 기준은 다음과 같은 **질적(qualitative) 조건**에 기반합니다. **1. LocalWorkspace 방식 선택 기준** * **월드 규모:** 월드의 크기가 **크는 경우** * **작업자 규모:** 작업자의 수가 **많은 경우** * **작업 방식:** 외부에서 스크립트를 작성한 후, 다시 메이플스토리 월드로 동기화(Sync)시 [followup] | [followup_answer] | [scores] | [judge_reason] | [source_doc] | # 학습 과정 소개 다양한 사람들이 함께 모여 월드를 제작할 수 있는 방법에 대해 알아봅시다. ##### 참고 가이드 * [그룹 생성과 멤버 관리](/docs/?postId=1325"target":"_self"}) * [공동 제작 그룹 멤버의 등급과 권한](/docs/?postId=1077) * [LocalWorkspace](/docs/?postId=1165) * [ExtendedScriptFormat](/docs/?postId=1166) # 공동 제작 함께 월드를 제작하기 위해서는 우선 그룹을 형성하고, 멤버 권한을 설정해
[task] | two_turn [pass] | ⏳ 미판정 [title] | 스크립트 라이프 사이클 [question] | 제작 중인 월드에서 `EntityService`를 사용하여 다른 맵의 엔티티에 접근하거나 포탈로 이동할 때 맵 로드 방식은 어떻게 변화하나요? [answer] | 제작 중인 월드에서 기본 맵 로드 방식은 **편집 중인 맵만** 불러오는 것입니다. 이는 출시된 월드에서 서버가 시작 시 모든 맵을 로드하는 것과 가장 큰 차이점입니다. 하지만 다음과 같은 두 가지 경우 중 하나가 발생하면, 해당 다른 맵도 즉시 로드됩니다. 1. **EntityService 사용:** `EntityService` API를 사용하여 다른 맵에 있는 엔티티를 직접 조회하거나 접근할 경우. 2. **포탈 이동:** 플레이어가 포탈을 통해 다른 맵으로 이동하는 경우. 즉, 초기에는 편집 중인 맵만 로드되지만, 스 [followup] | 출시된 월드에서는 불가능한 이런 동적 맵 접근이 제작 중 월드에서만 가능한 이유와, 이로 인해 발생할 수 있는 동작 오류를 방지하기 위한 코딩 관점은 무엇인가요? [followup_answer] | 출시된 월드에서는 서버가 시작 시점에 이미 모든 맵을 로드해 두기 때문에, 특정 맵을 "동적으로" 로드할 필요가 없으며 실제로도 그러한 동작이 발생하지 않습니다. 반면, 제작 중인 월드에서는 초기에는 편집 중인 맵만 로드되므로, 다른 맵의 엔티티에 접근하거나 이동할 때만 해당 맵이 필요에 따라 로드되는 구조입니다. 이러한 차이를 인지하지 못하고 코드를 작성하면, 제작 중인 월드에서는 정상적으로 동작하지만 출시된 월드에서는 의도하지 않은 결과가 나올 수 있습니다. 예를 들어, 제작 중 테스트 시 `EntityService`로 다른 [scores] | [judge_reason] | [source_doc] | 서버와 클라이언트가 호출되는 전체 흐름을 알아봅시다. 플레이 라이프 사이클은 **제작 중인 월드**와 **출시된 월드**에서 약간의 차이가 있습니다. 가장 큰 차이점은 맵을 불러오는 방식입니다. * **제작 중인 월드**에서 플레이할 때는 10개의 맵을 만들었더라도 플레이어가 있는 맵만 불러옵니다. * **출시된 월드**에서는 플레이어 유무와 상관없이 모든 맵을 불러옵니다. 이와 같은 차이를 알고 있다면 **제작 중인 월드** 또는 **출시된 월드**에서 크리에이터 의도대로 동작하지 않는 무언가가 있을 때, 그 원인이 잘못된
[task] | single_turn [pass] | ⏳ 미판정 [title] | 스크립트 라이프 사이클 [question] | 편집용 엔티티의 OnBeginPlay나 OnUpdate가 호출되지 않는다고 하는데, 렌더링이 필요한 컴포넌트만 예외라고 설명되어 있는 구체적인 기준이 무엇인지 궁금합니다. [answer] | 제시된 문서에는 렌더링이 필요한 컴포넌트로서 `OnUpdate`가 호출되는 구체적인 기준이나 목록이 명시되어 있지 않습니다. 문서에는 "편집용 엔티티는 `OnBeginPlay` `OnUpdate` `OnEndPlay`가 호출되지 않지만, 렌더링이 필요한 컴포넌트는 예외로 `OnUpdate`가 호출된다"는 사실만 언급되어 있을 뿐, 어떤 종류의 컴포넌트가 해당되는지에 대한 세부 정보는 제공되지 않습니다. [followup] | [followup_answer] | [scores] | [judge_reason] | [source_doc] | 서버와 클라이언트가 호출되는 전체 흐름을 알아봅시다. 플레이 라이프 사이클은 **제작 중인 월드**와 **출시된 월드**에서 약간의 차이가 있습니다. 가장 큰 차이점은 맵을 불러오는 방식입니다. * **제작 중인 월드**에서 플레이할 때는 10개의 맵을 만들었더라도 플레이어가 있는 맵만 불러옵니다. * **출시된 월드**에서는 플레이어 유무와 상관없이 모든 맵을 불러옵니다. 이와 같은 차이를 알고 있다면 **제작 중인 월드** 또는 **출시된 월드**에서 크리에이터 의도대로 동작하지 않는 무언가가 있을 때, 그 원인이 잘못된
[task] | two_turn [pass] | ⏳ 미판정 [title] | 월드 숍 서비스 활용하기 [question] | 유료화 월드 숍 서비스에서 상품을 구매한 유저에게 포션 아이템과 Pass 이용권을 어떻게 반영하는지 전체적인 프로세스를 설명해 주세요. [answer] | 유료화 월드 숍 서비스에서 상품을 구매한 유저에게 포션 아이템과 Pass 이용권을 반영하는 전체 프로세스는 다음과 같습니다. ### 1. 컴포넌트 설정 및 프로퍼티 정의 먼저 **PlayerReward** 컴포넌트를 생성하여 **DefaultPlayer**에 추가합니다. 이 컴포넌트에는 UI 텍스트를 업데이트하기 위한 `TextComponent` 참조와, 서버와 클라이언트 간에 동기화될 상태 값인 `Potion`(포션 수량)과 `HasPass`(이용권 보유 여부) 프로퍼티를 정의합니다. ```lua Property: [None] [followup] | 4번 단계 코드에서 `PassCheck` 메서드가 `[client]`로 지정되어 있는데, `OnBeginPlay`에서 호출될 때 `_WorldShopService:UserHasPassAndWait`가 정상적으로 작동하는지 그리고 `self.Entity.Name` 사용이 올바른지 확인해 주세요. [followup_answer] | 제시된 참고 문서를 근거로 `PassCheck` 메서드와 `OnBeginPlay`의 동작 방식 및 `self.Entity.Name` 사용에 대해 분석한 결과는 다음과 같습니다. ### 1. `PassCheck` 메서드의 실행 공간과 `_WorldShopService:UserHasPassAndWait` 작동 여부 참고 문서의 4번 단계 코드에서는 `PassCheck` 메서드가 **`[client]`**로 지정되어 있습니다. ```lua [client] void PassCheck() { if self.Entity ~= _U [scores] | [judge_reason] | [source_doc] | 상품이 구매한 유저에게 반영될 수 있도록 만들어 봅시다. 1. 새로운 **PlayerReward** 컴포넌트를 생성하고, **DefaultPlayer**에 추가합니다. 2. 아래와 같이 프로퍼티를 추가합니다. ```lua Property: [None] TextComponent PotionValue = /ui/DefaultGroup/MyPotionInfo/PotionValue [Sync] number Potion= 0 [None] TextCompone
[task] | single_turn [pass] | ⏳ 미판정 [title] | 카드 섞기, 선택하기 [question] | CardBoard 컴포넌트에서 선택된 카드를 추적하기 위해 추가해야 하는 프로퍼티의 이름과 타입은 무엇인가요? [answer] | CardBoard 컴포넌트에서 선택된 카드를 추적하기 위해 추가해야 하는 프로퍼티는 다음과 같습니다. * **이름:** `SelectedCard` * **타입:** `Card` (Component 타입으로 지정) 관련 코드 예시는 다음과 같습니다. ```lua Property: [None] Card SelectedCard = nil ``` [followup] | [followup_answer] | [scores] | [judge_reason] | [source_doc] | 1. **CardBoard** 컴포넌트에서 새로운 프로퍼티를 추가하고 프로퍼티 타입을 **Component**로 지정합니다. ```lua Property: [None] Card SelectedCard = nil ``` 2. CardBoard 컴포넌트에서 `SelctCard` 함수를 찾습니다. 매개 변수를 추가하고 타입을 Component로 변경합니다. Component를 **Card**로 지정합니다. ```lua [client only] void SelectCard (C
[task] | instruction_following [pass] | ⏳ 미판정 [title] | 카드 섞기, 선택하기 [question] | SelectCard와 DeselectCard 메서드에서 self.SelectedCard 상태 변경 및 Card 컴포넌트 메서드 호출 순서를 표로 정리해서 작성하세요. [answer] | 제공된 코드 기준으로 `SelectCard`와 `DeselectCard` 메서드 내의 상태 변경 및 메서드 호출 순서를 정리하면 다음과 같습니다. | 순서 | 메서드 | 동작 내용 | 관련 코드 | | :--- | :--- | :--- | :--- | | 1 | `SelectCard` | `self.SelectedCard` 프로퍼티에 전달된 `card` 인자 할당 | `self.SelectedCard = card` | | 2 | `SelectCard` | `Card` 컴포넌트의 `CardOn()` 메서드 호출 (카드 활성화 색상 [followup] | [followup_answer] | [scores] | [judge_reason] | [source_doc] | ```lua Property: [None] Entity CardSpawnRoot = /ui/CardParirGameUi/UI_Board/UI_Blocks/UI_Block_Group [None] Card SelectedCard = nil Method: [client only] Void SetCards() { local deckTable = {} local cardTable = {} local deckCount = _DataService:GetRowCount("CardSet")
[task] | code [pass] | ⏳ 미판정 [title] | 배지 서비스 활용하기 [question] | BadgeSlot 컴포넌트의 BadgeId 프로퍼티를 기반으로 _BadgeService:GetBadgeInfoAsync()와 _BadgeService:UserHasBadgeAndWait()를 호출하여 배지 이름, 설명, 소유 여부를 TextComponent에 갱신하는 스크립트를 작성해줘 [answer] | BadgeSlot 컴포넌트에서 `BadgeId` 프로퍼티를 기반으로 배지 정보를 조회하고, 결과를 UI의 TextComponent에 표시하는 스크립트입니다. 1. **Property**: 조회할 배지 ID와 표시할 텍스트 컴포넌트(TextComponent) 참조를 정의합니다. 2. **Method**: * `OnBeginPlay()`: 실행 시 자식 엔티티의 TextComponent를 참조로 가져오고, 초기 배지 정보를 확인합니다. 또한 배지 상태를 다시 확인하기 위한 이벤트 연결을 설정합니다. * `Ba [followup] | [followup_answer] | [scores] | [judge_reason] | [source_doc] | 1. 새로운 **BadgeSlot 컴포넌트**를 생성하고 **BadgeSlot_01**에 추가합니다. 2. 획득한 배지의 이름, 소유 정보, 설명을 가져올 수 있도록 프로퍼티를 추가합니다. ```lua Property: [None] string BadgeId = "" -- 조회할 배지 ID [None] TextComponent BadgeTitle = nil -- 배지 이름 [None] TextComponent Hasbadge = nil -- 배지 소유 정보 [Non
[task] | code [pass] | ⏳ 미판정 [title] | 스크립트 라이프 사이클 [question] | 클라이언트에서 `OnUpdate` 함수를 통해 매 프레임마다 `Vector3` 타입의 위치 데이터를 갱신하고, 이 값을 `[Sync]` 프로퍼티에 반영하여 서버와 동기화하는 스크립트를 작성해줘 [answer] | mLua에서 `[Sync]` 프로퍼티는 서버에서 값을 변경하면 클라이언트로 동기화되는 방식이며, 클라이언트가 `[Sync]` 프로퍼티를 직접 수정하여 서버로 동기화하는 기능은 제공되지 않습니다. 따라서 클라이언트의 `OnUpdate`에서 `[Sync]` 프로퍼티를 수정하는 코드는 서버에 반영되지 않습니다. 참고 문서 및 mLua 규칙에 따르면, 클라이언트에서 서버로 데이터를 전달하기 위해 `[Sync]` 프로퍼티를 사용하는 것은 불가능합니다. 클라이언트의 로컬 상태를 서버와 동기화해야 한다면 `[Sync]` 프로퍼티 대신 서버로 [followup] | [followup_answer] | [scores] | [judge_reason] | [source_doc] | 서버와 클라이언트가 호출되는 전체 흐름을 알아봅시다. 플레이 라이프 사이클은 **제작 중인 월드**와 **출시된 월드**에서 약간의 차이가 있습니다. 가장 큰 차이점은 맵을 불러오는 방식입니다. * **제작 중인 월드**에서 플레이할 때는 10개의 맵을 만들었더라도 플레이어가 있는 맵만 불러옵니다. * **출시된 월드**에서는 플레이어 유무와 상관없이 모든 맵을 불러옵니다. 이와 같은 차이를 알고 있다면 **제작 중인 월드** 또는 **출시된 월드**에서 크리에이터 의도대로 동작하지 않는 무언가가 있을 때, 그 원인이 잘못된
[task] | instruction_following [pass] | ⏳ 미판정 [title] | 카드 섞기, 선택하기 [question] | 카드 짝 맞추기에서 `CardBoard` 컴포넌트의 `SetCards()` 함수 내에서 카드 쌍을 생성하고 섞기 위한 `for` 루프 코드를, 코드 블록으로만 출력하세요. [answer] | ```lua for i = 1, (deckCount / 2) do table.insert(cardTable, deckTable[i]) table.insert(cardTable, deckTable[i]) end for i = 1, #cardTable do local randomIndex = _UtilLogic:RandomIntegerRange(1, #cardTable) local temp = cardTable[i] cardTable[i] = cardTable[randomIndex] cardTable[randomIndex] [followup] | [followup_answer] | [scores] | [judge_reason] | [source_doc] | # 카드 섞기 카드 보여주기에 성공했으니 이번에는 한 쌍의 카드가 나오게 만들어 봅시다. 1. **CardBoard** 컴포넌트의 `SetCards()` 함수에서 세 번째 `for i = 1, deckCount do`를 찾습니다. 처음에는 deckCount의 수만큼 실행했지만, 이번에는 deckCount의 절반만큼만 실행하기 위해 (deckCount / 2)로 변경합니다. 그 절반을 동일하게 두 번 불러와 쌍을 이루는 판을 만듭니다. `table.insert`는 [table](/apiReference/Lua/table) 레
[task] | instruction_following [pass] | ⏳ 미판정 [title] | 카드 섞기, 선택하기 [question] | CreateCardEntities 함수에서 카드 생성 시 _SpawnService:SpawnByModelId 호출 인자 구성과 스프라이트 설정 과정을 코드만 출력하고 설명은 주석으로 작성하세요. [answer] | ```lua Property: [None] Entity CardSpawnRoot = /ui/CardParirGameUi/UI_Board/UI_Blocks/UI_Block_Group Method: [client only] void CreateCardEntities(table cardTable) { -- 카드 모델 ID를 문자열 상수로 정의 local cardModelId = "Model_Card EntryID" -- 테이블의 길이(카드 총 개수)를 조회 local cardCount = #cardTable [followup] | [followup_answer] | [scores] | [judge_reason] | [source_doc] | ```lua Property: [None] Entity CardSpawnRoot = /ui/CardParirGameUi/UI_Board/UI_Blocks/UI_Block_Group [None] Card SelectedCard = nil Method: [client only] Void SetCards() { local deckTable = {} local cardTable = {} local deckCount = _DataService:GetRowCount("CardSet")
[task] | instruction_following [pass] | ⏳ 미판정 [title] | 카드 섞기, 선택하기 [question] | `Card` 컴포넌트에서 `ButtonClickEvent`를 처리하여 `CardPairGameLogic`의 `OnCardClicked()`를 호출하는 이벤트 핸들러 코드를, 조건문 포함으로 코드만 출력하고 설명은 주석으로 작성하세요. [answer] | ```lua Event Handler: [self] HandleButtonClickEvent (ButtonClickEvent event) { -- Parameters local Entity = event.Entity -------------------------------------------------------- -- 카드가 보이지 않는 상태라면 처리를 중단합니다. if self.Entity.Visible == false then return end -- 카드가 [followup] | [followup_answer] | [scores] | [judge_reason] | [source_doc] | # 카드 섞기 카드 보여주기에 성공했으니 이번에는 한 쌍의 카드가 나오게 만들어 봅시다. 1. **CardBoard** 컴포넌트의 `SetCards()` 함수에서 세 번째 `for i = 1, deckCount do`를 찾습니다. 처음에는 deckCount의 수만큼 실행했지만, 이번에는 deckCount의 절반만큼만 실행하기 위해 (deckCount / 2)로 변경합니다. 그 절반을 동일하게 두 번 불러와 쌍을 이루는 판을 만듭니다. `table.insert`는 [table](/apiReference/Lua/table) 레
[task] | two_turn [pass] | ⏳ 미판정 [title] | 스크립트 라이프 사이클 [question] | 제작 중인 월드에서 테스트 플레이를 실행하면 편집용 엔티티와 테스트 플레이용 엔티티의 생명주기 처리가 어떻게 달라집니까? [answer] | 제작 중인 월드에서 테스트 플레이를 실행하면 편집용 엔티티와 테스트 플레이용 엔티티의 생명주기 처리는 다음과 같이 달라집니다. **1. 편집용 엔티티 (클라이언트 편집용 월드)** * 테스트 플레이 실행 시 편집용 월드가 비활성화됩니다. * 편집용 엔티티의 `OnBeginPlay`, `OnUpdate`, `OnEndPlay` 함수는 **호출되지 않습니다**. * 예외: 렌더링이 필요한 컴포넌트의 경우 `OnUpdate`만 호출됩니다. **2. 테스트 플레이용 엔티티 (로컬 서버 및 클라이언트)** * 편집용 월드가 [followup] | 편집용 엔티티에서 `OnUpdate`가 호출되지 않는 일반 컴포넌트와 렌더링이 필요한 컴포넌트의 차이를 구체적으로 설명해 주세요. [followup_answer] | 제작 중인 월드에서 편집용 엔티티의 생명주기 호출 여부는 컴포넌트의 렌더링 필요성에 따라 다음과 같이 구분됩니다. **1. 렌더링이 필요하지 않은 일반 컴포넌트** * `OnBeginPlay`, `OnUpdate`, `OnEndPlay` 함수가 모두 **호출되지 않습니다**. * 테스트 플레이를 실행하여 편집용 월드가 비활성화되면 해당 컴포넌트의 로직이 완전히 정지된 상태로 유지됩니다. **2. 렌더링이 필요한 컴포넌트** * `OnBeginPlay`와 `OnEndPlay`는 **호출되지 않습니다**. * 예외적으 [scores] | [judge_reason] | [source_doc] | 서버와 클라이언트가 호출되는 전체 흐름을 알아봅시다. 플레이 라이프 사이클은 **제작 중인 월드**와 **출시된 월드**에서 약간의 차이가 있습니다. 가장 큰 차이점은 맵을 불러오는 방식입니다. * **제작 중인 월드**에서 플레이할 때는 10개의 맵을 만들었더라도 플레이어가 있는 맵만 불러옵니다. * **출시된 월드**에서는 플레이어 유무와 상관없이 모든 맵을 불러옵니다. 이와 같은 차이를 알고 있다면 **제작 중인 월드** 또는 **출시된 월드**에서 크리에이터 의도대로 동작하지 않는 무언가가 있을 때, 그 원인이 잘못된