강좌/Minecraft Mod 제작2015. 10. 6. 20:08

강의 환경 : forge-1.7.10-10.13.0.1160-1.7.10

강의 목표 :

1. 모드의 기반 클래스를 작성할 있다.

2. Mod Name, ID, Version 같은 모드 정보를 이해한다.

3. PreInit, Init, PostInit이벤트 메소드를 이용할 있다.

 

이 강좌에서는 모드의 기반이 되는 클래스를 만들어 보도록 하겠습니다.

 

우선, 프로젝트를 열고 Package Explorer 탭을 봐 주세요.

 

src/main/java 디렉토리를 펼쳐주시면, 다음 사진과 같이 examplemod가 나올 겁니다.

 

 

저 ExampleMod는 일종의 예시 모드인데,

 

기본적인 모드는 어떻게 구성되어야 하는지를 보여주고 있습니다.

 

이 모드는 아무 일도 하지 않습니다. 오직 모드의 기반만 포함하고 있는 예제이기 때문이죠.

    

그렇기에 이번 강좌의 목적에 잘 부합하기도 합니다.

 

우선 이 모드를 구성하는 유일한 소스 파일인 ExampleMod.java를 살펴보면서,

 

모드를 어떻게 구성해 나가야 하는지 살펴보도록 합시다.

 

 

위 사진은 ExampleMod.java를 열었을 때 나오는 화면입니다.

 

그렇게 많은 내용이 있지는 않지만, 일반적인 자바 프로그래밍을 해오신 분들이라면 잘 이해가 가지 않는 부분이 몇 군데 있을 겁니다.

 

그리고 그 이유는 아마 포지가 @Mod나 @EventHandler와 같은 Annotation을 중요하게 많이 활용하기 때문일 것입니다.

 

(잘 모르시는 분은 다음 사진까지 넘어가셔도 됩니다)

 

일반적으로는 Annotation은 드물게 활용되는 편이며 중심적인 역할을 맡는 경우는 드물고, 그나마 주석과 비슷한 용도로만 사용되는 경우가 흔한데,

 

포지에서는 모드의 기반이 되는 클래스에는 물론 이제는 포지의 핵심이 된 이벤트 체계도 Annotation을 중심으로 구성되어 있습니다.

 

사실 저도 왜 저렇게 되었는지 이해가 잘 가지는 않습니다만..

 

아마 모드 제작자에게 인터페이스 등을 상속하지 않을 자유를 주기 위한 것이라 생각됩니다. 사실 그러한 상속 작업이 번거롭기는 하지요.

 

한편 부작용으로, 처음 모드를 제작하는 분들은 어떻게 시작을 해야 하는지 알기가 어렵고,

 

모드 버전을 업데이트할 때에도 빨간 줄의 오류만 보게 되며 실제로 어떤 부분을 바꾸어야 하는지를 알기 어렵게 됩니다.

 

사실 그런 이유로 ExampleMod.java라는 파일이 등장한 것으로 보입니다만, 여기서 사설은 그만두겠습니다.

 

 

어쨌든, 위 사진의 내용으로 다시 돌아가서 살펴보겠습니다.

 

위 코드를 분석해 보면, 중요한 몇 부분을 발견할 수 있습니다.

 

1. @Mod

이 어노테이션은 모드 (기반) 클래스를 표시해주는 역할을 하며,

 

주로 @Mod(modid = "examplemod", name="ExampleMod", version="1.0.0") 이런 식으로 작성하게 됩니다.

 

여기서 modid, name, version과 같은 인자들은 필수적으로 지정해 주어야 합니다.

이들은 다음 표와 같은 의미를 갖습니다.

인자 이름

자료형

의미 및 용법

modid

String

모드의 ID(식별자) 입니다. 모드마다 각기 달라야 합니다.

name

String

Mods창을 열면 표시되는 모드의 이름입니다.

version

String

모드의 버전입니다. 업데이트할 때마다 바꾸어주어야 합니다.

 

이 외에도 다음과 같은 인자들이 있습니다. (필수적인 것은 아닙니다)

