새로 오신 분들은 길라잡이위키 규칙을 꼭 읽어주세요.

문서 작성번역을 도와주시면 이 위키에 큰 힘이 됩니다.

We would love to get your opinion on your experience with our site with a short survey. Take Survey

베드락 에디션 작성자 지침

Minecraft Wiki
이동: 둘러보기, 검색
Mclogo.svg

여기에 제공된 지침은 "마인크래프트"에 대한 콘텐츠를 만드는 더 나은 경험을 제공하는 모범 사례예요. 그것은 창조물이 작동하고 게임의 변화에 능동적이고 탄력적 이도록 도와줘요.

일반 지침[편집 | 원본 편집]

  • 세계와 팩 디렉토리에서 내용과 관련없는 파일을 제거하세요..
    • 팩 안에 팩이 없거나 Windows 또는 포토샵 파일이 없어요. 이 중 일부는 콘텐츠의 처리, 가져 오기 또는 로드 중 문제를 일으킬 수 있어요.
  • 제출하기 전에 콘텐츠에서 사용되지 않는 리소스를 제거하세요.
    • 이렇게하면 컨텐츠 크기를 최소로 유지하면서 콘텐츠 유효성 검사가 실패 할 가능성을 줄일 수 있어요.
  • 플랫폼에 따라 허용 경로 길이가 달라요. 팩이나 세계의 경로 외에도 플랫폼은 마인크래프트에서 가져온 디렉토리를 계산해요. 이 한도를 초과하면 팩 가져 오기 실패하고 잘못된 상태로 남아 있어요. 이 때문에 다음 사항을 권장해요.
    • 경로 길이를 70 자 이하로 유지하세요. 즉, 패키지 또는 세계 템플릿의 루트에서 파일까지 가장 긴 경로는 70 자 여야해요.
    • 경로의 각 부분 (디렉토리 또는 파일 이름)은 60 자 미만이어야합니다. 그렇지 않으면 일부 플랫폼에서 해당 부분를 인식하지 못해요.
    • 리소스 또는 행동 팩의 디렉토리 이름은 10 자 미만이어야해요. 이를 통해 제작자는 파일 및 하위 디렉토리의 이름을 더 길게 만들 수 있어요. 예를 들어, bp_mw 는 다음 경로에 있어요.
      • MyWorld/behavior_packs/bp_mw.

정의 파일[편집 | 원본 편집]

  • blocks.json, mobs.json, sound_definitions.json 등의 정의 파일에는 바닐라의 모든 요소에 대한 정의가 포함되요. 팩에는 변경해야하는 요소 및 필드의 변경 사항 만 포함되어야해요. 즉, 모든 바닐라 정의를 복사 / 붙여 넣기를 수행하고 필요로하는 부분 만 수정하지 말고 변경해야하는 부분 만 파일에 포함 시키세요. 게임은 변경 사항을 바닐라와 병합해요.
    • 필요한 것 이상이 포함되어 있고 수정하려는 의도가 아닌 블록이나 군중에서 바닐라 변경이 발생하면 불필요하게 내용이 변경 될 수 있어요.
  • 다음 파일을 덮어 쓰지 마세요. 그것들은 공식적으로 지원되지 않아요. 변경 사항이 계속 작동하거나 앞으로도 계속 작동한다는 보장이 없기 때문이에요.
    • credits/end.txt
    • font/emoticons.json
    • texts/language_names.json
    • items_client.json
    • items_offsets_client.json
    • 쉐이더 디렉토리에있는 것

함수[편집 | 원본 편집]

  • 여러 행동 팩의 함수 파일 간의 충돌을 피하기 위해 하위 디렉토리를 사용하여 네임 스페이스를 만들어요. 함수 경로 (/ functions / 하위 디렉토리에서 시작)가 다른 팩의 함수 경로와 정확하게 일치하면 팩 스택의 맨 위가 다른 함수의 경로를 대체해요.
  • 특정 플랫폼에서 작동하지 않을 가능성을 낮추려면 디렉토리 및 기능 파일의 이름을 지정할 때 소문자를 사용하고 공백을 사용하지 마세요. /functions/awesome_pack/level1_function.mcfuntion.

재귀를주의해서 사용하세요. 지원되는 동안 재귀가 너무 심하면 성능 문제가 발생할 수 있어요.

  • 행동 팩의 매니페스트에 대해 "min_engine_version"으로 개발중인 현재 버전을 입력하세요. 예 : "min_engine_version": [1,8,0].
    • 이렇게하면 이전 버전과의 호환성을 위해 사용할 명령 버전을 제어 할 수 있어요.
  • 명령이 보류 기능 만 차단하면 수정하는 것이 더 쉬워져요. 더 중요한 것은 함수 파일을 포함하는 행동 팩에 대한 업데이트를 게시하면 해당 팩을 사용하는 세계는 새 팩이 적용된 후에 업데이트를 가져와요.

