Скриптование под мультиплеер

[TRam_]

kemal, то есть ты предлагаешь повесить мониторинг того, сидит ли в подъезжающем поезде игрок, и если сидит, то только в этом случае обрабатывать его проезд и рассылать остальным? Правильно понял?

А что делать с составами, которые без машинистов катятся? Или с составами, игрок которых вылетел? Кто будет сообщать серверу, что этот состав теперь нуждается в синхронизации по нему самому, а не по игроку?

Касательно перевода стрелок - если стрелки переведутся у игрока правильно, это соовсем не гарантирует, что состав не сойдёт на сервере (и из этого сойдёт у всех остальных). Тогда придётся делать некий сумматор состояний сервера и игрока, но... У нас и так канал едва справляется с рассылкой скоростных ограничений при проездах светофора с сервера, а тут нужно дублирование сообщения о проезде каждого светофора от каждого игрока на сервер, а потом его рассылка всем, кроме сервера и этого игрока...

---------- Сообщение добавлено в 23:53 ---------- Предыдущее сообщение размещено в 23:47 ----------

Ну и серверу таймаут события(?) если игрок не может его отослать.

[kemal]

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

kemal, то есть ты предлагаешь повесить мониторинг того, сидит ли в подъезжающем поезде игрок, и если сидит, то только в этом случае обрабатывать его проезд и рассылать остальным? Правильно понял?

Да, типа того. Просто у меня это реализуется автоматически (обрабатываются не триггеры, а составы. Соответственно, "не свои" составы просто пропускаем).

А что делать с составами, которые без машинистов катятся? Или с составами, игрок которых вылетел?

Все "ничейные" составы на сервер. Он же эти составы обрабатывает, соответственно и взаимодействие с сигналкой обрабатывать тоже ему.

Кто будет сообщать серверу, что этот состав теперь нуждается в синхронизации по нему самому, а не по игроку?

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

Касательно перевода стрелок - если стрелки переведутся у игрока правильно, это соовсем не гарантирует, что состав не сойдёт на сервере (и из этого сойдёт у всех остальных). Тогда придётся делать некий сумматор состояний сервера и игрока

Вот тут да, согласен. Хотя, с другой стороны, чем эта ситуация лучше перевода стрелки на сервере, когда у игрока поезд ещё не проехал?
И да, это не требует дополнительных затрат на синхронизацию, так как маршрутизация (в отличии от децентрализованной сигнализации) полностью остаётся на сервере.

но... У нас и так канал едва справляется с рассылкой скоростных ограничений при проездах светофора с сервера...

Вот тут ещё хотелось бы добавить кое-что. По моему мнению существующий подход избыточно грузит канал связи. Сейчас при, например освобождении блок-участка, сервер обновляет несколько предыдущих светофоров и затем для каждого рассылает на клиенты новое состояние. Гораздо лучше было бы синхронизировать только события наезда/съезда, а обновления состояний рассчитывать на каждом клиенте.

---------- Сообщение добавлено в 01:04 ---------- Предыдущее сообщение размещено в 01:02 ----------

а тут нужно дублирование сообщения о проезде каждого светофора от каждого игрока на сервер, а потом его рассылка всем, кроме сервера и этого игрока...

Зачем??? Бродкастом всем от игрока, управляющего составом. Таким образом сигналка становится децентрализованной.

[TRam_]

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

Сервер будет непрерывно проверять, какие составы никому не назначены, правильно понял?

обрабатываются не триггеры, а составы

в sU обрабатываются массивы составов над триггером. Потому что их может быть два, в случае манёвров в зоне триггера.

сервер обновляет несколько предыдущих светофоров и затем для каждого рассылает на клиенты новое состояние.

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

[kemal]

Сервер будет непрерывно проверять, какие составы никому не назначены, правильно понял?

