UnityRTSФорум

Система строительства

Страницы: 1 2 Следующая »
#0
20:33, 6 июня 2024

Пока нет времени сильно расписывать, поэтому пока тезисно, остальное можно посмотреть в видео.

Разработка игры HardLanding временно приостанавливается на неопределенный срок. Это плохая новость. Но уже некоторое время я работал над зарождением некой игры в жанре RTS. В этом ролике показывается, что от экспериментов с кубиками переходим к полноценной сцене, с многообразием оружия и анимациями персонажа. И после того, как это сделано в эту новую игру нужно также добавлять и размещать там предметы, т.е. аля строить. А значит нам нужна система строительства, которая на хорошем уровне уже была разработана в рамках игры HardLanding. Но вот не задача, в течении пары лет разработки код и требующиеся для этого ресурсы разбросаны по всему проекту, и нужно создать архитектуру, чтобы все это можно было собрать и перенести в другую игру. В ролике делается рассмотрение на  сверх высоком уровне, даже не с полета птицы, а из космоса. Но это необходимо, чтобы за деревьями/деталями не потерять суть.

Запустить видео по клику - Как делать игрыЗапустить видео по клику - Как делать игры

#1
16:47, 7 июня 2024

tac, Ведущий программист, архитектор

Lockstep ведущий программист и архитектур завести в архитектуру RTS не додумался, как и изолировать игровую логику от конкретного движка.

#2
(Правка: 18:34) 18:30, 7 июня 2024

Storm54
Чего именно я не додумался я не понял.

> изолировать игровую логику от конкретного движка
а это какая та глупость, изолировать логику от движка не возможно. Те кто это делают превращаются в движкописателей. Это аналогично тому, что писать код на языке программирования изолируя это от синтаксиса C#. Маразм? Вот и я говорю маразм. Не советуйте людям заниматься глупостями, а если не знаете, то спросите.

#3
23:06, 7 июня 2024

tac
> Чего именно я не додумался я не понял.
Как будете добавлять мультиплеер без локстепа?
Необходим полный детерменизм, чтобы расчет игровой логики можно было вести на каждом клиенте отдельно, а между ними синхронизировать лишь управляющие команды.

tac
> а это какая та глупость, изолировать логику от движка не возможно
Интерфейсы придумали не вчера. И в целом, хорошим тоном является изоляция конкретной реализации. К движку это также относится.
Конкретно по RTS: если добиваться детерминизма, то придется отказаться от использования вещественных чисел, придется отказаться от юнити типов, которые с вещественными числами работают (естественно, использовать их можно только для визуализации).
В некоторых случаях в RTS требуется быстрая промотка состояния мира (например, если механизм сохранения/загрузки реализуется через простую запись команд, а не через сохранение параметров мира). Это требует отказаться от явного использования юнити типов, чтобы не требовалось те же самые GameObject создавать/удалять при быстрой промотке игрового состояния.

К чему я это все: Если делать игру тяп-ляп, то все эти усложнения не нужны: можно забить на мультиплеер, забить на корректные сохранения/загрузки. Но, если требуются все основные фичи RTS: Мультиплеер, сохранение/загрузка, реплеи, легковесный авторитарный сервер (например, чтобы выдавать игрокам награду за результаты боев), то лучше сразу учитывать, как это все будет реализовываться.

#4
(Правка: 3:50) 3:27, 8 июня 2024

Давайте вначале уточним вашу терминалогию

Storm54
> без локстепа
что это такое?

Storm54
> Необходим полный детерменизм
> если добиваться детерминизма
необходимость в этом не понятна. Что именно под этим понимается?

Storm54
> придется отказаться от использования вещественных чисел
чего вдруг?

Storm54
> придется отказаться от юнити типов
еще какая то глупость

Storm54
> если механизм сохранения/загрузки реализуется через простую запись команд, а не через сохранение параметров мира
сохранение через "запись команд" выглядит очень странно, для чего так делать совершенно не понятно

Storm54
> при быстрой промотке игрового состояния
о какой быстрой промотке и зачем она вообще нужна, тоже не ясно

