Вы думаете я не знаю что такое redis ? У меня статья есть на эту тему. Пусть другие и использую для мастштабирования веб приложений, а для игрового сервера 60.000 rps больно медленно.
Что бы дать точное количество нужно точно знать для какой игры. Мое решение не игра, а технология где сервер делает все расчёты в тч физики. Если использовать его как типовой роутер на прием и пересылку запросов от игроков то и больше цифра онлайн
Так или иначе 20к игроков разом это что же за карта должна быть...
"Всякие редисы" - делают не для масштабирования, а для хранения данных в первую очередь и они слишком медленные. Горизонтально масштабирумое решение можно и 200к разом. Это 6-ая по счету статья-вся информация разбита по частям
посмотрел - используется сервер на PHP и сама игра как я понял на JS. Моя идея не делать игры , а дать возможность сделать мультиплеер в играх сделанных на любой платформе (unity, unreal engine , godot , phaser 2d и самописные в т.ч.)
В дополнение предоставить web инструменты для работы с контентом догружаемым в игру и возможность самим дополнять из админ панели игровой сервер механиками (не погружаясь как там работает код сервера и куда что вкорячивать)
Некий конструктор сервера для игры. В основном это будет код физики игровой. Что бы не игрок сам рассчитывал , а сервер (что бы игроки не могли отправить что им вздумается все вычисления делает сервер, игрок лишь отправляет что он нажал)
5.1 стоит - эта версия обусловлена плагином php LuaSandbox. Плагины php уже написаны на Си и мне кажется если и улучшать то доработать его, но не понятно будет ли выигрыш в скорости в тч с ffi. С объектом работать в lua можно если сделать некие метотаблицы с сеттарами и геттарами и в целом жить можно особенное если кешировать свойства и при изменении объекта извне при следующем вызове lua передавать что изменилось...В любом случае Си я не знаю пока.
плюс не только сервером будет хорош будущий сервис а админ панелью (не знаю есть ли в фотоне такое - скажите)
Админка позволяет редактировать контент игрового мира (новые карты добавлять . npc и тп). Притом игра может быть как браузерной так и устанавливаться на устройства
Я исследую технологии (типа Redis и фреймворки типа workerman), сравниваю что сколько может обработать в секунду. И если что то сильно отстаёт - смотрю чем заменить
Отсюда берутся цифры (например есть возможность второй сервер сделать где будут хранится данные и обращаться к нему по тому же websocket смогут Сервисы. но насколько это будет лучше redis - надо смотреть ) https://github.com/walkor/GlobalData
у меня тоже будет Облачное решение. Как сервис. И мне кажется что фотон основан на том что сервером выступает экземпляр игры...что довольно требовательно по ресурсам
Плюс мне показалось достаточно сложно интегрировать в клиент...Те там библиотеки определенные
Я же смотрю в стороны REST API которая возвращает и получает только текстовые даныне. А тот кто делает игру сам решает что с ними делать и как там строить анимации и тп
Разумеется, в задумке есть и коммерческая выгода. Онлайн имеется в виду 1 сервер, одно ядро 4 Гб оперативной памяти (на одной локации или разбросанных по миру 500 игроков по моим подсчётам сервер выдержит и в текущем состоянии, но я ориентируюсь на другие цифры)
Ну а почему бы не сделать. Время тут главный ресурс. Определюсь с архитектурой и технологиями - пойдет дело быстрее (сами игровые механики делаются за пару дней. с технологиями для хранения данных сижу неделю с тестами и исследованиями)
И я на согласен что redis "просто для хранения использовать глупо" - это его основная функция и довольно быстрая по сравнению с sql базами
И локаций может быть неограниченное число. Некоторые на одном физическом сервере, другие на другом и игроки по ним ходят
У меня мастштабирование идёт целыми локации игровыми.
Вы думаете я не знаю что такое redis ? У меня статья есть на эту тему. Пусть другие и использую для мастштабирования веб приложений, а для игрового сервера 60.000 rps больно медленно.
речь про совместных онлайн. Не про игры с комнатами по 5-20 игроков
Текущий vps за 10$ без оптимизации полагаю выдержит не более 2000 онлайн , вот ссылка на последние тесты http://my-fantasy.ru/articles/frontend/index/eyJpZCI6OX0=
Что бы дать точное количество нужно точно знать для какой игры. Мое решение не игра, а технология где сервер делает все расчёты в тч физики. Если использовать его как типовой роутер на прием и пересылку запросов от игроков то и больше цифра онлайн
Так или иначе 20к игроков разом это что же за карта должна быть...
"Всякие редисы" - делают не для масштабирования, а для хранения данных в первую очередь и они слишком медленные. Горизонтально масштабирумое решение можно и 200к разом. Это 6-ая по счету статья-вся информация разбита по частям
Проект что я разрабатываю прикруживается к любому игровому движку что может открыть Websocket (это и unity и unreal engine и js)
Ну кстати в мой проект можно встраивать JS код из админ панели (для расчёта физики)
посмотрел - используется сервер на PHP и сама игра как я понял на JS. Моя идея не делать игры , а дать возможность сделать мультиплеер в играх сделанных на любой платформе (unity, unreal engine , godot , phaser 2d и самописные в т.ч.)
В дополнение предоставить web инструменты для работы с контентом догружаемым в игру и возможность самим дополнять из админ панели игровой сервер механиками (не погружаясь как там работает код сервера и куда что вкорячивать)
Некий конструктор сервера для игры. В основном это будет код физики игровой. Что бы не игрок сам рассчитывал , а сервер (что бы игроки не могли отправить что им вздумается все вычисления делает сервер, игрок лишь отправляет что он нажал)
5.1 стоит - эта версия обусловлена плагином php LuaSandbox. Плагины php уже написаны на Си и мне кажется если и улучшать то доработать его, но не понятно будет ли выигрыш в скорости в тч с ffi. С объектом работать в lua можно если сделать некие метотаблицы с сеттарами и геттарами и в целом жить можно особенное если кешировать свойства и при изменении объекта извне при следующем вызове lua передавать что изменилось...В любом случае Си я не знаю пока.
Сейчас - отладка и больше просадка в скорости работа с базами.
плюс не только сервером будет хорош будущий сервис а админ панелью (не знаю есть ли в фотоне такое - скажите)
Админка позволяет редактировать контент игрового мира (новые карты добавлять . npc и тп). Притом игра может быть как браузерной так и устанавливаться на устройства
я не могу придумать такиех фичей и логик которые бы нельзя было реализовать если сервер быстрый...поэтому...делаю сервер )
в споре раздается истина :)
так что можно сказать...с потолка...пока потолок не достигнут
Я исследую технологии (типа Redis и фреймворки типа workerman), сравниваю что сколько может обработать в секунду. И если что то сильно отстаёт - смотрю чем заменить
Отсюда берутся цифры (например есть возможность второй сервер сделать где будут хранится данные и обращаться к нему по тому же websocket смогут Сервисы. но насколько это будет лучше redis - надо смотреть ) https://github.com/walkor/GlobalData
в любом случае второй сервис , для простеньких 2Д игр сделать оказалось сложнее чем это кажется на первый взгляд
у меня тоже будет Облачное решение. Как сервис. И мне кажется что фотон основан на том что сервером выступает экземпляр игры...что довольно требовательно по ресурсам
Плюс мне показалось достаточно сложно интегрировать в клиент...Те там библиотеки определенные
Я же смотрю в стороны REST API которая возвращает и получает только текстовые даныне. А тот кто делает игру сам решает что с ними делать и как там строить анимации и тп
Да вот нет, там не бесплатно а в прицепе это максимум (я честно сказать не вникал , ссылку взял из кометов)
https://doc.photonengine.com/en-us/realtime/current/troubleshooting/faq#what_is_the_maximum_number_of_players_supported_by_photon_rooms_
Разумеется, в задумке есть и коммерческая выгода. Онлайн имеется в виду 1 сервер, одно ядро 4 Гб оперативной памяти (на одной локации или разбросанных по миру 500 игроков по моим подсчётам сервер выдержит и в текущем состоянии, но я ориентируюсь на другие цифры)
Ну а почему бы не сделать. Время тут главный ресурс. Определюсь с архитектурой и технологиями - пойдет дело быстрее (сами игровые механики делаются за пару дней. с технологиями для хранения данных сижу неделю с тестами и исследованиями)