Пора определяться.

 
+
-
edit
 

Balancer

администратор
★★★★★
Итак, пора приступать к работе. А значит - нужно определяться с начальным базисом.

Резюме такое.

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

Поток данных вначале реализуется на обычном HTTP. Т.е. у каждого статического параметра будет свой уникальный URL работающий в рамках классичсеского HTTP. Любую текстуру можно будет скачать хоть из браузера.

Командный поток - бинарный, собственная реализация. Передаётся по TCP. Идеологически - калька с пакетов Lineage2. Нужно ещё обдумать формат пакетов, хотя писаться они будут, естественно, по мере необходимости.

Нерешённый вопрос - передача голосовой (в перспективе - и видео) информации. С одной стороны можно подумать о том же HTTP (обычное поточное вещание), с другой - можно посмотреть в сторону открытых стандартов обмена голосом, в сторону того же SIP. Gizmo, Google Talk, etc. Было неплохо иметь возможность общаться голосом сразу с Gizmo/Google Talks-пользователями прямо из своего клиента.




Языки тестовых версий сервера и клиента. Это будет Python и там, и там. Несогласные могут проводить изначально эксперименты с иными средствами в рамках протокола. Как я уже говорил - разнообразие серверов и клиентов будет приветствоваться. Но собственные сервер и клиент сервера на начальном этапе будут написаны на Питоне. В дальнейшем, после отработки протокола и при нехватке производительности сервера возможно его переписывание на нечто более производительное. Но сейчас нам важно реализовать протокол. Так что вопросы эффективности - вторичны.




Задача-минимум. 3D-красивости даже не рассматриваются. Сможет кто-то из команды осилить - прекрасно. Пока же достаточно будет если участники смогут видеть друг друга (пусть - всех одинаковых, с одной аватарой) на плоскости и общаться в чате. Зато нужно постараться ускорить реализацию голосового чата. Соответстсвенно, нужно сразу думать о голосовом протоколе.




Идеи. Очень полезно придумать систему виртуальной разработки... прямо из клиента. Т.е. после минимального функционального базиса виртуально собирается команда, общается там же в виртуале голосом и чатом и... тут же, совместно, пишет код или ваяет 3D. Это может очень существенно ускорить разработку и создать дополнительный интерес для новых разработчиков.




Формат общения - крайне рекомендуется этот форум. Ибо нужно документирование мыслей и идей.
… чтобы понять рекурсию, нужно сперва понять рекурсию …  
RU RandomAmbersky #10.09.2007 21:20
+
-
edit
 

RandomAmbersky

разработчик OpenWorlds
Кстати.. может будет более удобно собирать определившиеся тезисы и факты из форума в виде некоей wiki? Чтобы полученные факты были отделены от обсуждения и сосредоточены в одном месте с соответствующими информационными тегами, а то здравые мысли разбросаны по всему разделу форума...
 

Tico

модератор
★★☆

.
Mille viae ducunt homines per saecula Romam (C) Alain de Lille, Liber Parabolarum СССР был сложной наведённой галлюцинацией с ограниченным сроком годности. (c) МХ  
RU Balancer #18.09.2007 17:26  @RandomAmbersky#10.09.2007 21:20
+
-
edit
 

Balancer

администратор
★★★★★
RandomAmbersky> Кстати.. может будет более удобно собирать определившиеся тезисы и факты из форума в виде некоей wiki?

Безусловно. Только думаю, этим стоит заняться сразу после полного открытия проекта. А будет это после появления первых тестовых вещей :)
… чтобы понять рекурсию, нужно сперва понять рекурсию …  
UA SoulKeeper #31.10.2007 00:31
+
-
edit
 

SoulKeeper

разработчик L2J Fortress

Большой пузатый ап :)

Проэкт многообещающий, но похоже пока мертвый. Что очень печально :(
Разыскивается десятка с два датапакеров :) http://la2.wrk.ru/forum/viewtopic.php?id=50882  
+
-
edit
 

Balancer

администратор
★★★★★
Ходит и бродит в голове... Очень много про него думал в последнюю неделю.

Уже видно, что с самого начала нужно перекраивать очень многое из задуманного. Уже видно, что массу вещей, которые планировалось использовать в готовом виде (те же Ogre-биндинги) придётся чуть ли не самим писать. Как ни стараюсь, но никак не получается отойти от перспектив использования JVM (альтернатива - только .NET, и то слабая) вместо Питона...
… чтобы понять рекурсию, нужно сперва понять рекурсию …  
UA SoulKeeper #31.10.2007 12:26
+
-
edit
 

SoulKeeper

разработчик L2J Fortress

Мир клином на Огре не сошелся :)
Разыскивается десятка с два датапакеров :) http://la2.wrk.ru/forum/viewtopic.php?id=50882  

Murkt

Pythoneer

Да мне что-то столько проблем видится при реализации изначальной идеи, что даже не начинал ничего делать. А проблемы эти можно обойти мозговым штурмом пяти человек сразу когда уже есть на чём экспериментировать...
[team Їжачки - сумні падлюки]  

Murkt

Pythoneer

А кроме JVM/.NET варианты есть. Только никто из нас не умеет на этих языках программировать. Я вот собираюсь учиться только :)
[team Їжачки - сумні падлюки]  
RU Balancer #31.10.2007 12:45  @SoulKeeper#31.10.2007 12:26
+
-
edit
 

Balancer

администратор
★★★★★
SoulKeeper> Мир клином на Огре не сошелся :)

Скажем так, у нас вырисовывается несколько слоёв.