Ну... Можно и так сказать. У меня в каждой итерации происходит World.GetTrainList(). Соответственно, там же можно сделать проверку чей это поезд и нужно ли его обрабатывать. Как это можно сделать у тебя - не знаю.

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

Эм.. Чёт тут я не до понял твой посыл...
Чего у меня пронумеровано?
Да и что ты подразумеваешь под проверкой занятости? Разве "волна обновления" автоматически не подразумевает проверку занятости?

[TRam_]

Разве "волна обновления" автоматически не подразумевает проверку занятости?

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

[Эрендир]

Гладко было на бумаге, а потом попёрли баги.

[kemal]

Если подать сигнал проезда от игрока на сервер

Нет никакого сервера! Для сигналки все игроки равнозначны.
Перекрытие светофора по наезду не нужно перепроверять. Если от игрока пришло сообщение, что он наехал на светофор, то это значит что он точно на него наехал, ему лучше знать. Вот со съездом сложнее. Но и тут можно сделать у сообщения приоритет выше. То есть если пришло сообщение, что поезд съехал со светофора, а локально это не так, то мы его (поезд) у себя игнорируем.

Эрендир, чем это хуже существующих багов?

[Эрендир]

чем это хуже существующих багов?

Сложностью реализации. В остальном всё почти всё тоже самое. Да, безусловно обработку наезда, съезда стоило бы перенести на клиента для тех поездов, что с этого клиента управляются. Только нагрузка на канал увеличивается, ибо сначала надо отправить сообщение об изменении серверу, а потом с него разослать всем. Это явно не способствует уменьшению пинга. Не забывай, что при децентпализации всегда требуется больший канал. К тому же, помимо сложности реализации, ты получаешь кучу подводных камней. Классический пример с рождением неопределённости: Поезд на клиенте наезжает на светофор. Клиент обрабатывает это дело, так как это его поезд. При этом, имеем пинг около секунды. Через пол секунды после наезда этот клиент отваливается (BSOD или свет выключили. Да всяко бывает). Сервер (имею ввиду клиента выполняющего роль хоста) получает событие, что клиент отвалился и берёт обработку поезда на себя. В этот момент на сервере этот поезд съезжает со светофора. Но сервер ещё ничего не знает о том, что клиент на него наехал, так как сообщение от него придёт (если вообще придёт) только через пол секунды. Таким образом порождается неопределённость, которую очень сложно обработать и практически не возможно исключить. Да, пример из разряда маловероятно, но ведь вероятно. Да и сам пример отражает лишь сам процесс получения этой самой неопределённости.
Пример номер два. Не такой классический, но очень вероятный. Это, так любимые Tram_'ом проверки РЦ. Где эту проверку проводить? Ведь у всех клиентов обстановка разная. Причём, чем больше пинг, тем больше неопределённость. Да ещё и поезда призраки, которые любят мотаться на клиенте, порождая кучу событий наезда и съезда. Избавится от этой неопределённости также практически не возможно. А её вероятность уже очень высока. Примеров ещё можно приводить кучу. И все решения этих затыков требуют пристального внимания, и ресурсов на пару с каналом. Что опять же снижает производительность и увеличивает нагрузку на канал, хотя сама идея призвана сделать противоположное. В итоге, желаемый результат не достигнут, и багов меньше не стало, а может и больше. Да, светофор перестанет закрываться перед носом, но как он будет вести себя в глобальном масштабе, вопрос очень спорный.

Не, я тебя не отговариваю. Хозяин барин. Если ты сделаешь, и у тебя реально получится, ну что же, сниму шляпу.

[Рома]

Вспоминаю МСТС, с его воображаемым мультиплеером, в котором игроки разговаривали по скайпу и представляли, что они не одни на карте

[kemal]

гарантируется ли совпадение игровых Id у разных игроков?

Опыт показал, что не совпадают. У всех совершенное разные.

Отсюда встаёт вопрос, а как же тогда идентифицировать объекты? Если использовать тег autoname ну совсем не хочется.