마인크래프트 BE 도구 품질 시스템을 구현하기 전에 무엇을 확인해야 할까?

 

앞선 글까지 마인크래프트 BE 도구 품질 시스템의 기본 기획을 정리했습니다.

같은 도구라도 제작할 때 품질이 달라지고, 그 품질에 따라 결함이나 장점이 생기며 같은 품질 안에서도

서로 다른 결과가 나올 수 있도록 규칙을 만들었습니다.

 

하지만 어떤 시스템을 만들고 싶은지가 정해졌다고 해서 바로 구현할 수 있는 것은 아닙니다.

 

특히 마인크래프트 BE 애드온은 게임에서 제공하는 기능 안에서 만들어야 하기 때문에, 기획한 내용을 실제로 어떤 방식으로 구현할 수 있는지 먼저 확인할 필요가 있었습니다.

 

그래서 이번에는 바로 코드 작업을 시작하기보다 기획 내용을 구현 담당 AI에게 넘기기 위한 인수인계 문서를 만들고, 구현 전에 확인해야 할 부분을 정리하는 단계로 넘어갔습니다.

 

품질 등장 확률과 재료별 수치 범위를 정한 과정은 이전 글에서 정리했습니다.

 

마인크래프트 BE 도구의 품질은 어떤 확률로 정해지게 하면 좋을까?

 

기획과 구현 사이에 인수인계 문서를 만들었다

이번 작업에서는 처음부터 하나의 대화에서 기획과 구현을 모두 진행하지 않았습니다.

품질의 의미와 등급, 결함과 장점, 등장 확률처럼 시스템의 규칙을 먼저 정한 뒤 실제 구현은 별도의 단계로 넘기는 방식으로 진행했습니다.

 

문제는 대화를 나눈 AI가 바뀌면 이전에 어떤 기준으로 기획했는지를 다시 설명해야 한다는 점입니다.

 

도구마다 랜덤한 품질이 생기는 애드온을 만들어줘.

 

 

 

위처럼 전달하면 구현 담당이 세부 규칙을 다시 추측해야 할 수도 있습니다.

 

 

그래서 지금까지 정한 내용을 하나의 인수인계 문서로 정리했습니다.

품질이 무엇을 의미하는지부터 시작해서 어떤 도구에 어떤 특징이 붙을 수 있는지, 제작할 때 무엇을 랜덤으로 결정해야 하는지,

플레이어에게 결과를 어떻게 보여줄 것인지까지 이어서 볼 수 있도록 정리한 것입니다.

 

기획 담당에서 이미 결정한 내용을 구현 담당이 다시 해석하거나 추측하지 않도록 하는 것이
인수인계의 가장 중요한 목적이었습니다.

 

 

 

구현 전에 반드시 유지해야 할 부분을 구분했다

기획한 모든 요소가 똑같이 중요한 것은 아니었습니다.

 

이번 품질 시스템에서 반드시 유지하고 싶은 핵심은 같은 도구라도 제작 결과가 달라진다는 점입니다.

 

예를 들어 같은 철 검이라도 하나는 무딘 철 검이 될 수 있고, 다른 하나는 가벼운 철 검이 될 수 있습니다.

그리고 플레이어가 아이템을 확인했을 때

품질: 조잡
공격력 -2
이동 속도 -3%

 

처럼 실제 제작 결과를 알 수 있어야 합니다.

 

반면 Tooltip의 테두리 모양이나 배경 디자인처럼 시각적인 부분은 상황이 조금 다릅니다.

기획할 때 생각한 모습과 완전히 똑같이 구현할 수 있다면 좋지만, Bedrock Edition의 제한 때문에 어렵다면

다른 표현 방식으로 바꿔야 할 수도 있습니다.

 

즉 반드시 유지해야 하는 시스템의 핵심과 구현 환경에 따라 변경할 수 있는 표현 부분을 구분해두는 것이 필요했습니다.

 

 

 

가장 먼저 확인할 것은 아이템마다 다른 정보를 유지할 수 있는지였다

품질 시스템이 실제로 작동하려면 같은 종류의 아이템이라도 서로 다른 정보를 가져야 합니다.

 

 

