www.open-tager.ru

открытый лазертаг форум
Текущее время: 20 апр 2024, 19:43

Часовой пояс: UTC + 3 часа [ Летнее время ]


Реклама

Правила форума


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



Начать новую тему Ответить на тему  [ Сообщений: 41 ]  На страницу Пред.  1, 2, 3, 4, 5  След.
Автор Сообщение
 Заголовок сообщения: Re: VolksTager NRF24
СообщениеДобавлено: 02 дек 2015, 14:05 
Не в сети
Аксакал форума

Зарегистрирован: 29 авг 2011, 11:08
Сообщений: 1849
Alexies писал(а):
И ещё немного моего занудства: не называйте, пожалуйста, ретранслятор роутером. Это совсем разные вещи. Термины давно придуманы, новых не требуется...
Давайте позанудствуем - где это я написал что роутер(маршрутизатор) = ретранслятору ? :lol:

Alexies писал(а):
нужно уметь "поддерживать связь" тем или иным образом, прозрачно для приложения. У меня для того есть Acknoledgement-ы, хотя поддерживается работа и без них - это лишь один бит в пакете. Это усложнит жизнь.
Угу конееечно усложит: например типичная ситуация "выстрел в цель". Пока цель не подтвердит попадание, тагер будет самостоятельно продолжать посылать ИК пакеты, без подтверждения же никак нельзя обойтись :) А граната, пока от всех находящихся рядом не получит подтверждение низачто не выключится из эфира... так по вашему ?

Ситуаций в игре где _действительно_ нужно квитирование очень и очень мало.


Alexies писал(а):
Я свою систему сделал и скромно предлагаю своё решение. "Протокол доставки точно _не_ должен входить в систему радиоАПИ" - я так-то про это и говорю, это разные уровни по той же OSI. что именно Вы называете словом радиоАПИ.
Зачем здесь модель OSI, вы хотите транслировать пакеты в другую сеть на другой стороне земного шара ? Когда соединяете бутлоадер с контроллером тоже стек в 7 уровней выписываете ? Если вы идёте на рыбалку то берёте червяков - хотя сами любите колбасу.Так вот радиоАПИ, должно быть заточено на разработчиков уровня "пионер" ! В двух словах достаточно будет если получится похоже на то, что сейчас есть на канале ИК - всё больше ничего ненадо :)

Соответственно добавлять сюда стек/библиотеку "три колена объектной модели" для разбора трёх байтов всётаки излишне. Готовое решение это конечно замечательно, поучительно, любопытно посмотреть и тд, но Аскет лежит с готовым открытым решением в 200кб кода и его никто не пытается серьёзно модифицировать. В тоже время примитивный Ltag v1, уже переписан разными авторами так что вообще непохож на начальный вариант. Людям нужно простое решение, чтобы в коде можно было разобраться за 2..3 дня пока азарт не прошёл.


Alexies писал(а):
Зачем все эти навороты (ретрансляция, синхронизация параметров) личникам? - Во-первых, я нацелен не только на личников, а хочу сделать универсальное решение. Личнику всё равно приятно поменять настройки с телефона, например. Блютус-мост один на несколько человек, думаю, "личники" потянут. А если игра целиком на системе Caustic, то это всё нужно для статистики и управления игровым сценарием, для возможности удобного размещения индикаторов игрового процесса в любой точке поля. И вообще, почему бы не выжать из технологии максимум?
Ну это понятно всё коммерческие фишки, конкретно для личников всё таки ничего не даёт, для конфигурации с телефона например блютуф не нужен - ИК прекрасно работает. Основная мысль - система обязана быть простой без "3G, GPS и серверов в облаках".

_________________
"За 2 месяца максимум можно чертёж сделать, еще за 3 фундамент." (c) Номернабис


Последний раз редактировалось LTagKirov 02 дек 2015, 15:25, всего редактировалось 5 раз(а).

Вернуться наверх
 Профиль  
 
 Заголовок сообщения: Re: VolksTager NRF24
СообщениеДобавлено: 02 дек 2015, 14:44 
Не в сети
Аксакал форума
Аватар пользователя

Зарегистрирован: 12 авг 2011, 16:55
Сообщений: 7514
Откуда: Барнаул, Алтайский край (не путать с республикой Алтай) :-)
Если человек реализовал и проверил на практике да ещё и поделиться готов - чего велосипед то изобретать? :?
Я буду делать совместимую с Caustic архитектуру радиосети.

