LINUX.ORG.RU
ФорумTalks

Нет желающих заняться реализацией распределённого открытого 3D-мира? ;)


0

0

Сабж. Тут понемногу из старой гвардии формируется команда, собирающаяся сделать фигню, типа deeptown.org (Second Life, ActiveWorlds и т.п.), но полностью открытую (сервер, клиент, протоколы, подключение к системе).

Основное направление - на развитие стандартизированного расширяемого протокола. Т.е. в перспективе - система с произвольной разработки серверами и клиентами.

Всё это, естественно, мультиплатформенное.

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

Клиент первого этапа был намечен на связку Ogre3D + Python (апологеты C++ всегда смогут написать на нём свой варант клиента позже, нам же сейчас важно отработать протокол), но всё обломалось на самом начальном этапе - элементарно не выходит собрать python-ogre, на Linux они практически забили.

Поэтому - сабж.

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

Но хочется заполучить хотя бы одного-двух имеющих реальный опыт элементарного программирования мультиплатформенных 3D-клиентов. Желательно - на упомянутой связке Python-Ogre3D. Возможны также комбинации с Irrlicht, Java :)

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

★★★★★
Ответ на: комментарий от dmiceman

> но время, время.. :-(

Увы, это всеобщий бич :-(

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от DemonZLa

>да ещё эти затыки с самодельной скелетной анимацией

Да, под это придётся искать отдельного человека. Который такими вещами будет заниматься.

Вообще, есть надежда на то, что если разработку мешей и скелетов сделать сильно автономной и отвязанной непосредственно от сервера, а в каждый диалог информации, связанной с персонажем ввести заметную закладку "About", содержимое которое сможет заполнять разработчик соответствующего изделия (аватара, NPC, объекта...), то, по мере развития проекта могут подключиться профессиональные дизайнеры, которые будут раздавать качественные публичные версии таких объектов с целью рекламы, а в About размещать свою рекламу по изготовлению оных на заказ за деньги :)

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от pentagon

>И так изза интернета туча пацанов в кибердрочеров превратилась, а вы ещё такое делать собираетесь...

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

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от KRoN73

> Чёрт его знает, что лучше.

Видел когда-нибудь "уехавших" геймеров вживую? После этого таких вопросов не останется. Честное слово, пусть лучше траву курят.

pentagon
()
Ответ на: комментарий от pentagon

>Видел когда-нибудь "уехавших" геймеров вживую? После этого таких вопросов не останется. Честное слово, пусть лучше траву курят.

Ну, не знаю. Знакомых геймеров много, но вот сидит сейчас хороший знакомый, который баловался именно травой.

KRoN73 ★★★★★
() автор топика

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

MiDoS
()
Ответ на: комментарий от MiDoS

irc будет избыточен по объёму и недостаточен по возможностям.

Клиент-серверные пакеты однозначно должны быть предельно компактными и бинарными.

Ссылки на объекты же, в свою очередь, должны быть аналогичны нынешним URL.

Вообще, уже сам факт того, что irc так и не вышел за рамки чатов, уже говорит не в его пользу.

Лучше уж на тот же Jabber ориентироваться :)

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от KRoN73

>>Вообще, уже сам факт того, что irc так и не вышел за рамки чатов, уже говорит не в его пользу.

точно не скажу, но вроде ragnarok-online на ирке постоен

Lockywolf ★★★
()
Ответ на: комментарий от KRoN73

Не "так и не вышел за рамки" а "прочно занял нишу". На счет избыточности - большую часть канала будет отжирать загрузка объектов, а пакет взаимодействия с учетом ирк избыточности можно сделать в пределах 100 байт, и текстом будет передаваться толко заголовок, а само сообщение никто не мешает сделать бинарным. Jabber детально не изучал, может действительно лучше его. Хотя если хотите долгострой - изобретайте свое колесо.

Ссылки на какие именно объекты в виде url? Если на локации, то игра не стоит свеч, проще сделать гибрид vrml и ajax. Если на предметы внутри локации, как изображения на страницах, то будут большие проблемы с синхронизацией, при изменении одного свойства объекта придется перегружать объект целиком. К виртуальному миру подход http - что хочу то и загружаю - недопустим, тут клиент должен видеть что показывает ему сервер, и никак не меньше.

И в каком стиле будет происходить взаимодествие объектов мира? Рассчет координат как в шутерах (тогда действительно будет жестко нагружен и сервер, и канал), или взаимодействие с объектом по его имени, как в WoW, но тогда реализация многих игровых моментов отпадет.

