ПроектыФорумСобираю команду

Life is Feudal Sandbox MMORPG. Ищем тестировщика. (33 стр)

Страницы: 132 33 34 3542 Следующая »
#480
15:47, 9 окт 2014

Mephisto std
ааа, =)

#481
18:10, 9 окт 2014

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 серверов как я понял. Или нет?

#482
18:50, 9 окт 2014

San4es
> Что делать, если один инстанс должен взаимодействовать с двумя другими? Если он
> должен выступать как сервер для одного инстанса и как клиент для другого?

Уточнение, если говорить о связке из 7х7 серверов, из-за стыка углов один сервер должен "общаться" еще минимум с тремя серверами (а то и с 8, если брать стык снизу, сверху, слева, справа и столько же по диагоналям), помимо клиентов-игроков. Если я не прав, поправьте меня.

#483
20:32, 9 окт 2014

SuperArmor
Да ясно.
Только вопрос в другом - в API Torque.
У команды ведь есть спецы по сетям в торке вот я и задал вопрос.

А в случае с 7x7 - то здесь должна быть немного другая архитектура.
Смотри, если речь идет об обработке коллизий, - то да на стыке (на угле) могут участвовать сразу до 8 серверов.
Если узкое место какие то другие вычисления - то нагрузку можно распределить как угодно.

Вообще по идее нужно определять узкие места и их распараллеливать.
Типичные узкие места:
1)  сетевой интерфейс, т.е., по-твоему "общение" кого то с кем то. Проявляется в связях один-ко-многим. Решается увеличением кол-ва сетевых интерфейсов - можно сказать увеличением кол-ва серверов, которые общаются со "многими", каждый со своей группой, и частично обрабатывают и передают по необходимости если надо корневому серверу (ну а корневой уже дальше решает) То есть снимаем сетевой траффик с одного сетевого интерфейса и распределяем его на несколько.
2) Вычисление коллизий и задача поиска ближайшего соседа. Здесь может быть вот этот вышеописанный всеми вариант. Но в этом варианте не только коллизии рассчитываются, а и вся внутренняя логика. Один и тот же объект может существовать в одном сервере и в другом и в третьем. А может быть и другой вариант - абстрагировать коллизии от всего остального. Расчет коллизий должен быть отдельно от остальной начинки движка, чтобы программист мог использовать расчет коллизий как компонент с интерфейсом и комбинировать как ему надо с другими компонентами. Тогда мы будем использовать только как бы инстансы-серверы обработки коллизий. Разумеется, здесь тоже самое - объект может быть и в одном и в другом и в третьем одновременно, но зато здесь будут только коллизии и ничего больше. Дальше эти "сервера" передают результаты корневому серверу, а он уже решает чего делать.
Да, и ты описал архитектуру с архитектурной ошибкой (возможно в Торке будет сложно её обойти): сервера коллизий никак не должны быть связаны с другими клиентами-игроками, потому что это разные вещи. Например, может быть игровой персонаж MMO игры, который также управляет своими персонажами: слугами, юнитами и т.д. Поэтому стоит разбить серверную часть игры на несколько ролей и у каждой роли еще может быть несколько инстансов-экземпляров (это нужно для снятия и распределения нагрузки по экземплярам). Структура множества инстансов разных ролей в бесшовной ММО игре - иерархическое дерево.

Вот в этом у меня и был вопрос. То есть отделить расчет коллизий от остального - это в принципе можно на Торке (даже не прибегая к С++, к сторонним библиотекам  типа Bullet), просто создав отдельный проект для серверов коллизий и отключив в нем всё(графику, скрипты), кроме тех объектов которые нужны и добавив вспомогательные триггеры-bouding box'ы по необходимости. Но как сделать так, чтобы эти сервера получали данные из одного удаленного места и передавали другому - вот это вопрос. Причем сначала хочу сделать просто несколько серверов запускающихся на одном хосте, общающихся между собой - фиг ли, отладка, разработка. А уже потом их можно будет распределить на несколько хостов.

То есть мне надо связи типа клиент-"мой сервер" и "мой сервер"-"другой мой сервер"