인자 이름

자료형

의미 및 용법

dependencies

String

어떤 모드에 필요한 다른 모드들을 지정하거나, 모드들의 로딩 순서를 지정합니다.

useMetadata

boolean

true로 지정될 경우, @Mod의 modid, name, version 등의 정보 대신 mcmod.info 에 지정된 모드 정보를 사용합니다.

acceptedMinecraftVersions

String

받아들일 마인크래프트 버전을 의미합니다.

acceptableRemoteVersions

String

클라이언트가 서버에 연결했을 때 받아들일 버전의 범위를 의미합니다.

acceptableSaveVersions

String

세이브 파일 형식이 호환되는 버전의 범위를의미합니다.

bukkitPlugin

String

이 모드를 위해 로딩할 플러그인을 지정합니다. 플러그인-모드 연계에 쓰이는 것으로 보입니다.

certificateFingerprint

String

이 모드 파일에 대한 지문을 지정합니다. 이를 통해 무단 변경된 모드의 이용을 막을 수 있습니다.

modLanguage

String

언어를 지정합니다. (적절한 ILanguageAdapter만 할당해 주면, 다른 언어로 작성하는 것도 가능합니다)

canBeDeactivated

boolean

모드가 disable될 수 있는지를 의미합니다만, 현재로서는 용도가 없는 것으로 보입니다.

guiFactory

String

Config Gui에 사용되는 IGuiFactory구현 클래스의 위치를 지정합니다.

customProperty

CustomProperty

커스텀 속성을 지정할 수 있습니다.

 

 

 

2. @EventHandler

이 어노테이션은 모드 클래스로 하여금 기본적인 이벤트들을 받을 수 있도록 해줍니다.

 

위의 예를 들어 설명하자면,

 

@EventHandler

public void init(FMLInitializationEvent event)

 

자바의 기본 원리대로라면, 당연히 저 init 함수는 절대로 호출될 수 없습니다.

 

하지만 실제로는 호출됩니다. 어떻게 그럴 수 있을까요?

 

사실 모드를 로딩할 때, 포지는 이미 모드 클래스들을 조사하고 그 인스턴스도 만들어 둔 상태입니다.

 

이때 FMLInitializationEvent가 발생하면, 포지는 각각의 모드 인스턴스에 대해 저 init 함수를 호출하는 것이지요.

 

특히 저 부분은 중요한 역할을 하는데, 바로 모드의 초기화 시점에서 호출되기 때문입니다.

 

즉 처음 모드가 실행될 때의 초기화는 모두 저 init 함수에서 하게 되죠.

 

저 예제 모드에서는, 모드 로딩 시에 콘솔 창에 흙 블록의 현지화되지 않은 이름을 출력하게 됩니다.

 

물론 아무리 예제 모드를 넣고 마크를 실행시켜도, 어떤 것도 발견하기 어려울 겁니다. 콘솔 창에만 기록되니까요.

 

* 기억해 두셔야 할 점이 하나 있는데, init 함수의 이름은 마음대로 바꿔도 되지만,

@EventHandler를 달고 FMLInitializationEvent를 인자로 가져야 한다는 규칙은 엄격히 지켜야 한다는 것입니다.

 

 

모드 기반 클래스를 제작하는 데에는 저 2개면 충분하다고 보시면 됩니다.

 

이제 우리는 새로운 모드를 창조해 보도록 합시다.

 

우선 작업할 패키지를 만들어야겠죠? 저는 abr.tutorial로 정했습니다.

 

 

여기서 자신만의 패키지를 만들어 주세요, 모드의 대부분의 구조가 그 안에 자리잡게 될 것입니다.

 

이를 제작하였다면, 이제 모드 기반 클래스를 만들 차례입니다.

 

저 패키지 안에 새로운 클래스를 만들어 주세요. 여러분이 만들 모드의 이름을 쓰는 것이 좋습니다. 꼭 그럴 필요는 없습니다만-

 

그래서 저는 다음과 같이 만들었습니다.

 

 

