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

Мастер сервер и с чем его едят? (2 стр)

Страницы: 1 2 3 Следующая »
#15
10:55, 21 июня 2018

Tiendil
Академического интереса ради, чем плохи C#/Java в роли ЯП для написания сервера?
Раз у автора клиент на Unity, то и скрипты шарповские скорее всего. Что позволит без затруднений использовать общие классы.


#16
10:58, 21 июня 2018

Germes
Надо бы как-то прикинуть плановую производительность сервера. Сколько примерно игроков, как часто производят операции, сложность этих операций.
После этого станет ясно, нужно выжимать из техники максимум или можно транжирить. Если надо выжимать максимум - тут только С++ поможет. Если есть хотя бы десятикратный запас - можно чуток расслабиться и программировать теми средствами, которыми уже владеют ваши спецы, ибо это банально дешевле.

Но даже если вы вынуждены опираться на С++, из него надо выносить всякие настоечные дизайнерские фрагменты в подключаемые скрипты, ибо не разумно заставлять С-программистов ими заниматься, а малоквалифицированных в сишный код пускать нельзя, они там все порушат. Мало того, что С-программист дороже стоит, так он еще и не любит обычно всякую мелочь программировать, по заданиям дизайнера, который дважды в день перерешает что ему надо. Лучше такую работу поручать кому попроще, скриптизерам всяким. Обеспечить им такую среду, чтобы напакостить глобально не имели физической возможности. Бунтовать и кривить нос, что задачки дурацкие, они не будут, мало что умеют, выбирать что делать не вправе.

Ну и, само собой, веб-обвеску на С++ программировать будет полным извратом. Хотя и такое делают, когда программистам очень хочется, а руководство не понимает, что его разводят.

#17
11:09, 21 июня 2018

DoomGod
> Раз у автора клиент на Unity, то и скрипты шарповские скорее всего. Что позволит без затруднений использовать общие классы.
Я это и посоветовал в первых двух строках своего поста :-)

>Академического интереса ради, чем плохи C#/Java в роли ЯП для написания сервера?
Я бы не разводил тут холивара.

+ Показать

#18
11:34, 21 июня 2018

Tiendil

+ Показать
#19
11:45, 21 июня 2018

DoomGod
> Ну окей, надо будет глянуть на досуге что может показать python в качестве сервера. Может там и в правду есть нечто отличное от них.
В питон протянут юниксовый апи беркли сокетов, также как и в джаваскрипт. Получается эдакий покореженный си без плюсов. Программировать такими средствами можно только если у вас под рукой программист, который ими владеет и не владеет ничем иным. Да и то велик шанс, что он зашьется, придется все выбрасывать и начинать на других инструментах.

#20
12:20, 21 июня 2018

Tiendil
> Я бы не разводил тут холивара.
DoomGod
В спорах рождается истина) а именно её я тут и ищу.

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

Опыт есть в геймдеве, но нет опыта в серверах, отчего и появилась эта тема :)
Нагрузки? Тяжесть операций - это валидация клиентских команд. Условно - нужно проверить путь персонажа или условия применения заклинания.
Количество обращений с игрока точно не несколько за секунду) скорее всего пара команд секунд за 30 от самых резвых. Всё же игра пошаговая и тактическая.
Ну вот взять от плеча единовременный онлайн в 100 000. (я буду рыдать от успешности в этом случае, но наш гендир, наверное метит и выше)

100 000 игроков - это 100 000 логинов, но сколько там будет единовременных матчей? Думаю, не сильно больше 30 000.
Ну вот и выходит 1000-4000 обращений в секунду от разных игроков.

Хорошо бы разбивку на региональные сервера делать. Тогда на каждом сервере народа будет поменьше.

#21
12:45, 21 июня 2018

Tiendil
у топикстартера Unity. У нас тоже Unity, поэтому в итоге и серверами у нас работает Unity. Язык, соответственно C#. Что там мешает запускать под линуксом и каких библиотек может не хватать?
Теперь собственное мнение :)

+ Показать

#22
13:33, 21 июня 2018

Germes
> В спорах рождается истина) а именно её я тут и ищу.
Не в этот раз. Не та площадка и не те спорщики (и я в том числе). Тут днём с огнём не сыщещь человека с серьёзным и актуальным опытом хотя бы в двух разных технологиях. А без этого конструктивного обсуждения не получится. Соберите мнения, спроецируйте их на свою ситуцию и делайте выводы сами.

#23
13:38, 21 июня 2018

Поделюсь своим опытом написания серверов для Юнити.
1. Написать на C# и запускать на Винде - вполне все норм, как на выделенной машине так и в облаке (консольное приложение либо Web service + database)
2. Сервер оперирует своей логикой и физикой. Нет стоит там подключать Юнити, лучше постараться обойтись без него, т.к. работать он должен максимально быстро. Чаще всего я делал общую dll с сущностями и логикой их работы, на клиенте на них натягивались View, на сервере была дополнительно БД с данными игроков + настройки.
3. Горизонтальное масштабирование - если хочешь 100.000 игроков держать - делай возможность запускать несколько инстансов серверов (на нескольких выделенных машинах). Клиент может первый раз коннектиться к некоторому мастер серверу, который уже будет определять по IP регион и отправлять в сервера в соответствующем регионе на наиболее свободный инстанс. Но соответственно pvp будет происходить только с игроками в соответствующем регионе.
4. Постоянно соединение через Socket нужно только для отправки игровых команд и их получения от сервера. Readonly информацию (статистика всякая, лидерборды и проч) лучше вынести в API.
5. Старайся уменьшить нагрузку на БД - при подключении игрока можно загружать все необходимые данные в оперативную память и работать с этими данными пока игрок не выйдет, потом только записывать в БД. Хотя все равно некоторые данные придется время от времени сбрасывать в БД для того чтобы другим игрокам была доступна актуальная информация (условно - уровень игрока повысился)

