Files

T

sindoring a8f5f8217f Principles: dungeons and raids, boss mechanics an open question

The editor builds a dungeon's or raid's plain parts: map and entrance, mobs and packs, patrols,
loot, doors and objects, binding and reset. Boss mechanics are not built in it yet; how to author
them is the owner's open question, and the two mechanisms the core has (EventAI rows in the world
database, C++ scripts) are noted for it.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

2026-10-31 13:13:43 +04:00

5.4 KiB

Raw Permalink Blame History

Основные принципы MoonWell Editor

Сформулированы владельцем проекта 2026-10-31. При противоречии этот документ главнее плана в STATUS.md. Если задача не укладывается в эти принципы, спроси владельца, а не обходи их.

Что такое MoonWell Editor

Инструмент геймдизайна. Через него создаётся контент мира. Цель — согласованность и единая среда разработки контента: каждое изменение мира проходит одним путём и доходит до клиента и сервера в согласованном виде.

Что делается в редакторе, а что в клиенте

В редакторе	В клиенте (MoonWell / Benilla)
Новые локации и редактирование ландшафта	Геймплей и механики ядра
NPC: расстановка, внешность, маршруты	QoL-улучшения
Предметы	Новые фичи клиента
Точки полёта и полётные маршруты (такси)
Транспорт
Квесты
Подземелья и рейды: простые части (см. ниже)

Если задача из правой колонки, редактор её не решает.

Подземелья и рейды

В редакторе собирается всё, что не требует программировать механики боссов: карта и вход, расстановка мобов и групп, патрули, добыча, двери и объекты, привязка и сброс. Механики боссов (фазы, способности по таймеру, реакции на события) в редакторе пока не делаются.

Открытый вопрос: как программировать механики боссов. Над этим владелец ещё думает, и решение за ним. Агент не выбирает подход сам и не начинает работу над механиками без его слова. В ядре сейчас есть два механизма:

события в базе (creature_ai_events и creature_ai_scripts, около 6 тыс. записей): их можно выпускать миграциями, как остальной контент;
скрипты на C++ (src/scripts ядра): требуют пересборки сервера и выходят за рамки трёх артефактов ниже.

Куда попадает результат

Клиентская часть собирает и правит существующие MPQ. Форматы Blizzard (MPQ, DBC, M2, WMO, ADT, BLP) не меняем: свой формат сейчас слишком дорог.
Серверная часть — это база vMaNGOS. Всё новое (NPC, предмет и так далее) попадает в миграцию. Механизм в ядре уже есть: sql/content/migrations, deploy/local/apply-content.sh, init-db.sh.
DBC, которые затрагивают сервер, уходят в S3. При новом релизе сборка mangosd скачивает DBC релиза из S3 и проверяет их до компиляции. Без них сборка не продолжается. Контракт — manifest релиза.

Как это должно ощущаться

Удобный интерфейс для редактирования DBC. Не таблицы с номерами, а превью там, где они помогают: например, полётная сеть на карте.
Максимально простой drag-and-drop:
- поставил NPC;
- указал маршрут точками;
- такси так же: точки и пути на карте;
- квесты тоже собираются в редакторе.
Пользователь — геймдизайнер, а не разработчик. Номера id, guid, патчей и таблиц редактор выбирает и проверяет сам и показывает только когда это нужно.

Что из этого следует для работы

Каждая новая возможность заканчивается артефактом одного из трёх видов: клиентский MPQ, миграция или DBC в S3. Иногда сразу несколькими. Интерфейс показывает, что именно изменится, до публикации.
Изменение, которое нельзя выразить этими артефактами, — сигнал остановиться и спросить владельца.
Превью и простота важнее полноты таблиц. Новый редактор сущности начинается с того, как геймдизайнер ставит её в мир, а не со списка полей.

5.4 KiB Raw Permalink Blame History Unescape Escape