Storm54
> все основные фичи RTS: Мультиплеер, сохранение/загрузка, реплеи, легковесный авторитарный сервер
Видео вообще не про мультиплеер или сохранение, вы его вообще смотрели? Видео скорее про то, как делать, чтобы одни системы не влияли на другие. Вы же наоборот, пренебрегаете этим, и думаете что решения в системах сохранения или мултиплеера, должны ХОТЬ КАК ТО влиять на другое. НЕТ. Вообще не должны. Это очень и очень плохо, когда такие добавочные вещи как мултиплеер или сохранения накладываю хоть какие то требования не остальную игру, клиент в целом. В целом ваши рассуждения сомнительны. И это очень плохая архитектура мультиплеера и сохранений. Поэтому нет, Вы полностью не правы.

Storm54
> в целом, хорошим тоном является изоляция конкретной реализации.
это общие слова, которые к практике не имею ни какого отношения. Как раз наоборот, делать все через интерфейсы - это плохо. Вы могли заметить из видео как МАЛО интерфейсов в системе вообще должно быть. Они нужны очень редко, а когда их делают на каждый чих - это свидетельствует о неопытности.

Storm54
> легковесный авторитарный сервер
это конечно отдельный вопрос, но да я встречался с людьми, которые вообще не задумываются, что ценность этого очень низкая, и вообще выражение "легковесный авторитарный" является оксиюмороном, противоположным по смыслу вещами. Авторитарный предпологает, что движение юнитов будут рассчитывать на сервере? Так? Т.е. вы предлагаете выкинуть использование NavMesh от юнити, а делать свое движение. А затем вы будет как то проверять коллизии. Поздравляю, как и ожидалось вы встали на путь вечного движкописателя.

#5
18:54, 9 июня 2024

tac
> Необходим полный детерменизм
> > если добиваться детерминизма
> необходимость в этом не понятна. Что именно под этим понимается?
tac
> > придется отказаться от использования вещественных чисел
> чего вдруг?

Загуглите хотя бы, как создавались классические RTS. Серии Command & Conguer, Starcraft, Warcraft.
Как Вы начали создавать свою RTS, да еще и с замахом на обучающие видео, если даже не изучили это?)

tac
> Это очень и очень плохо, когда такие добавочные вещи как мултиплеер или сохранения накладываю хоть какие то требования не остальную игру, клиент в целом
Ок, допустим я не прав. Распишите, как сделаете мультиплеер в RTS с синхронизацией тысяч юнитов. Особенно, если по вашей логике он добавляется сугубо сбоку и не влияет на остальную игру.

#6
(Правка: 10 июня 2024, 1:58) 22:26, 9 июня 2024

Storm54
> как создавались классические RTS
Вы или давайте конкретные ссылки, которые по вашему мнению имеет смысл рассматривать, или не советуйте смотреть того чего нет.


Storm54
> Распишите, как сделаете мультиплеер в RTS с синхронизацией тысяч юнитов.
Это давно пройденный этап, и не представляет особого интереса сейчас. Вот вам ссылка, на старые дискуссии. Толстый/тонкий сервер. Синхронизация состояние мира. Какие минусы видите в такой реализации?

Кстати, в известной мере, написанное там устарело ,сейчас я бы делал по другому. Но в любом случае, это будет толстый клиент. Но сеть это на столько вторичное, что можно даже не думать об этом сейчас.

#7
4:39, 11 июня 2024

Storm54
> И в целом, хорошим тоном является изоляция конкретной реализации. К движку это также относится.
Есть один случай из ста, когда это нужно. Сможете назвать какой? Или будете и класс Vector3 изолировать, создавая своего близнеца?

#8
10:03, 11 июня 2024

tac
> Но в любом случае, это будет толстый клиент
То, что описано по ссылке - просто не работает, т.к. не описан механизм коррекции. Можно, конечно, передавать команды с клиента, вот только со временем будет увеличиваться погрешность между сервером и клиентом и понадобится механизм для корректирования состояния объектов. В играх с относительно небольшим количеством объектов, эта коррекция присылается сервером, а вот как Вы собрались присылать коррекцию на тысячи юнитов - вопрос. Чтобы избежать отправки коррекции, необходим полный детерменизм при обсчете игровой логики, это позволит добиться полностью одинакового поведения на клиенте (клиентах) и сервере.