MiDoS
()
Ответ на: комментарий от Lockywolf

> точно не скажу, но вроде ragnarok-online на ирке постоен

он не 3d, НЯЗ.

а что-то реалтаймовое без бинарных пакетов.. нуу.. попробуйте.

dmiceman ★★★★★
()
Ответ на: комментарий от MiDoS

> Рассчет координат как в шутерах (тогда действительно будет жестко нагружен и сервер, и канал)

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

dmiceman ★★★★★
()

Очень, очень интересная идея.
В последнее время сам неоднократно задумывался над этим.

Nicko
()
Ответ на: комментарий от MiDoS

>Не "так и не вышел за рамки" а "прочно занял нишу".

... из которой вылезать дальше не хочет ;) На своём месте он сидит неплохо (правда, я в качестве конференций всё равно Jabber предпочитаю), но делать на нём 3D-протокол - очень избыточно.

>На счет избыточности - большую часть канала будет отжирать загрузка объектов

Но потом они будут кешироваться. Даже чистый бинарный трафик будет составлять 1..5Мб/час. Если перевести его в текстовый, это легко приведёт и к его удвоению. За день сидения в онлайне "паразитный" трафик составит десятки мегабайт. И зачем? Только ради того, что прикрутить сюда IRC? :)

Нефига, когда можно сделать свой компактный бинарный протокол?

Тем более, что сама идеология IRC тут не шибко поможет, ИМХО. Будет очень много тонкостей в роутинге, балансировке, межсерверном взаимодействии.

>а пакет взаимодействия с учетом ирк избыточности можно сделать в пределах 100 байт

Зачем так много? Типичный пакет занимает от единиц до десятков байтов весь :) (move_to[x, y, z]; stop_move[], social_action[id]...).

>Ссылки на какие именно объекты в виде url? Если на локации, то игра не стоит свеч, проще сделать гибрид vrml и ajax.

Локации в виде координат точки входа, не более того.

Основные "URL-подобные" координаты - это объекты мира. Текстуры, меши, звуки, скрипты.

"Локаций" как таковых клиенту передвать незачем. Ему нужно передавать ссылки на объекты. Клиент перемещается и получает от сервера пакеты с идентификаторами исчезающих из поля хрения объектов и входящих в поле зрения. По этому ID клиент извлекает все данные объекта (если есть - из кеша, нет - качает) и рисует его.

>при изменении одного свойства объекта придется перегружать объект целиком.

Каждый компонент объекта будет адресоваться отдельно. Получили ссылку на объект. Он возвращает ссылки на текстуры, скелет, скрипты. Если текстура поменялась - будет скачана заново.

>К виртуальному миру подход http - что хочу то и загружаю - недопустим, тут клиент должен видеть что показывает ему сервер, и никак не меньше.

В ActiveWorlds принцип был именно "что хочу, то загружаю" :) Ты приходишь в новую локацию - ты видишь её сразу. Но ещё пустую. Потом она понемногу дозагружается, на ходу дорисовываясь. В SecondLife сейчас такая же картина.

>И в каком стиле будет происходить взаимодествие объектов мира? Рассчет координат как в шутерах (тогда действительно будет жестко нагружен и сервер, и канал), или взаимодействие с объектом по его имени

Внутри одного кластера все объекты располагаются в единой координатной сетке. Клиенту сообщаются его координаты и координаты каждого передаваемого объекта. Т.е. где их рисовать относительно него. Кроме координат - ссылка на сам объект, по которой оный будет загружен, если его ещё нет. Координаты будут приходить в бинарном пакете по постоянному соединению. Объекты будут грузиться по временному соединению, хоть по тому же HTTP :)

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от Opik

> А не смотрели ли в сторону http://www.ireon.org - все открыто, engine: orge, lang: cpp + pythom

Нет, не видел его. Интересно. Пощупаю.

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от Nicko

>Очень, очень интересная идея. В последнее время сам неоднократно задумывался над этим.

Ну так, милости просим. Даже на уровне генератора идей :) Хотя, конечно, хочется в первую очередь клиентских программистов, пока со вчерашнего дня... Ну, я бы сказал, 0.75 такого программиста нашли (0.5 + 0.25 :D ). У кого-то опыта мало, у кого-то побольше, но ещё долго не сможет приступить к работе в проекте (время, время! дайте мне 100 часов в сутках! :D)

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от KRoN73

>Но почему же в таком случае на UDP не переходят? :)

потому что требования к задержкам у MMORG более другие, нежели у FPS и других игр, где задержка играет большую роль. Если ты не хочешь изначально ограничить "внутренние" миры - придется этот вопрос хорошо обдумать.