이제 모드 기반 클래스로서 제 구실을 하도록 만들어야겠죠? 아까 보았던 예제대로 구성을 해봅시다.

 

우선 @Mod를 붙여 주세요. 그럼 다음과 같이 됩니다.

 

 

(어노테이션의 인자에는 클래스에서 public static final로 선언한 변수의 값을 사용할 수 있습니다.)

 

위와 같이 모드 클래스에 public static final로 modid, name, version을 미리 선언해 둔 후, @Mod에서 참조하는 것을 추천합니다.

 

참고로 modid는 따로 쓸 일이 많기 때문에, 클래스에 public static final로 선언해 두는 것이 정말 도움이 됩니다.

 

 

그렇다면 이제 모드의 초기 구성을 위한 초기화 부분을 넣을 차례입니다.

 

아까 예제에서는 FMLInitializationEvent 하나밖에 없었지만,

 

일반적으로는 FMLPreInitializationEvent과 FMLPostInitializationEvent를 같이 사용합니다.

 

이 둘은 각각 FMLInitializationEvent 의 전과 후에 호출되며 각기 중요한 역할을 맡게 됩니다.

 

즉 우선 각각의 모드에 대해 FMLPreInitializationEvent가 모두 호출된 후, 역시 각 모드에 대해 FMLInitializationEvent가 호출되며, 이후 FMLPostInitializationEvent가 호출됩니다.

 

- FMLPreInitializationEvent에서는 주로 모드가 추가하는 블록과 아이템 등을 포지에 등록하게 됩니다.

* 모드 컨피그도 이곳에서 제공되지만, 그렇다고 이곳에서만 접근할 수 있는 것은 아닙니다.

- FMLInitializationEvent에서는 주로 모드 기본 세팅을 합니다. 이곳에서 레시피들을 등록하게 됩니다.

- FMLPostInitializationEvent에서는 주로 모드간의 호환과 관련된 일이 일어나게 됩니다.

 

이들에 대한 자세한 설명 역시 나중에 하도록 하겠습니다.

 

일반적으로는, 아래와 같이 작성해 주시면 됩니다.

 

 

여기까지 하셨다면, 이제 포지가 제공하는 기본 예제는 전혀 필요가 없습니다. 과감히 지워주도록 합시다.

 

(혹시라도 지금 안 지웠다가 여러분의 모드를 배포할 때까지 그대로 놓아두게 된다면,

나중에 사용자가 여러분의 모드를 받았을 때 ExampleMod라는 정체불명의(?) 모드가 같이 깔려있게 되는 불상사가 생길 수도 있습니다!)

 

여기까지 따라하셨다면, 이제 여러분은 모드 (기반) 클래스의 골격을 완성하신 겁니다.

 

… 프록시라는 한 가지 중요한 요소를 제외하고는 말이죠.

 

다음 강좌에서는 프록시에 대해 다뤄보도록 하겠습니다.

Posted by Abastro
강좌/Minecraft Mod 제작2015. 10. 6. 11:36

# 강좌는 Eclipse IDE 사용하며, Windows에서 설치하는 경우에 대해서만 설명합니다.

# 다른 OS 작업을 해야 한다면.. 문의를 주세요.

   

이번 강좌에서는 Forge 다운로드하고, 모드를 작성할 있도록 설정하는 법을 알려드리겠습니다.

   

먼저, 포지를 다운로드하기 위해서는 Minecraft Forge Forum 사이트로 가셔야 합니다.

   

가면 다음과 같은 창을 보실 있습니다.

   

   

여기서 Files 찾아 들어갑니다.

   

그러면 다음과 같은 창이 뜨지요.

   

   

그러면 저곳에 여러 버전들에 대한 Downloads 뜨는데,

   

우리는 1.7.10에서 작업할 것이므로 1.7.10 Recommended 받아줍시다.

   

(* Recommended 포지의 추천 버전으로서, 안정적인 것이 확인된 버전이고,

 Latest 어느 정도 안정적인 최신 버전으로서 Recommended보다는 부족한 편입니다.

   

 여기서는 Recommended 사용하지만, 최근에 업데이트된 새로운 Feature들을 사용하기 위해 Latest 사용하는 경우도

 많습니다.)

   

