• Неуловимая проблема тайминга кадров
    0
    Понятно что какие-то дерганья всегда есть, все работает с погрешностью. Но я, к примеру, не способен увидеть такие лаги, пока они не достигают критических значений. Может просто у вас зрение позволяет замечать больше, чем у большинства людей.
  • Неуловимая проблема тайминга кадров
    0
    FixedUpdate() как правило вызывается реже, чем Update. К примеру на один FixedUpdate у вас будет вызвано 5 раз Update, в этом случае у вас 5 кадров объект будет со старыми координатами, посчитанными в FixedUpdate. Потом вызовется FixedUpdate, и изображение дернется. Ну или даже если вы сделаете частоту вызова FixedUpdate чаще, чем в Update, все равно, будет разсинхрон, который приведет к дерганию.
    В итоге будет плавающая задержка между фактическим отображением кадра и текущим состоянием мира, но она колеблется в слишком небольших пределах, чтобы на что-то влиять, эффектов торможения от этого не должно быть.

    Вы это пробовали сами написать? У меня всегда в таких случая были только лаги. Так можно делать, если в Update пихать интерполяцию между старыми и новыми значениями, посчитанными в FixedUpdate(), но и то, объект то будет ускоряться то замедляться.
    Рассмотрим пример. Пусть частота FixedUpdate() и Update () примерно равна. В FixedUpdate() мы изменяем координату на один. x+=1; В Update отображаем эту координату. За 9 итераций FixedUpdate выводит значение x {1,2,3,4,5,6,7,8,9}, Update вызывается без синзронизации, поэтому иногда он будут запаздывать, иногда брать значение раньше, чему нужно, может получиться к примеру {1,1,3,4,4,6,6,8,9} То есть иногда объект будет слишком спешить, иногда ждать.
  • Неуловимая проблема тайминга кадров
    0
    Если сделать вот так, то объект будет двигаться плавно, за исключением случаев, описанных в статье. По факту — выявить такие случае на этапе разработки на компьютере разработчика практически не реально.
    Vector3 velocity;
    void Start() {
    velocity = transform.forward;
    }
    void Update() {
    transform.position += velocity * Time.deltaTime;
    }

    И как же, по вашему, может быть решена проблема, описанная в статье, используя методы FixedUpdate? По моему мнению, проблема, описанная в статье, на данный момент, нерешаема в общем виде. Только костылями. Если вы придумали решение, будь-те любезны показать пример кода.
    Вообще я разрабатываю сетевые игры. Например RTS стратегию. У меня координаты смещения объектов вычисляются вообще в отдельном потоке или приходят по сети. А в Update идет интерполяция между старым и новым положением. В любом случае, transform.position должен меняться в методе Update и всегда по какой-то формуле, зависимой от времени. Только так получается достигнуть плавного движения. Буду рад увидеть код с другим решением.
  • Неуловимая проблема тайминга кадров
    0

    Такой баг сложно воспроизвести. Скорее всего вы двигаете куб на константное значение в методе update, а надо константное значение умножать на Time.deltaTime. Тогда плавность будет нарушена только в очень редких случаях, как описано в статье

  • Ты только повод дай. Или под каким предлогом вас могут грабить прямо сейчас?
    +1
    Ни разу не было ничего подобного на операторе Йота. Единственные проблемы — только с качеством связи бывают, но не ниже чем у других операторов РФ (в других странах 3G работает быстрее, чем у нас LTE)
  • Игры и облако. Мифы и реальность. Ожидаем горячее обсуждение 12 апреля. Приходите виртуально
    +1
    Я занимаюсь разработкой Real Time игр. Основная проблема, которую я вижу в облаках, так это маленькое покрытие мира серверами. Например, я живу в Новосибирске, пинг до виртуалок в европе достаточно большой. Я не знаю как оно будет работать в какой-нибудь австралии, но даже дома я не могу нормально протестировать сетевую игру. Периодически есть скачки пинга.
    Рассматривал и сервис gamesparks.com, который базируется на базе облака Azure и Amazon. Та же самая проблема.
    Но даже в США, где пинг будет вполне хороший, облака не получается использовать. Причина этому — поддержка IPV6, которой просто нет (или не было несколько месяцев назад). Дело в том, что Apple для своей платформы требует поддержку IPV6 на территории США.
    Третья проблема, это достаточно высокая цена, по сравнению с другими хостингами.
    Исходя из выше перечисленных проблем, я пока склоняюсь к тому, чтобы арендовать VPS или выделенные серверы в разных странах и писать свою реализацию.
    Например, на одном московском хостинге я использую VPS с 512 оперативки за 65 рублей в месяц на базе Linux. На ней запущен сервер с .net core. Пинг из Новосибирска 49-50 у одних провайдеров, и 60-70 у других. Из европейской части страны и восточной Европы меньше 20. В США я вообще брал VPS за 4 доллара в год, с IPV6, без белого IPV4 и всего с 20 проброшенными портами IPV4, но и этого хватит для игры. Пока это на тестах, потом вероятно арендую выделенные серверы для загруженных регионов.
    До азуре пинг из Новосибирска порядка 100 – 200 мс. По крайне мере был, когда я еще надеялся делать игру на этом облаке.
    Вот это касается проблем сетевых игр.
    Если же нужно просто хранить данные в «одиночной» игре типа веселая ферма «онлайн», то инди разработчикам я бы порекомендовал бы сервис gamesparks.com. Все таки, оно бесплатно для 100 тысяч активных игроков в месяц.
    Вообще я очень уважаю компанию Майкрософт, за Visual Studio, язык C# и особенно за .net core и во всех случаях стараюсь в первую очередь использовать технологии Microsoft. Также и когда мне нужно было решить какой выбрать хостинг, то я в первую очередь рассматривал Azure. Надеюсь, когда-нибудь Майкрософт доработает облако: сделает лучше покрытие по миру, добавит IPv6 и предоставит недорогие альтернативы виртуальных машин.
  • Инструментарий фондового рынка: что такое фьючерсы и как они работают
    0
    Каким образом сперва продажа ресурса, а затем покупка того же ресурса в том же количестве могут привести к снижению цены этого ресурса?


    На снижение или повышение цены влияет то: кто готов ждать, а кто нет.
    Например, есть продавец, продающий за 110 рублей, и продавец, продающий за 120 рублей.
    Есть покупатель за 90 рублей, и покупатель за 80 рублей. Вот такие цены на рынке, и никто не готов двигаться.
    И тут приходит человек, который взял бумагу в долг и продает её. Т.е. ему придется продать одну за 90, а если хочет две, то уже за 80 рублей, потому что покупатели есть только такие. А следующие покупатели готовы уже только за 70 рублей покупать. В итоге цена бумаги на рынке становится 70 – 110 рублей. И допустим, все поняли, что надо избавляться от бумаги (авария на заводе, олимпиаду решило правительство устроить и т.д.), и также её продают, а покупатели все готовы платить меньше и меньше. Цена падает. Дальше если спекулянт готов ждать, то выставляет позиции на покупку бумаги, скажем, за 60 рублей — и ждет.
    Так почему цена падает? Потому что активно продает, а потом с ожиданием покупает. Если на рынке нет тех, кому этот актив действительно нужен (реальные потребители), то цена будет падать. Но если этот товар востребован, то никакой спекулянт не сможет сбить на него цены (другие участники просто скупят все что дешево). Таким образом, спекулянты действительно могут снизить цены переоцененного актива.

    P.S. Это мое мнение, построенное на наблюдении сделок на бирже, может отличаться от мнения специалистов, которым я не являюсь.
  • Молнии
    0
    с текстурой должен работать соответствующий Shader.
  • Архитектура сервера онлайн-игры на примере Skyforge
    0
    Туман как раз ограничивает по количеству человек, так что он будет ёжиком, который видит не пару десятков, а максимальное число игроков заданное по производительности. Для Skyforge такой максимум 250 игроков. Просто если игроки решат устроить флешмоб, и собраться в одном месте, то будет туман, и игрок будет видеть только ближайшие 250 игроков.
    По поводу коллизий и показа соседям. Вопрос не однозначный с точки зрения сервера. Показ соседям – это может быть только изменение состояния: сообщение что персонаж начал двигаться из пункта А в пунтк Б. Начал анимацию удара и т.д. Коллизия происходит при расчете движения. В любой момент два движущихся тела могут столкнуться. Все зависит и от механики игры и от способа реализации. Я не вижу однозначного ответа на данный вопрос.
    Данная оптимизация полезна не только для густонаселенных карт. Она уменьшит трафик и просто на больших картах, так как персонажи за пределами области видимости клиента не будут ему передаваться.
  • Архитектура сервера онлайн-игры на примере Skyforge
    0
    Признаю, что выражаю мысли не совсем корректно. Поясняю.
    Разбивать на мини локации нужно, чтобы
    1. Облегчить расчет коллизий на сервере между динамическими объектами.
    2. Чтобы определить набор ближайших персонажей, и передавать только первую сотню (или другое количество) из них, а других скрывать в тумане, или отображать упрощенно еще одну-две сотни.
    Если коллизия, то клеточки должны быть маленькими. Так как все равно нельзя столкнуться с тем, кто в 5 метрах и больше. То есть если столпилось несколько тысяч человек в одном месте, столкновение на самом деле проверяется только с теми, кто в этой же и соседней клеточке, а это не так много персонажей.
    Видимость и дальность выстрела зависит от механики игры. Я сказал «допустим» 10 человек (это выстрел на три шага получается). Если механика предполагает дальнобойные выстрелы, и персонаж видит далеко, мы можем по спирали анализировать ближайшие клеточки, уже не 9 штук, а больше, пока не получим сотню персонажей, или пока не достигнем предела дальности видимости. В нормальной ситуации, когда персонажей не много, игрок будет видеть далеко, но если нагрузка увеличивается, то появится туман, который сделает часть юнитов более размытыми, а часть вообще невидимыми.
    Опять же, туман может появляться, только когда сервер не справляется с нагрузкой, если справляется, то может передавать всех без ограничения.
  • Архитектура сервера онлайн-игры на примере Skyforge
    0
    Еще иначе можно сказать так. Отображаем игроку только самых близко находящихся X персонажей. Если рядом с ним уже толпа из сотни человек, то он не заметит, что где-то там кого-то не видно (можно еще туман усилить). А если дополнительно игровым дизайном ограничить нахождение такого числа человек рядом с ним, то можно спокойно делать бесшовный мир с огромным количеством игроков.
  • Архитектура сервера онлайн-игры на примере Skyforge
    0
    Под уменьшением квадратичной сложности я имею в виду следующее.
    Разбиваем карту на клеточки. Допустим, в каждой клеточке может вместиться максимум 10 персонажей. Каждый персонаж может взаимодействовать только в пределах своей клеточки и соседних. То есть 9 клеточек на плоскости. Итого в самом сложном случае каждый персонаж будет взаимодействовать максимум с 90 персонажами.
    Итого сложность алгоритма не N*N, а X*N, где X – максимальное число персонажей, которое может находиться рядом с игроком, а N – число персонажей, обрабатываемых на сервере. Т.е. с каждым новым игроком нагрузка вырастает линейно, на величину X
  • Архитектура сервера онлайн-игры на примере Skyforge
    0
    В общем, от каналов отказываться не целесообразно с экономической точки зрения. Но с таким подходом можно повысить количество человек в определенной локации, например, разрешить нескольким тысячам человек находиться на эпичном поле боя.
  • Архитектура сервера онлайн-игры на примере Skyforge
    0
    Кроме того. По поводу передачи данных. Задача то какая. У нас есть N клиентов, и каждому из них надо передать абсолютно одинаковый набор байт, т.е. информацию об N аватаров. Можно организовать что-то типа udp broadcast. Ну, например, есть игровая механика, к игровой механики присоединено 100 серверов рассылки сообщений. К каждому серверу рассылки сообщений присоединено по 1000 игроков. Всего 100 тысяч игроков на локации. Серверу механики нужно собрать информацию о 100 тысячах аватаров в один пакет, послать его 100 серверам рассылки сообщений, и каждый из этих серверов пошлет еще 1000 клиентам этот пакет.
    То есть какая работа проделывается: сначала линейная работа по сбору данных в один пакет. Потом линейная задача по отсылки этого пакета каждому клиенту. Количество трафика – квадратично и распределено. Нагрузка на каждый отдельный железный сервер линейна почти.
    А если разместить дата центры в разных частях мира, чтобы клиенты коннектились к ближайшим серверам рассылки сообщений, то вообще можно еще и с пингом порядочно бороться.
  • Архитектура сервера онлайн-игры на примере Skyforge
    0
    Ок. Я вероятно слишком уделил внимание мелочам в моем сообщении. Основная мысль сообщения: Можно сделать так, чтобы в одном городе было множество игроков, и при этом не тормозило бы на сервере.
    Я как понял у вас аватар — это просто класс, который хранит данные персонажа. Его сериализуют и передают с одной локации на другую. А сам клиент коннектится к локации (игровой механики, которая соответствует одной локации). Поэтому на один неделимый сервер возникает большая нагрузка. Если же коннект производить к самому аватару, а аватары будут работать на отдельном от игровой механики сервере, то нагрузка будет для данного сервера линейна.
  • Архитектура сервера онлайн-игры на примере Skyforge
    0
    Как Вам такое решение квадратичной сложности.
    Делаем понятие агента игрока. Он крутится на специальном сервере агентов, один такой сервер хостит несколько агентов. Клиент коннектится по TCP/IP непосредственно к агенту, а не к локации. Агент – это серверная часть, потому доверенная. Когда агент заходит на локацию, то он передает локации сообщение, что он пришел. Локации регистрирует его, и передает всем зарегистрированным агентам идентификатор новичка, а новичку, список всех агентов на локации. Аналогично при уходе агента с локации.
    Когда аватар выполняет действие, анимацию какую-нибудь, перемещается, то посылает сообщение своему клиенту и всем другим агентам в списке, чтобы они послали информацию уже своим клиентам. Таким образом для сервера, где хостится агент — это линейная задача, не квадратичная, а количество серверов можно масштабировать.
    Многие проверки может делать сам агент. Например, проверить, чтобы аватар не прошел сквозь стену, для этого агенту нужно просто иметь локальную копию карты.
    Чтобы игроки не проходили друг через друга они могут послать запрос на перемещение серверу, где хостится локация, и только получив ответ начать перемещение. Локацией кстати может быть достаточно маленькая площадь бесшовного мира или большой карты, тогда агент игрока бы работала бы с данной и соседними локациями. Причем можно сделать чтобы в локацию физически не вошло бы много игроков. В зависимости от карты агенту бы приходилось работать со списком из например 9 локаций на равнине, или 3 локаций в прямом коридоре. В том смысле, что списку игроков из этих локаций ему нужно было бы передавать свое состояние. Размер локации – это расстояние выстрела/видимости на клиенте. Ну и сообщение должно формироваться не таким циклом:
    for(Avatar av1: allAvatars) { for(Avatar av2 : allAvatars) { replicate(av1, av2); } }
    А сначала формируем тело сообщение, а потом сформированный набор байт рассылаем всем агентам в списке. Тоже, экономия процессорной мощности.
    Ну и само собой, сервера локаций тоже могут хостится на разных железных серверах.
    Вот Вам и бесшовный мир, и зависимость, которая хоть и немного выше линейной, но точно не квадратичная. По край не мере позволит собрать на одной карте множество игроков.
    — Подвожу краткий итог предложения:
    — Рассылку сообщений игрокам можно распараллелить и поручить другим серверам, для которых это будет линейной задачей. Конечно в общем задача в этом случае будет квадратичной, но выполнится быстро.
    — Рядом с игроком не должно физически помещаться слишком много персонажей. Это естественным образом уменьшит квадратичную сложность задачи.
  • Экономическая симуляция как игра для программистов
    0
    Думал как-то тоже делать экономическую игру, но пока мне кажется это очень сложно. Для моей идеи нужно привлечь к разработке юристов и бизнесменов. Может Вам пригодятся эти идеи:
    Я хотел бы сделать симуляцию жизни обычного гражданина. Использовать реальные законы, принятые в РФ. Должна быть возможность использовать незапрещенные схемы оптимизации налогообложения.
    Среди прочих потребностей игроков была бы такая потребность как «понты». При этом в таблице игроков в топе были бы именно те, у кого выше эти «понты». У игроков был бы выбор, купить сейчас дорогую тачку и повысить уровень своих «понтов», или вложить деньги в активы, чтобы потом за прибыль купить «понты» попозже. В то же время наличие дорогой машины хоть и держали бы «понты» на уровне, вело бы к повышенной финансовой нагрузке, и может и бонкротству. И игроки, поддавшись желанию славы, также бы как и в реальности, часто совершали бы ошибки.
    В игре было бы несколько типов дохода: портфельный, пассивный, активный.
    Игровой персонаж обладал бы ресурсом: временем, и думал, куда бы его инвестировать. На поиск возможностей, на активную работу, на повышение своих навыков.
    Бизнес строился бы из нескольких составляющих: схема бизнеса, кадры, капитал, навыки. Схема бизнеса – это что-то типа франчайзинга. Схему персонаж мог бы разработать сам, инвестировав время, деньги на специалистов и навыки, а мог бы купить готовую.
    Кроме непосредственно главного персонажа, игрок мог бы набирать свиту из специалистов. Эти специалисты дополняли бы навыки главного персонажа.
    Один игрок может владеть несколькими компаниями, причем в некоторых иметь только определенную долю, совместно с другими игроками. Компании могут выходить на биржу и выпускать свои акции в общий доступ (что стоит денег), а могут торговать ими локально, делая специальные предложения некоторым инвесторам.
    Также игроки могут формировать временные команды с общими навыками, для решения определенной задачи, например, улучшения схемы бизнеса. Следовательно, кто-то мог бы зарабатывать как специалист, сдавая своего персонажа в аренду.
    Игра была бы полезна для изучения законодательства и для людей, которые хотят открыть свой бизнес.
  • Физический движок для железнодорожного транспорта
    0
    Движок разработан для тренажеров оперативного персонала сортировочных горок, предполагается использовать его и для имитационных систем, и для виртуальной грузовой станции. На грузовой станции тоже есть операции, для которых важно взаимодействие между вагонами, например: расформирование толчком. Локомотив толкает отцеп перед собой, часть вагонов в отцепе расцеплены. Потом локомотив тормозит, а отцепленные вагоны едут вперед на нужный путь, их там ловят башмаками.
  • Физический движок для железнодорожного транспорта
    +6
    В движке учтен люфт автосцепки, из-за чего есть следующий эффект:
    Когда автосцепка в составе сжата, а локомотив начинает тащить вагоны, то вагоны начинают двигаться не одновременно, а последовательно, по мере натяжения автосцепки.
    Если я правильно понял, это то, о чем вы говорите.
    Тем не менее, звук в движке я не делал, для моей задачи это было не нужно. Думаю, там много нюансов.