Я хотел, чтобы в моей MMO могли творить другие. Пришлось выбирать, чей код пускать на сервер, ч. 5

Я хотел, чтобы в моей MMO могли творить другие. Пришлось выбирать, чей код пускать на сервер, ч. 5

Я никогда не хотел делать игру только для себя. Ещё с тех времён, когда мы с друзьями мечтали о своей онлайн-игре, мне нравилась мысль, что мир можно строить вместе. Друзья выросли и разошлись по своим делам, но идея осталась: пусть на моём сервере любой человек сможет придумать свою механику — квест, заклинание, поведение монстра — и добавить её, не залезая в код сервера.

Звучит красиво. А на деле это значит пустить чужой код туда, где крутится живой мир. И сделать так, чтобы он ничего не сломал и не затормозил.

Песочница для чужих идей

Чужой код нужно запирать в «песочнице»: он работает сам по себе, до файлов и данных других игр не дотягивается. Оставался вопрос, на каком языке его писать. Я сравнил два самых популярных варианта для таких задач — Lua и JavaScript.

Все замеры я делал на скромной машине: два ядра, 4 гигабайта памяти. Мне было важно понять, выдержит ли идея не лабораторные условия, а обычный недорогой сервер.

Lua: старый проверенный друг

Я хотел, чтобы в моей MMO могли творить другие. Пришлось выбирать, чей код пускать на сервер, ч. 5

На Lua до сих пор пишут квесты, диалоги и баланс во многих онлайн-играх. Я встроил его в сервер и получил около 70 тысяч вызовов в секунду. А вот живая игровая механика — например, восстановление здоровья — вместе со всей обвязкой заняла 0,17 тысячных секунды.

Вот так это выглядело в админке: пишешь механику прямо в браузере, и она сразу работает в игре.

Я хотел, чтобы в моей MMO могли творить другие. Пришлось выбирать, чей код пускать на сервер, ч. 5
Я хотел, чтобы в моей MMO могли творить другие. Пришлось выбирать, чей код пускать на сервер, ч. 5

JavaScript: быстрее, но капризнее

Я хотел, чтобы в моей MMO могли творить другие. Пришлось выбирать, чей код пускать на сервер, ч. 5

Второй претендент — JavaScript на движке V8, том же, что в Google Chrome. Если код подготовить заранее, он выдавал до 600 тысяч вызовов в секунду. Зато каждый раз передавать ему свежие данные из сервера оказалось медленно — приходилось хитрить.

Что я понял

Оба языка годятся. JavaScript популярнее у новичков и богаче библиотеками. Lua проще встраивается и привычен тем, кто делал моды для старых игр. Но главный вывод был другим: чтобы чужой код жил на сервере безопасно, мне предстояло перестроить почти всю архитектуру.

Честно, в тот момент это было неприятное открытие. Зато именно из него выросла песочница, в которой сегодня работают все механики моей платформы — и мои, и чужие.

А вы бы хотели добавлять свои механики в чужую игру? На каком языке вам было бы удобнее?

История:

  1. Введение
  2. Масштабируемость и асинхронность
  3. WebSocket
  4. Redis
  5. LUA и JavaScript
  6. Выбор технологий, протокола и архитектурный шаблон Entity Component System
  7. Игровые локации (тайловые карты)
  8. Клиентская часть на Unity
  9. Игровые серверные механики
  10. Открытый бесшовный мир в 2D игре
  11. FPS, Ping, паузы между командами, интерполяция и экстраполяция
  12. Очереди и параллельное программирование на CPU
  13. Event-driven паттерн, JSON-RPC и почему не сервисная (SOA) архитектура
  14. Сетевая карта и задержка кадра (Latency frame) по RFC 2544 (1242)
  15. Создание сервера для онлайн ММО игр на PHP
  16. Готовое MVP сервиса 2D MMO RPG игр (realtime)
  17. Я научил ИИ делать мою MMO: игровая фича теперь рождается из одного описания
  18. Конвейер контента для MMO: импорт анимации, экипировка и обновление игры без патчей
  19. Каталог ассетов и git: как командой вести игру в облаке
  20. Как я тестирую код, который пишет ИИ: контракты вместо тестов
  21. Бесшовный мир: как карты MMO сшиваются в одно целое
  22. Сколько обходится содержание одного игрока
1133