_________________
Ваше оружие становиться значительно эффективней, если его снять с предохранителя!


Вернуться наверх
 Профиль  
 
 Заголовок сообщения: Re: VolksTager NRF24
СообщениеДобавлено: 02 дек 2015, 16:42 
Не в сети
Аксакал форума
Аватар пользователя

Зарегистрирован: 27 ноя 2011, 00:22
Сообщений: 1569
Откуда: Україна
Pingvin писал(а):
Ещё раз напоминаю - будет общая плата ядра ARMada/Caustic, считайте - это 40-ногий DIP контроллер!
Шилды легко каждый может сделать сам ЛУТОМ либо вовсе на макетке собрать.

Тут же все равно заводскую плату (ядро) покупать придется! ;)

Здесь уже есть готовая плата. Нужны только внешние силовые ключи для управления. И стоит это $3.5
Ваше ядро несомненно имеет большую мощность чем 51-й контроллер с 16кБ флеш. Но дело в том что больше чем 16к то и не надо, а будет ли ядро Армады + радиомодуль стоить дешевле $3.5 ? Это ещё надо отдельно заказывать ядро и допаивать.
А здесь готовая плата "ядра" но уже с радиомодулем и за меньшие деньги.

_________________
Нет предела совершенству, но ресурсы заканчиваются быстро.


Вернуться наверх
 Профиль  
 
 Заголовок сообщения: Re: VolksTager NRF24
СообщениеДобавлено: 02 дек 2015, 17:36 
Не в сети
Аксакал форума
Аватар пользователя

Зарегистрирован: 12 авг 2011, 16:55
Сообщений: 7514
Откуда: Барнаул, Алтайский край (не путать с республикой Алтай) :-)
Pacifist писал(а):
... а будет ли ядро Армады + радиомодуль стоить дешевле $3.5 ? Это ещё надо отдельно заказывать ядро и допаивать.
А здесь готовая плата "ядра" но уже с радиомодулем и за меньшие деньги.

Все равно шилд делать, так что - какая разница?
Получится узкоспециализированная вещь.
Да пусть будет, я только "ЗА"!
Но ядро ARMada/Caustic даёт большую свободу творчества.

_________________
Ваше оружие становиться значительно эффективней, если его снять с предохранителя!


Вернуться наверх
 Профиль  
 
 Заголовок сообщения: Re: VolksTager NRF24
СообщениеДобавлено: 02 дек 2015, 18:15 
Не в сети
Аксакал форума

Зарегистрирован: 29 авг 2011, 11:08
Сообщений: 1849
Pingvin писал(а):
Все равно шилд делать, так что - какая разница?
Разница в цене - это огорчает и радует одновременно...

+ Пользователям нЕнужен вифи и блюпуп если есть беспроводка, им вообще неважно как она получена главное задёшево. Задумка действует, это радует :)

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

_________________
"За 2 месяца максимум можно чертёж сделать, еще за 3 фундамент." (c) Номернабис


Вернуться наверх
 Профиль  
 
 Заголовок сообщения: Re: VolksTager NRF24
СообщениеДобавлено: 03 дек 2015, 02:54 
Не в сети
Старожил

Зарегистрирован: 18 мар 2015, 13:19
Сообщений: 574
Откуда: Нижний Новгород
LTagKirov писал(а):
Alexies писал(а):
И ещё немного моего занудства: не называйте, пожалуйста, ретранслятор роутером. Это совсем разные вещи. Термины давно придуманы, новых не требуется...
Давайте позанудствуем - где это я написал что роутер(маршрутизатор) = ретранслятору ? :lol:


Примерно тут:
LTagKirov писал(а):
2. Ретрансляция и маршрутизация пакетов должна быть отдельной подсистемой, на _отдельных_ радиоканалах. Эта штука медленная, передача пакета по цепочке занимает длительное время соответственно если эти пакеты похранятся в функции роутера и передадутся как-то потом ничего страшного не случится. На первое время эта часть радиоАПИ вообще не нужна, система не заточена на прокат.

Или я не понял, о чём Вы говорите. Слово "роутер" больше нигде не употреблялось.