tac
> Есть один случай из ста, когда это нужно. Сможете назвать какой? Или будете и класс Vector3 изолировать, создавая своего близнеца?
Как минимум случай, когда необходимо отказаться от вещественных чисел для создания детерминированной игровой логики (читайте абзац выше).
Также случай, когда нет желания тащить юнити (или UnityEngine.dll в частности) на сервер.

tac
> Вы или давайте конкретные ссылки, которые по вашему мнению имеет смысл рассматривать, или не советуйте смотреть того чего нет.
Самое наглядное из того, что смог найти за пару минут:
https://www.gamedeveloper.com/programming/minimizing-the-pain-of-… p-multiplayer

#9
(Правка: 11:25) 10:28, 11 июня 2024

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


По поводу статьи

1. По поводу чудного термина, гугл мне перевел, лучше чем вы - use lockstep multiplayer = используется многопользовательский режим с фиксированным шагом [синхронизации]

  • думаю это очень специфичный подход
  • 2. Они не используют Юнити, поэтому у них свои личные проблемы. У них время обсчета юнитов зависит от рендеринга, чего в Юнити нет изначально. Им же пришлось делать то, что они упомянули в Fixed Timestep Updates

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

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

    > Можно, конечно, передавать команды с клиента, вот только со временем будет увеличиваться погрешность между сервером и клиентом и понадобится механизм для корректирования состояния объектов.

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

    > Также случай, когда нет желания тащить юнити (или UnityEngine.dll в частности) на сервер.
    Если игра требует на сервере выполнять какие то расчеты, как например, расчеты NPC для всех игроков. То, конечно, их нужно реализовать как отдельных клиентов, освободив от этого сервер, тем самым только на клиенте будут сборки Юнити с UnityEngine.dll и прочим. Да они могут быть без рендеринга, но это опция запуска клиента. При этом, на сервере не понадобится ни какая гейм-логика, и он сможет заниматься исключительно синхронизацией и сохранением. Поэтому нет, когда возникает такое мнение "нет желания тащить" - оно вызвано плохой архитектурой.

    #10
    21:52, 11 июня 2024

    tac
    > Ну пока я вижу человека, который сам не разобрался как сделать сервер
    Понял. Несколько тысяч CCU на моем проекте как-то крутятся, наверно из интернета "сервер" скачал...

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

    Ага, про читеров только не подумали.

    tac
    > думаю это очень специфичный подход

    Очень специфичный... Большинство топовых RTS его используют...

    Итого по ответам:
    Либо Вы - тролль, либо уже очень старый и, к сожалению, уже не способны эффективно усваивать новую информацию.

    #11
    (Правка: 23:15) 23:09, 11 июня 2024

    Storm54
    > Несколько тысяч CCU на моем проекте как-то крутятся
    дали бы ссылку, если не бла-бла

    Storm54
    > Ага, про читеров только не подумали.
    что о них думать, пару проверок на синхронизации и их нет

    Storm54
    > Большинство топовых RTS его используют...
    бла-бла ...

    Storm54
    > эффективно усваивать новую информацию
    заниматься вторичными вопросами, как то сетью или сохранениями, а не делать игру - вот это и есть отвлечение внимания. А затачивать под вторичные вопросы архитектуру игры - еще один видимо новый нонсенс.

    #12
    7:18, 12 июня 2024

    tac
    > дали бы ссылку, если не бла-бла
    https://bannerlord-online.com/
    В ютюбе видосов полно.

    tac
    > бла-бла ...
    Продолжай врать себе, реальности вокруг не существует.

    #13
    13:03, 12 июня 2024

    Storm54
    > https://bannerlord-online.com/
    Какое Вы имеете к этому отношение?

    Я вижу, что там разработчик  TaleWorlds Entertainment.

    #14
    (Правка: 22:19) 21:17, 13 июня 2024

    tac
    > Какое Вы имеете к этому отношение?
    Есть одиночная игра, а есть MMO мод, основанный на этой игре.

    Страницы: 1 2 Следующая »
    UnityRTSФорум