В связи с запланированным обновлением Fly Data Processor, возникла необходимость обновить и сборщик карты, чтобы было кому автоматически запускать Fly Data Processor.
А чтобы обновить сборщик карты не рискуя нарваться на еще одну полную его переделку - полезно сперва определиться со спецификацией. О чем, собственно, этот пост.

Основные требования:

  • Сборщик должен быть модульным - в него должно быть возможно встроить любую утилиту, у которой есть консольный режим, при условии вменяемого поведения подключаемой утилиты
  • Сборщик должен легко подключаться к любой среде разработки, в которой есть возможность вызывать внешние файлы и передавать им параметры
  • Поведение сборщика должно полностью управляться из конфигурационного файла, а передаваемые извне параметры могут только указать на конфигурационный файл и выбрать один из предопределенных конфигурационным файлом режимов работы

Принятые решения:

  • Использовать Lua в составе сборщика.
  • Заменить конфигурационные файлы Lua файлами, которые могут содержать как конфиги, так и логику сборки.
  • Сборщик будет состоять из нескольких частей - управляющее приложение запиленное на C++, конфиги и билд-скрипты на Lua, внешние модули с Lua обертками, плагины для интеграции с IDE.
  • В стандартную поставку будут входить встроенные в сборщик "стандартные" модули, Lua обертки для них, плагин для интеграции с vs-code, пресет пустого проекта готовый к работе, внешний запаковщик карты и обертка к нему.
  • Любой модуль или обертку будет возможно переопределить или заменить своей реализацией, как на уровне всего сборщика, так и на уровне отдельного проекта.
  • Сборщик будет исправно работать независимо от того, установлен ли он отдельно или внутрь папки проекта. Однако при установке внутрь папки проекта сборщик будет автоматически переключаться в режим работы с конкретным проектом, соответственно, при таком режиме установки не будет разделения на глобальные и локальные модули.

Чек-лист на первый релиз

  • Подключение и выполнение Lua файлов. done
  • Архитектура подключения модулей и выполнения билд-скриптов.
  • Внутренний псевдо-модуль "Config", предназначенный для стандартизации работы с конфигами.
  • Внутренний модуль "Log", позволяющий добавлять кастомные записи в лог.
  • Внутренний модуль "Code", выполняющий поиск, парсинг, сборку и модификацию кода карты.
  • Внешний модуль "Pack", выполняющий упаковку карты.
  • Внешний модуль "Data" - обертка для подключения Fly Data Processor.
  • Тестовый проект карты, в котором есть билд-скрипт, собирающий карту в двух режимах, "разработка" и "релиз", используя все модули.
  • Плагин к vs-code, умеющий запускать редактор, сборщик карты в одном из двух режимов и отправлять карту на тестирование.

Чек-лист поведения сборщика

  • При запуске без параметров сборщик пытается определить запущен ли он в режиме проекта или в режиме утилиты. Если сборщик запущен в режиме утилиты, то выводится справка об использовании сборщика. Если сборщик запущен в режиме проекта, он находит стандартный билд-скрипт проекта и выполняет стандартный процесс сборки для этого проекта. Если стандартный билд-скрипт не найден, выводится предупреждение и справка об использовании.
  • При запуске с одним параметром сборщик ожидает получить путь к папке проекта либо к билд-скрипту. Если путь ведет к папке, то сборщик пытается найти там стандартный билд-скрипт проекта и выполнить стандартный процесс сборки для этого проекта. Если стандартный билд-скрипт не найден, выводится предупреждение и справка об использовании. Если путь ведет к билд-скрипту, то сборщик пытается выполнить этот билд-скрипт в стандартном режиме.
  • При запуске с двумя параметрами сборщик ожидает получить путь первым параметром и режим работы вторым. Порядок действий аналогичен запуску с одним параметром, с тем отличием что вместо стандартного режима используется режим выполнения определяемый вторым параметром.
  • Для хранения настроек сборщика используется файл config.lua, находящийся в одной папке с исполняемым файлом сборщика, независимо от того, в каком режиме используется сборщик. При отсутствии этого файла, сборщиком производится попытка по косвенным признакам определить ожидаемый режим работы, после чего генерируется config.lua со стандартными настройками.
  • При определении режима работы, сборщик ищет файл project.json или project.lua на одну директорию выше своего текущего расположения на диске. Если такой файл найден, то выбирается режим работы в проекте.
  • Стандартные настройки подразумевают хранение исходников в папке src внутри папки проекта.
  • Стандартные настройки подразумевают хранение всего связаного со сборщиком в папке builder внутри папки проекта. При автоматической генерации конфига в режиме проекта, реальный путь к исполняемому файлу сборщика используется для установки этого параметра.
  • Стандартные настройки подразумевают хранение временных файлов возникающих при работе сборщика в папке .build внутри папки проекта.
  • При выполнении билд-скриптов сборщик ищет обертки к необходимым модулям, подключает их и затем выполняет сборку.
  • При подключении модулей приоритет отдается локальным модулям проекта и только при отсутствии там соответствующего модуля, используется стандартный модуль находящийся в месте установки сборщика. Если сборщик работает в режиме проекта, то считается что у него нет стандартных модулей, только локальные.
  • Если модуль не найден ни локально ни в в месте установки сборщика, выводится сообщение об ошибке, после чего сборка прерывается.

