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

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

Поделиться

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

war_zesПостоялецwww10 сен. 20177:01#15
joub
Вообще есть такая бесценная сокровищница знаний - github :)
Конкретно тебе стоит поискать по словам server/mmorpg/emulator
эмуляторы реальных мморпг очень хороши для примеров - они пишутся простыми людьми(простой код), но и при этом проходят боевое крещение (запуск пиратских серверов на них)
(а если очень хорошо постараешься - найдешь код реальных мморпг, но не думаю что тебе прям он нужен)

Лично я начинал вот с этого человека:
https://github.com/Ratstail91/Tortuga
(там очень простой код.. и хотя многие решения сомнительны, но этот проект позволит понять - с чего вообще все это дело начать)


А книг нет...

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

MixeYaПостоялецwww10 сен. 201710:19#16
Chupakaber
> и тут как раз 300+ юзеров с их в лучшем случае 600+ потоков уже начнут
> создавать существенный оверхед
А чем эти потоки отличаются от корунтин в юнити? Там вроде даже написано, что они почти бесплатные.
ChupakaberПостоялецwww10 сен. 201713:20#17
MixeYa
> А чем эти потоки отличаются от корунтин в юнити?
корутины в юнити от потоков отличаются тем, что их менеджер работает по другому принципу нежели системная многопоточность. там каждый такт не переключаются контексты для процессора, там один контекст непрерывный, изменяемый в момент вызовов startcoroutine. т.е. конечно от количества корутин накладные расходы растут из-за "менеджера" корутин в движке, но они не создают такой космический оверхед как потоки, которые честнее делят ресурсы между процессами. но за счет этого у корутин есть свои минусы. например если в корутине тяжелый долгий код исполняется между yield, то все корутины будут вставать раком пока он не отработается, т.е. до yield код работает неразрывно, в отличие от потоков
таким образом в корутинах снижается оверхед, но и их главная задача распараллеливания также немного страдает и требует особого внимания разработчика

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

joubПостоялецwww10 сен. 201713:38#18
Сколько людей, столько мнений.
Бегать во круг друг друга - это самое простое, есть приемник который просто ретранслирует ходы(направления движения) другим игрокам кто в зоне видимости, а вот бой - это уже пошаговая система, с возможно крайне малым временем на один шаг.

И все же очередной раз повторюсь - чего бы почитать, статьи, книги, и прочая литература...
Да и ММОРПГ  по моему никогда в режиме action не работают.

ChupakaberПостоялецwww10 сен. 201713:44#19
joub
> Да и ММОРПГ  по моему никогда в режиме action не работают.
и все эти новомодные с нон таргет боевыми системами? (типа blackdesert, tera online, etc)
joubПостоялецwww10 сен. 201713:49#20
я не говорю про достаточно навороченные системы, а про неболшие и не сложные.
ChupakaberПостоялецwww10 сен. 201713:55#21
ясно
по началу "никогда" звучало довольно категорично
мне кажется, вам стоит первым делом формализовать в мыслях и может быть текстовом документе то, что вы хотите в итоге сделать
тогда и литературу найти будет гораздо проще, пока предполагаю, что "мысль витает в воздухе", а в такой ситуации к архитектуре приступать рановато
MixeYaПостоялецwww10 сен. 201714:07#22
Chupakaber
>они не создают такой космический оверхед как потоки, которые честнее делят ресурсы между процессами
Спасибо за разъяснения. Я вообще-то слышал мнение, что корунтины только по памяти экономнее, а по процессорному времени одинаково. Может вы путаете потоки с процессами?

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

ZabПостоялецwww10 сен. 201714:25#23
Под виндой есть легкие потоки - fiber'ы. Но в них нельзя использовать синхронные операции, по сути. Остановившийся на ожидании файбер замораживает не только себя, все остальные тоже ждут, ибо для системы они все - один поток.
Под многими версиями соляриса потоки были двухуровневыми. Поток создается всегда как легкий, как только вызывается нечто ожидающее, он превращается в настоящий, api управления как у обычных потоков, в отличие от виндовых файберов, имеющих свой несовместимый с потоками api. В последних версиях соляриса от двухуровневой системы отказались, кажется, не знаю почему.
ChupakaberПостоялецwww10 сен. 201717:47#24
MixeYa
> Я вообще-то слышал мнение, что корунтины только по памяти экономнее, а по
> процессорному времени одинаково. Может вы путаете потоки с процессами?

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

Thread benchmark
End. [ 26796ms ; rendered frames: 1 ]
загрузка ЦП: https://gyazo.com/3bd23f1c33ea22413b513490176f2fde

Coroutine benchmark
End. [ 9951ms ; rendered frames: 13 ]
загрузка ЦП: https://gyazo.com/dff3a9e5b47185736ee6da3b08231073

выходит корутины крутятся в главном потоке (у меня 4 ядра и 1 ядро только нагружалось - 25%)
при этом многопоточная версия так сожрала ЦП, что основной поток юньки не успевал ничего нарисовать, один кадр только прорисоваться успел, а с корутинами более менее 1 fps был

+ код_бенча

UPD:

вобщем-то 50000 потоков даже для ммо-сервера довольно таки дофига, так что бенч так для сравнения корутин с потоками чисто принципиально. а на деле в 10000 потоках разница намного меньше

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

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

MixeYaПостоялецwww10 сен. 201720:32#25
Chupakaber
> вышел такой вот интересный результат, даже неожиданный для меня
Не могу ссылки посмотреть, гугл блочит.
Может не цп было сожрано, а память?
ChupakaberПостоялецwww10 сен. 201720:50#26
MixeYa
> Не могу ссылки посмотреть, гугл блочит.
скрины диспетчера задач
у потоков загрузка ЦП 91% (ну 2-3% прочие нагрузки от других приложений), красным 10%
у корутин загрузка ЦП 27% (тоже 2-3% - другие приложения, 25% это полностью одно ядро, в графике по ядрам в диспетчере тоже смотрел, нагружается 1 ядро), красным меньше 1%
память честно говоря не смотрел
если юнька под рукой есть можешь бенч у себя прогнать, скрипт под спойлером, память посмотреть
в общем как я понял корутины в юньке обрабатываются в главном цикле после событий Update и до событий LateUpdate каждый кадр. каким-то хитрым скрытым образом юнька вычисляет сколько корутин за кадр она может прогнать
таким образом для тяжелых долгих рассчетов корутины в юньке не подходят, а для коротких задач вполне себе
но раз тема была про серверную архитектуру, то в целом юньку я бы в качестве сервера ММО не взял никогда (8
MixeYaПостоялецwww10 сен. 201720:53#27
Chupakaber
А на каком количестве потоков и корутин тестировал?
ChupakaberПостоялецwww10 сен. 201721:28#28
один проход на 50к
я же писал уже, и в коде это есть там под спойлером в 24 посте
MixeYaПостоялецwww10 сен. 201721:32#29
Chupakaber
> в коде это есть там под спойлером

Я не программист. У меня код плохо читается. А про 50 000 было на счёт сервера сказано.
Ну и да. 50 000 это немало. Это не 200 и не 300 :-)
И конечно, у юнити должна быть своя реализация корутин, удобная для движка. На си шарп, asinc await, возможно, по своему реализованы.

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

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

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