Skip to Content

Мультиплеер. Пост №1.

AlexanderG

Не буду писать вводную, думаю, и так все понятно. Для начала просто опишу с т.з. программирования. Комплекс для МП будет состоять из следующих частей:
  1. Программа-драйвер, реализующая обмен данными между ТРС и внешним миром через редактирование памяти.
  2. Программа, реализующая сетевой обмен с сервером.
  3. Собственно сервер.
  4. Правило сессии, реализующее обмен данными с внешним миром через программу-драйвер.
  5. Правило сессии, интерпретирующее поступающие извне команды и наоборот.

Драйвер занимается обменом инфой с ТРСом. Также он имеет внешний локальный сетевой интерфейс (сервер, работающий через Loopback) для связи с плагинами. Все принимаемые из игры сообщения рассылаются всем подключенным плагинам, а те уже дальше интерпретируют их как нужно либо отбрасывают. Это позволит писать сторонние модули (в частности, драйверы для воплощенных в "железе" пультов), не внося изменения в критичный к ошибкам код работы с памятью. Также такая технология позволит использовать простой сокетный интерфейс для общения модулей с игрой, не заморачиваясь работой с памятью, формированием фреймов, синхронизацией и т.п.

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

Правила сессии действуют аналогично внешней программной части, для разделения низкоуровнего и высокоуровнего кода и упрощения интерфейса для сторонних скриптов.

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

Сейчас я пока застрял на реализации API для формирования и обработки "фреймов", передаваемых\получаемых из игры. Планируется, что в одном фрейме возможно хранить произвольное количество строк произвольной длины (что позволяет почти неограниченную скорость передачи данных). Если кому интересно, опишу формат представления фрейма в памяти, может, кто-то упростит мне работу ^_^

На сегодня это все, всем спасибо за внимание.
Join Dropbox and SHARE YOUR SHIT FOR FREE!
 
 

Re: Мультиплеер. Пост №1.

agmike

Эх, блин, сначала б саму прогу сделать, а уж потом думать о правилах и регламентах.
The Cake is a Lie.
 

Re: Мультиплеер. Пост №1.

AlexanderG

Вчера отладил функции сборки и разборки фрейма данных.
Join Dropbox and SHARE YOUR SHIT FOR FREE!
 

Re: Мультиплеер. Пост №1.

TRam_

>Как находим адрес — отдельное ноу-хау Принцип тот же, что и в АртМани. Насчет формата, пока решил организовать так:
1) Маркеры для поиска в памяти (20 байт).
2) Указатель количества сообщений во фрейме (4 байта).
3) Таблица адресов сообщений (4*число сообщений).
Далее идет область собственно данных в следующем формате:
1) Длина сообщения (4 байта).
2) Собственно сообщение (до 4ГБ).


ну а я подумаю над альтернативой. Состав примерно такой (для удобства распознавания всего этого ТРСом предлагаю использовать объект класса строки ТРС / он же массив char в памяти):

1) символ направления передачи
2) символ завершения записи в строку
3) символ завершения чтения строки
4) длина сообщения
5) собственно данные

Размер строки фиксирован.

Две строки, на одной из которых выполняется передача из трс в прогу, а в другой из проги в трс, изначально забиваются некой последовательностью символов (вся длина строки, т.е. 1000-2000 символов), который прога при "коннекте" ищет в памяти - при этом находятся нужные нам строки, и некоторые лишние. Затем по команде пользователя скрипт меняет по одному символу в обоих строках, и опять же по команде пользователя/по таймеру прога проверяет эти символы во всех строках, в которых найдена последовательность.

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

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

В результате мы получаем необходимость передавать в пике около 2000 символов в секунду в обе стороны, т.е. траффик при максимальной нагрузке (20 поездов, каждому выдеелено по 100 символов) 2000*4*2=16000 бит/секунду= 16 кбит/секунду

блок искания уже почти готов, а вот с серверами-клиентами я ноль полный. Да и скрипты дешифровщики+ "умные" скрипты установщики скорости ещё писать и писать.
Последний раз редактировалось TRam_ 11.05.2010, 01:45, всего редактировалось 4 раз(а).
в z7 всё можно, а что нельзя - можно в sU
 

Re: Мультиплеер. Пост №1.

agmike

Мультплеер — дело десятое, сначала нужно сделать передачу произвольных строк из ТРСа в систему и обратно. Значит, требуется сделать интерфейс для этого как в ТРСе, так и в системе, причем в последнем случае желательно иметь средства удобнее чем сишный экспорт.
2) символ завершения записи в строку
3) символ завершения чтения строки

Зачем делать сложности там, где они не нужны?

А вот маркеры должны присутствовать всегда. Мало ли, выбило скрипт или ТРС. Не хочу получать SIGSEGV.
Да и вариант Александра мне кажется вполне подходящим, не вижу смысла его менять.
по команде пользователя

И чтоб все автоматически было, без всяких пользователей!

На заметку тебе: пишешь в конфиге либы always-load-in-global-context 1 и получаешь всегда загружаемую библиотеку. Ну и с этим про World.GetCurrentModule() не забывай.
Последний раз редактировалось agmike 12.05.2010, 11:59, всего редактировалось 3 раз(а).
The Cake is a Lie.
 

14 ответов • Страница 2 из 21, 2

 
 
Архивы
- Декабрь 2009