마인크래프트 BE 도구 품질 시스템은 처음에 어디까지 구현할 수 있었을까?

 

앞선 글에서는 마인크래프트 BE 도구 품질 시스템의 기획을 구현 담당 AI에게 넘기기 위해 인수인계 문서를 만들고, 실제 구현 전에 어떤 부분을 확인해야 하는지 정리했습니다.

 

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

 

 

 

 

이번에는 그 문서를 실제로 구현 담당에게 전달했습니다.

기획 단계에서 생각한 기능을 그대로 코드로 만들어달라고 하기보다, 먼저 현재 Bedrock Edition에서 가능한 부분과 어려운 부분을 구분하고 그 결과를 바탕으로 실제 애드온을 만들어보는 방식으로 진행했습니다.

 

결과부터 말하면 품질 시스템의 기본 구조는 구현할 수 있었지만, 기획한 모든 요소를 처음부터 그대로 적용할 수 있었던 것은 아니었습니다.

아이템 이름과 Lore처럼 비교적 그대로 구현할 수 있는 부분도 있었고, 공격 사거리나 작업 속도처럼 다른 방식으로 타협해야 하는 부분도 있었습니다.

 

 

구현하기 전에 먼저 가능 여부를 다시 확인했다

인수인계 문서에는 단순히 품질 시스템의 규칙만 적어두지 않았습니다.

아이템마다 서로 다른 이름과 Lore를 가질 수 있는지, 품질에 따라 텍스트 색상을 다르게 표시할 수 있는지, 그리고 기획하면서 만든 Tooltip 시안을 어느 정도까지 구현할 수 있는지도 따로 확인하도록 했습니다.

구현 담당이 내린 1차 결론은 부분 구현 가능이었습니다.

무딘 철 검처럼 아이템마다 다른 이름을 표시하고, Lore에 품질과 실제 능력치 변화를 여러 줄로 적는 정보 구조는 구현할 수 있다고 판단했습니다.

 

반면 처음 구상했던 RPG 스타일의 Tooltip 박스를 완전히 새롭게 만드는 것은 제한이 많았습니다.

 

그래서 UI 자체를 억지로 재현하기보다 이번 시스템에서 가장 중요했던

도구의 특징을 이름으로 먼저 보여주고, 자세한 제작 결과는 Lore에서 확인한다 라는 구조를 우선하기로 했습니다.

 

구현 담당의 1차 검토

 

 

 

처음 구상했던 Tooltip은 단순한 방향으로 타협했다

기획할 때는 아이템 이름과 품질, 특성을 영역별로 구분하고 색상과 구분선까지 사용하는 Tooltip 시안도 만들었습니다.

하지만 실제 구현 단계에서는 이 부분을 과하게 수정하는 것보다 마인크래프트 기본 Tooltip을 활용하는 쪽이 더 현실적이라고 판단했습니다.

예를 들어 조잡한 철 검이 만들어졌다면

 

무딘 철 검

이라는 이름을 붙이고,

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

 

 

 

처럼 Lore에서 실제 결과를 확인할 수 있게 하는 방식입니다.

불이익과 이득은 색상을 다르게 표시하고, 품질 등급에도 색상을 적용하는 정도라면 처음 생각했던 정보 구조를 충분히 유지할 수 있었습니다.

 

처음 만든 시안의 모양을 그대로 재현하는 것보다, 플레이어가 제작 결과를 바로 이해할 수 있게 만드는 것을 우선했습니다.
결국 Tooltip 외형은 단순해졌지만 품질 시스템에서 전달하고 싶었던 정보 자체는 유지하는 방향이 됐습니다.

 

 

 

 

기본 바닐라 도구를 그대로 사용하는 방향으로 구현했다

첫 구현에서 또 하나 중요했던 결정은 도구를 전부 새로운 커스텀 아이템으로 만들지 않는 것이었습니다.

 

철 검이나 다이아몬드 곡괭이 같은 기존 마인크래프트 도구를 그대로 사용하면서, 제작 결과에 따라 이름과 Lore를 추가하는 방식으로 구현했습니다.

 