여기서 1.7.10-Recommended 찾아, 우측의 (Src) 눌러주시면 됩니다. (양심상 * 누르지 맙시다)

   

그런 다음 adf.ly에서 5초를 기다린 , 우측 상단에 나오는 다운받기를 클릭하여 다운받으시면 됩니다.

   

다운받은 파일을 원하는 곳에 압축을 풀어준 , 적당히 이름지어 줍시다. 주로 프로젝트와 관련된 이름을 지어주시는 것이 좋습니다.

   

저의 경우 다음과 같이 AbTutorial이라 지었습니다.

   

방금 만든 폴더에서, 모든 모드 제작 작업이 이루어지게 겁니다.

   

아직 폴더 안으로 들어가시면 안됩니다. 작업이 하나 남았거든요.

   

폴더를 Shift + 우클릭 해주세요.

   

   

, 여기서 명령 열기(W) 눌러 주시면 됩니다.

   

그럼 다음 명령 창이 뜹니다.

   

   

여기에 gradlew.bat setupDecompWorkspace eclipse 치면,

   

일련의 진행 상태 안내문들이 뜨면서 셋업을 시작할 것입니다.

   

* 여기서 주의할 점은, 인터넷이 연결되어 있어야 한다는 것입니다.

    인터넷 서버에서 다운로드해야 하는 파일들이 가지 있기 때문이죠.

   

   

사진은, 초기 진행 중에 뜨는 화면입니다. ( 과정에서 gradle이라는 프로젝트 설정 관리기를 준비합니다)

   

   

MCP 설정 중에 뜨는 화면입니다. MCP 팀을 설명하는 부분이 보이는군요.

   

   

MCP 설정이 끝나면 Forge ModLoader 설정이 진행됩니다.

   

   

그리고 시간을 두고 기다려 사진과 같이 Build Succesful 나오면, 정상적으로 완료된 것입니다.

(그렇지 않은 경우에는 문의해 주세요)

   

이러한 과정들은 아마 오래 걸릴 것이며, 시간을 두고 기다려야 것입니다.

   

그래도 예전보다는 상당히 빨라진 편입니다. (예전에는 40 이상 기다려야 하는 경우도 있을 정도였죠)

   

, 이렇게 하면 설정이 완료된 것입니다.

   

   

물론 상태에서 어떻게 eclipse 모드 작업을 해야 하는지, 막막할 겁니다.

   

우선 eclipse 열어 줍시다.

   

그럼 물론 다음과 같은 프로젝트 위치 선택 창이 뜨겠죠?

   

   

저기서 Browse 눌러, 우선 설치했던 프로젝트 위치를 찾아 줍시다. (저의 경우에는 AbTutorial입니다.)

   

   

사진과 같이 찾아주신 다음, 하위 폴더에서 eclipse 눌러 줍시다.

   

다음 사진과 같이 다음 확인 버튼을 눌러 주시면 됩니다.

   

   

이제 디렉토리에서 Eclipse 시작해 주시면, 다음과 같은 화면이 뜹니다.

   

   

위와 같이, Project Explorer 칸에 Minecraft 뜨면, 정상적으로 설정이 완료된 것입니다.

   

(역시 아니라면, 문의를 주시기 바랍니다.)

   

여기부터 이제, 모드 제작을 시작할 있습니다!

   

이번 강좌는 여기까지입니다. 다음 강좌에서는 모드의 기반을 만드는 일을 보도록 하겠습니다.

'강좌 > Minecraft Mod 제작' 카테고리의 다른 글

[1.7.10] 모드 현지화  (0) 2015.11.04
[1.7.10] 커스텀 블록 제작  (2) 2015.11.04
[1.7.10] FML 기본 이벤트들 (FML Lifecycle Events)  (0) 2015.10.28
[1.7.10] 모드 기반 제작  (0) 2015.10.06
Minecraft Forge 소개  (0) 2015.10.06
Posted by Abastro
강좌/Minecraft Mod 제작2015. 10. 6. 11:09

