Это дев приятель, да и к тому же обучающий материал больше, чем руководство к действию, каждый сделает как ему виднее, в проде очевидно вся работа с ключами будет автоматизирована с vault/let's encrypt, вероятно выпушу вторую расширенную статью на этот счет (окончательная prod версия кластера). Прилепил в данный момент schema registry+redpanda console, на проде/stage также планируется keycloak oauthbearer с теми самыми ACL про которых "ни слова" в конце статьи, которая и так портянка сама по себе
Да, я в курсе. Просто практика показывает, что в большинстве случаев zookeeper до сих пор часто используется. Если есть возможность то конечно же рекомендуется использовать Kraft, более того в чартах он есть
Может быть 1-2 простых алгоритмических задачи на собеседовании и уместны, но когда весь собес превращается в полуторачасовое разжевывание кишков языка, которые не имеют ничего общего с реальной работой, это бред. Яндекс например этим маразмом занимается. А отсеивать кандидатов можно и в автоматическом режиме, для этого есть различные опросники, тесты, с автоматической проверкой, рекомендательные и сопроводительные письма. Собеседующий человек в первую очередь должен смотреть на опыт, проекты и увлеченность потенциального работника, а не это вот все.
Нагрузочное тестирование мультиплеера - дело тонкое, нужен отдельный выделенный мощный сервер, для тестов нужно разграничивать 2 части - это сам netty с nio-обработкой запросов и игровой луп, в данном случае - в виде ScheduledExecutorService, netty может справиться с коллосальной нагрузкой и миллион запросов в секунду, но с игровым лупом ситуация сложнее, зависит от кол-ва вычислений, заложенных в него. Именно луп с вычислениями тонкое место, здесь прямая зависимость от мощности процессора или видеокарты(смотря где они происходят). Думаю чуть позже даже напишу отдельную статью на эту тему, с результатами как раз. Gatling тесты под свой мультиплеер как таковые не писал, не вижу необходимости, т.к. продукт не готов, скрипты тестов будут очень замудреные, а о большом кол-ве пользователей и говорить не приходится, даже в agar.io пиковая нагрузка состовляла 10k пользователей в ДЕНЬ, вероятно в секунду - не более 1000, это очень мало. Тестировал на своей машине визуально производительность игрового лупа с мок-тестовыми НПС(пользователями), чтобы проверить как вообще двигаются персонажи, на каком этапе усиливается задержка, впринципе, 500 комнат по 20 человек и серверным тиком в 10ms спокойно держит(проц слабенький, 8 ядер, в цикле - обработка коллизий на сеточных моделях и расчеты положения), а дальше начинает поддтормаживать. С хорошей балансировкой нагрузки нескольких нод, думаю 50-100k игроков и более с периодичностью 10ms вполне осилит, а если произвести оптимизации, отказаться от JSON в пользу бинарных данных, то и подавно. В общем, конкретные цифры будут позже в новой статье.
Балансировщик можно прикрутить любой, взависимости от того какая платформа будет под ним, пока до этого не дошло. Вероятно haproxy будет вполне достаточно
Поскольку я Java разработчик то именно она ближе ко мне, если нагрузка будет возрастать на сервер, то можно прилепить low-latency GC вроде shenandoah zgc и тд. Если и этого не хватает, то на помощь придет горизонтальное масштабирование и балансировка нагрузки. Если нужны GPU вычисления, то конечно же найдутся Java обертки вокруг OpenCL, Cuda и пр. Тем не менее, NodeJS сервера держат огромное кол-во игроков, а именно они используются в большинстве io мультиплееров, и джавовский будет ничуть не хуже. Уверен, что 10 000 игроков в момент времени обработать вполне возможно. Разумеется думал и про C++, это идеальный язык для написания подобного рода вещей, думаю, после того как взлетит мой текущий проект, второй проект будет именно на C++ (libuv, libevent).
Суть фейзера это как раз таки разработка через код, мне как разработчику это легче, судя по всему и создатель фреймворка делает также. Про структуру, это сильно зависит от конечной задумки: если игра достаточно проста, а в качестве gui допускается использовать обычные react/html компоненты то темплейты выше самое то. Все сводится к обычной верстке, React компоненты в одном пакете, сцены в другом, персонажи и модели в третьем, сеть в четвертом, грубо говоря. Если же ui предполагается быть нарисованным, то это уже другая история, core и плагины phaser думаю берут на себя эту задачу, кстати тут как раз ide была бы хорошим подспорьем, но только тут. Что касается геймплея, так или иначе, вся логика находится на сценах и в большинстве случаев они разрастаются до существенных обьемов и требуют декомпозиции, это норма для фейзера. Работа с сетью на ваше усмотрение, может растекаться на все приложение, видел также вариант перевода вебсокет сообщений во внутренние события phaser’а, что тоже выглядит удобно. IDE это конечно хорошо, но ее отсутствие не мешает мне писать свой мультиплеер. А уж если художественные материалы специально рисуются под вашу игру то совсем проблем не вижу, не придется подгонять анимации под конкретную текстуру и тд. Мне лично не подошел только Tiled как редактор уровней, ибо была проблема в отрисовке полигонов, и пришлось написать свой - заняло пару дней.
Спасибо, прилепил redpanda console, отличная штука
Это дев приятель, да и к тому же обучающий материал больше, чем руководство к действию, каждый сделает как ему виднее, в проде очевидно вся работа с ключами будет автоматизирована с vault/let's encrypt, вероятно выпушу вторую расширенную статью на этот счет (окончательная prod версия кластера). Прилепил в данный момент schema registry+redpanda console, на проде/stage также планируется keycloak oauthbearer с теми самыми ACL про которых "ни слова" в конце статьи, которая и так портянка сама по себе
В проде очевидно вся работа с ключами будет автоматизирована с vault/let's encrypt, вероятно выпушу вторую расширенную статью на этот счет
Да, я в курсе. Просто практика показывает, что в большинстве случаев zookeeper до сих пор часто используется. Если есть возможность то конечно же рекомендуется использовать Kraft, более того в чартах он есть
Может быть 1-2 простых алгоритмических задачи на собеседовании и уместны, но когда весь собес превращается в полуторачасовое разжевывание кишков языка, которые не имеют ничего общего с реальной работой, это бред. Яндекс например этим маразмом занимается. А отсеивать кандидатов можно и в автоматическом режиме, для этого есть различные опросники, тесты, с автоматической проверкой, рекомендательные и сопроводительные письма. Собеседующий человек в первую очередь должен смотреть на опыт, проекты и увлеченность потенциального работника, а не это вот все.
Нагрузочное тестирование мультиплеера - дело тонкое, нужен отдельный выделенный мощный сервер, для тестов нужно разграничивать 2 части - это сам netty с nio-обработкой запросов и игровой луп, в данном случае - в виде ScheduledExecutorService, netty может справиться с коллосальной нагрузкой и миллион запросов в секунду, но с игровым лупом ситуация сложнее, зависит от кол-ва вычислений, заложенных в него. Именно луп с вычислениями тонкое место, здесь прямая зависимость от мощности процессора или видеокарты(смотря где они происходят). Думаю чуть позже даже напишу отдельную статью на эту тему, с результатами как раз.
Gatling тесты под свой мультиплеер как таковые не писал, не вижу необходимости, т.к. продукт не готов, скрипты тестов будут очень замудреные, а о большом кол-ве пользователей и говорить не приходится, даже в agar.io пиковая нагрузка состовляла 10k пользователей в ДЕНЬ, вероятно в секунду - не более 1000, это очень мало. Тестировал на своей машине визуально производительность игрового лупа с мок-тестовыми НПС(пользователями), чтобы проверить как вообще двигаются персонажи, на каком этапе усиливается задержка, впринципе, 500 комнат по 20 человек и серверным тиком в 10ms спокойно держит(проц слабенький, 8 ядер, в цикле - обработка коллизий на сеточных моделях и расчеты положения), а дальше начинает поддтормаживать. С хорошей балансировкой нагрузки нескольких нод, думаю 50-100k игроков и более с периодичностью 10ms вполне осилит, а если произвести оптимизации, отказаться от JSON в пользу бинарных данных, то и подавно. В общем, конкретные цифры будут позже в новой статье.
Балансировщик можно прикрутить любой, взависимости от того какая платформа будет под ним, пока до этого не дошло. Вероятно haproxy будет вполне достаточно
Да, VertX хороший фреймворк, но пока не пробовал.
Поскольку я Java разработчик то именно она ближе ко мне, если нагрузка будет возрастать на сервер, то можно прилепить low-latency GC вроде shenandoah zgc и тд. Если и этого не хватает, то на помощь придет горизонтальное масштабирование и балансировка нагрузки. Если нужны GPU вычисления, то конечно же найдутся Java обертки вокруг OpenCL, Cuda и пр. Тем не менее, NodeJS сервера держат огромное кол-во игроков, а именно они используются в большинстве io мультиплееров, и джавовский будет ничуть не хуже. Уверен, что 10 000 игроков в момент времени обработать вполне возможно. Разумеется думал и про C++, это идеальный язык для написания подобного рода вещей, думаю, после того как взлетит мой текущий проект, второй проект будет именно на C++ (libuv, libevent).
Есть немножко кода на моем гитхаб профиле, в данный момент как раз занимаюсь его наполнением и закину скоро что нибудь еще
Если творчество вам нравится и доставляет удовольствие то это не труд, а вызов
Суть фейзера это как раз таки разработка через код, мне как разработчику это легче, судя по всему и создатель фреймворка делает также. Про структуру, это сильно зависит от конечной задумки: если игра достаточно проста, а в качестве gui допускается использовать обычные react/html компоненты то темплейты выше самое то. Все сводится к обычной верстке, React компоненты в одном пакете, сцены в другом, персонажи и модели в третьем, сеть в четвертом, грубо говоря. Если же ui предполагается быть нарисованным, то это уже другая история, core и плагины phaser думаю берут на себя эту задачу, кстати тут как раз ide была бы хорошим подспорьем, но только тут. Что касается геймплея, так или иначе, вся логика находится на сценах и в большинстве случаев они разрастаются до существенных обьемов и требуют декомпозиции, это норма для фейзера. Работа с сетью на ваше усмотрение, может растекаться на все приложение, видел также вариант перевода вебсокет сообщений во внутренние события phaser’а, что тоже выглядит удобно. IDE это конечно хорошо, но ее отсутствие не мешает мне писать свой мультиплеер. А уж если художественные материалы специально рисуются под вашу игру то совсем проблем не вижу, не придется подгонять анимации под конкретную текстуру и тд. Мне лично не подошел только Tiled как редактор уровней, ибо была проблема в отрисовке полигонов, и пришлось написать свой - заняло пару дней.