Мультиплеер. Пост №1.
Не буду писать вводную, думаю, и так все понятно. Для начала просто опишу с т.з. программирования. Комплекс для МП будет состоять из следующих частей:
Драйвер занимается обменом инфой с ТРСом. Также он имеет внешний локальный сетевой интерфейс (сервер, работающий через Loopback) для связи с плагинами. Все принимаемые из игры сообщения рассылаются всем подключенным плагинам, а те уже дальше интерпретируют их как нужно либо отбрасывают. Это позволит писать сторонние модули (в частности, драйверы для воплощенных в "железе" пультов), не внося изменения в критичный к ошибкам код работы с памятью. Также такая технология позволит использовать простой сокетный интерфейс для общения модулей с игрой, не заморачиваясь работой с памятью, формированием фреймов, синхронизацией и т.п.
Сервер. Пока неизвестна его роль в МП — она может варьироваться от тупого рассылальщика сообщений куда попало до сложного комплекса, реализующего разграничение доступа, фильтрацию ошибок и т.п.
Правила сессии действуют аналогично внешней программной части, для разделения низкоуровнего и высокоуровнего кода и упрощения интерфейса для сторонних скриптов.
На данный момент есть реальный результат — удалось передать в игру и получить обратно байт данных. А где один байт — там и полноценный обмен, так что возможность всего этого безобразия экспериментально доказана.
Сейчас я пока застрял на реализации API для формирования и обработки "фреймов", передаваемых\получаемых из игры. Планируется, что в одном фрейме возможно хранить произвольное количество строк произвольной длины (что позволяет почти неограниченную скорость передачи данных). Если кому интересно, опишу формат представления фрейма в памяти, может, кто-то упростит мне работу
На сегодня это все, всем спасибо за внимание.
- Программа-драйвер, реализующая обмен данными между ТРС и внешним миром через редактирование памяти.
- Программа, реализующая сетевой обмен с сервером.
- Собственно сервер.
- Правило сессии, реализующее обмен данными с внешним миром через программу-драйвер.
- Правило сессии, интерпретирующее поступающие извне команды и наоборот.
Драйвер занимается обменом инфой с ТРСом. Также он имеет внешний локальный сетевой интерфейс (сервер, работающий через Loopback) для связи с плагинами. Все принимаемые из игры сообщения рассылаются всем подключенным плагинам, а те уже дальше интерпретируют их как нужно либо отбрасывают. Это позволит писать сторонние модули (в частности, драйверы для воплощенных в "железе" пультов), не внося изменения в критичный к ошибкам код работы с памятью. Также такая технология позволит использовать простой сокетный интерфейс для общения модулей с игрой, не заморачиваясь работой с памятью, формированием фреймов, синхронизацией и т.п.
Сервер. Пока неизвестна его роль в МП — она может варьироваться от тупого рассылальщика сообщений куда попало до сложного комплекса, реализующего разграничение доступа, фильтрацию ошибок и т.п.
Правила сессии действуют аналогично внешней программной части, для разделения низкоуровнего и высокоуровнего кода и упрощения интерфейса для сторонних скриптов.
На данный момент есть реальный результат — удалось передать в игру и получить обратно байт данных. А где один байт — там и полноценный обмен, так что возможность всего этого безобразия экспериментально доказана.
Сейчас я пока застрял на реализации API для формирования и обработки "фреймов", передаваемых\получаемых из игры. Планируется, что в одном фрейме возможно хранить произвольное количество строк произвольной длины (что позволяет почти неограниченную скорость передачи данных). Если кому интересно, опишу формат представления фрейма в памяти, может, кто-то упростит мне работу
На сегодня это все, всем спасибо за внимание.
Join Dropbox and SHARE YOUR SHIT FOR FREE!
Re: Мультиплеер. Пост №1.
Эх, блин, сначала б саму прогу сделать, а уж потом думать о правилах и регламентах.
The Cake is a Lie.
Re: Мультиплеер. Пост №1.
Вчера отладил функции сборки и разборки фрейма данных.
Join Dropbox and SHARE YOUR SHIT FOR FREE!
Re: Мультиплеер. Пост №1.
>Как находим адрес — отдельное ноу-хау Принцип тот же, что и в АртМани. Насчет формата, пока решил организовать так:
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 кбит/секунду
блок искания уже почти готов, а вот с серверами-клиентами я ноль полный. Да и скрипты дешифровщики+ "умные" скрипты установщики скорости ещё писать и писать.
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 кбит/секунду
блок искания уже почти готов, а вот с серверами-клиентами я ноль полный. Да и скрипты дешифровщики+ "умные" скрипты установщики скорости ещё писать и писать.
в z7 всё можно, а что нельзя - можно в sU
Re: Мультиплеер. Пост №1.
Мультплеер — дело десятое, сначала нужно сделать передачу произвольных строк из ТРСа в систему и обратно. Значит, требуется сделать интерфейс для этого как в ТРСе, так и в системе, причем в последнем случае желательно иметь средства удобнее чем сишный экспорт.
Зачем делать сложности там, где они не нужны?
А вот маркеры должны присутствовать всегда. Мало ли, выбило скрипт или ТРС. Не хочу получать SIGSEGV.
Да и вариант Александра мне кажется вполне подходящим, не вижу смысла его менять.
И чтоб все автоматически было, без всяких пользователей!
На заметку тебе: пишешь в конфиге либы always-load-in-global-context 1 и получаешь всегда загружаемую библиотеку. Ну и с этим про World.GetCurrentModule() не забывай.
2) символ завершения записи в строку
3) символ завершения чтения строки
Зачем делать сложности там, где они не нужны?
А вот маркеры должны присутствовать всегда. Мало ли, выбило скрипт или ТРС. Не хочу получать SIGSEGV.
Да и вариант Александра мне кажется вполне подходящим, не вижу смысла его менять.
по команде пользователя
И чтоб все автоматически было, без всяких пользователей!
На заметку тебе: пишешь в конфиге либы always-load-in-global-context 1 и получаешь всегда загружаемую библиотеку. Ну и с этим про World.GetCurrentModule() не забывай.
The Cake is a Lie.
14 ответов • Страница 2 из 2 • 1, 2