#484
22:00, 9 окт 2014

San4es
> Да, и ты описал архитектуру с архитектурной ошибкой
Условно у меня нет ошибки, так как я не разделял сущность "сервер" на составные части, типа сервера коллизий, корневой сервер и т.д.

Интересно услышать мнение команды разработки по этим вопросам :)

#485
22:37, 9 окт 2014

SuperArmor
Ну да, ошибки нету, но так делать не надо (не разделять) Раз уж встал вопрос (об объекте который находится одновременно в 8 серверах) лучше разделять. Это как в жизни, как в конторах - люди стоят в окошко с документами, сама девушка в окошке только принимает документы складывает и перенаправляет, а загран изготавливается уже другими людьми. Ну или как в магазине ситилинк - распечатал номер заказа, в кассу (кассир только пробивает товар), в окошко выдачи (чувак выдал товар по чеку) Или как в Макдональдсе - лучший пример - кассир принимает заказ и делегирует все пункты заказа своим сотрудникам, а их много (человек десять только наливают-запаковывают, человек десять за лотком как бы готовят - разогревают, заворачивают, жарят картофан, кладут на лоток)

Макдональдс - самый лучший пример для того чтобы понять как съархитектурить серверную часть ММО.

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

#486
23:02, 9 окт 2014

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

И физика (коллизии в частности) относится как раз к таким задачам - разбить на части её непросто, а считать на отдельном сервере модет не получиться ввиду нехватки мощности.

Хотя, в случае ЛиФ где, как я понимаю, нет физ. взаимодействий между игроками на достаточно больших расстояниях, особых проблем с разделением, наверное, быть не должно - скорее чисто проблемы синхронизации соседних инстансов должны быть, по идее.

#487
23:30, 9 окт 2014

slava_mib
Ну так уже же предложили как разбить задачу определения столкновений на части выше.
Вот это и есть partialing space - разбиение пространства на зоны и определение к какой зоне принадлежит объект. Задается шаг разбиения.
Правда может получиться так, что все объекты окажутся в одной зоне, а не распределены по всем зонам.
Тогда задача посложнее - octree разбиение. Задается либо глубина octree дерева,  либо максимальное кол-во объектов в ячейке.
Octree с двигающимися объектами очень сложен будет и, возможно, тяжеловат.

#488
23:35, 9 окт 2014

San4es
> а это обязательно
> %result = %conn.connect();
>
> только у меня ошибку во время выполнения пишет. И сервер и клиент находятся в
> одном инстансе.
> connectLocal() я не использую, а надо?
>
> Или я имею право использовать connect() только в другом инстансе? или даже на
> другом хосте еще к тому же?

Если и клиент и сервер в одном инстансе, надо использовать connectLocal(), что и происходит при загрузке любой миссии в голом торке.
Вообще в таком режиме - торк у себя запускает внутри "сервер" и сам же к нему подключается как клиент.

В случае, если сервер и клиент разделены - то тут все "классически".
На сервере ты выставляешь порт слушать:
setNetPort(28000);
А на клиенте ты говоришь куда подключаться:
%conn = new GameConnection();
%conn.connect("127.0.0.1:28000");

#489
23:35, 9 окт 2014

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 (по краям).

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

Сорри если получилось немного сумбурно, но мозг на работе перегрелся, поэтому сходу объяснить все довольно-таки сложно)

#490
0:00, 10 окт 2014

bank
Спасибо!
Попробую два инстанса сделать. Надеюсь на одном хосте они смогут работать ))

#491
0:02, 10 окт 2014

bank
Отлично-отлично!

#492
0:19, 10 окт 2014

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

#493
2:44, 10 окт 2014

bank
49 серверов? - а сколько у вас пользователей в онлайне и зачем их держать в одном едином мире?

+ Показать
#494
3:44, 10 окт 2014

bank
> получилось немного сумбурно
да не, интересная схема

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

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

ну и нигде пока я не смог попробовать такую схему : )

Страницы: 132 33 34 3542 Следующая »
ПроектыФорумСобираю команду

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