철 검 두 자루를 만들었을 때 하나가 조잡이고 다른 하나가 견고라면 각각의 품질과 특징이 따로 유지되어야 합니다.

그래서 구현 단계에서 우선 확인해야 할 항목을 정리했습니다.

 

제작 직후 각 ItemStack에 랜덤으로 결정된 품질과 특징을 기록할 수 있는지, 개별 아이템의 이름과 Lore를 변경할 수 있는지, 그리고 그 정보가 아이템을 보관하거나 이동한 뒤에도 유지되는지를 확인해야 합니다.

 

이 부분이 가능해야 단순히 철 검 전체에 같은 효과를 적용하는 것이 아니라 각각의 제작 결과를 가진 도구를 만들 수 있습니다.

 

 

아이템 이름과 Lore에서 어디까지 표현할 수 있는지도 중요했다

품질 시스템에서는 플레이어에게 정보를 어떻게 보여줄지도 중요합니다.

이름에는 여러 특징을 전부 넣지 않고 대표적인 특징 하나만 보여주는 방향으로 기획했습니다.

예를 들어 여러 효과가 동시에 적용되어도 이름은

 

 

무딘 철 검

처럼 짧게 유지합니다.

대신 자세한 정보는 Lore에서 확인할 수 있도록 합니다.

품질: 조잡
공격력 -2
이동 속도 -3%

 

 

높은 품질도 같은 방식입니다.

 

가벼운 네더라이트 검

품질: 극상
이동 속도 +10%
공격력 +3
공격 사거리 +0.5

 

이런 구조라면 아이템 이름을 지나치게 길게 만들지 않으면서도 플레이어가 실제 적용된 효과를 확인할 수 있습니다.

그래서 구현 담당에게도 개별 ItemStack의 이름과 Lore를 변경할 수 있는지, 여러 줄의 정보를 표시할 수 있는지 등을 확인하도록 정리했습니다.

 

 

 

Tooltip 디자인은 반드시 그대로 구현해야 하는 요소는 아니었다

아이템 정보를 조금 더 보기 좋게 만들기 위해 별도의 Tooltip 참고 시안도 만들었습니다.

구현 전 참고용으로 만든 Tooltip 시안

 

 

아이템 이름을 가장 위에 표시하고, 품질과 실제 능력치 변화를 구분해서 보여주는 형태였습니다.

품질에 따라 색을 다르게 사용하거나 이득과 불이익을 색상으로 구분하고, 필요한 경우 구분선이나 여백을 넣는 방식도 생각했습니다.

 

다만 참고 이미지를 만든 목적은 그 UI를 그대로 복제하는 것이 아니었습니다.

 

이번 품질 시스템에서 더 중요한 것은 화려한 Tooltip보다 플레이어가 제작 결과를
빠르게 이해할 수 있는 정보 구조였습니다.

 

 

 

만약 Tooltip 배경이나 내부 배치를 원하는 수준까지 바꾸기 어렵더라도 아이템 이름과 Lore를 이용해 핵심 정보를 제대로 전달할 수 있다면 시스템 자체는 유지할 수 있습니다.

 

그래서 UI 디자인과 정보 전달을 같은 문제로 보지 않고 따로 판단하도록 했습니다.

 

 

 

구현 방법도 한 가지로 정하지 않고 확인하기로 했다

Tooltip과 아이템 정보를 표현하는 방법도 처음부터 하나로 단정하지 않았습니다.

일반적인 Behavior Pack과 Script API에서 처리할 수 있는 부분이 어디까지인지 확인하고, Resource Pack을 이용하면 Tooltip의 외형을 더 수정할 수 있는지도 따로 검토할 필요가 있었습니다.

 

기본 Tooltip만으로 원하는 표현이 어렵다면 별도의 UI를 사용하는 방법도 생각해볼 수 있습니다.

 

하지만 별도 UI 역시 실제 플레이에서는 문제가 생길 수 있습니다.

아이템을 선택할 때 바로 정보를 갱신할 수 있는지, 기본 Tooltip과 동시에 표시되어 화면이 복잡해지지는 않는지 등을 함께 고려해야 합니다.

 