Может что-то еще забыл, отпишу если вспомню.

#24
13:56, 21 июня 2018

D_A_C
А у вас какая логика вообще используется?
На компе-сервере стоит Unity Master Server, который у них в открытом доступе.
И при старте матча мастер-сервер поднимает новый экзепляр сервер-билда вашей игры, и в этом билде какая-нибудь серверная сцена крутится.
Через сервер-билд проходит матч, после чего он закрывается.

Так?)

MANAB
Ага, интересно, спасибо)

Tiendil
Этим и занимаюсь) спасибо за вашу помощь

#25
14:41, 21 июня 2018

Germes
У нас на компе-сервере стоит Unity-приложение, которое написано с использованием Master Server Framework (это опенсорс и к юнитекам не имеет никакого отношения).
Штатно да, MSF позволяет подымать экземпляры серверных билдов игры, пропускать матч и обмениваться с ними данными.
Но у нас совершенно другая логика, реализованная на нем же, с минимальными доработками, кстати.
У нас есть некий большой мир с собственной иерархией локаций, клиенты цепляются к нему и там играют. Короче, как в ММО больших устроено, а не комнатных сессионках, хотя "комнатный" геймплей тоже свободно делается. База данных - отдельное приложение на отдельном компе-сервере, доступ по REST API. Соответственно, мы можем запускать произвольное количество инстансов серверов в разных точках планеты и пускать туда столько людей, сколько нам надо. В планах еще горизонтальный обмен данными меж инстансами запилить, но это когда-нибудь.
У нас тоже стратегия, хоть и не пошаговая.

#26
14:46, 21 июня 2018

MANAB
> Хотя все равно некоторые данные придется время от времени сбрасывать в БД для
> того чтобы другим игрокам была доступна актуальная информация (условно -
> уровень игрока повысился)
Зачем прогресс игрока постоянно сбрасывать в БД? Мастер-сервер кроме авторизации, может отлично его хранить и показывать для других игроков.

#27
16:02, 21 июня 2018

D_A_C
> Зачем прогресс игрока постоянно сбрасывать в БД? Мастер-сервер кроме
> авторизации, может отлично его хранить и показывать для других игроков.
1. не постоянно, а только когда нужно (событийно) и только некоторую нужную для других игроков или логики инфу
2. память не резиновая
3. в таком случае за частью инфы придется лезть и в БД и еще и на мастер-сервер или какой-то другой сервер, который по сути выполнять будет роль самописной БД. А если вообще все данные хранить в оперативе на мастер-сервере - смотри п.2
4. сервер может ляснуться, прогресс потеряется

#28
16:42, 21 июня 2018

MANAB

1. не постоянно, а только когда нужно (событийно) и только некоторую нужную для других игроков или логики инфу

С событийностью согласен, а "некоторую" - фактически это вся инфа о прогрессе игрока.
2. память не резиновая

можно в цифрах? типа "ну вот мы храним 10 тысяч игроков онлайн и нам не хватает 64 Gb оперативы на сервере"
3. в таком случае за частью инфы придется лезть и в БД и еще и на мастер-сервер или какой-то другой сервер, который по сути выполнять будет роль самописной БД.

за какой частью?
4. сервер может ляснуться, прогресс потеряется

Принято, поэтому я в БД передаю сжато, асихронно и в фоне :)
#29
0:05, 22 июня 2018

MANAB
> Readonly информацию (статистика всякая, лидерборды и проч) лучше вынести в API.

+
это лучшее решение на перспективу - вынести всё-всё, что не является неотъемлемой частью сессии игровой партии, на api, с которым будут работать как клиенты на стороне игрока (через http, например на php, python или nodejs), так и сами игровые сервера (но с разным уровнем доступа конечно, с ролями так сказать)
вплоть до регистрации/авторизации и внутриигрового магазина
это позволит стать сильно гибкими на этапе поддержки с маркетинговой стороны. хотя бы те же скидки в магазине внедрить будет намного менее трудозатратно

__

сервер на linux на шарпе (mono) чуствует себя не хуже, чем на винде, хотя и есть некоторые нюансы, различия в библиотеках

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

__

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

[DllImport("lib.dll")]
с помощью маршалинга передать при старте игровой сессии туда некую память, указатель на неё, а при завершении - насильно очистить. во время сессии вызывать туда всякие рассчеты и забирать результаты теми же библиотечными методами
чтобы это не было мучительно - сразу на шарпе написать обертку, которая отделит библиотечные вызовы от человеко-понятных шарповых методов

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

Страницы: 1 2 3 Следующая »
ПрограммированиеФорумСеть

Тема в архиве.