Tictim과 함께하는 마인크래프트 모딩 101
2. 블럭, 아이템 그리고 모델
※ 이 강좌는 1.10 ~ 1.11버전을 기준으로 작성됩니다.
다시 돌아왔습니다. 틱팀입니다.
이 강좌도 1화처럼 쓰는 데 한세월 걸릴지도 모르겠습니다. 안 그랬으면 좋겠습니다만 말입니다.
1. 아이템
간단한 아이템을 만들어 봅시다. 하나는 평범한 아이템, 하나는 우클릭하면 stdout으로 로그를 출력하는 아이템을 말이죠.
먼저, 아이템을 public static final field의 형태로 보관할 클래스를 만듭니다.
이름은 아무거나 해도 되지만 "Items"는 추천드리지 않습니다. 바닐라에 이미 동명의 클래스가 존재하기 때문에 하나를 임포트하면 다른 하나를 임포트할 수 없게 되는 기묘한 일이 벌어집니다.
저는 메인 패키지에 Contents라는 이름으로 클래스를 자주 만듭니다. 사실 이는 모더마다 많이 다릅니다. 서브 패키지에 클래스를 만든다던지. 어느 쪽이 보편적이냐고 물으시면 제 쪽이 많이 후달리는 느낌?(..)
아무튼, 이 클래스는 인스턴스를 생성할 필요도 상속을 받을 필요도 없으니 final class에 생성자도 private로 해 놓읍시다.
그리고, 이런 형태로 Item 필드를 만들어줍시다. 이 Item이 평범한 첫 번째 아이템이 될 겁니다.
Item [ net.minecraft.item.Item ] 클래스는 이름에서 알 수 있듯이 모든 Item 클래스의 어미 클래스이며, 별 다른 하는 일이 없는 단순한 아이템입니다.
하지만 아이템을 등록하려면 몇 가지 필요사항을 거쳐야 하며, 추가적으로 거치면 좋은(?) 사항들도 있습니다.
setRegistryName(String name) |
필수적인 사항입니다. 마인크래프트에서 아이템에 관한 정보를 관리할 때 쓰입니다. 소문자만으로 지정하는 것이 좋습니다. |
setUnlocalizedName(String name) |
편하게 아이템의 이름을 지정할 수 있는 메소드입니다. [item.***.name] 식으로 표시됩니다. |
setCreativeTab(CreativeTabs tab) |
편하게 크리모드 탭을 지정할 수 있는 메소드입니다. |
이 메소드들은 모두 Item 형태의 자기 자신을 반환합니다. 따라서 저런 사슬 형태의 코드를 통해 한 줄에 한 아이템을 만들고 기본적인 정보까지 맞춰 놓을 수 있습니다.
이제 모드 클래스로 돌아가 봅시다. 저번에 pre-Init, init, post-Init에서 로그를 출력해 봤었죠. pre-Init로 가 봅시다. 비밀결사 어쩌구를 출력했던 곳으로요.
그리고, 이 코드를 추가해 주시면 됩니다.
GameRegistry [ net.minecraftforge.fml.common.registry.GameRegistry ] 에서는 아이템, 블럭, 월드젠, 타일엔티티 등을 게임에 등록시킬 수 있는 클래스입니다. 그리고 register 메소드는 아이템과 블럭을 등록시킵니다. 여기서는 아이템을 등록시키죠.
한 번 런쳐를 실행해 봅시다. 모델을 지정해 주지 않아 와꾸가 빻아 버린 모습입니다만, 어쨌든 아이템은 만들어졌습니다. 이름도 이상합니다. item...뭐? 아무튼.
모델과 이름은 아래에서 만들 예정입니다. 그러면 두 번째 아이템으로 넘어가죠.
특수한 일을 하는 Item의 경우 따로 메소드를 받아 처리해 줘야 합니다. 메소드를 받으려면 메소드를 상속해야 하고, 그러려면 Item을 상속하는 새 클래스를 만들어야겠죠.
일단 클래스를 만들기 이전에, 만들어 뒀던 모드 클래스가 위치하는 패키지 아래에 item이라는 서브 패키지를 만듭시다. 여기에 만드는 모든 Item 클래스를 집어넣으시면 됩니다. 정리가 최고예요.
그리고 그 안에 ItemSecond라는 이름의 클래스를 새로 만듭니다.
Item을 상속하게 해 주세요.
+
이 강좌에 나오는 클래스의 이름은 바꾼다고 해도 작동 여부와 큰 관련은 없긴 합니다. 하지만 그래도 이름을 지을 때 최소한의 규칙은 지켜 주시는 것이 좋습니다. 남한테 좋은 게 아니라 바로 당신에게 좋습니다.
클래스를 상속할 때, 예를 들면 이 Item같은 클래스를 상속할 때는 이름 앞에 부모 클래스의 이름을 붙여 주시는 것이 좋습니다. ItemBucket, ItemSnowball처럼요.
가나다순 정렬로도 이쁘게 나오고, 무엇보다 엄마 아빠 클래스가 누군지 한 눈에 보입니다. ItemAAA와 BlockAAA가 모두 AAA라는 이름이었다고 한다면 누가 블럭이고 누가 아이템인지 어떻게 알아요?
조금 코드를 짜 본 모습입니다.
NOTE 1 - Contents에서 ITEM_FIRST에서 호출했던 세 개의 메소드입니다. 밖에서 호출할 수 있으니 당연히 생성자에서도 호출할 수 있겠죠.
NOTE 2 - 해당 메소드는 아이템을 우클릭했을 때 호출되는 메소드입니다. 여기에 로그를 출력시키는 코드를 넣으면, 우클릭할 때 로그가 나오게 됩니다.
NOTE 3 - 아이템과 월드의 상호작용에 쓰이는 값입니다. 지금은 그냥 넘기셔도 됩니다.
두 번째 아이템도 Contents에 추가해서 인스턴스를 만들어 줍시다. 생성자에서 이미 setRegistryName을 비롯한 3개의 메소드를 호출한 상태이기에 첫 번째와 같이 메소드를 호출하지는 않아도 됩니다.
*
더 정확히 말하자면 호출하지 말아야 합니다. setRegistryName은 두 번 설정하려 하면 오류를 터트립니다.
그리고 두 번째 아이템도 preInit에서 등록해 주세요.
이러면 두 아이템 모두 인게임에서 나오게 됩니다. 들고 우클릭하면 로그도 잘 출력됩니다. 그런데 두 번 호출되네요?
로그가 두 번 호출되는 이유는 클라이언트에서 서버가 하는 일을 따라하기 때문입니다. 로그를 출력하는 걸 따라하는 게 아니라 플레이어가 아이템을 들고 우클릭하는 것을 따라 같은 메소드를 호출하고, 별다른 처리를 안 했기에 같은 줄이 동시에 두 번 호출된 겁니다. 로그를 보시면 하나는 서버 스레드, 하나는 클라이언트 스레드에서 터지고 있죠?
이를 방지하기 위해서는 world#isRemote를 참조하시면 됩니다.
World [ net.minecraft.world.World ] 는 플레이어가 있는 월드입니다. 블럭, 타일엔티티, 엔티티 등등을 가지고 있죠. 그리고 isRemote 필드는 이 월드가 서버를 따라하는 종속된 월드인지 여부를 가지고 있습니다. 즉 true면 클라이언트 월드, false면 서버 월드라고 생각하시면 됩니다.
여기서는 값을 뒤집어서 서버일 때만 로그가 출력되도록 만들었습니다.
정말로 완성입니다. 아이템 끝!
+
1.10 버전에서는 ItemStack(아이템과 스택 수, 대미지값, NBT 등등을 모두 핸들링하는 클래스) 인스턴스의 취급 방법이 약간 다릅니다. ItemStack 자체의 작동 방식도 다르고요. 따라서 1.10에서 해당 코드를 작성한다면..
이렇게 되겠습니다. 함수에 전달되는 인자가 약간 바뀌었습니다. 그 외에는...실수로 SUCCESS를 PASS로 바꿔 버리긴 했지만(...) 이외에 다른 점은 없습니다.
다른 버전에서 개발하실 때면, 앞으로 맞아떨어지는 함수가 없는 사태가 종종 발생하실 겁니다.
그럴 때는 컨트롤+F키를 이용해 이름이 맞는 함수를 대신 상속해서 코드를 짜시면 됩니다.
2. 블럭
블럭 또한 간단하게 만들어 봅시다. 이번에도 하나는 그냥 블럭, 하나는 우클릭하면 로그가 출력되는 블럭으로 말입니다.
편의상 전에 만들어 둔 아이템 담아두는 곳에 블럭 인스턴스를 만들도록 합시다. Block [ net.minecraft.block.Block ] 은 Item과 같이 모든 블럭의 어미 클래스이며, 별 다른 하는 일이 없는 평범한 블럭입니다.
생성자의 인자로 받는 Material [ net.minecraft.block.material.Material ] 은 지도에서 표시되는 색깔부터 시작해서 히트박스 유효 검사, 도구 사용 여부 등등 오만 가지 사항에 쓰이며, Material 클래스에 전부 public static final field의 형태로 존재합니다. 저는 나무로 넣어 주겠습니다.
아이템과 비슷하게 블럭 또한 등록을 위해서는 필요사항을 거쳐야 합니다.
setRegistryName(String name) |
필수적인 사항입니다. 마인크래프트에서 블럭에 관한 정보를 관리할 때 쓰입니다. 소문자만으로 지정하는 것이 좋습니다. |
setUnlocalizedName(String name) |
편하게 블럭의 이름을 지정할 수 있는 메소드입니다. [tile.***.name] 식으로 표시됩니다. |
setCreativeTab(CreativeTabs tab) |
편하게 크리모드 탭을 지정할 수 있는 메소드입니다. |
하는 방법은 아이템과 거의 똑같습니다.
그리고 모드 클래스로 돌아가, 다음 코드를 추가해 줍시다.
GameRegistry의 register(...) 메소드는 앞에서 말씀드렸다시피 블럭 또한 등록할 수 있습니다.
그리고 아래에 ItemBlock [ net.minecraft.item.ItemBlock ] 인스턴스를 생성해서 등록합니다.
ItemBlock은 Item의 하위 클래스로, 블럭을 받는 아이템 클래스입니다. 우클릭하면 블럭을 설치하는 기능을 구현하고 있으며, 기타 여러 가지 일도 해 줍니다.
블럭 인스턴스 자체는 아이템이 아니어서, ItemBlock을 생성해서 넣어 주어야 비로소 아이템 형태의 블럭을 얻을 수 있습니다. 만약 ItemBlock을 생성해서 넣어 주지 않는다면 그 블럭은 아이템을 얻을 수 없게 됩니다.
+
ItemBlock도 Item의 자녀 클래스입니다. 그리고 Item에서 필수적으로 행해야 하는 사항들 또한 그대로 존재합니다. 그런데 Registry Name만 지정해 줘도 되나요?
사실, ItemBlock은 인자로 준 Block 인스턴스에서 많은 것을 참조합니다. 그 예로 아이템의 이름, 크리모드 탭이 있겠습니다.
따라서 꼬리에 꼬리를 무는 뱀같은 코드를 작성하지 않아도 ItemBlock을 생성할 수 있습니다.
또한 몇 가지 더 참조되는 사항이 있습니다만, 이 사항들은 Item과 Block을 다시 강좌할 때 알아보도록 합시다.
이제 런쳐를 실행해서 block_first 블럭을 설치해 봅시다. 가관이군요. 아이템과 비슷하게 모델을 안 지정해 줘서 기본값인 자주검정 텍스쳐에 박스를 그린 겁니다만, 나중에 고칩시다. 아무튼 블럭이 나왔다는 점에서 기뻐해도 되는 부분 아니겠습니까?? ???
이제 런쳐를 끄고, 두 번째 블럭을 만듭시다. 블럭은 아이템과 비슷하게 마인크래프트 모드를 만들 때 가장 많이 바리에이션을 만들게 되는 클래스 중 하나이기 때문에, 잘 정리해 둘 필요가 있습니다. 패키지부터 만들어 주세요.
그리고 패키지 안에 BlockSecond라는 이름의 클래스를 만들어 주세요.
약간 코드를 짜 본 모습입니다.
NOTE 1 - 블럭이므로 당연히 Block을 상속해야 합니다. 안할시곰보
NOTE 2 - 생성자에는 블럭의 초기화 과정을 그대로 행하시면 됩니다.
NOTE 3 - 이 메소드는 블럭이 우클릭되었을 때 터집니다. 쉬프트를 눌렀을 때를 제외하고 말이죠.
인자가 오지게 많긴 합니다만, 중요한 건 몇 안 됩니다.
1 World - 블럭이 존재하는 월드입니다. 오버월드에서 클릭되었으면 오버월드고, 지옥에서 클릭되었으면 지옥이고.
2 BlockPos - BlockPos는 숫자 3개로 이루어졌으며, 블럭의 위치를 담고 있습니다. 즉 클릭된 블럭의 위치입니다.
3 IBlockState - 블럭스테이트는 지금은 설명하기 약간 어렵습니다만, 대충 말해 블럭과 메타데이터를 합친 블럭 정보 집대성 인스턴스입니다.
4 EntityPlayer - 이 블럭을 클릭한 플레이어 엔티티입니다.
5 EnumHand - 어느 쪽 손으로 우클릭했는지에 대한 값입니다. Main Hand(오른손)와 Off Hand(왼손) 둘 중 하나이며, 값을 오른손으로 해서 호출했다가 특별한 일이 없을 시 값을 왼손으로 바꿔서 다시 호출합니다. 즉 따로 처리를 안 해 주면 이 메소드는 두 번 호출됩니다.
6 EnumFacing - 커서가 클릭된 블럭의 면입니다. 위쪽을 클릭했으면 Up. 아래쪽을 클릭했으면 Down. 이하동문
7 8 9 float - 각각 커서가 클릭된 x 좌표, y 좌표, z 좌표. 써먹을 데는 거의 없을 겁니다.
NOTE 4 - ItemSecond에서처럼, 이 메소드도 클라이언트에서 따라 호출합니다. 그러니 world#isRemote로 검사를 확실히 해 줘야 합니다.
NOTE 5 - true를 반환하면 해당 블럭 클릭에 관련된 상호작용 처리를 중단합니다.
예를 들어 화로를 클릭하면 손에 든 횃불이 설치되지 않죠. 횃불이 클릭 이벤트를 처리하기 전에 화로가 해당 메소드에서 true를 반환했기 때문입니다.
여기에서도 화로처럼 바로 true를 반환해서, 오른손 왼손 두 쪽에서 모두 메소드를 호출하지 않고 한 번만 호출 후 중단하도록 만들었습니다.
Contents로 돌아가서 BlockSecond도 인스턴스를 생성해 주시고,
BlockFirst와 같이 등재를 해 줍시다.
잘(?) 나옵니다.
이제 모든 아이템과 블럭을 만들었으니, 제대로 된 이름도 지어 주고 모델까지 입혀 봅시다!
3. 프록시
..그 전에, 만들어야 하는 중요한 클래스가 있습니다. 프록시라는 이름의 뭔가 복잡해 보이는 클래스입니다만, 사실 전혀 복잡하지 않습니다.
마인크래프트 코드를 보면 @SideOnly [ net.minecraftforge.fml.relauncher.SideOnly ] 라는 어노테이션을 심심찮게 보실 수 있습니다. 이 녀석이 말하는 사이드가 뭐냐면.. 클라이언트와 Dedicated 서버 중 어느 사이드인지에 대한 정보입니다. 그리고 사이드 온리란 말은 한쪽 사이드에만 존재한다는 의미입니다.
이런 사이드 온리 옵션이 붙은 것들은 생각보다 많습니다. 서버에서 존재할 필요가 없는 것들은 거의 다 클라이언트 온리입니다. 아이템에 커서를 대면 나오는 설명들, 모델과 타일엔티티 렌더러 등등. 이런 것들은 서버에서 신경 쓸 필요가 없죠.
해당 어노테이션이 붙은 클래스, 메소드, 혹은 변수의 경우, 지금의 해당되는 사이드와 다른 사이드에서 로드할 때 해당 어노테이션이 붙은 곳을 완전히 날려 버립니다. 이렇게 무참히 분쇄당한 곳을 함부로 참조할 경우, 프로그램은 바로 에러를 일으키고 꺼집니다. 뭣같죠. 날려버릴 거면 말이라도 하던가!
..그래도, 크래시를 일으키지 않고 해당 기능을 사용할 수 있는 방법이 있습니다. 이것이 바로 프록시입니다.
프록시의 작동 원리는 이렇습니다. 서버 프록시(혹은 커먼 프록시)와 이를 상속하는 클라이언트 프록시, 총 두 개의 프록시 클래스가 있습니다. 포지가 모드를 로드할 때 Dedicated 서버면 서버 프록시를, 클라이언트면 클라이언트 프록시를 자동으로 생성해서 모드 클래스에 넣어줍니다.
이 다음부터 꽤 재미있습니다. 서버 프록시에 메소드를, 예를 들어 모델을 지정해 주는 메소드를 만들고, 아무 것도 하지 않습니다. 클라이언트 프록시에서는 이 메소드를 상속해서 실제 모델을 지정하는 일을 수행하게 합니다.
나중에 모델을 만들어야 할 시점에 해당 메소드를 호출하면, Dedicated 서버가 가진 서버 프록시에서는 아무 일도 일어나지 않습니다. 반면 클라이언트가 가진 클라이언트 프록시에서는 모델을 지정합니다. 클라이언트 프록시가 있어야만 모델을 지정하기에, 결론적으로 서버에서 존재하지 않는 클래스를 참조하는 일 없이 모델을 지정할 수 있습니다.
참 쉽죠?? 걱정 마세요. 안 쉬워도 프록시를 쓰다 보면 쉬워집니다. 아마도요.
모드의 메인 패키지에 CommonProxy라는 이름의 클래스를 만듭니다. 이 클래스가 서버에서 생성되는 커먼 프록시가 됩니다.
+
프록시를 따로 패키지를 만들어서 분류하는 모더들도 있습니다. 자기 취향이니 알아서 선택하시면 됩니다. 이런 분들은 프록시의 패키지명으로 주로 [메인 패키지].proxy의 형태를 쓰는 것 같습니다.
내용물은 매우 저렴합니다. 쓸 메소드는 나중에 추가하면 됩니다.
또 모드의 메인 패키지(혹은 프록시 패키지)에 ClientProxy라는 이름의 클래스를 만듭니다.
저렴하게 CommonProxy만을 상속시켜 주면 됩니다.
그리고 CommonProxy의 필드를 모드 클래스에 만듭니다.
이 @SidedProxy [ net.minecraftforge.fml.common.SidedProxy ] 어노테이션은 모드 인스턴스가 만들어질 때 자동으로 프록시의 클래스를 찾아서 인자가 없는 생성자를 호출해 인스턴스를 생성해 넣어 줍니다.
넣어주는 값은 다음과 같습니다.
clientSide - 문자열 형태로 Client Proxy의 클래스 이름을 패키지명까지 포함해서 적으시면 됩니다.제 경우에는 이름이 ClientProxy이고 패키지가 com.tictim.example이니 com.tictim.example.ClientProxy가 되겠습니다.
serverSide - 문자열 형태로 Common Proxy의 클래스 이름을 패키지명까지 포함해서 적으시면 됩니다. 클라이언트 프록시와 동일한 방법으로 적으시면 됩니다.
+
Q1. 클래스 이름이 틀리면 어떻게 되나요?
A1. 터집니다.
Q2. 인자가 없는 생성자를 호출한다고 했는데, 프록시가 인자가 없는 생성자를 가지고 있지 않을 시 어떻게 되나요?
A2. 터집니다. 또 생성자를 public으로 내놓지 않아도 터집니다. 접근성에 관련된 처리를 하지 않아서 호출이 불가능하기 때문입니다.
놀랍게도 이제 프록시를 다 만들었습니다. 대단해 보이는 이름에 비하면 별로 복잡하지 않았죠?
이제 모델을 등록하러 가 봅시다.
커먼 프록시에 Item을 인자로 받는 메소드를 만들었습니다. 커먼 프록시 자체에서는 아무 일도 하지 않지만, 클라이언트 프록시에서 이 메소드를 오버라이드하여 모델을 등록할 겁니다.
클라이언트 프록시에서 오버라이드된 메소드의 모습입니다.
ModelLoader [ net.minecraftforge.client.model.ModelLoader ] 는 이름에서 알 수 있듯이 아이템과 블럭의 모델을 로드하고 관리하는 클래스입니다. 이 클래스의 setCustomModelResourceLocation(...) 메소드는 해당 아이템의 모델 위치를 지정하는데요. 다음과 같은 인자를 가집니다.
1 Item - 지정할 아이템입니다.
2 int - 아이템의 대미지값을 받습니다. 석탄과 목탄 같이 한 아이템을 공유하지만 대미지값에 따라 텍스쳐가 달라지는 아이템을 보신 적이 있으실 겁니다. 이 값을 바꿔 호출해서 대미지값마다 다른 모델을 부여할 수 있습니다.
다만 지금 우리가 만든 아이템은 그런 기능을 가지고 있지 않으니 딱히 이 값을 만질 필요는 없습니다. 기본값인 0으로 넣어 줍시다.
3 ModelResourceLocation - ModelResourceLocation [ net.minecraft.client.renderer.block.model.ModelResourceLocation ] 은 마인크래프트 json 모델의 위치를 나타내 줍니다. 생성자로 받는 인자는 ResourceLocation과 모델의 바리에이션?을 설명해 주는 String입니다.
여기에서는 아이템의 이름을 적당히 참조해서 모델을 찾도록 ResourceLocation은 아이템의 이름을 넣었고, 모델의 바리에이션은 inventory로 넣었습니다.
+
그런데 ResourceLocation이 뭐죠?
ResourceLocation [ net.minecraft.util.ResourceLocation ] 은 도메인과 패스 두 가지의 문자열을 묶어서 저장하는 클래스입니다. (도메인):(패스)의 형태로 변환됩니다. 마인크래프트에서 F3+H(아마도)를 누른 상태로 아이템에 커서를 가져다 대면 맨 아래에 콜론으로 나뉜 두 개의 단어가 보일 것입니다. minecraft:stone과 같은 것들 말이죠. 이게 바로 ResourceLocation입니다.
ResourceLocation은 이름 그대로 텍스쳐, 모델 등의 리소스Resource의 경로Location를 얻는 데 사용될 뿐만 아니라, 마인크래프트에 등재되는 모든 아이템과 블럭에게 고유한 키 값을 부여하는 데도 사용됩니다. 우리가 이전에 아이템과 블럭에서 호출한 setRegistryName(...)도 사실 (모드 ID):(인자로 전달한 문자열) 형태의 키 값을 부여하기 위해 호출한 겁니다.
1.11 이후부터는 ResourceLocation의 도메인과 패스에 포함되는 대문자가 모두 소문자로 변환이 되어 버립니다. 따라서 여러분이 1.11~12, 혹은 그 이상의 버전 포팅에 있어서 골머리를 썩히고 싶지 않으시다면 도메인(모드 ID)와 패스(블럭, 아이템 등의 이름)는 소문자만으로 지정해 주시는 게 좋습니다. 저처럼 1.10에 대문자 썼다가 낭패를 보는 일이 없으시길 바랍니다. 흑흑
이제 프록시의 메소드를 사용하여 모델을 지정하면 됩니다. 결과물에 비해선 설명이 상당히 장황하군요. 흠흠
이제 모델의 위치를 지정했으니, 모델 자체를 만들러 가 봅시다.
4. 모델
※
이 파트에서 설명하는 대상은 1.7 버전에는 없습니다. 1.7에서는 대신 IIcon 등등의 인스턴스를 이용해서 블럭과 아이템 등등을 직접 그리는데, 이에 대해서는 나중에 기회가 되면 설명드리겠습니다. 여기서는 1.8 이후의 모델만을 간단히 강좌합니다.
1.8 버전 때, 마인크래프트의 렌더링 시스템은 엄청난 변화를 겪었습니다. 바로 악명 높은 JSON 모델의 등장입니다. JSON은 간단한 데이터 상수를 기술하는 쉬운 포맷입니다. 마인크래프트는 Pre-Init과 Init 스테이지 사이에서 게임에 등재된 모든 모델들을 읽어들이고 미리 만들어진 모델 렌더러로 변환시킵니다.
4-1. 아이템의 모델
먼저 특정 경로에 폴더를 만들어야 합니다. MDK폴더로 가서 다음 경로까지 폴더를 만들어 주세요. 여기가 마인크래프트가 아이템의 모델을 참조하는 경로가 됩니다.
[MDK 폴더 이름] -> src -> main -> resources -> assets -> [모드 ID] -> models -> item
이제 Item_First의 모델을 만들어 봅시다. 당연히 JSON으로 쓰여져 있으며 내용물은 다음과 같습니다.
2번째 줄 - parent는 다른 모델의 서식을 그대로 베껴 오는 역할을 합니다. 값은 ResourceLocation으로 지정이 되는데요, 이 경우에는 도메인이 없고 패스만 존재하기 때문에 도메인은 기본값인 minecraft, 즉 마인크래프트 바닐라의 것으로 설정이 됩니다.
여기 보이는 minecraft:item/generated라는 위치에 존재하는 json 모델의 서식을 베껴오는데요, 이 모델은 간단히 말하자면 그냥 평범한 아이템입니다.
3번째 줄~5번째 줄 - textures에서는 위에서 불러온 generated로 무슨 텍스쳐들을 렌더링할 것인지를 ResourceLocation으로 전달합니다.
보통 layer0으로 단 한 개의 텍스쳐를 그리도록 명령하며, 여기서는 example:items/item_first라는 이름의 텍스쳐를 찾도록 지정했습니다.
이 json 모델을 방금 만들어 놓은 모델 파일에 .json 확장자를 붙여 저장해 주세요. 이름은 아이템의 setRegistryName에 넣은 그대로 붙여 주시면 됩니다. 저는 item_first를 사용했으니 item_first.json으로 저장해야겠죠?
텍스쳐를 지정했으니, 이제 텍스쳐를 넣어 줘야 합니다. 마인크래프트가 json 모델에서 지정된 ResourceLocation에서 텍스쳐를 찾는 방법은 다음과 같습니다.
(도메인):(패스) = assets -> (도메인) -> textures -> (패스).png
여기서 저는 example:items/item_first라는 이름의 텍스쳐를 찾도록 지정했습니다. 따라서 제가 텍스쳐를 넣어야 할 곳은
assets -> example -> textures -> items -> item_first.png
가 됩니다.
디렉토리를 입력하는 것처럼 빗금으로 세부 폴더를 지정할 수 있습니다. 여기서는 items라는 세부 폴더에 텍스쳐를 지정했죠.
1분도 안 돼서 걸작이 나왔습니다. 와!안두인!가면라이더! 정말 멋잇ㅆ씁니다. 모나리자에 비벼 볼 만한 완성도입니다.
다들 그렇게 생각하죠? 어서 그렇다고 말하십시오
아무튼 텍스쳐를 넣어 줍니다. 이걸로 1번째 아이템이 완성되었습니다.
같은 식으로 item_second도 마무리해 줍시다! 이건 혼자서 한 번 해 보세요. 직접 해 보는 것도 많은 도움이 됩니다.
+
json 모델에 오타가 있으셨나요?
그렇다면 F3+T를 입력해 보세요. F3+T는 마인크래프트에서 로딩한 모든 리소스를 다시 로드합니다. 이는 텍스쳐, 모델, lang 파일 등등을 포함합니다. 인게임에서 누르시면 됩니다.
4-2. 블럭의 모델
아이템이 비교적 만들기 쉬웠던 반면, 블럭의 모델은 조금 복잡합니다. 블럭스테이트가 개입하기 때문입니다.
블럭스테이트는 앞에서 간단히 말해서 블럭+메타데이터라고 말씀드렸습니다. 그리고 모델을 렌더링할 때도 블럭스테이트를 참조하는데요, 이에 따라 블럭스테이트의 모든 바리에이션마다 json 모델을 지정할 필요가 있습니다.
하지만 다행히도 우리가 만든 블럭은 바리에이션이 없는 단순한 블럭이기 때문에, 쉽게 모델을 지정할 수 있습니다.
블럭스테이트에 따른 모델을 지정하는 json입니다. 우리는 바리에이션이 없기 때문에 4열에 있는 example:block_first라는 모델만 만들어 주면 됩니다.
이 블럭스테이트 json 파일을 해당 위치에 저장해 주세요.
assets -> [모드 ID] -> blockstates
여기서 마인크래프트가 블럭의 Registry Name과 동일한 이름을 가진 json 파일을 참조합니다.
이번에는 블럭의 모델입니다.
minecraft:block/cube_all은 모든 면이 한 텍스쳐로 감싸져 있는 블럭입니다. textures로 전달한 all 텍스쳐를 받아서 6면과 파티클을 렌더링합니다.
이 블럭 모델은 models -> block에 저장해 주세요. 블럭스테이트에서 모델을 참조할 때 models/block 폴더에서 모델을 찾기 때문입니다.
블럭의 모델만으로는 아이템을 렌더링할 수 없기에 아이템 버전의 블럭에도 모델을 만들어 줘야 합니다. 여기서 우리는 블럭의 모델을 parent로 지정하겠습니다. 딱히 인벤토리 안의 블럭과 월드에 설치된 블럭이 다를 필요도 없으니 말이죠.
만약 아이템과 블럭이 다르게 보이는 것을 원하신다면, 아이템 모델을 구현하던 것처럼 parent를 item/generated로 설정하고 텍스쳐를 넣어 주세요. 깔때기 비슷한 모양새를 만드실 수 있습니다.
아이템의 렌더링에 사용될 모델이니, item 디렉토리에 넣어줍시다.
이번엔 10초도 안 걸려서 만들었습니다. 네, 귀찮습니다. 어차피 제대로 된 모드도 아니고 예제인데 뭐!빼애액!
여러분은 이런 틱팀을 본받지 말고 열심히 도트를 찍어 보도록 하세요.
이번엔 텍스쳐를 assets -> example -> textures -> blocks -> block_first.png에 넣도록 합시다. 블럭 모델에서 그렇게 지정했기 때문입니다. 원하신다면 바꾸셔도 무방합니다.
만들어야 하는 json 파일의 양이 늘어났고 귀찮음도 제곱으로 늘어난 거 같긴 하지만, 두 번째 블럭도 만들어 보도록 합시다!
결과물입니다. 너무 아름답지 않ㅅ습니까ㅣ??
이번엔 아니라고 말씀하셔도 됩니다. 하지만 그렇다고 말해 주시는 것만으로도 저에게는 큰 힘이 될 수도 있고 아닐 수도 있습니다. 자세한 사항은 그렇다는 말씀을 받은 이후 알려드리도록 하겟습니다. 제가 틱팀입니까 갑팀입니까!!앺X아바타입니까!!중얼,,중얼,,
5. 현지화Localization
제대로 아이템이 렌더링되어도 아직 해결되지 않은 사항이 한 가지 있습니다. 그것은 바로...
이름입니다. 이번엔 이 테러블한 이름을 고쳐서 우리에게 친숙한 이름으로 바꿔 봅시다. 바로 lang 파일을 만들어서 말이죠.
lang 파일은 별 거 없습니다. 현지화 전 이름과 현지화 후 이름을 (이전)=(이후) 식으로 대응해 한 줄 한 줄 나열해 놓은 게 다입니다. 마인크래프트에서는 이 lang 파일을 읽어서 우리에게 보이는 이 이상한 item.뭐시기 뭐시기.name 비슷한 이름을 다른 친숙한 이름으로 자동으로 바꿔 줍니다.
이렇게 전에 보이던 이상한 이름들과 이를 대체할 이름을 =으로 대응시킨 파일을 작성해서
ko_kr.lang으로 저장해 주세요. 소문자 맞춰 주시구요.
마인크래프트에서는 한국어 현지화를 할 때 이 ko_kr.lang 파일을 읽어서 사용합니다.
또 en_us.lang이라는 이름으로도 파일을 만들어 주세요.
이는 한국어 lang 파일보다 중요합니다. 그 이유는 한국어 이외의 현지화를 할 때 다른 lang 파일이 없으면 기본적으로 en_us.lang 즉 영어의 현지화 결과를 출력하기에, en_us.lang이 없으면 한국어에서만 이름이 나오고 다른 나라 말로 바꾸면 이상한 item.뭐시기 뭐시기가 또 출력되는 현상이 생기게 됩니다.
아무리 영어를 못 해도 en_us.lang 파일은 만들어 줍시다. 그 전에 기본적인 단어만 알면 이름 정도는 다 적을 수 있을 겁니다.
이러면 이름에 모델에 기능까지 전부 만드셨습니다. 여기까지 따라오신 분들 모두 수고하셨습니다. 중간에 막히신 분들도 열심히 노력해서 좋은 성과 얻으시길 빕니다.
+
lang 파일에 오타가 있으셨나요?
그렇다면 F3+T를 입력해 보세요. F3+T는 마인크래프트에서 로딩한 모든 리소스를 다시 로드합니다. 이는 텍스쳐, 모델, lang 파일 등등을 포함합니다. 인게임에서 누르시면 됩니다.
복사,,붙여넣기,,앗,,아앗,,
+
우리 한국어가 좀 아픈 것 같아요
한국어가 이상하게 깨지는 이유는 인코딩 때문입니다. ko_kr.lang파일을 열어서 인코딩을 UTF-8로 변환해 주세요.
변환을 못 하시는 분들께서는,,,,,음,,,,, 여기는 메모장 혹은 노트패드++ 강좌가 아니기에, 직접,,,,,
아뇨 어렵지는 않아요. 그냥 쓰기 귀찮아요. 빼애액!!
6. 차회?
다음 화에서....적을 게 약간 애매하기도 하고, 다른 강좌들처럼 바로 타일엔티티+인벤토리 -> GUI로 넘어가는 심플한 과정이 재미없을 수도 있는지라 댓글로 차회에 무엇을 쓸지를 조사해 보고 싶습니다.
1) 초보자가 따라하기 쉬운 절차적 구성 (이 강좌와 같은 구성)
아무것도 바탕에 깔리지 않은 상태에서 읽기 좋습니다. 따라하기는 쉽지만 수박 겉핥기 수준의 글이라서 그 이상의 레벨에서는 얻을 건 별로 없을 겁니다.
커스텀 화로(?) 제작 (타일엔티티, 인벤토리와 컨테이너, GUI)
커스텀 활/포션 제작 (심도 있는 아이템 강좌, 플레이어 인벤토리의 사용법, 포션 효과)
등등.
2) 심도 있는 하나의 클래스에 대한 고찰
하나의 클래스에 대해 집중적으로 서술합니다. 배경 지식이 필요하지만, 미처 알지 못했던 사항들을 발견할지도 모릅니다. 또한 분량이 이런 큰 강좌보다는 짧게 여러 번 나오기에 틱팀이 글을 더 잘 쓴다는 이점도 있습니다(...)
개인적으로는 이런 종류들을 쓰고 싶네요.
아이템(+IItemColor)
블럭(+블럭스테이트)
모델(+Json 모델)
NBT Data(Compound, List, Primitive...)
등등.
사실 둘 다 쓰면 좋기는 합니다. 하지만 제가 맨날 글만 싸지르는 기계도 아니고 그렇게 빠르게 많은 분량의 글을 쓸 수는 없잖아요?? 라고 변명 좀 해 보겠습니다. 하!하!
그럼 이만 변명하는 기계 틱팀은 변명을 하러 물러가겠습니다.안녕여러분
공지 목록
[TTMP에 관심이 있으신 분들께 드리는 말씀]
[코노조에 어서오세요]
