Документ описывает компонентную архитектуру игровой механики MMORPG, включая задачи по проектированию, систему разработки и балансировку игровых компонентов. Рассматриваются примеры реализации механик, таких как заклинания и задания, а также проблемы, связанные с дублированием функциональности и производительностью. Особое внимание уделяется созданию эффективных сервисов и редакторов для игровых элементов.

1. Илья Вайсмантехнический директор проекта,департамент клиентских игрwww.mail.ruКомпонентная архитектура игровой механики MMORPG

2. Оглавлениеwww.mail.ru2Постановка задачи Компонентная модель Последствия Дизайн

3. Сервисы

4. Клиент

5. РедакторыПостановка задачиwww.mail.ru3Постановка задачи Компонентная модель Последствия Дизайн

6. Сервисы

7. Клиент

8. РедакторыМеханика MMORPGwww.mail.ru4Классика:RPG-система предметы заклинания и пассивные способности навыки интерактивные объекты – мобы и устройства система спавна задания и скриптование зонСпецифика – всё, что угодно

9. Особенности MMOwww.mail.ru5Большое количество компонентовРаспределённые вычисленияЗащита от жульничества

10. Вопросы реализацииwww.mail.ru6Гарантия производительностиСвобода дизайнеровТрадиция. Дизайнеры не занимаются вопросами производительности.

11. Размер кирпичикаwww.mail.ru7Баланс между крайностями регулируется размером кирпичиков, из которых дизайнер собирает игру

12. Аргументацияwww.mail.ru8Низкая квалификация дизайнеровВысокая квалификация дизайнеровБольшие кирпичикиМаленькие кирпичики Меньше работы дизайнерам.

13. Рост гарантии эффективности работы игры.

14. Риски, связанные с большим количеством типов компонентов.

15. Код состоит из небольших независимы кусочков.

16. Большие возможности для повторного использования.

17. Отсутствие дублирования функциональности.Компонентная модельwww.mail.ru9Постановка задачи Компонентная модель Последствия Дизайн

18. Сервисы

19. Клиент

20. РедакторыПример сборки – заклинаниеwww.mail.ru10

21. Универсальные компонентыwww.mail.ru11УстройствоНавыкЗаклинаниеЗаданиеМобСпособностьПредметУсловиеВоздействиеДолговременный эффект

22. Опасность дублированияwww.mail.ru12Производя большое количество мелких элементов, легко наделать дубликатов или просто похожих запчастей.Эту тенденцию надо пресекать как можно раньше.

23. Непредвиденные ожиданияwww.mail.ru13Пример. Элементы типа «условие» легко проверять.Однако для реакции на их изменение каждый раз потребуется новый код.

24. Последствияwww.mail.ru14Постановка задачи Компонентная модель Последствия Дизайн

25. Сервисы

26. Клиент

27. РедакторыДизайнwww.mail.ru15Постановка задачи Компонентная модель Последствия Дизайн

28. Сервисы

29. Клиент

30. РедакторыЗаказана функциональностьwww.mail.ru16Это происходит со скоростью примерно одна задача на программиста в день.Заказ в текстовом видеДекомпозицияОбобщение компонентовРеализация недостающихИспользование существующихСборкапримераОбъяснение заказчикам, как этим пользоваться

31. Документацияwww.mail.ru17СхемыИмеют сложный дизайн, требуют подробного описания. Их немного и меняются они редко.КомпонентыУстроены просто, документируются именем и кратким описанием.

32. Сложная функциональностьwww.mail.ru18Пример сборки сложной функциональности – задание сопровожденияТриггер на сопровождаемомЗаставляет идти по маршруту, меняет поведение на агрессивное.Считает число сопровождающих, уничтожает носителя при обнулении.ЗаданиеИнициализирует ситуацию – развешивает триггеры на всех участников.По-разному обрабатывает ситуации «начать сопровождение» и «присоединиться к сопровождению».Триггер на сопровождающемСледит за удалением от сопровождаемого, за достижением им конца пути, за смертью всех участников.Специфичного кода нет

33. Повторное использованиеwww.mail.ru19А теперь – много заданий сопровождения, отличающихся деталями.Если никак не подпирать, число дизайнерских ошибок в заданиях сопровождения будет пропорционально числу заданий сопровождения.Выходы.Специальный код в редакторе (частное решение).Шаблоны ресурсов.

34. Сервисыwww.mail.ru20Постановка задачи Компонентная модель Последствия Дизайн