Насчёт OSI, ну не хотите - как хотите называйте. Я просто пытался говорить на общепринятом языке. Не нравится фраза "канальный уровень" - называйте это "5 байт адреса". Не нравится "уровень представления" - называйте это "радиоАПИ". В любом случае, то, что у Вас получится, можно классифицировать по этой модели. И это не имеет никакого отношения к WiFi, интернету и международным сетям. По это модели хоть мобильная связь, хоть домофон, хоть проволочный телеграф, хоть записки у первоклассников работают, если хотите. Только соответствия всегда нестрогие.

LTagKirov писал(а):
Alexies писал(а):
нужно уметь "поддерживать связь" тем или иным образом, прозрачно для приложения. У меня для того есть Acknoledgement-ы, хотя поддерживается работа и без них - это лишь один бит в пакете. Это усложнит жизнь.
Угу конееечно усложит: например типичная ситуация "выстрел в цель". Пока цель не подтвердит попадание, тагер будет самостоятельно продолжать посылать ИК пакеты, без подтверждения же никак нельзя обойтись :) А граната, пока от всех находящихся рядом не получит подтверждение низачто не выключится из эфира... так по вашему ?


Да эти ситуации очевидны. Например, игрока убили. Его таггер должен тут же выключиться. Время реакции больше 0,1 сек. неприемлемо. Также, всякие разновидности shock delay. Вместо подтверждения пакета можно, конечно, слать целую очередь из пакетов со случайным задержками, "авось дойдёт хоть один", но это ещё только усугубит ситуацию в эфире. А если перестрелка масштабная, то таггеры будут отключаться вообще не предсказуемо.
Также, любые команды управления игрой и передача статистики. Целостность проще всего контролировать на уровне пакетов. А то будет, как у некоторых производителей - половина дошла, половина - нет.

При чём тут ИК-пакеты и гранаты - я в упор не пойму. Мы же, кажется, про радио говорим? Естественно, не нужно посылать подтверждение о получении ИК-пакета. А гранате радио не нужнее, чем пассатижи в бане.

Если что, в моём радиопротоколе, конечно, далеко не на всё требуются подтверждения.

Насчёт пионеров... Начинать разработку протокола тогда уж надо с того, чтобы внятно оговорить область его применения. Мне не очевидно, например, из этой ветки, что одним из требований является простота его имплементации. Слова "система должна быть простой" я всегда понимал в смысле аппаратного обеспечения. Это понятно, поскольку это позволяет упростить пайку и удешевить комплект. Но зачем ограничивать себя простой прошивкой, я понять не могу. "Пионеры" сами писать ничего не будут, а мы тут уж как-нибудь осилим несложную сетевую логику. То есть, зачем сразу отказываться от вещей, которые можно получить бесплатно (на программном уровне)?

Также о пионерах. Если игра будет на разношерстных девайсах, то всё радио в любом случае сведётся только к беспроводному оружию. Потому что у одного будет таг8, у другого - LW, а у третьего - Armada или Caustic. А играть они будут в клубе с прокатчиками, где LSD.
В случае моей системы, радио даст ещё и простоту конфиграции (ага, ИК-пульт - это удобно! Он прям сразу показывает, сколько у игрока здоровья, в какой он команде и какой там shock delay...)
Если Вы заранее нацеливаетесь только на беспроводную связь оружия и повязки без всякой базы и удаленного управления - тогда вопросов нет, можно спамить пакетами, сколько удобно. Каналов хватит всем.

А если игра на радио-совместимых системах, то тогда имеет смысл делать умный протокол.

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


Вернуться наверх
 Профиль  
 
 Заголовок сообщения: Re: VolksTager NRF24
СообщениеДобавлено: 03 дек 2015, 11:58 
Не в сети
Аксакал форума

Зарегистрирован: 29 авг 2011, 11:08
Сообщений: 1849
Alexies писал(а):
Например, игрока убили. Его таггер должен тут же выключиться. Время реакции больше 0,1 сек. неприемлемо. Вместо подтверждения пакета можно, конечно, слать целую очередь из пакетов со случайным задержками, "авось дойдёт хоть один", но это ещё только усугубит ситуацию в эфире.
Несовсем так. Повязка с маркером всё равно _постоянно(спам)_ обмениватеся пакетами и желательно почаще(0,1сек), тогда вопрос зачем отправлять в обратную сторону пакет подтверждения, если скоро следующий сеанс и придёт свежий пакет ? Удваивать количество выходов в эфир (квитирование) и спамить канал от этого ещё сильнее :)

