Trigger Reactor / 트리거 리엑터

 트리거 리엑터란 무엇일까?

 트리거 리엑터는 wysohn 을 제작자로 하는 스크립팅 플러그인입니다. 여기서 말하는 스크립팅 플러그인이란,

마인크래프트 내에서 특정 기능을 실행할 때, 플러그인에서 짜여진 대로 실행되는 것이 아닌, 플러그인에서 제공하는 기능을 활용하여 사용자 정의로 기능을 만들어 사용할 수 있는 플러그인을 의미합니다.

대표적인 스크립팅 플러그인으로는 Variable Triggers, Skript, Trigger Reactor 등이 있이 있습니다.

 기존에 서버에서 자주 쓰던 "그 트리거" 와는 무엇이 다를까?

 (부제: 트리거 리엑터의 탄생 배경)

 기존에 서버에서 자주 쓰던 트리거는 Variable Triggers (이하 VT)라는 플러그인입니다. "그럼 있는걸 그대로 쓰지 왜 이걸로 넘어왔느냐" 라는 의문점이 생길 수도 있는데, 왜 기존에 쓰던 VT는 사용하지 않고 Trigger Reactor (이하 TR) 을 사용하는걸까요? 그 이유는 VT 의 개발상황이 점점 악화되고 상위버전에서의 안정성이 편치 못한 편이기 때문입니다. VT 의 개발자가 개발 중단선언을 이미 한차례 한 것에 의의를 두면, 상황이 좋은 편만은 아니다. 이 상황에 놓이게 된 VT 플러그인 사용자中 wysohn  는 기존 VT의 뒤를 잇고자 하여 VT와 비슷한 형식을 가진 플러그인을 만들게 됩니다.

그리하여 만들어진 것이 바로 Trigger Reactor 입니다.

 전 VT 사용자들이 Skript 대신 TR을 사용하는 것이 효율적인 이유가 있을까?

 한국 서버에서 많이 쓰는 스크립팅 플러그인으로는 VT말고도 Skript가 있습니다. 왜 있는 Skript사용을 하지 않고 구지 TR을 사용하는 것이 효율적이라고 말할 수 있을까요? 그 이유는 구문작성 문법에 있습니다.

기본적으로 VT는 VT만의 "스크립트(@EXIT)", "플레이스 홀더(<playername>", "문자열" 등을 주로 하여 문법이 구성됩니다. 그에 반해서 Skript는 영문법을 기반으로 한 역시 Skript만의 문법을 가지고 있죠.

다음 예시를 보며 설명하자면,

@CMDOP kill <playername>

위 VT 구문은 해당 트리거를 실행시킨 사람을 죽이도록 설정되어 있습니다.

위 구문을 Skript 문법으로 작성해보면

kill the player

위와 같이 작성됩니다.  VT와 Skript 구문 문법의 차이가 확실하게 보이시죠?

하지만 위 구문을 TR문법으로 작성해보면

#CMDOP "kill "+$playername

위와 같이 작성됩니다. 몇몇의 기호가 달라지긴 했지만 전체적인 흐름은 비슷한 것을 볼 수 있습니다.

또한 개발자인 wyshon은 이 플러그인을 만들 때, VT에서 영감을 많이 받았다고 언급한 바가 있습니다.

위를 정리해보면, 기존 VT사용자들이 Trigger Reactor을 배울 경우, 문법의 유사성에 의해서 조금 더 빠르게 습득할 수 있다는 가능성이 있다고 결론지을 수 있습니다.

다만, TR과 Skript 사이에서 우위를 가릴 수는 없습니다.

 Trigger Reactor의 장점은?

• Multi-threading 작동 (렉 없는 최적화)
• 7가지 트리거들: Click, Walk, Command, Named, Inventory, Repeating, Custom
• 쉽고 편리한 사용을 위한 49가지 이상의 Executor와 43가지 이상의 Placeholders
  • 원하는게 없으면 직접 만들어, 타 플러그인과의 호환
• 직접 JavaDoc의 메소드들을 사용가능
• 광역 변수, 지역 변수 기능 사용가능
• 강력한 조건문 시스템
• 반복문과 배열 제작 및 사용 
• 타 플러그인 API 엑세스
• IMPORT 사용가능

1. Multi-Threading 작동

