Статус и план дальнейшего развития утилиты

Published
Не для публикации на главной
Если вам знакома утилита Fly Data Processor - хорошо. Если нет - ничего страшного, ведь текущая версия этой утилиты безнадежно устарела, да и не работала никогда толком. Но это в прошлом, а впереди - будущее. Весьма отдаленное будущее ввиду недостатка свободного времени, но это уже другая история. Дальнейшей разработке утилиты быть, но в новом направлении.
И так, что мы имеем сейчас:
  • основная фича "простой доступ к данным из РО в коде" более не актуальна т.к. к этим данным теперь можно получить доступ нативными средствами, да еще и в реальном времени, а не на этапе компиляции карты.
  • работа с Jass кодом не актуальна ввиду добавления Lua в качестве альтернативного скриптового языка карты.
  • интеграция с JNGP не актуальна т.к. сам JNGP не актуален, а в тренде внешние сборщики карты.
  • извлечение файлов данных из карты не актуально т.к. есть режим хранения карты в виде папки.
  • подстановка данных и выполнение арифметики в текстовых описаниях не актуально, отчасти благодаря добавлению встроенного генератора ссылок в описания, а отчасти потому как текущая версия рассчитана на ручное использование этой фичи
  • парсинг данных из файлов данных не актуален т.к. нет актуального применения этим данным.
  • использование сторонней билиотеки-шаблонизатора для генерации кода и файлов строк более не актуально т.к. есть свой собственный рабочий парсер Lua кода, который путем минимальной модификации даст необходимый функционал.
  • язык Java более не актуален т.к. я на нем практически не пишу на данный момент
В то же время, переход на внешнюю сборку карты ради удобной работы с кодом и добавление Lua, также открывают новые возможности и при работе с данными и строками:
  • прежде всего, теперь можно явно разделить "исходную" версию файла строк, используемую редактором и "релизную", используемую в игре и не бояться потерять исходник из-за случайно нажатой кнопки или прихоти редактора
  • также, теперь можно комфортно заниматься генерацией данных по объектам, не опасаясь конфликтов с WE т.к. WE можно закрыть на время генерации новых данных
  • в отличии от Jass, на Lua достаточно легко написать стандартизованную базу данных, если таковая понадобится (старая версия утилиты оставляла эту задачу на совести пользователя и предоставляла только шаблоны для этого)

План

Сроки

Конкретных сроков реализации этого плана на практике пока нет - когда-нибудь по мере наличия свободного времени после выхода рефоржа.

Основные задачи по адаптации утилиты к новым реалиям

  • Портирование на C++ или Lua вместо джавы т.к. именно на этих языках я сейчас в основном работаю (с джавой мне по прежнему более комфортно, но эффективнее будет пользоваться тем же набором языков, что и при повседневной работе)
  • Адаптация утилиты к формату карты-папки и устранение зависимости от внешнего распаковщика карты (а если кто по прежнему пользуется картой-архивом, то это будет на его совести, достать из карты все нужные файлы)
  • Интеграция с инструментами для внешней сборки карты вместо JNGP и устранение прямой зависимости от внешнего запаковщика карты (это не задача этой утилиты паковать карту обратно)
  • Интеграция с моим собственным внешним сборщиком карты и реализация дополнительных фич, доступных за счет этой интеграции
  • Переход на Lua в качестве основного языка карты вместо Jass (потенциальные пользователи этой утилиты и так переходят на Lua, а тем кто останется на жассе и гуях эта утилита не особо поможет)
  • Адаптация утилиты к тому факту, что теперь можно гарантировать наличие исходного файла строк
  • Поиск и имплементация новых фич и юзкейсов на замену устаревшим и не актуальным
  • Реализация библиотеки на Lua, стандартизующей способы хранения и доступа к данным, попавшим в базу и доступным на этапе игры.

Предполагаемые новые фичи