geek ★★★
()
Ответ на: комментарий от geek

>потому что требования к задержкам у MMORG более другие, нежели у FPS и других игр

Если бы UDP был во всём лучше TCP, то, полагаю, писали бы исключительно на нём :)

Значит - просто обязаны быть подводные камни.

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от KRoN73

>Если бы UDP был во всём лучше TCP, то, полагаю, писали бы исключительно на нём :)

его и используют. Там, где _опоздавший_ пакет с данными становится бесполезным в силу объективных причин. В ip-телефонии, 3д-шутерах, леталках. Где требуется жёсткий интерактив, в общем

>Значит - просто обязаны быть подводные камни.

подводные камни тут только необходимость самостоятельно гарантировать доставку пакетов, которые должны быть доставлены _гарантировано_. Всё.

geek ★★★
()
Ответ на: комментарий от geek

>Там, где _опоздавший_ пакет с данными становится бесполезным в силу объективных причин.

Кхм. Что в шутерах, что в MMORPG бесполезных пакетов быть не может. Если ты отдаёшь команду на перемещение, а до клиента она не дойдёт, то что будет? :D Угу, сервер твоё перемещние отрабатывать начнёт, клиент - нет. Приехали.

_Все_ пакеты важны.

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от geek

>подводные камни тут только необходимость самостоятельно гарантировать доставку пакетов, которые должны быть доставлены _гарантировано_

А таковых в протоколе обмена - подавляющее большинство. Если не все. Разве что какие-нибудь social actions можно доставлять без гарантий. Ну так у них и задержка некритична.

А требовать от клиента подтверждения на каждый пакет - это сильный рост как трафика, так и загрузки сервера. Ему придётся проверять доставку каждого пакета. Если для FPS с онлайном в 16 человек это фигня, то когда этих человек будет хотя бы 500...

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от KRoN73

Собственно по этому поводу, кстати, и вопрос - кому-нибудь известны примеры... скажем так, MMOFPS :) Т.е. FPS с онлайном хотя бы на несколько сотен, а лучше - на тысячи. Тысяча игроков, 40 тысяч NPC/мобов :) Есть у меня сомнения, что такую хрень можно эффективно реализовать на UDP с подтверждением.

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от KRoN73

>А таковых в протоколе обмена - подавляющее большинство. Если не все.

нет. меньшинство.

координаты, например, подтверждения не требуют. Все равно, если пакет n+5 пришёл раньше пакета n+4 - пакет n+4 теряет актуальность.

geek ★★★
()
Ответ на: комментарий от KRoN73

>Если ты отдаёшь команду на перемещение, а до клиента она не дойдёт, то что будет?

там не команды на перемещение ходят. А координаты объектов. Поток которых интерполируется особым образом, чтобы ликвидировать дерганье. Плюс используется предсказание

geek ★★★
()
Ответ на: комментарий от geek

>координаты, например, подтверждения не требуют

Гы. Какие координаты? :D В Lineage2 протоколе координаты шлёт _клиент_ серверу раз в полторы секунды при беге (и никогда - при неподвижности) и, только если они не совпадают с серверным - сервер может выслать поправку. Иных координат постоянных нет. Тут что UDP, что TCP... Разницы никакой :D

Основной поток пакетов - это MoveTo, StopMove, StartAutoAttack, StopAutoAttack и т.п. :) При чём из этих перечисленных координаты есть только у MoveTo но шлётся он достаточно редко, раз в несколько секунд - когда игрок указывает поинт :)

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от geek

>там не команды на перемещение ходят. А координаты объектов.

Вот тогда и понятно, почему у FPS редко бывает более 16 игроков на одном сервере :D Вот когда сетевые технологии смогут посылать постоянно координаты десятков тысяч объектов тысячам пользователей - тогда иной вариант и рассмотрим :D

А сегодня ни сети, ни железо такое просто не потянут.

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от KRoN73

>Вот когда сетевые технологии смогут посылать постоянно координаты десятков тысяч объектов тысячам пользователей - тогда иной вариант и рассмотрим :D

десятков тысяч не надо. Достаточно в зоне видимости. Откуда ты 10к взял?

geek ★★★
()
Ответ на: комментарий от KRoN73

>Гы. Какие координаты? :D В Lineage2 протоколе координаты шлёт _клиент_ серверу раз в полторы секунды при беге (и никогда - при неподвижности) и, только если они не совпадают с серверным - сервер может выслать поправку. Иных координат постоянных нет. Тут что UDP, что TCP... Разницы никакой :D