이번 포스팅에서는 모드 제작에 흔히 쓰이는 Forge 관해 소개해 보려 합니다.

모드 제작 강좌에 앞서, 혹시 MCP 모드로더를 이용한 모드 제작에 관해 질문하시는 분이 있을 같기도 하고

이들을 이해하는 것이 Minecraft Forge 대해 이해하는데 도움이 되기에,

우선 이들의 역사를 살펴보기로 하겠습니다.

 

1. MCP(Minecraft Coder Pack)

 

   

 

 먼저, 최초로 만들어진 모드 제작용 도구는 MCP였습니다.

 

MCP '마인크래프트 모드'라는 것을 가능하게 해준, 아주 혁신적인 도구였었죠.

 

도구는 난독화되어 있는 마인크래프트 소스를 해석하고, 주석을 달아 마인크래프트 소스를 수정할 있도록 해주었습니다.

 

MCP 출범함으로서, 마인크래프트의 자유도를 더욱 높이는 많은 모드들이 쏟아져나오기 시작하기도 했지요.

 

그런데 여기에는 문제가 하나 있었습니다.

 

MCP 이용해 만든 모드들은 마인크래프트 코드를 직접 고쳐 만들어졌기 때문에 대부분 서로 호환되지 않았고,

 

따라서 여러 모드들을 다운받아서 같이 수가 없었다는 것입니다. 다양한 컨텐츠를 한꺼번에 즐길 수가 없었죠.

 

그래서 문제를 해결하기 위해, MCP 기반 위에 2가지 플랫폼이 등장하게 되었는데,

 

그것이 바로 (리수가미의) 모드로더 마인크래프트 포지였습니다.

 

 

