Проект HighCity (мы не одиноки во вселенной VR :)

Всем привет, я автор проекта HighCity (http://highcity.sourceforge.net/ , но там все в зачаточном состоянии, только схемы ). Проект разрабатывается на C++, с использованием кросс-платформенного масштабируемого движка AmberSkyNet ( [ AmberSkyNet VR ], регулярно обновляются исходники в SVN, который тоже я пишу, довольно медленный и с не очень хорошей архитектурой, возникает желание забить и сделать по-быстрому виртуального клиента на VElib, скажем

---

Идея 3d-мира приходила в голову и мне.. Я вдохновлялся немецкой программой Roomancer ( единый мета-сервер, куча пользовательских локаций.. весь контент хранится на локальных компах у участников.. можно "заходить в гости" на удаленный комп и принимать гостей у себя.. )
Одна из идей проекта HighCity - разделить сервер логики и граф. сервер по двум разным серверам.. Соответственно к одному и тому же серверу логики можно "подцепить" несколько "визуализаторов" - 3d, 2d, текстовые, адаптированные для КПК, мобильные, итп.. Таким образом куча пользователей может находиться в одном и том же мире, сидя на разных устройствах...

Cервер логики проверяет - может ли обьект Х cовершить операцию У над обьектом Z, и если может, то проводит ее...
Сервер графики - по полученному от сервера логики XML-файлу логики делает визуализацию системы и передаёт дальше XML-файл с описанием изменений в 3d-мире...
Сервер графики еще может быть полезен тем, что служит как бы "шляпкой" для сервера логики, и если его взломают, то сервер логики останется невредимым..
--
Еще одна идея 3d-мира - адаптация других интерфейсов в единую VR-среду Например - модуль IRC-клиента, через который сервер логики общается с обычным IRC-сервером и передает полученные от него в VR-среду, которая в зависимости от пользовательских настроек трансформирует полученные сообщения, например, в падающие сверху на "рабочий стол" конверты, при клике на которых эти сообщения будут прочитаны, и при желании на них можно будет ответить..

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

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

---

К чему это я? Может быть какие-то идеи вам понравятся (их можно смело воровать :), может быть получится сделать единый XML-протокол для 3dWeb на основе наших проектов...

Единый протокол безусловно рулит, но мы ратуем за бинарный обмен. Экономия в командном потоке будет очень большая, буквально - в разЫ.

Если делать только бинарный проткол, имхо - будет еще один 3d-чат со своим особым протоколом В XML - сила
В конце концов, можно сделать поддержку и того и другого, а XML по-моему будет легче увязать со сторонними разработками, чем бинарный протокол..
Например, в том же Flash есть средства для разбора XML, поэтому и на нем можно будет сделать визуализацию XML с сервера логики не используя сторонних библиотек..

В XML - сила. Но у нас стоит задача минимизации трафика

Вообще, есть в качестве примера для подражания протколы L2 и WoW. Где, скажем, пакет CharMoveToLocation (один из самых часто посылаемых) занимает 29 байт (код операции + код объекта + 3 координаты исходной точки + 3 координаты конечной). В то время, как в XML он же будет занимать уже под две сотни байт:

1. <packet action="CharMoveToLocation">
2. <object_id>123456</object_id>
3. <from>
4. <x>123456</x>
5. <y>56789</y>
6. <z>-1234</z>
7. </from>
8. <to>
9. <x>123499</x>
10. <y>56789</y>
11. <z>-1234</z>
12. </to>
13. </packet>

Итого - шестикарнтый проигрышь по трафику на таком простом примере. А даже бинарный протокол на не самом загруженном L2-сервере уже в упор забивает стомегабитные каналы на сервере и едва хоть как-то позволяет играть на хороших модемах.

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

Кроме того, у нас даже бинарный пакет будет больше размером (координаты придётся делать long, object_id - тоже не меньше long'а, если вообще не строкой...)

(пока писал уже ответили

Повторюсь, ведь. Просаживается не только канал юзера. Но и канал сервера