Pull to refresh
13
0
Send message
Не прошел ни первый ни второй Portal, хотя обе понравились, просто внимание переключилось на другую игру, а возвращаться к играм я не люблю.

Не видел движков, у которых этой проблемы проблемы в том или ином виде нет. Вот в Unreal вообще все ассеты бинарные и если конфликтуют то делай что хочешь.

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

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

Оно её и предоставляет в объемах описанных в законах. и, объективно, у нас далеко не самая плохая и недоступная медицина в мировых масштабах.


Получить помощь даже описанную в законах часто не представляется возможным или требует преодоления таких бюрократический преград, что это становится просто невозможным для заболевший, как пример, можно вспомнить новости про отсутствующий бесплатный инсулин.
Что уж говорить о том что по политическим (и, я уверен, коррупционным) западные работающие лекарства в планах лечения были заменены на импортозамещенные, неработающие.
А то что есть страны где хуже? Я не для того плачу налогов почти как в Германии, чтобы сравнивать результаты работы с Зимбабве.
У вас нездоровое представление, что государство существует само по себе и для какой-то собственной цели, а не как инструмент для существования общества.

Если государство обещает бесплатную медицину, а тем более берет за это дополнительные деньги (помним, что в ОМС работодатель перечисляет деньги в процентах от зп работника) то пусть будет добро её предоставлять и не прикрываться «трактовками», если оно не способно это делать то пусть перестанет брать за это деньги.

Собственно это и происходит в странах с более эффективным управлением.Нашему же только граждане постоянно что-то должны.

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


Траффика меньше, потому что вводов меньше, чем данных о мире, которые бы пришлось рассылать всем игрокам.

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

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

Для клиент-серверной архитектуры сервер не обязательно должен находиться у амазона и вообще у конторы разработчика.

Говорили же про старкрафт, там сервера у разработчика стоят.

Я не зря написал про peer-to-peer lockstep — соль тут именно в том, что для избавления от мапхака у нас просто не должно быть p2p обмена данными.

Так в современных стратегиях p2p трафика обычно и нет, все же за NATом сидят. Сервер просто рассылает клиентам вводы других игроков.

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

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

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

Сейчас в основном используют локстеп с центральным авторитетом, а основное преимущество технологии — минимизация траффика — как был так и остается необходимым для игр с большим количеством юнитов.

Возможны максимально неполные данные вида «событие в точке X,Y». Да, на основании этого можно сделать мапхак, но далеко не такой интересный, как «вижу всё, что делает противник».


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

Если есть из чего посчитать — то данные есть у клиента, мапхаки возможны, если считать на сервере то неизбежны задержки (пойди посчитай всё какой поднабор инпутов север должен отправить каждому клиенту).

Сложно? Конечно это сложно. Но далеко не невозможно.


В общем случае (случайной сложности геймдизайн) невозможно.

Даже если предположить возможность это всё ещё чрезвычайное повышение сложности, а значит источник багов, а так как это сетевая синхронизация, то багов особо веселых для воспроизведения. Так же это убивает одно из преимуществ локстепа, что код симуляции можно писать не зная о том что игра сетевая. В реальном мире уже этого всего достаточно, чтобы сказать «Пожалуй, мы поборемся с мепхаками по-другому».
Решение, которое вы описываете это адский ад, как с точки зрения программирования так и гейм-дизайна. В общем случае нельзя сказать, не посчитав, влияет ли некое действие в тумане войны на состояние вне тумана войны, в результате такой подход частичной синхронизации приведет к тяжеловоспроизводимым случайным рассинхронизациям. Не говоря у ж о том что синхронизировать 10 минут игры в один кадр, когда твой зилот первый раз пришел на базу противника гарантированно приведет к просчету в пару секунд. Если бы всё было так просто это бы уже давно все сделали.
А где технические подробности?
Делаете свой движок — молодцы, честь и хвала, но если рассказываете об этом то почему без деталей?
Например, демовидео, оно на каких устройствах запускалось? Графика не вызывает особого восторга, хоть и симпатична, юнити вполне способна такое показать на устройствах уровня iphone 6s.
Если сравнивать с Unreal, то он кроме рендера он ещё и предлагает хорошо показавшую себя в шутерах сетевую часть, какая у вас сетевая модель? Какие целевые пинги?
Насчет выстрелов себе в ногу, посмотрите на код из примеров юнити:

Unity.Physics.Collider* capsuleColliderForQueries;
{
    Unity.Physics.Collider* colliderPtr = collider.ColliderPtr;

                    // Only capsule controller is supported
    Assert.IsTrue(colliderPtr->Type == ColliderType.Capsule);

    byte* copiedColliderMemory = stackalloc byte[colliderPtr->MemorySize];
    capsuleColliderForQueries = (Unity.Physics.Collider*)(copiedColliderMemory);
    UnsafeUtility.MemCpy(capsuleColliderForQueries, colliderPtr, colliderPtr->MemorySize);
   capsuleColliderForQueries->Filter = CollisionFilter.Default;
}


Сильно это отличается от стрельбы себе в ногу в с++?
Мне примеры не кажутся страшными — там вроде даже указатели не используются.
То, что это C# позволит шарить между скриптинговой средой и высокопроизводительными джобами юзерский ECS код. И все не-гцшные фичи языка можно свободно использовать.


А вы пробовали? Обычно хватает небольшого тестового проекта, чтобы осознать, что писать так как предлагается это страдание.
Не в этом случае, нет, в HPC# парадигме написать так чтобы тормозило из-за языка сложно и ограничений на то что и как ты пишешь достаточно, чтобы написать специальный компилятор со специфичными оптимизациями, компилятор общего назначения С++ не всегда сможет так соптимайзить.
в с++ за счет шаблонов, не спрятанных от разработчика указателей и ссылок, можно построить более удобный фреймворк, и даже памятью управлять не придется ведь по условию задачи мы не используем динамическую память.
Свалят, но они и от HPC# свалят, писать в Unity ECS очень трудоемко и неудобно, дебажить ECS очень сложно и так далее и тому подобное. Эта тема взлетит только среди профессиональных разработчиков с большим бюджетом именно на разработку.

Говорю это имея опыт написания на Unity ECS тестовых игр и некоторый опыт профессиональной разработки с другими ECS

Information

Rating
Does not participate
Registered
Activity