2. (리수가미의) 모드로더 (Risugami's Modloader)

 

 

( 사진은 리수가미의 모드로더와 상관이 없음을 알려드립니다)

 

MCP 이러한 결점으로 인하여, '모드 호환을 위한 모드' 만들어지기 시작했습니다.

 

그렇게 등장한 것이 Minecraft beta 1.2에서 등장한 리수가미의 모드로더입니다.

 

Risugami라는 모드 제작자 사람이 제작하였죠.

 

모드로더는, 설치된 모드들을 '로딩'함으로서 변경 사항들을 마인크래프트에 적용하는 방식으로 작동하는데,

 

따라서 그러한 모드들이 마인크래프트 기본 코드를 고칠 필요가 없게 되었습니다.

 

과정에서 '모드' 라는 프로그램의 개념이 완전히 달라지게 되는데, 이전에는 마인크래프트 코드를 수정하는 형식이었으나

 

이제는 간단히 BaseMod 상속하는 객체 하나가 여러가지에 접근할 있는 형태로 바뀐 것입니다.

 

 

3. 마인크래프트 포지 (Minecraft Forge)

 

 

마인크래프트 포지는 리수가미의 모드로더와 유사한 모드 제작 플랫폼으로서,

 

Minecraft beta 1.7.3 버전에서 처음 등장하였습니다.

 

어쩌면 리수가미의 모드로더에서 영감을 받아 제작되었을 가능성도 있지만 자세한 내막은 알려져 있지 않습니다.

 

마인크래프트 포지는 Minecraft Forge Forge ModLoader 2가지 모드로 구성되는데,

 

Forge ModLoader 리수가미의 모드로더처럼 모드를 로딩해 주는 역할을 하며,

 

Minecraft Forge 모드 제작 API로서, 모드 제작을 용이하게 줍니다.

 

사실 Forge ModLoader(FML)만으로 모드 제작은 가능합니다. 간단히 포지 모드를 로딩해 주는 모드로더만 있더라도 실행되기 때문입니다.

 

하지만, 이것만으로는 모드 제작 자체가 불가능할 정도로 Minecraft Forge라는 API 모드 제작에서 중요한 역할을 맡고 있습니다.

 

예를 들어보자면, 가장 최근 정식 1.8 버전에서 일어났던 일이 있습니다.

 

사실 1.8 버전에서는 우선 FML 먼저 출시되었었지요. 이것만으로도 일부 모드들은 1.8 업데이트되었었습니다.

 

하지만 포지 API 없는 이런 업데이트는 너무도 어려운 일이었고, 사실상 대부분의 모드들은 1.8 포지 API 나올 때까지

 

기다릴 수밖에 없었지요.

 

포지 API 대해 설명을 하자면,

 

원래 포지 API 레지스트리, 인터페이스 다양한 방식의 API 골고루 지원해 왔습니다.

 

중에서도 레지스트리가 미미하게나마 비중이 높았죠.

 

하지만 최근 들어서는 이벤트 쪽으로 움직이는 강한 경향이 나타나고 있으며,

 

따라서 모드 제작에서도 이벤트 처리가 점차 중요해지고 있는 추세입니다.

 

이외에, 세부 사항에 대해서는 다음 강좌들을 통해 차차 설명할 계획입니다.

 

4. 결과

 

모드로더와 포지가 나온 이후, 여러 모드들이 서로 호환되기 위하여 이들을 기반으로 하는 모드들을 만들기 시작했고,

 

얼마 MCP 자체만으로 모드를 만드는 사람들은 별로 남지 않게 되었습니다.

 

 

원래 베타 후기에서 정품 초기까지의 버전들에서는 모드로더와 포지가 병존했기 때문에,

 

중에서 무엇을 선택할지에 대한 선택권이 있었습니다.

 

이때까지는 모드로더 전용 모드 제작자 계열과 포지 전용 모드 제작자 계열이 나뉘어 있었는데, 모드로더가 먼저 생겼으므로

많은 모드가 모드로더를 이용하여 작성되는 편이었습니다.

 

하지만 모드로더에는 중대한 문제가 하나 있습니다.

 

바로 '단일 제작자' 리수가미가 혼자서 창조하고 관리해 왔다는 것이지요. (아마 독단적으로 운영했던 같습니다.)

 

그러다 보니, 리수가미가 '그만두기만 하면' 모드로더는 모든 것이 끝인 되어 버린 겁니다.

 

게다가, 리수가미는 모드로더 뿐만 아니라 여러 모드를 함께 제작하고 있기 때문에, 모드로더 자체에 전념할 수가 없었습니다.

 

반면 다수의 서포터들이 존재했던 포지는 상황이 전혀 달랐지요.

 

처음부터 LexManos, cpw, Eloraam 등의 여러 제작자가 함께 제작하였으며,

 

현재 cpw 등이 그만두면서 결국 LexManos라는 단일 제작자가 이어나가게 되었지만,

 

여전히 주위에 많은 개발자들이 많은 측면에서 돕고 있었습니다.

 

게다가 LexManos 포지로 먹고 사는 처지가 되었으니 그쪽에 전념할 수밖에 없었죠.

(실제로 그가 제작하거나 기여한 모드는 Minecraft Forge Forge Mod Loader 뿐입니다...)

 

결과적으로 모드로더는 업데이트도 늦고, API 개선도 별로 없었기에,

 

시간이 가면서 나날이 발전해 갔던 포지에 비해 점점 뒤쳐지게 되었고,

 

제작자인 리수가미가 이상 모드로더를 이어 나가기 힘들게 되면서, 사실상 작별을 고하게 됩니다.

 

특히 1.6, 1.7, 1.8에서 이어지는 강력한 모장의 마크 기반 코드 변경을 단일 코더인 리수가미가 버텨내기는 어려웠을 것이며,

그래서 1.6.2 버전까지만 업데이트 것으로 보입니다.

 

결과적으로 이러한 이유들로 인하여, 포지 중심으로 모드 제작이 옮겨가게 되었습니다.

 

(현재는 MCP 팀도 Minecraft Forge 권장하더군요. 그러니 이제 마크 공인 모드 제작 플랫폼이 겁니다.)

 

 

* 5. 버킷과 포지의 차이

 

 vs.  

 

댓글 중에서 버킷과 포지를 질문한 분이 있었습니다. 차이에 대해 궁금하실 분들이 많다고 보기에,

 

이렇게 따로 설명해 드리고자 합니다.

 

우선, 근본적인 차이는 다음과 같습니다.

 

1. Minecraft Forge 마인크래프트 클라이언트와 서버를 모두 수정할 있습니다.

    반면 Bukkit API 서버에 대한 변경만을 지원합니다.

 

2. Minecraft Forge 모드로 하여금 서로 호환되면서도 마인크래프트 기본 코드를 많이 건드릴 있게 해줍니다.

   반면 Bukkit API Abstraction API 방식을 사용함으로서, 플러그인에게 간접적으로 접근할 있는 권한만 부여합니다.

 

 

아마 1번의 차이점은 많이 들어보셨을 텐데요, 세부 사항에 대해서는 아마 모르는 분이 계실지도 모릅니다.

 

차이점은, 기본적으로 버킷은 마인크래프트 서버 프로그램을 변경한 프로그램이라는 사실로부터 나옵니다.

 

버킷으로서는 마인크래프트 코드를 그대로 이용할 이유가 없으며,

 

단지 클라이언트와 제대로 통신만 있으면 전혀 문제가 없습니다.

 

사실, 버킷은 원래 C Python같은 다른 언어로 만들어질 수도 있었습니다. (그리고 실제로 그런 것이 있습니다..)

 

그러하니 버킷으로서는 서버 파일을 자의적으로, 마음대로 변경할 있었고,

 

결과적으로 코딩하기 쉬운 방법으로 바꾸었던 것으로 보입니다. 실제 많은 변경이 가해지지는 않은 것으로 보입니다만..

 

플러그인 제작자 분들께서 사용하시는 버킷 API '버킷'이라는 프로그램에 접근할 있도록 주는 API이며,

 

실제로 버킷에서 일부 이벤트만 받아 처리할 있도록 해주는 아주 일부의 변경만을 지원할 뿐임에도 불구하고

 

그러한 이점으로 인해 상당히 많은 부분에 접근하여 많은 변경을 가할 있는 구조를 가지고 있습니다.

 

 

반면, 포지는 MCP 딸린 모드입니다. 물론 마인크래프트 코드를 변경하지만, 아무래도 조심스러울 수밖에 없었습니다.

 

잘못하면 이로 인해 마인크래프트의 본질을 심각하게 훼손할 수도 있기 때문이죠.

 

그래서 처음부터 포지가 세운 원칙 중에 '마인크래프트 코드는 있으면 적게 고친다' 라는 것이 있습니다.

 

또한 최근에 MCP 코드 패치 파일을 만드는 제도로 바뀌면서,

 

원칙은 Minecraft Forge 개발버전 크기를 최소한으로 줄이기 위한 하나의 방법이 되기도 하였습니다.

 

이러한 제한으로 인해, 서버 부문에서는 버킷의 기능이 모두 구현 가능하지만, 그다지 이점이 없는 상태이기도 합니다.

 

  (그래도 기본 코드를 효율적으로 이용하고 변경할 있기 때문에,

         서버 모드는 실제적으로 버킷보다 많은 것을 있습니다)

 

 

2번의 차이점은 아마 들어보지 못하셨던 분들이 많을 것으로 생각됩니다. 부연 설명을 하자면,

 

예를 들어 마인크래프트의 블럭에 접근할 있도록 해주는 Block이라는 객체가 도구에 어떻게 구현되어 있는지를 살펴보면 좋을 것입니다.

 

 

 

마인크래프트 포지에서는, 그냥 마인크래프트 원래 코드에 있는 Block 사용하되,

 

일부를 고쳐 접근하게 쉽게 만드는 방법을 사용합니다.

 

블럭을 새로 만들고자 때에도 Block 상속받는 클래스를 하나 만들고,

 

접근하고자 때도 마찬가지로 Block 클래스를 통해 접근합니다. 마인크래프트 기본 코드를 적극 활용하는 것입니다.

 

또한 이를 통해 마인크래프트 기본 코드가 어떤 식으로 작동되는지도 수도 있고,

 

모드 제작시에도 이를 따라 하는 것이 하나의 좋은 모딩 방법으로 공인되어 있습니다.

 

 

 

반면, 버킷에서는 Block 인터페이스입니다. 외부에서 접근할 있는 일부 함수만이 주어져 있죠.

 

아마 버킷 내부에서 실제 Block 나타내는 객체와 연결이 되어있을 것으로 보이는데, 자세한 내막은 없어요.

 

마인크래프트의 기본 코드는 고사하고 버킷 내부에서 어떻게 작동하는지도 없다는 것입니다.

 

플러그인으로서는 'Bukkit API'라는 버킷의 외부 경계면만 있고 접근할 있는 것이죠.

 

 

이러한 차이는, 궁극적으로 1번의 차이점에서 유래한 것으로 보입니다.

 

위에서 서술하였듯이, 버킷과 달리 포지는 마인크래프트 코드를 수정하는 데에 제한이 있기 때문에,

 

그에 상당하는 API 구축하는 데에는 상당한 어려움이 있습니다.

 

대신 포지는 모드로 하여금 마인크래프트 코드 자체에 직접 접근할 있도록 함으로서,

 

상당히 많은 부분을 고치고 제어할 있는 권한을 모드 제작자에게 부여합니다.

 

그럼으로서, 모드의 가능성은 (서버에서만 돌아가는 '서버 모드' 대해서도) 플러그인을 능가하는 수준이 됩니다.

 

또한 마인크래프트 기본 코드를 봄으로서 코드를 어떻게 작성해야 자신이 원하는 효과를 얻을 있는지에 관해

많은 통찰력을 얻을 수도 있다는 사실도 얼마간 이에 작용한 것으로 보입니다.

 

이렇게 만들 경우 가지 단점이 있는데,

 

하나는 마인크래프트가 업데이트될 때마다 모드도 업데이트해 주어야 한다는 것입니다.

 

대개 마인크래프트 버전이 업데이트될 때마다 코드가 바뀌게 되는데,

 

아주 사소한 차이라고 할지라도 모드가 바뀐 부분을 사용하거나 언급이라도 한다면, 버전과 호환되지 않게 됩니다.

 

또한 마인크래프트의 '난독화' 버전마다 달라지기 때문에, 모드로서 여러 버전에 호환되는 것은 애초에 불가능한 일이 됩니다.

 

버킷의 경우 마인크래프트 자체 코드에 접근하지 않기 때문에 그러한 일이 생기지 않죠.

 

그렇기 때문에, 포지도 버킷처럼 Abstraction API 방식으로 바꾸어야 한다는 말도 많았지만

 

포지 제작자 LexManos 이러한 요구들을 모두 거부했습니다.

 

그러자, 일부 사람들은 Forge 위에 Abstraction API 올리는 일을 시도하기 시작했습니다. 물론 힘든 일입니다.

 

특히 포지 초기 버전에서는 Forge API 수준이 미흡했기 때문에 그러한 일이 거의 불가능하다시피 했습니다.

 

하지만 시간이 가면서 Forge API 발전을 거듭하였고,

 

근래에는 Abstraction API 포지 기반에 제작하는 것이 가능해지는 수준에 이르게 되었습니다.

 

때맞추어 버킷이 DCMA 소동에 휩싸이면서 모드 버킷(mcpc, Cauldron) 제작자들과 버킷 쪽에 종사하던 일부 주도적인 플러그인 제작자들이 포지를 기반으로 하는 '버킷 대용품' 제작에 나섰고,

 

 

결과 Sponge 탄생하게 되었습니다.

 

Sponge 제작자들은 Forge 위에 Abstraction API 올리는 것을 시도하고 있고, 현재까지는 성공적인 것으로 보입니다.

 

 

어쨌거나.. 지금까지 Minecraft Forge의 역사에 대해 알아보고, Bukkit 차이점을 알아보았습니다.

Posted by Abastro