Добавлен prog,
опубликован
Не для публикации на главной
Если вам знакома утилита Fly Data Processor - хорошо. Если нет - ничего страшного, ведь текущая версия этой утилиты безнадежно устарела, да и не работала никогда толком. Но это в прошлом, а впереди - будущее. Весьма отдаленное будущее ввиду недостатка свободного времени, но это уже другая история. Дальнейшей разработке утилиты быть, но в новом направлении.
Если вам знакома утилита 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.
В РО в описании предмета с равкодом I001 добавляем строку "+coolness 100500", которая в релизной версии карты будет заменена строкой "очень крутой предмет +100500" с цветовой окраской соответствующей положительным характеристикам. Также в коде карты доступ к переменной ItemData.I001.coolness должен вернуть значение 100500.
Генератор данных
- Возможность описать в текстовом формате данные для объектов в РО или процесс их генерации
- Возможность выполнить генерацию этих данных либо их обновление в уже сгенерированных данных
- Встроенная опциональная SLK-оптимизация, позволяющая сгенерировать таблицы с данными для последующего их использования в релизной верси карты
- Возможность автоматического удаления неиспользуемых данных
Послесловие
Еще раз акцентирую внимание на том, что это не более чем манифест, цель которого формализовать план дальнейших действий и собрать обратную связь, на случай если у кого-то вдруг возникнут интересные идеи. О прогрессе разработки будет отдельный пост.
`
ОЖИДАНИЕ РЕКЛАМЫ...
Чтобы оставить комментарий, пожалуйста, войдите на сайт.
Отредактирован Drulia_san
Отредактирован Drulia_san
Но в любом случае интегрированный редактор мне ближе к душе, потому что под рукой всегда хочется иметь РО со всеми юнитами, абилками и бафами.
Будет что-то пригодное к использованию широкой аудиторией - сообщу.
Отредактирован prog