Программирование игр, создание игрового движка, OpenGL, DirectX, физика, форум
GameDev.ru / Программирование / Форум / Архитектура много пользовательского игрового сервера.

Архитектура много пользовательского игрового сервера.

Поделиться

Страницы: 1 2 3 Следующая

joubПостоялецwww9 сен. 201718:12#0
Доброго всем дня. Подскажите что почитать на тему создания многопользовательских игровых серверов. Желательного на веб советах.
В частности интересует распределение подключений и ресурсов самого сервера. Возможно есть примеры более-менее не сложные но проверенные боевым опытам.
Или есть хорошая литература по этой теме.
И желательно на с++ или java, второе предпочтительней.
kvakvsПостоялецwww9 сен. 201719:41#1
Для простоты можно начать с асинхронных сокетов на любом удобном языке.
Такая программа будет обрабатывать множество подключений в одном треде быстро по очереди, и её вполне может хватить на несколько сотен подключенных клиентов, а если игра простая то и на несколько тысяч. Масштабируется такая программа запуском копий сервера в других тредах или просто запуском копий программы по числу имеющихся на сервере ядер.

А как начать? Очень просто
google://java async websocket game

ChupakaberПостоялецwww9 сен. 201720:32#2
в целом звучит, будто необходим по меньшей мере видео-туториал "как за 5 минут сделать" с применением указанных технологий

во-первых: архитектура сервера игры подразумевает выбор всех технологий и особенностей, составляющих этот сервер, то есть делать на java'е , плюсах, или чем-то ещё это уже рекомендация к архитектуре а не просто хотелка

во вторых: более-менее не сложные примеры это заведомо упрощённая архитектура, имеющая все соответствующие минусы, кроме одного - сложности в реализации и трудоемкости

это то, что у меня не вязалось в сабже и 0-посте
далее детально

joub
> Желательного на веб советах.
полагаю, тут опечатка в слове "веб-сокетах"
почему желательно? есть ли тут альтернатива? если это браузерная игра, то коммуникация может происходить тремя способами:
веб-сокеты (tcp),
get/post запросы (http) - заведомо непроизводительны, плюсов нет у такого выбора
webrtc (udp) - вроде как преимущество в no-reliable пакетах, но очень спорное, и большой недостаток собственно в серверной архитектуре с ice/stun/turn дополнительными серверами и более тяжелой (по производительности) обработкой пакетов на стороне игрового сервера

если что забыл - напомните
так что не вижу тут альтернатив в плане архитектурного выбора коммуникации

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

так как подразумевается браузерка, полагаю подразумевается MMO, а не инициируемый игроком мультиплеер до 64 игроков на сервере
значит актуален такой выбор:
1. на каждое подключение свой поток
2. на каждую глобальную задачу свой поток
и выбор очевиден, на каждое подключение отдельный поток приведёт к невероятным потерям по производительности на накладных расходах с потоками
значит потоки должны укладываться примерно в число доступных ядер серверного железа помноженные в 2-5 раз, чтобы не терять производительности
т.е. один поток на приём сообщений от клиентов, один поток на обработку этих сообщений и распределение по задачам, один поток на выполнение задач игровой логики, ещё один на обработку отправки сообщений клиентам, и так далее, т.е. все потоки работают со своим пулом неких сущностей (подключений игроков, списка сообщений, списка задач и т.д.)

далее вопрос сложнее, с учетом требований: горизонтальная масштабируемость, т.е. распределение мощностей на несколько серверов-компьютеров
с одной стороны хорошая архитектура должна поддерживать такую возможность, чтобы не переписывать кучу кода, когда понадобится расширить мощности сервера новыми железками
а с другой
joub
> примеры более-менее не сложные но проверенные боевым опытам.
требование простой реализации, типа чтобы время разработки сэкономить
и тут возникает вопрос, что же на самом деле нужно? качественная архитектура, или быстро и просто в реализации?

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

то есть тут универсального туториала уже нет, в большинстве немаловажных вопросов важен контекст

joubПостоялецwww9 сен. 201720:51#3
Веб сокеты выбраны не с проста. Во первых к ним модно подключать клиента как обычного сокет приложения так и сктриптик на js. т.е. не больших ограничений для стека технологий клиентского приложения.