Аргумент что после выхода из игры игрока спам прекратится, несущественен, так как во время игры система спам переваривала, а после вдруг ей станет заметно легче ? Квитирование для повязки, маркера, гаранаты, аптечки не уменьшает количество пакетов в сети - наоборот удваивает, попробуйте сделать модельку системы на обычном компютере и сами убедитесь :) Ещё раз посторюсь у нас не сеть передачи данных, а сеть синхронизации состояний - квитирование только мешает. Это утверждение проверено на железе с весьма маленькой скоростью (RFID до 10метров), и показало отличные результаты. Я понимаю ваши сомнения, вы привыкли делать так как уже получалось 100500раз, и очень трудно допустить другое решение задачи.


Alexies писал(а):
При чём тут ИК-пакеты и гранаты - я в упор не пойму. Мы же, кажется, про радио говорим?
Радиограната более полезная и интересное устройство для игры чем ИК. В LtagV2 реализованы радиогранаты(RFID 10метров), так вот если сравнивать реальную игру с ИК и RFID гранатой, геймплей получается в разы интерестнее: на открытой местности и в траве RF гранаты _реально_ работают, от RF гранаты не спрятатся за картонной дверью - кидающий тоже опасается гранаты и кидает её действительно подальше, и радиус радио гранаты возможно сделать по настоящему большим (симуляция бомбы)


Alexies писал(а):
Насчёт пионеров... Начинать разработку протокола тогда уж надо с того, чтобы внятно оговорить область его применения. Мне не очевидно, например, из этой ветки, что одним из требований является простота его имплементации.
Это очень важное требование.
Яркий пример: функция клонирования настроек в майлс. Вещь архинужная, но _ни_в_одном любительском и коммерческом российском лазертаг проекте эта функция не реализованна, и у вас тоже наверняка не реализованна(причины выбрать по вкусу). Казалось бы что там сложного массив выгрузить и готово, ан нет комерсы несмогли сделать, а ХСЛщикам уже и нескем это применять. Чуть-чуть сложнее чем три байта отправить и всё "кина небудет" :)


Alexies писал(а):
зачем ограничивать себя простой прошивкой, я понять не могу. "Пионеры" сами писать ничего не будут, а мы тут уж как-нибудь осилим
Основная цель, чтобы пионеры _всётаки_ захотели писать сами.
Здесь такие варианты:
1. Сложный большой код ненужный никому кроме авторов, его нежалко выложить - продать его невозможно (Аскет, Ltk v2).
2. Хороший большой код, авторы зажмут - жалко трудов(всё правильно), не будем себя обманывать ;)
3. Хороший(плохой) _маленький_ код, авторы легко поделятся так как сил потрачено немного - это очень важный момент. (Ltk v1, tommy, Tag8)

Второй вариант самый неудачный система не будет "народной", очередная поделка пытающаяся под ширмой помощи ХСЛ раскрутится до продаж, публика не дураки быстро смекнут что к чему. Продажи это нормально, не надо стеснятся, так и говорите, здесь вполне нормально относятся к коммерсантам и не смотрят на них как на врагов народа если те не пытаются прикинутся овечкой.


Alexies писал(а):
Также о пионерах. Если игра будет на разношерстных девайсах, то всё радио в любом случае сведётся только к беспроводному оружию. Потому что у одного будет таг8, у другого - LW, а у третьего - Armada или Caustic. А играть они будут в клубе с прокатчиками, где LSD. А если игра на радио-совместимых системах, то тогда имеет смысл делать умный протокол.
Вот поэтому радипротокол должен быть настолько простой чтобы даже в прошивку Tag8 поместился за 30 минут работы. Никаких умностей, сессий, состояний и прочего сетевого барахла. Чтобы была возможность любому пионеру очень быстро и недорого сделать мост RF-IR поместить его на повязку или в макет от любого производителя, чтобы даже прокатчики соблазнились ценой и простотой интеграции новой радиофункции и внедрили гранаты и радиобомбы.