명령어[편집 | 원본 편집]

  • 틱마다 명령을 실행하지 마세요. 특히 중요한 것은 매 틱마다 수십 개의 명령을 실행하진 않아요.
    • 틱당 30 개 이상의 명령을 실행하지 마세요.
    • 명령을 자주 실행해야하는 경우 시계에 넣는 것이 좋아요. 따라서 매 5 초마다 틱을 실행해요.
    • 위와 관련하여 오프셋 클록을 설정하여 명령이 다른 틱에서 실행되도록하면 작업의 균형을 유지하고 성능을 향상시킬 수 있어요.
    • 명령으로 인해 콘텐츠의 성능이 나쁜지 쉽게 알 수있는 방법은 commandblocksenabled [Commands / gamerule|game rule]을 사용하여 모든 명령 블록의 실행을 중지하는 것이에요.
  • 자주 실행하는 명령 (예 : big /clone 또는 /fill)을 사용하지 마세요. 가능한 경우 다른 틱에서 실행되는 둘 이상의 명령에서 이것을 분리하세요.
  • 현지화 된 이름으로 항목을 타겟팅하지 마세요. /testfor @e[name=beacon]
    • 플레이어의 언어가 다른 경우 항목 이름이 변경되고 명령이 작동하지 않아요.

모델[편집 | 원본 편집]

  • 작은 부품이 많은 모델은 로우 엔드 장치 및 일부 GPU에서 성능이 저하 될 수 있어요. 세부 사항과 성능 사이의 올바른 균형을 찾으세요.