Да, и в самом начале - "что почитать" статейки, тутариалы, может книженции какие... С примерами желательно. Я вас не прошу сервер писать, или дать мне готовят код от и до.
То что мной задумывается - достаточно сложное по своей структуре и логике, и что бы понять на сколько это вообще асе реализуемой хотелось бы ознакомиться с какими-то примерами архитектур...

ChupakaberПостоялецwww9 сен. 201721:11#4
joub
> хотелось бы ознакомиться с какими-то примерами архитектур...
так вот в том то и вопрос: с архитектурой ознакомиться или с примерами простейших реализаций?
архитектура это набор правил и выборов

быстро нагугленное по архитектуре:
https://www.youtube.com/watch?v=af_UkpkyJV8
смотри видео, практически всё по делу, к твоему случаю можно применить также практически всё думаю, хоть и не знаю что у тебя за "достаточно сложное по своей структуре и логике"

примеры кода java netty websockets думаю нагуглить сам в состоянии, если это тебе нужно, а не архитектура

ZabПостоялецwww9 сен. 201721:36#5
joub
> Веб сокеты выбраны не с проста. Во первых к ним модно подключать клиента как
> обычного сокет приложения так и сктриптик на js. т.е. не больших ограничений
> для стека технологий клиентского приложения.
Ошибаешься. В этом случае как раз максимум ограничений. Зачем тебе тащить с собой всю инфраструктуру встраивания в броузеры, если твоя задача этого не требует?

Книжек хороших для начинающих не знаю по этой тематике, к сожалению. Сам когда-то осваивал достаточно долго (порядка года), постепенно открывая для себя те или иные аспекты.

joubПостоялецwww9 сен. 201722:12#6
Мне кажется не так там и много чего... Зато клиент может быть как браузер на любом устройстве, так и приложение на планете или смартфона, тем более все туда катится...
ZabПостоялецwww9 сен. 201722:37#7
joub
Рассматривай конкретную задачу, а не философски рассуждай. И сразу же окажется, скорее всего, что "клиента как броузера" у тебя все равно не будет, а поддержка броузерных протоколов мало того что сожрет в десятки и сотни раз больше ресурсов, так еще и на структуру сервера наложит мучительные ограничения.

Это в том случае, конечно, если у тебя есть клиент игры. Если же игра броузерная, да еще и безплагиновая, все делается на сервере - иной расклад.

ChupakaberПостоялецwww9 сен. 201723:02#8
joub
> Зато клиент может быть как браузер на любом устройстве, так и приложение на
> планете или смартфона, тем более все туда катится...
кроссбраузерная онлайн ммо игра это миф

Zab
> Рассматривай конкретную задачу, а не философски рассуждай.
++
предметная область всегда легче всего изучается на конкретной задаче
joub
не старайся сделать на будущее все возможные варианты развития событий, ориентируйся на что-то конкретное, что ты можешь сразу выбрать и утвердить как самое лучшее и максимально узко старайся ставить задачу себе. это и по трудозатратам и по итоговой производительности выйдет в плюс
ну а серверная архитектура это вообще про другое, это бэкэнд, который впринципе клиенту игры не виден, всё что от транспортного протокола и дальше
самое полезное, что ты можешь сделать в архитектуре сервера это сделать транспортный протокол модульным, чтобы ты не меняя архитектуру сервера в будущем мог подключить модуль websocket-ов и отключить например http модуль, или голый udp модуль, или использовать два-три протокола разных одновременно для браузерных, мобильных и десктопных клиентов, это вот решение архитектурное уже