Alexies писал(а):
В случае моей системы, радио даст ещё и простоту конфиграции (ага, ИК-пульт - это удобно! Он прям сразу показывает, сколько у игрока здоровья, в какой он команде и какой там shock delay...)
Всем прекрасно понятно, что вам хочется чтобы новые модули приняли _ваш_ протокол, так как это может принести вам некоторые выгоды в будущем, это нормально ;). Ваше видение протокола явно заточено под коммерческое использование, оно отлично подходит под прокатные применения и имеет свои важные плюсы, и это хорошо, но к сожалению такой протокол не смогут поддержать "пионеры". Очевидно что целиком исходники вашего проекта никогда не появятся в общем доступе, а сами они не смогут сделать поделку такой сложности с ноля, итого толку от библиотек протокола ноль, а ведь для ХСЛ пионеры главная движущая сила, больше людей брать неоткуда. Программистов среди них нет, есть только любители, надо спустится с олимпа до их уровня...

_________________
"За 2 месяца максимум можно чертёж сделать, еще за 3 фундамент." (c) Номернабис


Последний раз редактировалось LTagKirov 03 дек 2015, 12:26, всего редактировалось 1 раз.

Вернуться наверх
 Профиль  
 
 Заголовок сообщения: Re: VolksTager NRF24
СообщениеДобавлено: 03 дек 2015, 12:59 
Не в сети
Местный
Аватар пользователя

Зарегистрирован: 15 май 2013, 13:16
Сообщений: 367
Откуда: Киев
Пока писал стало не особо актуально, но пусть будет

Alexies писал(а):
Примерно тут:
Или я не понял, о чём Вы говорите. Слово "роутер" больше нигде не употреблялось.

Я так понял из контекста имелась ввиду функция-маршрутизатор, иллюстрируемая например заражением "вирусом" - она не обязательно ретранслирует пакет-заражение сразу дальше в сеть с подтверждением, т.к. время здесь не критично , а хранит в себе , передавая на определённых условиях - при попадании в рейндж игрока другой команды, при "смерти" или другом катализаторе.. +я так понял имелась ввиду доставка пакетов типа "Игрок № параметр №,сохрани и передай дальше" - который в конечном счёте дойдут до адресата, как только он попадёт в зону взаимодействия с другими модулями - при это цепочка передачи может быть прерывистой и сильно растянутой во времени.
Я так понял по принципам это больше похоже на то что называют Mesh сети (?)
Цитата:
Да эти ситуации очевидны. Например, игрока убили. Его таггер должен тут же выключиться. Время реакции больше 0,1 сек. неприемлемо. Также, всякие разновидности shock delay. Вместо подтверждения пакета можно, конечно, слать целую очередь из пакетов со случайным задержками, "авось дойдёт хоть один", но это ещё только усугубит ситуацию в эфире. А если перестрелка масштабная, то таггеры будут отключаться вообще не предсказуемо.
Также, любые команды управления игрой и передача статистики. Целостность проще всего контролировать на уровне пакетов. А то будет, как у некоторых производителей - половина дошла, половина - нет.

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

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

Цитата:
При чём тут ИК-пакеты и гранаты - я в упор не пойму. Мы же, кажется, про радио говорим? Естественно, не нужно посылать подтверждение о получении ИК-пакета. А гранате радио не нужнее, чем пассатижи в бане.

Я так понял вопрос в том, что от ИК гранаты (или бомбы если хотите) может прикрыть трава\колея\снег\ямка в которой она лежит. радиограната\бомба таких проблем не имеет, может хоть сквозь тонкую стену накрыть и легко регулируеться мощность. аналогично зоны, точки и артефакты.
Цитата:
Если что, в моём радиопротоколе, конечно, далеко не на всё требуются подтверждения.

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

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

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

Цитата:
В случае моей системы, радио даст ещё и простоту конфигурации (ага, ИК-пульт - это удобно! Он прям сразу показывает, сколько у игрока здоровья, в какой он команде и какой там shock delay...)

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

_________________
"какой фонтан !! какое артериальное давление !!!" © Фаргус
-Look, buddy,- i'm a complete ZERO in HSL.


Вернуться наверх
 Профиль  
 
 Заголовок сообщения: Re: VolksTager NRF24
СообщениеДобавлено: 03 дек 2015, 15:18 
Не в сети
Старожил

Зарегистрирован: 19 сен 2012, 20:19
Сообщений: 807
Откуда: Москва
"...функция клонирования настроек в майлс. Вещь архинужная, но _ни_в_одном любительском и коммерческом российском лазертаг проекте эта функция не реализованна.."
Ну, как минимум в одном все же реализована;) -Макстар

