Делаем убийцу Diablo 1, нужен геймдизайнер (77 стр)

за кем я под ником suslik бегал и нагнул s3bd ?

Вий
Очень круто. Мне нравится.

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

Я бы предложил "мокрое полотенце", но боюсь сообщества с других форумов нас не поймёт.

711
> И имя того кто даст ответы Геймдизайнер
Отлично!

711
> По сути это уже игра.
Я тоже считаю что вполне годно выходит и нужно доделывать убийцу Diablo, ну или повнимательнее посмотреть например на ultima online

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

1) User-proxy
Я думаю, нужно разделять между серверами подключенных пользователей, то есть часть пользователей будет подключаться к серверу 1, часть - к серверу 2 и так далее. В принципе можно ограничиться тем, что каждый такой сервер будет подключен к некоторому "главному серверу", который будет передавать этим серверам полные данные о состоянии мира, а они уже будут рассылать каждому игроку актуальную их часть, а в обратную сторону наоборот - данные игроков из крошечных пакетиков будут собираться в крупные пакеты и отправляться на главный сервер. Так главному серверу перестанет быть необходимо рассылать K*N состояний игроков (каждому из N игроков информацию о K других игроках) и достаточно будет рассылать всего N*M, где M - количество серверов, не нужно будет проверять видимость и т.п., а достаточно будет применять команды , обновлять симуляцию и рассылать результаты. Наверное это неплохой вариант масштабирования, но у такого способа есть важный недостаток - когда-нибудь одного главного сервера может оказаться мало.

2) World-shards
Можно разделять мир по географическому принципу, при этом динамически меняя границы раздела для того, чтобы особо крупные скопления игроков не перегружали отдельные локации. Допустим, договориться о том какой из серверов за какую часть мира отвечает серверы смогут (хотя это и потребует довольно хитрой логики), но вот как быть с игроками около границ? Что если игрок на одной стороне границы бьет игрока на другой стороне? Тут конечно тоже можно придумать какие-то хитрые правила типа "взаимодействующие около границы игроки обрабатываются на сервере с минимальным номером", но в целом взаимодействия около границ будут в лучшем случае лагать, а в худшем просто глючить.

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

3) User-processors
Как вариант, разделить игроков по разным серверам независимо от того где они находятся, тогда все взаимодействия будут периодически происходить между игроками на разных серверах. И вот тут можно просто передавать обработку игроков с сервера на сервер. Ударил игрок 1 игрока 2 - для обработки этого удара игрока 2 система перебрасывает на сервер к игроку 1, там они дерутся и после этого игрок 2 так и остается жить на этом сервере, пока не повзаимодействует с кем-нибудь с другого сервера. Такой варинат нормально работать будет только при условии, что игроки подключаются через User-proxy.

Интересно было бы услышать мнение опытных разработчиков ММО

Вий
Ну я тебе могу сказать на печальном опыте, что не стоит заморачиваться "преждевременной оптимизацией", пока реально не получишь ситуацию к этому обязывающую. Ну я пессимист, поэтому действуй на свое усмотрение)
Сетевой канал всегда узкий, ну тебе проще, ты на плюсах вроде как, у меня в шарпе с оптимизацией байтов хуже. Самое простое решение, которое я применял на последнем проекте это несколько сетевых потоков (как бы айпишник один, портов много, ограничено там 65к, ну я не вникал какие порты системные и нельзя использовать), ну и раскидываешь юзеров по потокам чтобы не забивали сеть. Тут все упрется в стоимость железа.
Ну и как бы сразу нахрен текстовые сообщения (json, xml), сразу бинарные, в разы все быстрее. Ну у меня самая толстая была карта (части видимой карты), я ее в зип паковал перед отправкой, на клиенте распаковывал, на порядок трафик экономило.

Дядя Саша
У меня уже передаются бинарные данные в аккуратно подобранном формате. Проблем прокачать через один сокет хоть 10 гигабит/с у меня нет, а вот сервер с таким каналом дороже чем 10 серверов с каналом 1 гигабит/с и кажется 10 серверов по 100 мбит/с еще дешевле с учетом безлимитного трафика

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

Дядя Саша
Даже плохо оптимизированная версия которая выложена сейчас на сервер позволяет отправлять около 8000 сообщений игрокам в секунду в ответ на их действия, 100 идеально одновременно побежавших игроков потребуют 0.013 секунды, что меньше длительности кадра при 60 фпс.

Вий
Тогда я вообще не понимаю чего ты заморочился. Я не в курсе состояния игры конечно. Но по моему мнению игра первостепенна. Мастер-серверы и масштабируемость конечно хорошо, ну тут надо быть уверенным что игра стоит свеч.

Дядя Саша
Дело в том, что в зависимости от архитектуры серверов, всю игру нужно писать очень по-разному, так что если сначала сделать хорошую игру для 1 игрока, переделать ее даже просто в многопользовательскую может быть очень тяжело, а в ММО так и вовсе может оказаться невозможно. Кроме того, если в самом начале окажется, что игра не может справиться с обслуживанием набежавших в первый день игроков с достойным качеством, все эти игроки тут же убегут и никогда не вернутся, а второй раз заманить столько же игроков как в день запуска - очень тяжело, так что лучше подготовиться как следует.

Вий
если тебе нужно одну локацию разбить на несколько обслуживающих серверов то как-то так это делается
https://gamedev.ru/projects/forum/?id=133110&page=33&m=3666234#m489
тут приведён статичный вариант когда границы заранее определены и не меняются в рантайме

#!
Ну да, я примерно о таком и думаю, только разделение наверное будет не ровными квадратиками а скорее сотами, причем образованными типа «базовыми станциями» с разными радиусами и не регулярно расположенными центрами, чтобы в динамике менять покрытие мира.

Чтобы не совершенствовать технологию бесконечно, поставлю конкретную цель: технически игра должна суметь обслуживать столько же одновременно подключенных игроков, сколько было на пике у Eve Online, то есть 65 303.

Кодзима
Может тебе к нам ?
А то я уже целую гору набросков сделал, и никак не могу найти точку опоры. Хоть бы за что-то зацепится, чтобы вселенная начала обрастать персонажами, событиями, интересными свойствами… нужна какая то основа.