У нас есть массовое ПВП, но я не знаю могу ли я уже публично называть цифру сколько там будет людей.
Сами же отвечаете на свой вопрос… ) На сервере сделать можно при очень большом желании. Но клиент всё равно не отрисует, если на срежет графику в ноль. Будет медленно и не красиво. А у нас игра про то, чтобы всё бегало быстро и красиво, и боёвка очень динамичная, как в мортал комбате. Не думаю, что можно просто сделать мортал комбат на 1000 человек :)
Да вы всё правильно поняли. Можно послать сообщение неверному адресату, и это печально. В идеале и адреса и абоненты должны быть типизированы. Но… так исторически сложилось :) Ввиду количества кода переделать это не так просто.
Доступность сообщений на клиенте отдана на откуп интерфейсу. Если его сломать можно слать какие угодно сообщения кому угодно. Но везде, где это хоть сколько-нибудь опасно или должно быть ограниченно игрой есть серверные проверки. Тогда в логах сервера будут ошибки, мы их увидим и плохого игрока… кхм… накажем :)
Большой открытый мир наши дизайнеры не заказывали. Если мнение, что в нём играть не так уж и интересно. Люди любят играть, а не бегать от замка к замку. Но это лучше не со мной обсуждать :)
Ева как раз в счёт. Ева показывает, что происходит если сделать большой мир. Когда начинаются эпичные сражения, тормоза неизбежны просто алгоритмически. Приходится придумывать замедление времени и другие некрасивые хаки.
Данные храним централизованно, в базе данных, PostgreSQL, в статье есть ссылка на мою предыдущую статью на эту тему. Лучше её почитать, чем тут дублировать.
Концепция чисто техническая, для отсечения указателей. Транзакционности там нет. Ещё оно применение локалей — для телепорта. Локаль может целиком сериализоваться и улететь на другой сервер, поэтому в ней не должно быть ссылок на другие запчасти сервера.
Друг Вася не может пригласить вас на конкетный канал. Но если вы состоите в группе, то вы будете прозрачно для игрока попадать с ним вместе на один и тот же канал. От шардов это отличается тем, что вы можете взаимодействовать с любым игроком, и взаимодействовать со всем миром через общие сервисы, типа форума, чата, гильдий, поиска приключений и т.п. Кроссерверные группы в ВоВ-е появились именно как попытка обойти ограничения шардов.
Есть разные мнения на этот счёт :)
Если бы мы сделали типизированные сообщения, то внутри месседж системы нам пришлось бы cделать unchecked cast.
В этом случае мы делаем checked cast и можем отреагировать как-нибудь осмысленно.
Обычно делается мессажка MsgToAvatar extends Msg, в которой прячется этот каст, и все кому надо посылать сообщения аватару наследуются от него и не пишут этот каст 100500 раз.
1) На старте проекта у нас была уже готовая реализация нашего серверного движка, которая нас устраивала, с которой мы умели работать, знали все её особенности и ограничения. Не было никакой мотивации переходить на любой другой, пусть даже самый модный, движок. Тем более тогда он был ещё в зачаточном состоянии.
2). Это зависит от коллег :) Если они захотят, то напишут.
3) Единый мир заключается в том, что гильдии, поиск приключений и прочие социальные взаимодействия возможны между всеми игроками реалма. Поиск приключений идёт быстрее, торговля лучше, флуд на форуме не надо разделять на подфорумы по шардам и т.п.
Ну вот я погуглил и не нашёл никаких корней этих 8GB кроме заметок в блогах в стиле «всем известно что больше 8GB» плохо". Почему плохо и почему 8GB никто нигде не говорит. Это очень похоже на какой-то старый миф, который уже никто не помнит откуда и зачем взялся. Таких мифов на самом деле полно :)
Хотя в некоторых случаях было указано, что shared_buffers более 8Гб дает прирост производительности (но только в том случае, если вся база влазит в shared_buffers).
Это, кстати, тоже не правда.
Вопрос в том, чтобы добится как можно большего cache hit ratio. Если вся база 1ТБ, working set 100GB, но большая часть всех операций работает с 30GB, то имеет смысл сделать shared_buffers где-то примерно 30GB. Таким образом можно получить до 99% cache hit ratio. Повышение shared_buffers выше не даст никакого профита, только проблемы…
В общем о shared_buffers следует рассуждать именно в таких терминах, а не в терминах «есть мнение что 8GB это разумный предел»
Отвечаю: я передумал :)
Сами же отвечаете на свой вопрос… ) На сервере сделать можно при очень большом желании. Но клиент всё равно не отрисует, если на срежет графику в ноль. Будет медленно и не красиво. А у нас игра про то, чтобы всё бегало быстро и красиво, и боёвка очень динамичная, как в мортал комбате. Не думаю, что можно просто сделать мортал комбат на 1000 человек :)
Доступность сообщений на клиенте отдана на откуп интерфейсу. Если его сломать можно слать какие угодно сообщения кому угодно. Но везде, где это хоть сколько-нибудь опасно или должно быть ограниченно игрой есть серверные проверки. Тогда в логах сервера будут ошибки, мы их увидим и плохого игрока… кхм… накажем :)
Ева как раз в счёт. Ева показывает, что происходит если сделать большой мир. Когда начинаются эпичные сражения, тормоза неизбежны просто алгоритмически. Приходится придумывать замедление времени и другие некрасивые хаки.
Да не, это не из-за перфоманса. Cast-ы в Java очень быстрые. Скорее ближе к «так исторически сложилось» :)
Тюнили, попрошу коллег ответить как.
Конфигурацию ноды узнать нельзя. NDA.
Данные храним централизованно, в базе данных, PostgreSQL, в статье есть ссылка на мою предыдущую статью на эту тему. Лучше её почитать, чем тут дублировать.
Концепция чисто техническая, для отсечения указателей. Транзакционности там нет. Ещё оно применение локалей — для телепорта. Локаль может целиком сериализоваться и улететь на другой сервер, поэтому в ней не должно быть ссылок на другие запчасти сервера.
Друг Вася не может пригласить вас на конкетный канал. Но если вы состоите в группе, то вы будете прозрачно для игрока попадать с ним вместе на один и тот же канал. От шардов это отличается тем, что вы можете взаимодействовать с любым игроком, и взаимодействовать со всем миром через общие сервисы, типа форума, чата, гильдий, поиска приключений и т.п. Кроссерверные группы в ВоВ-е появились именно как попытка обойти ограничения шардов.
Если бы мы сделали типизированные сообщения, то внутри месседж системы нам пришлось бы cделать unchecked cast.
В этом случае мы делаем checked cast и можем отреагировать как-нибудь осмысленно.
Обычно делается мессажка MsgToAvatar extends Msg, в которой прячется этот каст, и все кому надо посылать сообщения аватару наследуются от него и не пишут этот каст 100500 раз.
2). Это зависит от коллег :) Если они захотят, то напишут.
3) Единый мир заключается в том, что гильдии, поиск приключений и прочие социальные взаимодействия возможны между всеми игроками реалма. Поиск приключений идёт быстрее, торговля лучше, флуд на форуме не надо разделять на подфорумы по шардам и т.п.
Это, кстати, тоже не правда.
Вопрос в том, чтобы добится как можно большего cache hit ratio. Если вся база 1ТБ, working set 100GB, но большая часть всех операций работает с 30GB, то имеет смысл сделать shared_buffers где-то примерно 30GB. Таким образом можно получить до 99% cache hit ratio. Повышение shared_buffers выше не даст никакого профита, только проблемы…
В общем о shared_buffers следует рассуждать именно в таких терминах, а не в терминах «есть мнение что 8GB это разумный предел»