Прочитал еще раз Ваш пост. Не понимаю, как он связан с тем, о чем я говорю. Загуглите ошибку GetThreadContext failed. Это косяк старого моно, который исправлен в новом моно. Но поскольку юнити юзает старый моно, то все пользователи юнити подвержены этому косяку. Вне зависимости от того, используете ли вы в своем коде многопоточность или нет.
Следовательно для n комнат, будет нужно n build'ов, что будет наверное очень немерянно потреблять ресурсы.
Именно так. Но если прицепить NetworkView то объекты будут автоматически синхронизировать себя между всеми клиентами, в случае же использование SmartFox или Photon всю физику и положения объектов придется вручную обсчитывать на сервере, или же есть возможности упростить это?
можно схитрить и на каждом клиенте держать свою физику. а нужные объекты синхронизировать.
p.s. У меня почему то не получилось запустить обсчет комнаты для headless build'a, наверное я что то делаю не так. Может есть какие нибудь особенности в реализации?
Ищите ошибку у себя. Сеть в хэдлесс режиме работает нормально.
Юнитевая сеть хороша для игр, у которых сервак хостится на клиенте. Типа десматчи в контре, когда ты сам можешь поднять у себя сервак и резаться с друзьями.
Для всех остальных случаев, когда нужен полноценный сервер, с разделением по комнатам и т.д. и т.п, юнитевая сеть не приспособлена и вам придетс это все делать самому.
Кроме того, юнитевая сеть работает внутри билда юнити, и если вам не надо обслуживать физику на сервере, то билд юнити — это лишнаяя трата ресурсов.
На юнитевой сети нельзя сделать одновременно симуляцию физики для разных комнат-боев. Только для одного.
В текущем проекте юзаем смартфокс для синхронизации 20 игроков в реалтайме. А вообще все зависит от конкретной задачи. Может вам и юнитевой сети хватит.
Имхо, самая главная инструкция к начинающему разработчику игр — сделать пару простых игр, но при этом обязательно сделать их законченными. Без этого лучше даже не думать про инвесторов, ООО и т.п.
Здесь мы видимо останемся каждый при своем мнении. Я искренне считаю, что использование смартфокса сэкономит при разработке куда больше, чем 1 месяц или даже два.
Ясненько. Я видимо разбалован такими движками, как Юнити и Смартфокс и под термином движок понимаю нечто большее, что позволяет абстрагироваться почти полностью от глубин стевого транспорта, или обсчета физики и рендеринга и сосредоточиться непосредственно на создании игровой логики. Хотя и при наличии данных замечательных движков процесс разработки все равно получается не быстрым.
Надеюсь, что таки напишете. Когда в начале разработки гуглил поверхностно по этому вопросу ничего сверх полезного не нашел.
Ну, если вы пилите свой движок серверный (хотя может и не только серверный), то там всем сетевым вопросам должно быть уделено самое тщательное внимание, и на этом экономить конечно нельзя.
Да, конечно, вопрос максимально точной синхронизации большой и интересный. Возможно, когда мы пройдемся по нему вдоль и поперек, я и напишу про это статью. Но раз уж Вы этим сами сейчас занимаетесь, буду рад почитать статью про ваши изыскания в данном вопросе.
«Построение серверной архитектуры — тот еще, конечно, вопросец, но в принципе ничего невозможного нет, достаточно полопатить MSDN. А вот вопросы синхронизации — гораздо глобальней.»
С одной стороны да. С другой стороны, Смартфоксы пилят свой серверный движок уже больше 8 лет. Не хочется с нуля повторять их опыт, читая мсдн, поэтому я за то, чтобы использовать готовые движки.
По поводу третьего пункта — если человек, который оплачивает Вашу разработку согласен на такой план, то нет проблем. Но чаще всего никто не согласится увеличивать разработку проекта на несколько месяцев (и соответственно платить всей команде зарплаты) только для того, чтобы некоторый процент игроков с лагающей сетью чувствовал себя комфортней. Звучит немного грубо, но это суровая правда жизни. Если у Вас не так — то это здорово, надеюсь Ваша синхронизация будет самой безглючной.
Воссоздание геометрии уровня и просчет всех столкновений для всех коллайдеров машинок на серваке. Ну и если уж все это подняли, можно идти дальше, просчитывать все выстрелы.
1. Вы поняли неправильно. Сервер изначально был не в локалке, альфатестирование на данный момент в самом разгаре и на лаги синхронизации никто еще не жаловался.
2. Вопросы синхронизации положения машинок — это отдельная огромная статья, которую когда-нибудь может и напишу. Цели осветить этот вопрос в данной статье не стояло.
3. Как бы не был красив клиент — с неотлаженной сетью это полная хрень. Обратное утверждение так же верно. Со стремным клиентом и идеально отлаженной сетью это тоже будет полная хрень. В реальной жизни приходится соблюдать баланс, и откладывать многие вещи до тех пор, пока не всплывет необходимость ими заниматься.
Сглаживание писали сами, машинки конечно же не телепортируются на каждый апдейт позиции. За основу взяли набросок скрипта то ли из демки юнити какой то, то ли из просторов сети, и изрядно ее допилили.
Экономику читы никак не сломают, вся экономика на сервере. А вот бой испортить — это да. Тут уж постараемся по максимуму обезопасить остальных игроков от читеров.
полгода мечтаем, чтобы они и на этот баг патч наложили. Но на форуме вроде как клятвенно пообещали, что работа уже кипит.
Именно так.
Но если прицепить NetworkView то объекты будут автоматически синхронизировать себя между всеми клиентами, в случае же использование SmartFox или Photon всю физику и положения объектов придется вручную обсчитывать на сервере, или же есть возможности упростить это?
можно схитрить и на каждом клиенте держать свою физику. а нужные объекты синхронизировать.
p.s. У меня почему то не получилось запустить обсчет комнаты для headless build'a, наверное я что то делаю не так. Может есть какие нибудь особенности в реализации?
Ищите ошибку у себя. Сеть в хэдлесс режиме работает нормально.
Для всех остальных случаев, когда нужен полноценный сервер, с разделением по комнатам и т.д. и т.п, юнитевая сеть не приспособлена и вам придетс это все делать самому.
Кроме того, юнитевая сеть работает внутри билда юнити, и если вам не надо обслуживать физику на сервере, то билд юнити — это лишнаяя трата ресурсов.
На юнитевой сети нельзя сделать одновременно симуляцию физики для разных комнат-боев. Только для одного.
docs.google.com/spreadsheet/ccc?key=0AjZV0SdoOTsPdFVGQWxUWW9Fdmk2RzNfa3hUZU90V1E&hl=en_US#gid=0
В текущем проекте юзаем смартфокс для синхронизации 20 игроков в реалтайме. А вообще все зависит от конкретной задачи. Может вам и юнитевой сети хватит.
Ну, если вы пилите свой движок серверный (хотя может и не только серверный), то там всем сетевым вопросам должно быть уделено самое тщательное внимание, и на этом экономить конечно нельзя.
«Построение серверной архитектуры — тот еще, конечно, вопросец, но в принципе ничего невозможного нет, достаточно полопатить MSDN. А вот вопросы синхронизации — гораздо глобальней.»
С одной стороны да. С другой стороны, Смартфоксы пилят свой серверный движок уже больше 8 лет. Не хочется с нуля повторять их опыт, читая мсдн, поэтому я за то, чтобы использовать готовые движки.
По поводу третьего пункта — если человек, который оплачивает Вашу разработку согласен на такой план, то нет проблем. Но чаще всего никто не согласится увеличивать разработку проекта на несколько месяцев (и соответственно платить всей команде зарплаты) только для того, чтобы некоторый процент игроков с лагающей сетью чувствовал себя комфортней. Звучит немного грубо, но это суровая правда жизни. Если у Вас не так — то это здорово, надеюсь Ваша синхронизация будет самой безглючной.
2. Вопросы синхронизации положения машинок — это отдельная огромная статья, которую когда-нибудь может и напишу. Цели осветить этот вопрос в данной статье не стояло.
3. Как бы не был красив клиент — с неотлаженной сетью это полная хрень. Обратное утверждение так же верно. Со стремным клиентом и идеально отлаженной сетью это тоже будет полная хрень. В реальной жизни приходится соблюдать баланс, и откладывать многие вещи до тех пор, пока не всплывет необходимость ими заниматься.