1. Слой-протокол для распределённого обмена объектами (закачка с серверов разных миров геодаты, объектов, текстур, скриптов, музыки и т.д.) - с одной стороны, это будет основной скелет системы, с другой - не будет проблем менять его и настраивать. Что интересно, пригодится он не только для OpenWorlds (об этом ниже).

2. Слой - отрисовка полученных данных. К сожалению, тут надо очень тщательно продумать всё с самого начала. Если мы заложим передачу объектов для Ogre, то не сможем использовать Irrlicht. Заложим Irrlicht - не сможем использовать что-то ещё... Это главный затык на сегодня. Кроме того - у меня ещё с ним личная трудность. С 3D не работал... И не менее важная трудность - Что ogre4j, что jirr сегодня крайне сырые и почти неработоспособные, python-ogre ненамного лучше, а pyrr, кажется, вообще умер. Реально начанать прямо сейчас хоть что-то можно только с python-ogre, но у python постоянно натыкаешься на массу трудностей, которые будут отсутствовать в JAVA-варианте. В общем - думать и думать перед тем, как проборвать...

3. Программный слой для всего этого безобразия. Вырисовывается, кстати, гибкая плагинная репозиторная система, с которой можно будет делать очень модульный софт с контролем версий. Отчасти это решит проблему выбора 3D-движка для 2-го пункта. Можно будет реализовывать для разных миров разные 3D-движки. Нужные программные модули будут подгружаться наравне с прочими элементами мира.

Пункты 1 и 3, кстати, могут оказаться очень интересным решением и без привязки в OpenWorlds. Неплохо иметь гибко и автоматически расширяющиеся по мере надобности системы. Но тут постоянно утыкаешься в то, что нормальный базис подо всё это есть сегодня только в JVM. Это и возможность изолированного (безопасного) исполнения апплетов, и возможность передачи бинарных программ без исходников (для тех, кто не захочет отдавать свои сорцы), и удобные механизмы JAR'ов, просто богатый выбор языков и библиотек, наконец...
… чтобы понять рекурсию, нужно сперва понять рекурсию …  
+
-
edit
 

Balancer

администратор
★★★★★
Murkt> Только никто из нас не умеет на этих языках программировать.

Я считаю, что мы не должны привязываться к языкам :) Мы должны привязываться к мультиязычным системам
… чтобы понять рекурсию, нужно сперва понять рекурсию …  
UA SoulKeeper #31.10.2007 17:51  @Balancer#31.10.2007 12:45
+
-
edit
 

SoulKeeper

разработчик L2J Fortress

Balancer> 1. Слой-протокол для распределённого обмена объектами (закачка с серверов разных миров геодаты, объектов, текстур, скриптов, музыки и т.д.) - с одной стороны, это будет основной скелет системы, с другой - не будет проблем менять его и настраивать. Что интересно, пригодится он не только для OpenWorlds (об этом ниже).

Не вижу вообще в этом проблемы. Обычный HTTP протокол с воможностью докачки, проверка скажем по той же md5 чексуме. Не самый быстрый вариант но работоспособный. Передаем zip(или любой другой архив) Можно конечно попытатся выпендрится и сделать что-то вроде побайтового сравнения файлов и докачки только нужной части, но тут такое выгодно только для больших файлов и строго привязывать их к чексуммам\чему-то другому, иначе получится не экономия траффика, а пустая трата.



Balancer>Я считаю, что мы не должны привязываться к языкам Мы должны привязываться к мультиязычным системам

Главное что-бы тут не получилось "горе от ума"
Основное ядро должно быть написано на одном языке, а скрипты - на чем душа пожелает :). Имхо :)
Разыскивается десятка с два датапакеров :) http://la2.wrk.ru/forum/viewtopic.php?id=50882  
+
-
edit
 

Murkt

Pythoneer

Murkt>> Только никто из нас не умеет на этих языках программировать.
Balancer> Я считаю, что мы не должны привязываться к языкам :) Мы должны привязываться к мультиязычным системам

Ой, звыняйте. Я не про клиент говорил :) В клиенте, действительно, только .NET/JVM/Python. Не на С++ же его писать.

По поводу ограниченного выполнения - в Питоне это сделать можно, очень-очень просто. Я только что в консоли попробовал. Просто подменил _import_ на свою версию. Обойти - нереально.

По поводу собственно мультиязычных систем - я не согласен с тем, что оно нужно, это раз. Мультиязычность можно прикрутить к любому языку, это два. Было бы яростное желание и мозг :)
[team Їжачки - сумні падлюки]  
RU Balancer #01.11.2007 09:56  @SoulKeeper#31.10.2007 17:51
+
-
edit
 

Balancer

администратор
★★★★★
SoulKeeper> Главное что-бы тут не получилось "горе от ума"
SoulKeeper> Основное ядро должно быть написано на одном языке, а скрипты - на чем душа пожелает :). Имхо :)

А ядро (в идеале) будет совсем крошечным. Микроядерные системы рулят при разработке :)
… чтобы понять рекурсию, нужно сперва понять рекурсию …  
AD Реклама Google — средство выживания форумов :)
+
-
edit
 

Balancer

администратор
★★★★★
Murkt> По поводу собственно мультиязычных систем - я не согласен с тем, что оно нужно, это раз. Мультиязычность можно прикрутить к любому языку, это два. Было бы яростное желание и мозг :)

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

в начало страницы | новое
 
Поиск
Настройки
Твиттер сайта
Статистика
Рейтинг@Mail.ru