Виртуальные статы

  • Возможность в описании чего бы то ни было в редакторе объектов использовать особый формат шаблона для отметки блока, который должен быть разобран парсером и помещен в базу данных для дальнейшего использования. Назовем это "блок данных" в рамках описания текущей фичи.
  • Блок данных может содержать пары ключ-значение, причем в качестве значения могут также выступать арифметические операции и ссылки на другие данные, в том числе нативные ссылки на данные и данные из других блоков данных.
  • Блок данных удаляется из описания при создании релизной версии файла строк.
  • Блок данных может быть автоматически заменен отформатированным текстом, сгенерированным на основе данных из блока и шаблонов определяющих стиль и текст соответствующие этим данным
  • Данные из блока данных должны быть доступны в коде на этапе игры
Пример использования:
В РО в описании предмета с равкодом I001 добавляем строку "+coolness 100500", которая в релизной версии карты будет заменена строкой "очень крутой предмет +100500" с цветовой окраской соответствующей положительным характеристикам. Также в коде карты доступ к переменной ItemData.I001.coolness должен вернуть значение 100500.

Генератор данных

  • Возможность описать в текстовом формате данные для объектов в РО или процесс их генерации
  • Возможность выполнить генерацию этих данных либо их обновление в уже сгенерированных данных
  • Встроенная опциональная SLK-оптимизация, позволяющая сгенерировать таблицы с данными для последующего их использования в релизной верси карты
  • Возможность автоматического удаления неиспользуемых данных

Послесловие

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


Views: 739

Shown only a small set of comments around the pointed one. Go to actual.

Drulia_san #6 - 2 years ago 0
Голосов: +0 / -0
prog:
Drulia_san, так фишка хорошо сделанного внешнего сборщика в том, что РО никуда не девается. Разве что кнопку для запуска проверки карты приходится нажимать не в WE, а где-то снаружи, в виде батника или кнопки в среде разработки для кода. Более того, что старая версия моей тулзы о которой этот пост, что новая - обе предназначены именно для работы с РО и кодом одновременно.
Как твоя новая тулза называется? Хочу опробовать
GetLocalPlayer #7 - 2 years ago 0
Голосов: +0 / -0
На хайве и US форумах варкрафта бурги то и дело мне раз 10 советовали именно ceres, юзабилити которого стремилась к нулю, про остальные не слышал.
Ceres давал контроль над процессом сборки через Lua, код карты и сборщика в одном файле. Идея хорошая, но автор ушел в афк.
prog #8 - 2 years ago 0
Голосов: +0 / -0
Drulia_san, так новая версия Fly Data Processor пока только в планах, о чем и написан пост под которым мы комменты сейчас строчим. А сборщик я свой пока просто не выкладывал, чтоб не получилось как со старым Fly Data Processor, который был выложен слишком сырым, а потом у меня закончилось свободное время.
Будет что-то пригодное к использованию широкой аудиторией - сообщу.
Drulia_san #9 - 2 years ago 0
Голосов: +0 / -0
А что посоветуешь из текущих публичных сборщиков?
prog #10 - 2 years ago 0
Голосов: +0 / -0
Drulia_san, я бы рекомендовал посмотреть поделия от назарпанка и скорпа здесь на xgm, для начала. Ну и плагин warcraft-vscode к vscode ради простоты его установки и использования. Если vscode, то к нему еще языковой сервер под Lua от sumneko, он имхо, топ среди альтернатив. Остальные сборщики мне не понравились по той или иной причине, так что я не запомнил особо где их видел.
NazarPunk #11 - 2 years ago 3
Голосов: +3 / -0
prog #13 - 2 years ago (изм. ) 0
Голосов: +0 / -0
NazarPunk, так я ушел их искать какраз, а ты уже тут как тут)

Еще есть вот такая штука, но я не знаю что там за статус разработки нынче

Shown only a small set of comments around the pointed one. Go to actual.