_________________
-Look, buddy,- i'm an engineer.


Вернуться наверх
 Профиль  
 
 Заголовок сообщения: Re: VolksTager NRF24
СообщениеДобавлено: 03 дек 2015, 17:25 
Не в сети
Завсегдатай
Аватар пользователя

Зарегистрирован: 24 фев 2013, 17:41
Сообщений: 177
Откуда: Красный Май
Расскажу как вижу использование радио канала в лт со своей колокольни.
По чему нужен радио канал для лазертага.
1.Радио сигнал всенаправленный
2.Не зависит от освещённости (погодных условий)
3.Область приёма передачи можно регулировать мощностью передатчика при стандартной чувствительности приёмника.
4.Не нужен прямой физически или визуальный контакт с устройством (игрок может не(а иногда и не должен) знать где передатчик)
5.Идентификация живых игроков игровыми устройствами

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

ПРИНИМАЮЩИЕ – только принимают радио команды
ПЕРЕДАЮЩИЕ – только передатчики радио команд
ПРИЕМОПЕРЕДАЮЩИЕ устройства
АКТИВНЫЕ – игрок должен физически взаимодействовать с устройством (нажать кнопку, активировать датчик)
ПАСИВНЫЙ – взаимодействие с игроком только по радио каналу.

ПАСИВНО –ПЕРЕДАЮЩИЕ устройства - только передают команду которую устройство игрока выполняет
Пример - Различной площади зоны бафов\дебафов и глобальных событий.
1. Точки радиации или госпиталь
2. Зоны куда игрок не должен заходить (попав в неё игрок сразу умирает)
3. Выбросы – глобальные игровые события (старт, стоп игры, оживить всех)

ПАСИВНЫЕ – ПРИЁМНИКИ устройство только определяет есть ли игрок в зоне действия устройства
Пример: ОБЕЛИСК(точка вархамер) Чем больше игроков одной команды в зоне приёмника тем быстрее активируется(захватится) точка

ПАСИВНЫЕ – ПРИЁМОПЕРЕДАТЧИКИ передают команду и запрос на ответ получают ответ и меняют логику своей работы.
Пример: точка бонуса – Точка постоянно передаёт команду (+10 здоровья), пробегая мимо неё, устройство игрока принимает эту команду, и в ответ посылает команду «ВЗЯЛ». Точка уходит в стендбай на N секунд после этого.
Так могут работать аптечки, аномалии или минные поля.

АКТИВНЫЕ ПРИЁМНИКИ – устройство проверяющие по радио каналу игрок жив и только тогда активируемое кнопкой.
Пример: Электронный замок игрок нажимает кнопку устройство проверяет есть ли живой игрок в радиусе приёма дверь открывается
Мина с объёмным датчиком сработает только на живого игрока.
В принципе - это тагеры\ножи\гранаты\индивидуальные аптечки\патроны(но тут должен быть более сложный по мне вариант общения личные предметы должны привязываться к игроку, чтоб была возможность использовать их быстро и также быстро отключать их функционирование)

АКТИВНЫЕ ПЕРЕДАТЧИКИ – устройства активируется (нажатие кнопки, или выстрел) и предаёт радио команду.
Пример: баллон с газом – игрок стреляет по устройству после чего оно предаёт команду взрыв
Различные системы поражения укреплений.

АКТИВНЫЕ ПРИЁМО ПЕРЕДАТЧИКИ- это устройство игрока.

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

и как мне кажется тут всего три типа данных в радио канале
команды - они могут быть с запросом на ответ или без него
ответ- одна универсальная команда "ВЗЯЛ" (ЧТО то типа да я получил команду в принципе не важно какую)
Состояние игрока ЖИВ\МЁРТВ более для игры не надо все остальные данные параметры нужны для настроек статистики но не вижу смысла это делать в онлайн режиме.

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


Вернуться наверх
 Профиль  
 
Показать сообщения за:  Сортировать по:  
Начать новую тему Ответить на тему  [ Сообщений: 41 ]  На страницу Пред.  1, 2, 3, 4, 5  След.

Часовой пояс: UTC + 3 часа [ Летнее время ]


Кто сейчас на форуме

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 8


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB