Minecraft Script Engine — возможности и ограничения

В данной статье я хотел бы проанализировать все, что на данный момент известно про Minecraft Script Engine (ранее упоминавшийся во многих ресурсах как Script API/Scripting API) и составить некое полноценное виденье того, что это и для чего может быть применено. Сразу оговорю, что данная статья написана 25.10.2018 и может содержать неактуальные на момент прочтения сведения. Также на данный момент у меня нет возможности запускать и тестировать приведенные ниже примеры, поскольку возможности доступны только в закрытой бете игры.

Итак, тщательно ознакомившись с документацией по Minecraft Script Engine (и даже переведя большую её часть) и примерами, я смог сложить для себя определенное мнение о данной платформе. Попробую описать это в срезе плюсов/минусов по сравнению с InnerCore/BlockLauncher.

Итак, несомненные преимущества:

• Отсутствие необходимости устанавливать дополнительное программное обеспечение
• Официальная поддержка от Mojang и, вероятно, частые обновления
• Поддержка клиент-серверной архитектуры заложена в самом приложении, полное разделение клиентской и серверной логики
• Используется уже известный нам язык программирования JavaScript и его формат хранения данных — JSON.
• Возможность полноценной отладки с помощью отладчика JIT Debug (Visual Studio).
• Для создания интерфейсов используется формат WEB-страниц (HTML5), что позволяет с легкостью создавать окна и достаточно просто с ними работать.
• Возможна прямая работа с пакетами поведений, что несомненно является плюсом для тех, кто умеет с ними работать.
• Сохранена архитектура пакетов поведений, многие функции принимают аргументы в том же формате, в  котором они используются в JSON-файлах поведений.
• Сами скрипты являются частью пакетов поведений, а значит, их можно упаковывать в архивы с пакетами ресурсов и картами.

Но, у каждой медали есть две стороны. К сожалению, на данном этапе недостатки для меня оказались намного существеннее. И тут пойдут примеры кода, в качестве доказательств.

• Файловая система. Несомненно лучше, чем один файл ModPE (что решается с помощью системы сборки NIDE), но далека от гибкости и мощности файловой системы InnerCore. Все скрипты Minecraft Script Engine являются независимыми исполняемыми файлами и коммуницируют только на уровне событий.
• Архитектура. В ванильном варианте архитектура скрипта очень ограниченна контекстом вызова функций. Нужно либо объявлять все функции в пространстве имен системы (см. документацию), либо передавать во все функции, использующие API Script Engine’a, контекст их выполнения. Яркий пример:

var system = client.registerSystem(0,0);
system.initialize = function() {
    // Обратите внимание на поддержку стрелочных функций
    this.listenForEvent("minecraft:client_entered_world", 
        (eventData) => this.playerJoin());
    // Альтернативный вариант - передать контекст 
    // в качестве параметра обычной функции
    this.listenForEvent("minecraft:client_entered_world", 
        (eventData) => playerJoin(this));
}
// Функции приходится объявлять так
system.playerJoin = function() { 
    this.broadcastEvent("minecraft:display_chat_event ", 
        "Hello, world!");
}
// Альтернативный вариант - передать контекст в качестве параметра
function playerJoin(ctx){
    ctx.broadcastEvent("minecraft:display_chat_event ", 
        "Hello, world!");
}

•  Использование команд командного блока в качестве команд. Разбирая примеры, приведенные в документации, я часто наталкивался на подобные строки:

this.broadcastEvent("minecraft:execute_command", 
    "/fill -6 0 -4 -6 7 -4 barrier");
this.broadcastEvent("minecraft:execute_command", 
    "/tp @a -5.87 8 -4.0 -28 40");
this.broadcastEvent("minecraft:execute_command", 
    "/clear @p");

Вроде бы хорошо, в чем проблема? А их даже 2, а именно: читабельность (этот код сложно назвать интуитивно понятным) и скорость выполнения. Поскольку парсер команд — штука относительно медленная, вызывать подобные методы достаточно часто нельзя в принципе — слишком высокая нагрузка на клиент/сервер, так как команда будет передана из Minecraft Script Engine парсеру команд командного блока, а уже он её превратит в набор необходимых аргументов и вызовет нужные функции. Процесс, мягко говоря, медленный. Хотя, с другой стороны, гибкость этого метода все равно остается на высоте.

• Повторюсь, но отсутствие читабельности кода. Для того, чтобы получить всех сущностей в мире, например, нужно выполнить следующий код:

var view = this.registerView();
let entities = this.getEntitiesFromView(customView);

Согласитесь, не очень очевидно, о чем речь?)

• Отсутствие доступа к внешнему миру. В отличии от Inner Core & BlockLauncher, разработчики Minecraft Script Engine ни за что не предоставят доступ к Java (безопасность для них прежде всего). Тем не менее, запуск чего-либо «в коробке» сразу урезает возможности АПИ в разы.
• Наконец, полная недоделанность. Я все-таки отнесу это к минусам, хотя и понимаю, что большая часть функционала будет ждать нас впереди.

Моё личное мнение — не стоит возлагать больших надежд на Minecraft Script Engine. В корне неправильная архитектура и ограничения, связанные с безопасностью и скоростью работы, сделают это АПИ лишь очередным инструментом для создания карт либо отдельных модов, слабо интегрируемых друг с другом, следующей ступенью после пакетов поведений и текстур.

Что будет на самом деле — время покажет. Ваши предположения жду в комментариях)