소리[편집 | 원본 편집]

  • 장시간 실행되는 사운드만 스트리밍해요 (예 : 배경 음악(BGM).
    • 더 나은 게임 내 성능.
    • 일부 플랫폼은 동시에 열 수있는 제한된 수의 파일을 가지고 있어요. 모든 사운드를 스트리밍하면 콘텐츠가 게임을 충돌하게 만들어요.
  • 짧은 사운드 (예 : 사운드 효과)가 메모리에로드 된 경우 가장 잘 실행 돼요.
  • 간단한 기술을 사용하여 파일을 작게 유지하세요. 소리의 시작과 끝에서 무음 부분을 제거하세요.
  • 소리 정의에 사용할 수있는 플래그가 있어요 : load_on_low_memory. 이 플래그는 기본적으로 false로 설정되어 있어요. 즉, 컴퓨터의 메모리가 부족하면 아무 소리도로드되지 않아요. 특정 사운드를로드하는 것이 절대적으로 필요한 경우이 플래그를 true로 설정하세요. 그것의 사용법에 관하여 잘 알고 있으세요.

UI[편집 | 원본 편집]

  • 모든 UI 수정은 위험해요. 바닐라 화면이 어떤 방식 으로든 수정되면 해당 화면을 사용하는 콘텐츠가 손상 될 수 있어요. UI 시스템은 JSON 파일을 통해 모든 화면을 유연하게 수정할 수있는 방식으로 제작되었어요. 문제가 발생하는 곳은 이러한 수정 사항을 처리하는 방법 때문이에요. 이러한 UI JSON 파일 (사용자 정의 자원 팩)의 모든 변경 사항은 바닐라와 병합돼요. 이러한 변경 사항이 적절하게 병합되지 않으면 게임이 나쁜 상태가 될 수 있어요.
  • UI를 다시 스키닝하는 것, 즉 그것에 사용 된 텍스처를 수정하는 것은 위험한 변화가 적고 훌륭한 광택 요소를 만들 수 있어요.
  • 요소의 크기를 조정하고 이동하는 것이 위험하지만 대부분의 경우 괜찮아요.
  • 화면의 요소를 크게 변경하면 끊킬 위험이 커요.

UI 수정 예제[편집 | 원본 편집]

다음은 화면의 전체 사본을 만들 필요없이 UI 정의 파일을 수정하는 방법에 대한 예제에요. Enchanting Screen 파일 (enchanting_screen_pocket.json)을 기반으로해요.

예제 1 : 제한 변수[편집 | 원본 편집]

수정되지 않은 변수는 포함시키지 마세요. 예 : "color" 그리고 "shadow" 만 변경되는 경우 다른 변수를 복사하거나 붙여 넣지 마세요. 대체 대상 변수를 명시하는 것만으로 간단하게 대상을 변경할 수 있어요.

잘못된 복사/붙여 넣기:

   "generic_label": {
       "type": "label",
       "color": "$pocket_title_text_color",
       "anchor_from": "center",
       "anchor_to": "center",
       "shadow": false
   },

보다 나은 복사/붙여 넣기:

   "generic_label": {
       "color": "$pocket_title_text_color",
       "shadow": false
   },

예제 2 : 상속[편집 | 원본 편집]

상속에서 컨트롤이 수정되는 컨트롤을 다시 설명 할 필요가 없어요. 수정할 이름을 명시하세요. 아래의 코드에서 ""common.button""'은 건너 뛸 수 있어요.

나쁠 때:

   "enchanting_confirm_button@common.button": {

좋을 때:

   "enchanting_confirm_button": {

예제 3 : 자식 수정[편집 | 원본 편집]

예를 들어 같은 버튼을 사용하여 일부 컨트롤의 하위에서 특정 변수를 수정하기 만하면돼요 (예 : default 컨트롤. 컨트롤의 자식 만 수정하려면 {{code} control_name / child_name} 구문을 사용하세요. 이렇게하는 대신에 :

   "enchanting_confirm_button@common.button": {
       "controls": [
       {
           "default@enchanting_pocket.confirm_default_control": {
           "type": "image",
           "texture": "textures/ui/button_borderless_light" //Added fancy button texture to default control
       }
   },

변경:

   "enchanting_confirm_button/default": {
       "texture": "textures/ui/button_borderless_light" //Added fancy button texture to default control     
   },

예제 4 : 배열 수정하기[편집 | 원본 편집]

이 예제는 컨트롤에서 배열을 수정하는 방법을 보여줘요. 예 : 새 컨트롤을 자식으로 추가하거나 컨트롤의 바인딩에서 바인딩을 제거해요. 이를 위해 '"modifications"' 이라는 특수 변수가 있어요. 수정 배열의 각 항목마다 수정할 특정 배열, 수행 할 작업 및 결과를 지정할 수 있어요.

예를 들어 '"enchanting_book_panel"' 을 사용하면 컨트롤을 컨트롤 "controls " '"배열에 추가해야 할 경우 ""array_name": "controls", "operation": "insert_front", and the "value"을 지정하는 수정 항목을 만들 수 있어요. 새로운 컨트롤이 컨트롤 배열에있는 것처럼 처리해요. 다음은 위에 언급 된 내용과 패널의 오프셋을 수정하는 방법을 보여줘요.

"enchanting_book_panel": {
       "offset": [ -4, 1],
       "modifications": [
       {
           "array_name": "controls",
           "operation": "insert_front",
           "value": [
           "panel_outline@beacon_pocket.panel_outline": { "layer": 0 }
           ]
       }
       ]
   }

' ' ""player_level_label "' 자식 컨트롤에서 '"#player_level_color "' '바인딩을 제거하려면 다음을 수행 할 수 있어요.

   "enchanting_book_panel/player_level_label": {
       "offset": [ 0, 10 ],
       "layer": 3,
       "color": "$experience_text_color"
       "modifications": [
       {
           "array_name": "bindings",
           "operation": "remove",
           "where": {
           "binding_name": "#player_level_color"
           }
       }
       ]
   }

세계[편집 | 원본 편집]

[편집 | 원본 편집]

  • 한 번에 수십 개의 개체를 생성하지 마세요. 장치에 따라 동시에 많은 수의 엔터티가있는 경우 성능이 저하 될 수 있어요.

레드스톤[편집 | 원본 편집]

  • 가능하다면 서로 상호 작용하는 레드스톤 구성 요소가 청크 경계를 넘지 않도록 하세요.
    • 게임에서 대부분을 처리 할 수 있지만, 청크로드가 레드스톤 구성 요소가 똑딱 거리면서 상호 작용하여 일부 구성 레드스톤 구성 요소에는 레드스톤 신호를 방출, 전송 또는 사용하는 블록이 포함돼요.
      • 버튼
      • 명령 블럭
      • 비교기
      • 발사기
      • 깔때기
      • 레버
      • 관찰자
      • 피스톤
      • 레일:액티베이터,탐지기,파워
      • 레드스톤 갈고리
      • 레드스톤 탐지기
      • 다른것들

티킹 영역[편집 | 원본 편집]

  • 똑딱 거리는 영역을 과도하게 사용하지 마세요.
    • 이것은 메모리 량이 적은 장치에 중요해요.
  • 가능한 경우 똑딱 거리는 부분을 사용하여 완료되면 언로드하세요.
    • 이렇게하면 장치가 일부 메모리를 회수 할 수있을뿐 아니라 필요한 경우 새로운 똑딱 거리 영역을 생성 할 수 있어요.