예를 들어 철 검 하나가 만들어지면 품질을 판정하고, 결과에 따라

 

조잡

평범

견고

정교

극상

 

중 하나를 결정합니다.

그 뒤 조잡이라면 결함을 추첨하고, 견고 이상의 품질이라면 장점을 추첨합니다.

 

그리고 처음 선택된 특징 하나를 이름에 사용하고 나머지 결과는 Lore에 표시하도록 했습니다.

 

즉 기획 단계에서 정했던

 

제작  →  품질 판정  →  특징 결정  →  수치 결정  →  이름 변경  →  Lore 표시

 

라는 흐름을 실제 애드온 구조로 옮기기 시작한 것입니다.

 

 

 

모든 도구를 처음부터 넣지는 못했다

기획에서는 검뿐 아니라 창, 도끼, 곡괭이, 삽, 괭이까지 품질 시스템의 대상으로 생각했습니다.

하지만 첫 구현에서는 창을 제외했습니다.

 

구현 담당에서는 기획에서 말한 창에 정확히 대응하는 바닐라 도구가 없다는 이유로 우선 검, 도끼, 곡괭이, 삽, 괭이부터 적용했습니다.

 

이 부분은 처음부터 억지로 다른 아이템으로 대체하지 않고 이후 별도로 결정하기로 했습니다.

예를 들어 삼지창을 창처럼 사용할 것인지, 아니면 나중에 별도의 아이템으로 추가할 것인지에 따라 시스템 자체가 달라질 수 있기 때문입니다.

 

구현하기 어렵다고 임의로 다른 기능으로 바꾸기보다, 결정이 필요한 부분은 남겨두는 쪽을 선택했습니다.
첫 버전에서는 모든 기능을 넣는 것보다 이미 확정된 도구부터 제대로 작동시키는 것이 더 중요했습니다.

 

 

 

공격력은 적용했지만 다른 능력치는 같은 방식으로 처리할 수 없었다

실제 구현으로 넘어가면서 가장 분명하게 드러난 차이는 능력치였습니다.

 

기획에서는

 

공격력 증가와 감소,
이동 속도 증가와 감소,
작업 속도 증가와 감소,
공격 사거리 증가와 감소

 

 

같은 요소를 같은 품질 시스템 안에서 사용했습니다.

 

하지만 실제 마인크래프트에서는 이 모든 수치를 똑같은 방식으로 처리할 수 없었습니다.

첫 구현에서는 공격력 변화는 실제 전투에 반영하는 방향으로 만들었습니다.

 

반면 이동 속도와 작업 속도는 기획에서 생각한 임의의 퍼센트를 그대로 적용하기 어려워 바닐라 효과의 단계처럼 체감 가능한 몇 단계로 근사하는 방식을 사용했습니다.

 

 

이동 속도와 작업 속도 기획에서 생각했던 정밀한 퍼센트 값을 그대로 적용하지 못했고, 실제 게임에서 사용할 수 있는 효과 단계에 맞춰 비슷한 체감이 나도록 근사했습니다.

 

이 부분에서 기획과 구현의 차이가 처음으로 크게 보였습니다.

기획에서는 이동 속도 +몇 %라고 정하면 끝나지만, 구현에서는 그 수치를 게임 안에서 어떤 방법으로 만들어낼 것인지가 다시 필요했습니다.

 

 

 

공격 사거리는 첫 구현에서 실제 효과를 넣지 못했다

짧은과 긴은 검과 창의 공격 사거리를 바꾸기 위해 만든 특징입니다.

 

하지만 첫 구현에서는 이 부분을 실제 공격 판정에 적용하지 못했습니다.

그래서 우선 Lore에는 사거리 관련 특징을 표시할 수 있도록 두되, 실제 판정 거리를 변경하는 기능은 적용하지 않는 방식으로 남겨두었습니다.

 

이건 품질 시스템의 다른 요소와 비교하면 꽤 큰 차이였습니다.

공격력은 실제 피해량으로 연결할 수 있었지만, 공격 사거리는 같은 방식으로 단순히 숫자만 바꿔서 해결할 수 없었기 때문입니다.