joubПостоялецwww9 сен. 201723:32#9
Мморпг. Да, миф, а хочется сделать реальностью...
Я не планируют писать полноценного клиента, моя идея разработка именно сервера с открытым АПИ (тут можете смеяться и думать что хотите).
Принцип протокола и вообще работы с серверам мне понравился когда я копал апи бинари.ком, по заказу клиента.
В планах самое простое. Сервер авторизации и статы - это rest обычный, сервера миров (да -именно сервера, на мир по серверу) это на сокетах ...
А веб сокеты хороши ещё и тем что не надо париться безопасностью, а просто повесить на https.
9К720Участникwww9 сен. 201723:45#10
joub
> А веб сокеты хороши ещё и тем что не надо париться безопасностью, а просто
> повесить на https.
Вообще параллельные вещи
ZabПостоялецwww9 сен. 201723:45#11
Если в игре предполагается что несколько игроков бегают друг вокруг друга, надо передавать координаты чаще раза в секунду, это сразу же отметает реализацию через веб-интерфейсы. Слишком тяжеловесные сообщения. Мало того, что они текстовые, так еще и снабжены гигантскими обязательными неинформационными частями. И сервер не может слать ничего по своей инициативе, только отвечать на запросы клиента, что тоже порождает лишний трафик запросов "А нет ли у вас там для меня чего-нибудь?". И UDP использовать не сможешь, гарантированная доставка может доставлять неприятности, когда обрывает связь вместо потери части сообщений.
И это только часть неприятностей от веб формата.
kvakvsПостоялецwww10 сен. 20172:09#12
joub
Вернись к моему ответу в посте №1
Найди пример асинхронного сервера вебсокетов, и пиши свою игру.
Советчиков с многопоточными серверами не слушай. Там неизведанная земля и драконы, игру так никогда не напишешь, пока будешь бороться с багами.

Пишешь логин и вход в мир.
Пишешь карту и перемещение по ней.
Пишешь бой.
Молодец.

Архитектуру не усложняй, делай всё проще. Чем проще сделаешь, тем потом легче будет расширить.

Правка: 10 сен. 2017 2:10

ZabПостоялецwww10 сен. 20173:05#13
kvakvs
> Советчиков с многопоточными серверами не слушай. Там неизведанная земля и драконы, игру так никогда не напишешь, пока будешь бороться с багами.
Как раз с многопоточными серверами все просто. Сделать в разы проще асинхронного. И багам взяться неоткуда, в общем то.
Но это путь в никуда, дальше тестов не пойдет. Потом придется все выкинуть и делать заново асинхронный вариант.
На 300 юзеров можно и многопоточный сервер соорудить, с соответствующим количеством потоков системы еще справляются, хоть и не без тормозов.
ChupakaberПостоялецwww10 сен. 20173:40#14
Zab
> Потом придется все выкинуть и делать заново асинхронный вариант.
> На 300 юзеров можно и многопоточный сервер соорудить, с соответствующим
> количеством потоков системы еще справляются, хоть и не без тормозов.
есть конечно разные реализации названные асинхронными, но несколько штук реализаций асинхронных сокетов из разных языков на ум приходят, которые создают отдельный поток под свою задачу
и тут как раз 300+ юзеров с их в лучшем случае 600+ потоков уже начнут создавать существенный оверхед
если же в реализации асинхронного сокета используется один отдельный поток для приёма и обработки приходящих данных, и один отдельный для отправки, то для массивности 5000+ подключений это более рациональный вариант, но правда с другой стороны будут другие проблемы - большая задача по обработке пришедшего сообщения заблокирует всю движуху пока она не отработается
например 100 игроков присылают свой пользовательский ввод и 1 игрок присылает запрос на список гильдий сервера, и пока этот список гильдий не будет сформирован и отправлен все 100 игроков со своим пользовательским вводом будут лагать. в этом случае неплохо при снятии сообщения с сокета класть его в отдельную коллекцию с пометкой какого типа этот пакет (пользовательский ввод, или нагруженный запрос)
и добавить ещё два (!) потока, один поток из коллекции сообщений достает и обрабатывает сообщения быстрообрабатываемые и частые. а другой поток достает только тяжелые сообщения (ну то есть все остальные) и уже потихоньку их там колупает
таким образом 5 потоков на задачи, связанные с сетью (1. главный поток, 2. чтение с сокета, 3. запись в сокет, 4. обработка быстрых сообщений, 5. обработка медленных сообщений) , и остаются ещё серверные ядра на другие задачки с отдельными потоками, типа серверной физики и прочих взаимодействий, синхронизаций с базой данных (сохранение состояния мира например) и так далее

Страницы: 1 2 3 Следующая

/ Форум / Программирование игр / Сеть

2001—2017 © GameDev.ru — Разработка игр