Тёмная тема
- SuperArmor
- Постоялец
Mephisto std
ааа, =)
wad
Здравствуй, wad!
Прочитал Вашу переписку на http://www.gamedev.ru/projects/forum/?id=133110&page=31 и посмотрел видео ролик Life is Feudal. Название игры знакомо, потому что и раньше мелькало.
и на следующей странице тоже прочитал.
Так кто у вас специалист в торке по сетевому взаимодействию?
Mephisto std?
Кому можно задать вопрос про сетевое взаимодействие в Torque3d в scripting API?
Вы ведь используете Torque3d, взятый отсюда http://www.garagegames.com/products/torque-3d верно?
Я развернул последнюю версию 3.5.1 и в ней не обнаружил такие методы как описаны здесь
http://docs.garagegames.com/tgea/official/content/documentation/E… tworking.html
конкретно про методы из множества Net:: цитирую:
"Net::openPort() opens an unreliable socket, of which only one is allowed per application instance. Net::sendto() sends an unreliable datagram to the specified NetAddress. Net::openListenPort() opens a reliable socket for incoming TCP connections. Net::openConnectTo() begins the process of asynchronously connecting to a remote TCP socket. Net::sendtoSocket() sends data over an established TCP connection. Net::process() processes the platform network layer, possibly generating network related events that are then posted into the simulation via GameInterface::processEvent()."
Ну ясно - очень полезные методы, основа, обертки над простыми сокетами, вещь нужная.
Это - для другого движка - TGE чтоли?
А в чем отличие от Torque 3D тогда? и где его достать тогда?
Однако у меня, разумеется работают (во всяком случае ошибку не пишут) вещи описанные здесь:
http://docs.garagegames.com/torque-3d/official/content/documentat… FServer_Model
там методы
setNetPort(%myPort) (как я понял для установки слушающего порта, инстанс который так сделал становится сервером)
allowConnections(%enable) (окончательно стать сервером)
а на клиентской части, как я понял:
//create our server connection object
%conn = new GameConnection( ServerConnection );
или так:
%conn = new NetConnection( ServerConnection );
как я понял, это можно опустить:
RootGroup.add( ServerConnection );
%conn.setConnectArgs( $pref::Player::Name );
%conn.setJoinPassword( $Client::Password );
а это обязательно
%result = %conn.connect();
только у меня ошибку во время выполнения пишет. И сервер и клиент находятся в одном инстансе.
connectLocal() я не использую, а надо?
Или я имею право использовать connect() только в другом инстансе? или даже на другом хосте еще к тому же?
Как использовать можно?
Что делать, если один инстанс должен взаимодействовать с двумя другими? Если он должен выступать как сервер для одного инстанса и как клиент для другого?
Ведь у вас в вашей игре 7x7 серверов как я понял. Или нет?
San4es
> Что делать, если один инстанс должен взаимодействовать с двумя другими? Если он
> должен выступать как сервер для одного инстанса и как клиент для другого?
Уточнение, если говорить о связке из 7х7 серверов, из-за стыка углов один сервер должен "общаться" еще минимум с тремя серверами (а то и с 8, если брать стык снизу, сверху, слева, справа и столько же по диагоналям), помимо клиентов-игроков. Если я не прав, поправьте меня.
SuperArmor
Да ясно.
Только вопрос в другом - в API Torque.
У команды ведь есть спецы по сетям в торке вот я и задал вопрос.
А в случае с 7x7 - то здесь должна быть немного другая архитектура.
Смотри, если речь идет об обработке коллизий, - то да на стыке (на угле) могут участвовать сразу до 8 серверов.
Если узкое место какие то другие вычисления - то нагрузку можно распределить как угодно.
Вообще по идее нужно определять узкие места и их распараллеливать.
Типичные узкие места:
1) сетевой интерфейс, т.е., по-твоему "общение" кого то с кем то. Проявляется в связях один-ко-многим. Решается увеличением кол-ва сетевых интерфейсов - можно сказать увеличением кол-ва серверов, которые общаются со "многими", каждый со своей группой, и частично обрабатывают и передают по необходимости если надо корневому серверу (ну а корневой уже дальше решает) То есть снимаем сетевой траффик с одного сетевого интерфейса и распределяем его на несколько.
2) Вычисление коллизий и задача поиска ближайшего соседа. Здесь может быть вот этот вышеописанный всеми вариант. Но в этом варианте не только коллизии рассчитываются, а и вся внутренняя логика. Один и тот же объект может существовать в одном сервере и в другом и в третьем. А может быть и другой вариант - абстрагировать коллизии от всего остального. Расчет коллизий должен быть отдельно от остальной начинки движка, чтобы программист мог использовать расчет коллизий как компонент с интерфейсом и комбинировать как ему надо с другими компонентами. Тогда мы будем использовать только как бы инстансы-серверы обработки коллизий. Разумеется, здесь тоже самое - объект может быть и в одном и в другом и в третьем одновременно, но зато здесь будут только коллизии и ничего больше. Дальше эти "сервера" передают результаты корневому серверу, а он уже решает чего делать.
Да, и ты описал архитектуру с архитектурной ошибкой (возможно в Торке будет сложно её обойти): сервера коллизий никак не должны быть связаны с другими клиентами-игроками, потому что это разные вещи. Например, может быть игровой персонаж MMO игры, который также управляет своими персонажами: слугами, юнитами и т.д. Поэтому стоит разбить серверную часть игры на несколько ролей и у каждой роли еще может быть несколько инстансов-экземпляров (это нужно для снятия и распределения нагрузки по экземплярам). Структура множества инстансов разных ролей в бесшовной ММО игре - иерархическое дерево.
Вот в этом у меня и был вопрос. То есть отделить расчет коллизий от остального - это в принципе можно на Торке (даже не прибегая к С++, к сторонним библиотекам типа Bullet), просто создав отдельный проект для серверов коллизий и отключив в нем всё(графику, скрипты), кроме тех объектов которые нужны и добавив вспомогательные триггеры-bouding box'ы по необходимости. Но как сделать так, чтобы эти сервера получали данные из одного удаленного места и передавали другому - вот это вопрос. Причем сначала хочу сделать просто несколько серверов запускающихся на одном хосте, общающихся между собой - фиг ли, отладка, разработка. А уже потом их можно будет распределить на несколько хостов.
То есть мне надо связи типа клиент-"мой сервер" и "мой сервер"-"другой мой сервер"
San4es
> Да, и ты описал архитектуру с архитектурной ошибкой
Условно у меня нет ошибки, так как я не разделял сущность "сервер" на составные части, типа сервера коллизий, корневой сервер и т.д.
Интересно услышать мнение команды разработки по этим вопросам :)
SuperArmor
Ну да, ошибки нету, но так делать не надо (не разделять) Раз уж встал вопрос (об объекте который находится одновременно в 8 серверах) лучше разделять. Это как в жизни, как в конторах - люди стоят в окошко с документами, сама девушка в окошке только принимает документы складывает и перенаправляет, а загран изготавливается уже другими людьми. Ну или как в магазине ситилинк - распечатал номер заказа, в кассу (кассир только пробивает товар), в окошко выдачи (чувак выдал товар по чеку) Или как в Макдональдсе - лучший пример - кассир принимает заказ и делегирует все пункты заказа своим сотрудникам, а их много (человек десять только наливают-запаковывают, человек десять за лотком как бы готовят - разогревают, заворачивают, жарят картофан, кладут на лоток)
Макдональдс - самый лучший пример для того чтобы понять как съархитектурить серверную часть ММО.
люди в очереди - игровые клиенты
кассы - сетевые интерфейсы серверной части ( в одну кассу много людей)
подносчики или повара - экземпляры других ролей - серверы физики-коллизий, серверы игровой логики ( много людей, из которых каждый обслуживаете любого кассира по запросу )
Только, в отличие от маконалдса, игровой сервер не так-то просто разделить - многие задачи связанны друг с другом и их либо сложно дробить, либо они получаются слишком мелкими (а такие часто обрабатывать не выгодно), либо большими, но как итог - частично дублируют работу друг-друга.
И физика (коллизии в частности) относится как раз к таким задачам - разбить на части её непросто, а считать на отдельном сервере модет не получиться ввиду нехватки мощности.
Хотя, в случае ЛиФ где, как я понимаю, нет физ. взаимодействий между игроками на достаточно больших расстояниях, особых проблем с разделением, наверное, быть не должно - скорее чисто проблемы синхронизации соседних инстансов должны быть, по идее.
slava_mib
Ну так уже же предложили как разбить задачу определения столкновений на части выше.
Вот это и есть partialing space - разбиение пространства на зоны и определение к какой зоне принадлежит объект. Задается шаг разбиения.
Правда может получиться так, что все объекты окажутся в одной зоне, а не распределены по всем зонам.
Тогда задача посложнее - octree разбиение. Задается либо глубина octree дерева, либо максимальное кол-во объектов в ячейке.
Octree с двигающимися объектами очень сложен будет и, возможно, тяжеловат.
San4es
> а это обязательно
> %result = %conn.connect();
>
> только у меня ошибку во время выполнения пишет. И сервер и клиент находятся в
> одном инстансе.
> connectLocal() я не использую, а надо?
>
> Или я имею право использовать connect() только в другом инстансе? или даже на
> другом хосте еще к тому же?
Если и клиент и сервер в одном инстансе, надо использовать connectLocal(), что и происходит при загрузке любой миссии в голом торке.
Вообще в таком режиме - торк у себя запускает внутри "сервер" и сам же к нему подключается как клиент.
В случае, если сервер и клиент разделены - то тут все "классически".
На сервере ты выставляешь порт слушать:
setNetPort(28000);
А на клиенте ты говоришь куда подключаться:
%conn = new GameConnection();
%conn.connect("127.0.0.1:28000");
SuperArmor
> Каждый сервер должен держать (условно) одну большую локацию из 49? Как быть на
> стыке локаций? Или 7х7 серверов по сути - одно большое целое?
как реализовано меж-серверное взаимодействие в LiF.
Каждый из серверов, устанавливает по IrspConnection (наследник от GameConnection со своими добавками/тюнингом) к каждому из соседей.
Когда игрок подходит к территории соседнего сервера, он устанавливает GameConnection ко второму серверу (С2), а первый (С1) начинает отсылать обновления на второй сервер как "на клиент".
Т.е. в любой момент времени, пока игрок находится в "буферной зоне" (больше чем 1 сервер), он всегда управляется только одним сервером, а остальные - выступают в роли клиента (чтобы в их симуляции был объект игрока для корректного просчета физики и т.п.). Как только игрок переходит границу серверов, С2 отмечает у себя что объект теперь контролируется им, и информирует об этом все другие сервера, включая С1, и они "переключают" этот объект из реального в клиентский режим (т.н. Ghost). Ну и на клиент уходит сообщение, что теперь ты под контролем С2, а не С1.
Фактически, если мы возьмем схему 2х3 сервера, типа:
[С1][C2]
[C3][C4]
[C5][C6]
то будут подключения:
[C1] -> [C2], [C1] -> [C3], [C1] -> [C4]
[C2] -> [C1], [C2] -> [C3], [C2] -> [C4]
[C3] -> [C1], [C3] -> [C2], [C3] -> [C4], [C3] -> [C5], [C3] -> [C6]
и так далее.
получается, что между любыми двумя соседними серверами есть по 2 подключения (для проброса Ghost в каждую сторону, так как GameConnection это одно-направленное соединение).
В текущем LiF (не YO версия, а именно ММО), весь большой мир обрабатывается 7х7 = 49 серверами. Между ними установлено 312 IrspConnection + 49 подключений к координирующему серверу, итого 361 NetConnections :)
(312 = 25x8 (это центральные 5х5) + 4+3 (угловые) + 20х5 (по краям).
Выходит что каждый сервер, отвечает за свою территорию, + есть буферная зона, за которой следят все "соседи".
Сорри если получилось немного сумбурно, но мозг на работе перегрелся, поэтому сходу объяснить все довольно-таки сложно)
bank
Спасибо!
Попробую два инстанса сделать. Надеюсь на одном хосте они смогут работать ))
bank
Отлично-отлично!
> Ну так уже же предложили как разбить задачу определения столкновений на части выше.
San4es, а я и не говрю, что не предложили. ;-) Я лишь сказал, что в данном конкретном случае самая сложность не столько разбить, сколько синхронизовать. При этом надо помнить о том, что для другого случая - может быть другая ситуация.
bank
49 серверов? - а сколько у вас пользователей в онлайне и зачем их держать в одном едином мире?
bank
> получилось немного сумбурно
да не, интересная схема
я в своё время думал более сложную, где серверов два сорта, для подключений и которые считают локацию
и эти два сорта связаны между собой каждый с каждым
в результате клеент присасывается к одному из серверов подключений, и тот прозрачно для клеента перенаправляет трафик на нужный локационный
общение серверов локаций между собой через сервера подключений у меня достаточно туманно
ну и нигде пока я не смог попробовать такую схему : )
Тема в архиве.