Информация

Дата основания
Местоположение
Россия
Сайт
2gis.ru
Численность
1 001–5 000 человек
Дата регистрации

Блог на Хабре

Обновить
Комментарии 10
Связка React + Redux подходит для разработки игр, если вы:
<...>
готовы не просто отойти от «лучших практик», но и внедрять откровенные антипаттерны с пониманием, к чему это приведет;

Я вот не могу читать это как-то иначе, чем «связка React + Redux подходит для разработки игр, если вы готовы её выкинуть и взять что-то более удобное».

Но за проделанную работу и статью — большое спасибо, теперь куда нагляднее видно, почему не стоит тащить стейт-менеджмент в критичный код обновления состояния игры, а VDOM в браузерный гейминг вообще :-)
Вы, конечно, молодцы, что сделали игру и статью написали.
Но, с одной стороны, вы еще больше прокачали навыки React + Redux, а с другой — упустили возможность расширить свой кругозор, попробовав технологии, которые используются в геймдеве.

Что брать на замену? Предлагайте варианты в комментариях.
Первым делом я посоветовал бы обратить внимание на Unity3d. Правда, давно с ним работал и не в курсе, как сейчас там с webgl. Вроде поддерживается.
unity.com/features/multiplatform
Он умеет компилировать под множество стандартных платформ. Потребуются некоторые правки под особенности каждой платформы, но тем не менее, 3 команды не понадобятся. Но в вашем случае достаточно было только под webgl сделать сборку.
Что касается бекенда для игр, есть готовые решения (из известных мне — photon server/cloud, playfab). Правда, на их изучения тоже не мало времени уйдет.
Как я написал в статье, были достаточно серьезные временные ограничения. Поэтому я не готов принять фразу «упустили возможность» в том виде как она есть, но соглашусь, что по итогам нашего опыта, я бы не назвал react+redux технологиями геймдева.

Тем не менее на unity мы успели взглянуть. Сейчас особо подчеркиваю, что мы отталкивались от конечных реализаций и не факт, что нашли лучшее, что есть в мире unity, но то, что мы увидели:

1. Загружалось очень долго из-за огромного размера чанков JS-кода.
2. На моём рабочем ноутбуке со встроенной видеокартой даже самые простейшие игры подлагивали

Причем не стоит недооценивать первый пункт — он доставлял бы боль нашим мобильным пользователям, коих было большинство (так как завлекали аудиторию пушами).

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

А за готовые решения бэкэндов для игр — отдельное спасибо!
А можно, пожалуйста, поподробнее о готовых решениях? Особенно про playfab.
Я с ними мало работал и довольно давно. Особо рассказывать нечего.
Playfab — облачный сервис с sdk, в котором на беке уже реализована таблица лидеров, push уведомления, авторизация, покупка за внутреигровые валюты, просмотр аналитики и многое другое.
Вот примеры уроков по старой версии:
www.youtube.com/watch?v=fGNpiqVi5xU&list=PLHCfyL7JpoPbLpA_oh_T5PKrfzPgCpPT5&index=1

Photon engine
Для бекенда мультиплеерных игр.
Photon server — вариант для бека на своем сервере; Photon cloud — облачная версия.
doc.photonengine.com/en-us/realtime/current/getting-started/realtime-intro
Я только такое делал на photon cloud:
drive.google.com/open?id=0B2hJEfyfLUDhd0VDbnB5Qi1Da2s
React + Redux


-А ты приманку насадил?
-Конечно, насадил!
-Какую?
-Мандарин
-Мандарин? Кто ловит рыбу на мандарин?


Игры это хайлоад, тут чем ближе к железу, тем лучше. Не хочу рекламировать напрямую нашу компанию, но мы занимаемся webGL уже несколько лет — нет в нем ничего нового.
Не пробовали отказаться от redux стора и использовать многоуровневую систему провайдеров контекста и его консумеров? Такое ощущение что контекст в 16-м реакте затем и вернули из небытия, т.к. полная пересборка стейта слишком затратная.
Даже не думали так делать. На мой взгляд, контексты созданы не для стэйт-менеджмента, их назначение пошарить между компонентами что-то глобально-общее.

А в качестве альтернативы Redux’у более быстрый и мутабельный MobX не рассматривали? Там и множественные сторы с отдельными подписками и вычисляемые значения, и более оптимизированная из коробки версия shouldComponentUpdate, и ещё много чего хорошего :)

Я не автор, но в таких небольших приложениях, я не вижу необходимости использовать менеджер состояний. Учитывая, что они могут пересекаться с кодом игровой логики, которая должна выполняться десятки раз в секунду, они могут стать источниками проблем, а не помощью. Какого-нибудь pubsub.js было бы вполне достаточно. Было бы проще, меньше проблемных мест, меньше кода.
В более больших проектах можно было бы выделить время и посмотреть, как влияют на производительность менеджеры состояний и повыбирать.
Я игры не писал на JS. Фз с какими проблемами сам бы столкнулся.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.