Совместимость

World Editor

Совместимость с WE в первой релизной версии планируется на уровне предыдущей версии компилятора - WE и среда разработки для кода могут работать параллельно, сборка и запуск тестирования карты выполняется из среды разработки. В случае необходимости внести в карту изменения, которые должен увидеть WE, будет необходимо закрыть WE, выполнить изменения, открыть WE заново.
Создание карты, содержащей код, таким образом чтобы карту можно было сохранить в WE с сохранением функциональности не входит в задачи сборщика - эта задача должна решаться внешним модулем, подключенным в скрипт сборки. Однако, если будет готовая утилита и Lua обертка к ней, то этот функционал может быть включен в набор стандартных внешних модулей, поставляемых вместе со сборщиком.

WLPM

Поскольку в сборщик изначально не закладывается функционала менеджера пакетов, поддержка WLPM может органично закрыть эту дыру в функционале. Но подробности интеграции еще предстоит обсудить с ScorpioT1000.

"дешёвый" сборщик от ​Nazar​Punk

Написанные на Lua модули могут быть подключены к сборщику и использованы после минимальной модификации. Однако возникает вопрос подключения сборщика к IntelliJ IDEA.

добавление сборщика к существующему проекту

  • сборщик рассчитан на работу с картой в формате папки. Для работы в формате архива понадобится подключение дополнительных утилит умеющих распаковывать карту.
  • сборщик ожидает увидеть определенную структуру папок внутри проекта, но до определенной степени это поддается настройки в конфигах.
  • сборщик ожидает увидеть файл project.json или project.lua в корне проекта. Имя этого файла может быть изменено в конфиге. Предназначение этого файла - указвать сборщику где находится корень проекта, на случай отсутствия конфигурации, а также хранить метаинформацию о проекте, например его название и версию. В стандартной реализации скрипта сборки, эта информация также вшивается в код карты.
  • для успешной сборки проекта сборщику необходим билд-скрипт - скрипт на Lua, указывающий сборщику в каком порядке что делать, какие модули вызывать и так далее. В общем случае, должно быть достаточно стандартного скрипта сборки, идущего в составе сборщика, но его может потребоваться редактировать в соответствии с требованиями проекта.
  • в зависимости от требований проекта, к сборщику может потребоваться подключить внешние утилиты. Для этого можно либо напрямую указать их вызов в билд-скрипте, либо обернуть их в "модули", тогда в билд-скрипте будут вызываться функции из API модулей, а луа-код внутри модулей уже будет вызывать внешние утилиты.
  • в зависимости от используемой среды разработки, может потребоваться установка дополнительного плагина или ручная настройка вызова сборщика из среды разработки. В стандартной поставке планируется только плагин для vs-code и поддержка запуска сборщика в консольном режиме.

Послесловие