구현 담당에서는 이후 필요하다면 기본 공격 판정을 그대로 사용하는 것이 아니라 별도의 공격 판정을 만드는 우회 방식도 검토할 수 있다고 했습니다.

 

하지만 첫 버전부터 그 부분까지 추가하기보다 일단 품질 시스템의 기본 흐름을 먼저 작동시키는 방향을 선택했습니다.

 

 

 

첫 구현은 품질 시스템의 기본 구조부터 옮기는 단계였다

이렇게 첫 애드온을 만들면서 처음 기획했던 모든 기능이 그대로 들어가지는 않았습니다.

정리하면 첫 구현에서는

 

실제로 적용한 부분

• 바닐라 검·도끼·곡괭이·삽·괭이에 품질 부여
• 제작 또는 획득한 도구에 품질 판정
• 조잡 품질의 결함 추첨
• 견고·정교·극상의 장점 추첨
• 대표 특징을 아이템 이름에 표시
• 품질과 실제 수치를 Lore에 표시
• 공격력 변화 실제 적용

그리고

 

우선 다른 방식으로 처리하거나 남겨둔 부분

• 창
• 정밀한 이동 속도 변화
• 정밀한 작업 속도 변화
• 실제 공격 사거리 변경
• 처음 시안과 같은 완전히 새로운 Tooltip UI

로 나뉘었습니다.

 

 

 

처음에는 기획이 충분히 구체적이면 그대로 완성된 애드온이 나올 것이라고 생각하기 쉽습니다.

하지만 실제로 구현해보니 기획에서 정한 기능을 게임이 허용하는 방식으로 다시 해석하는 과정이 필요했습니다.

 

 

 

구현 담당에게 맡긴 뒤에도 직접 판단할 부분이 남았다

AI가 애드온 파일을 만들어줬다고 해서 작업이 끝나는 것도 아니었습니다.

 

오히려 첫 결과물이 나오면서 새로운 판단이 필요해졌습니다.

 

공격 사거리를 Lore에만 표시해도 괜찮은지,

이동 속도를 단계식으로 근사한 방식이 실제 플레이에서 자연스러운지,

제작뿐 아니라 단순히 획득한 도구에도 품질을 붙일 것인지,

창을 어떤 방식으로 추가할 것인지처럼 구현 결과를 보고 다시 결정해야 하는 문제가 생겼습니다.

 

이런 부분은 AI가 대신 정해주는 것보다 내가 처음 품질 시스템에서 만들고 싶었던 경험과 맞는지를 보고 판단해야 했습니다.

 

구현 담당의 결과는 완성된 정답이라기보다, 실제 게임에서 무엇을 더 수정해야 하는지를
확인할 수 있는 첫 결과물이었습니다.

 

 

기획 담당에서 기준을 만들고, 구현 담당에서 실제 결과물을 만든 뒤 다시 플레이하면서 문제를 찾는 과정이 필요한 이유가 여기서 분명해졌습니다.

 

 

 

이제 실제 플레이에서 확인할 차례였다 

첫 구현에서는 품질 시스템의 핵심 구조를 실제 Bedrock 애드온 형태로 만드는 것까지 진행했습니다.

 

하지만 구현됐다고 설명된 기능이 실제 마인크래프트 안에서도 내가 의도한 대로 동작하는지는 별도로 확인해야 합니다.

 

• 품질이 예상한 확률로 붙는지,
• 이름과 Lore가 제대로 유지되는지,
• 공격력 변화가 실제 전투에서 느껴지는지,
• 이동 속도와 작업 속도의 근사 방식이 자연스러운지

 

그리고 제작 과정에서 이상한 문제가 생기지는 않는지를 직접 확인해야 합니다.

이번 글이 기획을 처음 실제 애드온으로 옮기면서 무엇을 구현했고 어디에서 타협했는지를 정리한 과정이었다면,

 

다음 글에서는 첫 구현판을 실제로 사용하면서 발견한 문제와 그 문제를 다시 AI에게 어떻게 전달했는지를 정리해보려고 합니다.