처음부터 한 가지 방법으로 구현할 수 있다고 단정하기보다,
여러 방법을 비교한 뒤 가장 자연스럽고 안정적인 방법을 선택하는 것을 구현 단계의 목표로 잡았습니다.

 

 

 

구현이 어려운 부분은 대안을 찾도록 했다

애드온을 만들다 보면 처음 생각했던 기능을 그대로 구현하기 어려운 경우도 있습니다.

이때 단순히 불가능하다는 답만 받으면 기획을 실제 결과물로 이어가기 어렵습니다.

 

그래서 구현 담당에게 어떤 기능이 어렵다면 왜 어려운지뿐 아니라 가장 비슷하게 만들 수 있는 방법도 함께 검토하도록 했습니다.

 

예를 들어 원하는 Tooltip 디자인을 완전히 구현할 수 없다면 기본 Tooltip과 Lore를 활용할 수 있는지, 별도의 UI가 필요한지, Resource Pack이나 Script API가 추가로 필요한지 등을 비교하는 방식입니다.

 

이렇게 하면 기획을 그대로 복제하는 것에만 매달리지 않고 원래 만들고 싶었던 기능의 목적을 유지하면서 현실적인 구현 방법을 찾을 수 있습니다.

 

 

 

기획을 구현 담당에게 넘기면서 알게 된 점

이번 작업에서 기획과 구현 사이에 인수인계 단계를 둔 이유는 단순히 대화를 정리하기 위해서만은 아니었습니다.

앞부분에서 시스템 자체의 핵심과 바꿀 수 있는 표현 요소를 구분했다면, 실제로 AI에게 넘길 때는 이미 확정된 내용과 앞으로 확인해야 하는 내용을 구분해서 전달하는 것도 중요했습니다.

 

예를 들어 품질의 의미와 제작 규칙은 이미 정해진 내용이기 때문에 구현 담당이 임의로 다시 결정할 필요가 없습니다.

반면 Tooltip을 어느 수준까지 수정할 수 있는지, 각 ItemStack의 정보를 어떤 방식으로 저장할지처럼 구현 환경에 영향을 받는 부분은 실제 가능성을 확인해야 합니다.

 

이 둘을 구분하지 않고 지금까지 나눈 대화를 그대로 넘기면 어떤 내용이 확정된 것인지, 어떤 내용이 아직 검토 중인지 다시 판단해야 할 수 있습니다.

이미 결정된 내용은 다시 고민하지 않게 하고, 아직 결정되지 않은 부분에 구현 담당의 판단을 집중시키는 방식이
이번 작업에서는 잘 맞았습니다.

 

 

AI에게 긴 작업을 맡길 때도 모든 대화 내용을 그대로 이어가는 것보다 확정된 기준과 다음 단계에서 해결해야 할 문제를 따로 정리해서 전달하는 것이 맥락을 유지하는 데 도움이 됐습니다.

 

기획 내용을 구현 담당에게 전달한 뒤, 피드백을 바탕으로 부족한 부분을 다시 구체화하고 보완하는 방식으로 작업을 이어가고 있습니다.

 

 

 

이제 실제 구현 가능성을 확인할 차례

여기까지 진행하면서 품질 시스템의 핵심 기획을 구현 단계로 넘기기 위한 준비가 끝났습니다.

다음으로는 실제 마인크래프트 BE 환경에서 기획한 기능들이 어디까지 가능한지를 하나씩 확인해야 합니다.

 

개별 ItemStack에 품질 정보를 어떻게 유지할지, 제작된 도구를 어느 시점에 감지할지, 이름과 Lore를 어떻게 변경할지, 공격력이나 이동 속도 같은 실제 효과는 어떤 방식으로 적용할지 등을 확인해야 합니다.

 

이번 글이 기획과 구현 사이에서 무엇을 확인해야 하는지를 정리한 단계였다면, 다음 글부터는 실제 구현 가능성을 검토하면서 가능한 부분과 어려운 부분을 구분해보려고 합니다.