시스템에서 하나의 요소를 처리하기 위한 일종의 진행 과정을 Task라고 합니다. 즉 우리가 블럭을 밟아서 트리거를 하나 실행했다면, 그것은 1개의 Task를 실행시키는 것이죠. 여기서 Multi-Threading이란, 앞에서 말한 Task를 순차적으로 처리하는 것이 아닌, 동일시간대에 병렬 처리가 가능한 것을 말합니다. 즉 순차적으로 처리하면 100개의 Task가 3초동안 처리되지만, 병렬로 처리하면 0.1초 안에 100개의 Task가 모두 처리된다고 보시면 됩니다. 기존 Bukkit은 멀티 쓰레딩을 지원하지 않았습니다. 즉 트리거만의 독자적인 쓰레드에서 멀티쓰레딩을 구현하도록 했습니다. 

2. Executor와  Placeholder 직접 제작 가능 (심화)

여기서 말하는 Executor와 Placeholder은 나중에 설명할 것인데, Executor은 VT에서 @ 붙은것들, 이를테면 @CMDOP 와 같은것이고, Placeholder는 VT에서 <> 붙은것들, 이를테면 <playername> 과 같은 것으로 보면 됩니다.

기존 VT에서는 이런걸 직접 만들수가 없었는데, TR에서는 이것이 가능토록 했습니다.

저는 이를 이용하여 $realdate 라는 Placeholder를 만들어 보았습니다.

function realdate(args){   var date = java.util.Date;   var simpleDateFormat = java.text.SimpleDateFormat;   var df = new simpleDateFormat("yyyy-MM-dd");   var dateobj = new date();     return df.format(dateobj); }

직접 만들경우, 자바 스크립트를 기반으로 만들어집니다.

3. 버킷 메소드및 자바 문법 직접적 사용 가능 (심화)

사용하는 버킷에서 지원하는 모든 method를 사용할 수 있습니다. 예를 들면 #MESSAGE "안녕하세요!"를 Bukkit method를 통해 player.sendMessage("안녕하세요!") 라고 변형하여 트리거 리엑터 구문에서 그대로 사용할 수 있습니다. 이를 통해서 특정 플레이어를 죽이거나 레벨및 HP최대치를 맘대로 바꿀 수 있으며 심지어는 플레이어를 뛰게, 웅크리게 하거나 플레이 시간을 강제조정하거나, 버킷로거를 가져와 버킷로깅을 채팅에서 하는등 세부적인 기능까지 사용할 수 있습니다. 또한 자바문법의 직접적 사용도 가능하기 때문에 java.io 클래스를 통해서 Yaml을 트리거로 직접 만들어 관리할 수도 있습니다.

4. 타 플러그인 API 엑세스 가능 (심화)

타 플러그인 API 엑세스 가능이란, 한마디로 "다른 플러그인에 들어가서 정보를 빼오거나, 다른 플러그인에 있는 기능을 실행시키는 것이 가능하다는 것" 입니다. 예를들어 Essentials가 서버에서 돌아가고 있다면, 그 플러그인 시스템에 들어가서 특정 플레이어의 home목록을 빼오거나, GeoLocation을 통해서 접속위치를 불러오는 등의 행위가 가능하다는 겁니다. 조금더 쉽게 설명하자면, "어떤 플러그인이던지 간에, 트리거 리엑터랑 연동할 수 있습니다."

5. IMPORT 사용가능 (심화)

자바에서 흔히 사용하는 import를 트리거 리엑터 구문 내에서도 사용할 수 있습니다.

IMPORT org.bukkit.entity.Player IMPORT java.util.Date

위 두 구문은 각각 버킷에서 Player 인터페이스를 불러오는 구문, Java 자체에서 Date클래스를 불러오는 구문 입니다. Date 클래스는 Java가 실행중인 컴퓨터에서 시간정보를 수집하고 그 정보를 가지고 있는 클래스입니다. 위 클래스를 잘만 이용하면, 트리거 리엑터 구문만으로도 실제시간을 불러올 수 있습니다.

더불어 객체지향적 언어인 자바에 맞춰서 트리거 리엑터에서도 객체를 생성하여 사용할 수 있습니다.

소개를 마치며...

위에서 말한 내용중 본인의 개인적 견해를 제외하고는 거짓은 한치도 없습니다. 트리거 리엑터의 확장성은 본인이 생각하기에 무한에 가까우며, 활용하면 활용할수록 난이도가 점점 더 어려워지는 것을 느꼈습니다. 구지 말하자면 수학과 같은 겁니다. 하지만 확장성이 무한하기에, 어떠한 기능이던 만들 수 있다는것이 장점이라고 볼 수 있습니다. 편의성과 확장성 모두 갖췄지만, 사용할지에 대한 선택은 본인의 몫입니다. 또한 트리거 리엑터는 진입장벽이 매우 높습니다. 자신에게 되묻고 선택하기 바랍니다.