Как и в случае с Fly Data Processor, этот пост является манифестом и планом на будущее, а также местом для сбора фидбека, если кому-то найдется что сказать. О прогрессе разработки и/или релизе будет отдельный пост.
Эта версия сборщика является логическим продолжением предыдущей версии и подразумевает повторное использование кода и перенос фич, однако если у вас есть какие-то идеи или пожелания - высказывайте их в комментариях, даже если уже высказывали их в комментариях к предыдущему посту.
`
ОЖИДАНИЕ РЕКЛАМЫ...

Показан только небольшой набор комментариев вокруг указанного. Перейти к актуальным.
0
29
4 года назад
0
Планируется ли совместимость со стандартным эдитором?
0
24
4 года назад
0
NazarPunk, смотря что подразумевается под этой совместимостью. Если запись кода обратно в карту, то модуля для этого в стандартной поставке не планируется. Но, модульность подразумевает возможность с минимумом действий прикрутить любую тулзу и утилиту к проекту. Если будет спрос, а лучше - готовый код обертки над внешней утилитой запихивающей код в карту, то этот функционал вполне может быть включен в стандартную поставку.
А если просто речь об одновременной работе в IDE и WE, то тут все на том-же уровне, что и в предыдущем компиляторе Lua - пока не нужно модифицировать файлы в исходной карте, можно одновременно работать и там и там, но если нужно применить какие-то изменения которые должен увидеть редактор, то редактор придется закрыть, применить изменения и открыть заново.
0
29
4 года назад
0
смотря что подразумевается под этой совместимостью.
Всё просто, карта должна открываться стандартным эдитором и после пересохранения нормально работать.
0
24
4 года назад
0
NazarPunk, в первом релизе, да еще и в моей реализации - нет, точно не буду тратить на это время. Но взять тот способ которым ты пользовался у себя и адаптировать его к этому сборщику - дело пяти минут, причем без перекомпиляции самого сборщика, только поправить Lua скрипты.
0
24
4 года назад
Отредактирован prog
0
Фича, которая будет возможна за счет интеграции с FlyData или другими инструментами парсинга данных в карте
  • автоматическая генерация списка переменных для всех юнитов стоящих на карте
  • добавление этого списка в автоподстановку в IDE
  • регенерация участка кода, отвечающего за создание юнитов и запись их в переменные чтобы гарантировать что все используемые юниты с карты были занесены в соответствующие переменные
  • отсутствие необходимости явно указать через Гуи на юнита прежде чем его переменную можно будет использовать
Также, эта фича может быть расширена на разрушаемые объекты, но тут нужно осторожно, чтобы все не упало из-за деревьев.
0
29
4 года назад
0
Хорошо бы выглядела работа со скачиванием файлов, например как я делал здесь, только в более расширенном варианте. Ибо на данный момент импорт чужих наработок выглядит довольно убого и долго по времени, хорошо бы это упростить - указал ссылку на наработку и сразу все нужные объекты в РО создались.
0
24
4 года назад
Отредактирован prog
0
NazarPunk, я пока не планирую включать в состав сборщика какие бы то ни было инструменты для скачивания - это выходит за скоп задач которые должен решать сборщик - как по мне, это задача для внешних подключаемых модулей. А вот по поводу упрощенного импорта надо подумать - какой-нибудь merge-скрипт в состав FlyData вполне может зайти. Да и генерация объектов в РО из кода - тоже потенциальная работа для FlyData, заявленая в возможных фичах для новой версии.


На всякий случай уточню, у меня сейчас в планах и разработке три отдельных составляющих
  • менеджер сборки, то что я в этом посте называю сборщиком, он сам по себе не делает почти ничего кроме выполнения Lua файлов в правильном месте и порядке
  • парсер-компилятор для кода, переработка предыдущей версии компилятора, он может делать много разных вещей с кодом, но в отличии от старой версии ожидает что ему будут отдаваться команды из Lua скрипта, сам принимает решения только в "экспресс" режиме, рассчитаном на максимально быструю сборку по захардкоженным в сборщике правилам. Интегрирован в сборщик для расширения доступного функционала.
  • FlyDataProcessor, новое его поколение, содержит инструменты для работы с данными помимо кода, возможно в итоге будет интегрирован в сборщик, как и модуль для работы с кодом, но пока планируется как внешняя консольная утилита с несколькими режимами работы.
0
29
4 года назад
Отредактирован nazarpunk
0
Было бы шикарно, если бы его собрать в составе lua, как например в luadist.org, собрали кучу полезных вещей. Тогда он бы был отвязан от IDE, и каждый смог бы сам выбирать, что ему от сборщика нужно: совместимость со стандартным редактором (как например мне) или полный контроль над всем процессом сборки карты (как например тому же мне при создании релизных версий).

Так же круто будет засунуть функции сборки в SDK, чтоб справка была доступна прям в IDE.
Загруженные файлы
0
24
4 года назад
Отредактирован prog
0
NazarPunk, перечитай план в посте)
Сейчас привязка к IDE запланирована на уровне заворачивания в плагин который просто передает правильные параметры. Ну и запуск игры удобнее через плагин реализовать т.к. можно отслеживать запущенный ранее процесс и при необходимости убивать его. Сам сборщик полностью независим от IDE. Весь процесс сборки по плану контролируется билд-скриптом на Lua, в котором можно что угодно делать.
По поводу "засунуть в SDK" - у меня нет идеи и ставить я её ради этого не планирую - если найдешь мне спецификацию для этого, подумаю как получить нужный результат. В теории, это должно быть реально, но, скорее всего, не нужно на практике, да и будет вызывать проблемы т.к. функции из сборщика будут перетекать в подсказки к коду карты, хотя в коде карты эти функции не должны быть доступны.
По поводу "сборки в составе Lua" - все с точностью до наоборот - Lua включается в состав сборщика в виде dll. Сборщик не изображает из себя дистрибутив луа и, в принципе, не должен этого делать т.к. он является не универсальным дистрибутивом луа, а выполняет строго специализированную задачу, пользуясь Lua.


Пока, наверно, самый перспективный "дешевый" способ интеграции этого сборщика в идею может выглядеть так:
  • Проект форматируется в соответствии с требованиями сборщика (или генерится конфиг соответствующий текущей структуре проекта).
  • Сборщик ставится либо локально в каждый проект либо глобально один раз, от этого зависят только пути.
  • В проект добавляются конфиги и скрипты сборки, соответствующие требованиям проекта.
  • На каждую таску сборщика создаются отдельные исполняемые Lua-врапперы, которые и вызываются из идеи. Внутри этих скриптов, по факту, только запуск исполняемого файла сборщика с передачей ему параметра, определяющего какую таску выполнить. Примеры тасок "собрать код карты", "собрать карту полностью", "сгенерировать данные РО из кода", "собрать карту в релизном режиме со всеми оптимизаторами", "собрать карту в режиме совместимости с WE".
  • При работе в идее запускается на выполнение в стандартном Lua соответствующий Lua-враппер над сборщиком, а сборщик дальше уже самостоятельно выполняет свой Lua скрипт сборки проекта на своей копии Lua.
0
29
4 года назад
Отредактирован nazarpunk
0
Для меня был бы идеальный такой способ, сборщик включается в состав lua
В так называемые файлы подсветки добавляется весь хэлп по функциям
MyUnpacker = {}
MyUnpacker.pack() end
MyUnpacker.somefunc() end
И из любой IDE можно будет тупо дёргать lua файлы с нужными параметрами или просто написать .bat файл
C:/MyUnpacker/MyUnpacker.exe C:/Path/to/my/map/build.lua
Загруженные файлы
0
24
4 года назад
0
NazarPunk, Видимо, поговорим об этом еще раз когда я смогу показать все на практике.
Но, если коротко - да, черт подери, в качестве одной из возможностей сборщика изначально планировался его запуск с путем к билд-скрипту в параметре...
Показан только небольшой набор комментариев вокруг указанного. Перейти к актуальным.
Чтобы оставить комментарий, пожалуйста, войдите на сайт.