так в LA2 и точность для шутера, например, не подходит. Для гонок тоже =)

в общем, считаю необходимым предусмотреть FPS-like работу с сетью как вариант. А на tcp оставить сигнализацию. Иначе вылезут ограничения, которые будет уже не ликвидировать

geek ★★★
()
Ответ на: комментарий от geek

>десятков тысяч не надо. Достаточно в зоне видимости. Откуда ты 10к взял?

Я про сервер говорил. 1000 пользователей рассеявшихся по миру наблюдает 40 тыс. мобов. Типичная картина для MMOPG. Какая разница, сколько пакетов пойдёт одному юзеру. Важно сколько пакетов пойдёт в сумме. И сколько их придётся ещё "в памяти держать" на проверку дохождения.

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от geek

>в общем, считаю необходимым предусмотреть FPS-like работу с сетью как вариант.

MMO сегодня такие режимы не потянет.

Опровергнуть меня легко.

Приведи пример коммерческого шутера на UDP с онлайном хотя бы в 500 человек. Ась?

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от KRoN73

>Я про сервер говорил. 1000 пользователей рассеявшихся по миру наблюдает 40 тыс. мобов. Типичная картина для MMOPG. Какая разница, сколько пакетов пойдёт одному юзеру. Важно сколько пакетов пойдёт в сумме. И сколько их придётся ещё "в памяти держать" на проверку дохождения.

40 тысяч мобов - это что?

geek ★★★
()
Ответ на: комментарий от geek

>40 тысяч мобов - это что?

40 тысяч мобов. Монстров, NPC и т.п. Не-игроков. О действиях каждого из них нужно сообщать видящим их игроков. Что создаёт соответствующий (основной по факту) трафик.

Это типичная величина для Lineage 2.

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от KRoN73

>Почти убедил. Но какое там количество активных объектов в мире? Нигде не нашёл.

активные объекты - игроки. Всё остальное - spawn + визуализация на стороне клиента в зависимости от параметров спавна.. Ты же не думаешь, что при выстреле из автомата пользователю передаются координаты каждой пули?

geek ★★★
()
Ответ на: комментарий от KRoN73

>Монстров, NPC и т.п. Не-игроков. О действиях каждого из них нужно сообщать видящим их игроков.

ключевое слово - _видящим_. Основная нагрузка на сервер будет именно расчет видимости, а не генерация трафика.

в общем, протокол надо изобретать очень вдумчиво, чтобы ненароком не сжечь мосты =)

geek ★★★
()
Ответ на: комментарий от geek

Гы :) "Изменений для себя не заметил, но имеется полезная фича: отображени пинга до сервера. У меня составляет 230, у других в Германии от 170 до 250." :D

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от KRoN73

Так в том то и дело, что netcode2 вроде на tcp

в первоапрельском посте он пишет, что правильнее было бы выбрать udp изначально. А так там слишком много завязано на tcp

кстати, tcp грузит сервер больше. В случае udp можно обойтись одним raw-сокетом ;)

geek ★★★
()
Ответ на: комментарий от Sectoid

> Хм... AFAIK Deeptown Project будет выпущен под открытой лицензией.
Скажем так, есть вероятность, что будет под открытой.
Клиент, по крайней мере. Про открытие серверной части я пока не слышал.

pacify ★★★★★
()
Ответ на: комментарий от geek

>кстати, tcp грузит сервер больше. В случае udp можно обойтись одним raw-сокетом ;)

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

Это всё требует немалых ресурсов.

Вот, за 19 часов аптайма при онлайне менее десятка человек L2-сервер у меня отослал 53815436 пакетов. Представь, что сервер будет обрабатывать 500 человек. И 2/3 пакетов потребует его постоянного внимания.

Я не уверен, что он с этим вообще справится :)

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от KRoN73

> Вот, за 19 часов аптайма при онлайне менее десятка человек L2-сервер у меня отослал 53815436 пакетов. Представь, что сервер будет обрабатывать 500 человек. И 2/3 пакетов потребует его постоянного внимания.

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

Gharik
()
Ответ на: комментарий от KRoN73

>Нет, тут фишка в другом. Основные и массовые пакеты требуют подтверждения.

это можно будет утверждать только после разработки протокола

>Вот, за 19 часов аптайма при онлайне менее десятка человек L2-сервер у меня отослал 53815436 пакетов. Представь, что сервер будет обрабатывать 500 человек. И 2/3 пакетов потребует его постоянного внимания.

2/3 - это малореально

идеи о протоколе у тебя какие-то есть уже?

geek ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.