WS SAWER
Движок - средство запуска и вывода информации об игре. Ещё могут быть проблемы с графикой у движка, и то тут от рук зависит сильнее, ну или совместимостью с железом и системой, сопроцессором и т.п., но никак не с логикой самой игры - это задача самих разрабов игры, а не движка.
Она очень затратная по месту, что тоже не хорошо) ну и другие минусы, вроде возможной блокировки и энергозатрат, нужно балансировать. На бобмоде такое уже и вовсе огромные площади требует.
А вот главная шина довольно простая для новичков и быстрого размещения. А потом для продвинутого уровня можно шину сделать с автоматизацией ввода-вывода, лишив основных минусов(неравномерной загрузки), а затем ещё и заводов, что сильно уменьшит проблему прощадей. Но всё равно с очень большим количеством ресов скорость начнёт крайне быстро деградировать.
Тогда можно прямое подключение сделать, без дополнительных логистических блоков, так будет самая высокая эффективность по площади. Но её уже нельзя перенастроить.
А потом сделать Большие блоки, не обязательно рядом, но внутри которых прямое подключение для расходки и основных узлов, которые попадут в блоки с шинами, а те уже произведут недостающие товары для логистической сети, или что-то новое. + 1 блок управления всем этим добром и блок станций.
Это производство 50-60к кубов в минуту было или как?
Хорошая не может отталкивать... Хорошая не значит 100500 треугольников и огромные текстуры. Есть разные стили. И любой можно запороть
Есть новые игры такого плана с хорошей графикой и т.п. Ну и, конечно, я не помню названий...
ECS для извращенцев) А Jobs для велосипедистов)
Для довольно узкой задачи подойдёт, но в большинстве случаев оно не надо. Тесты как всегда... Как часто один пустой объект выполняет то же самое хотя бы 100 раз? Как часто в сцене бывает хотя бы тысяча объектов с нестандартным кодом(скриптов)? Я видел такое крайне редко даже на больших сценах.
А джобы - аналог тасков, но с кучей ограничений. Забавно было, как-то видел как они по производительности проигрывали чистым C# Task на одинаковой задаче и при, по сути, одинаковом коде. Конечно, сейчас могли и допилить, но это всё равно велосипед с ограниченным функционалом.
В обоих случаях надо много бойлерплейта, забить на кодстайл и хорошие практики, писать не для лучшей читаемости, а для того, чтобы данные скормить было удобно. Вот и страдает отладка, что через нехорошее место сделано. А с учётом того, что написать то обычно не проблема как угодно, что угодно, а вот баги править сложно и долго, то выходит как-то невесело.
PS: Сам ECS то норм... к реализации всегда вопросы. Даже к стандартным монобехам то вопросов не мало.
Я писал игры с большим кол-вом юнитов, писал программы в DO, ещё до того как это "переоткрыли" в Unity. В том числе применял это как отдельные алгоритмы. И тоже считаю, что DOTS и в целом DO для написания игр подходит плохо. А угробить кучу человеко-лет на такую хрень по итогу было главным провалом Unity всех последних лет. А такие видео со своим велосипедом это только подтверждают - каждый пилит своё, потому как получается не особо то жизнеспособный продукт.
Большая производительность - да, это есть. А вот гибкость то откуда? Выходит ровно наоборот, пользование DOTS сильно режет возможное использование языка и в целом фич юнити.
Но то ладно. По существу то ответишь? Мне вот интересно было бы узнать что-то, может что не знаю. Но ты только повторяешь то же самое, апеллируя не к проблеме, а к автору коммента выше.
В том, что сказал уверен. Думаешь иначе - аргументируй
Похоже на сабпиксельное(канал). Так же, как понял, иногда этим отображают глубину цвета(какой-то теоретический показатель)
Но я бы просто так не верил, с матрицей производители мутят, легко могут дать по синему каналу и 16 бит, с обычной 24 битной матрицей, просто потому, что там синих пикселей больше). Или те же 16 +8+8 =32/3 канала и вот тебе 10. Им не привыкать)
И вот что ещё - по цифре передаётся только 8 бит на канал) Как с этим работает видеокарта? В той же HDR картинке вся обработка до вывода на экран идёт на карте, на выходе опять же будет 32. Чтобы реально увидеть больше бит на канал нужно и ПО соответствующее, и канал передачи, и моник. ХЗ, есть, конечно, вероятность, что всё это уже работает. Но я таких шейдеров то никогда даже не видел)
Ну и ещё, FRC нормально будет работать только на высоком рейте, да ещё частоту срежет. Но и это странное, пиксели и так мерцают. Походу это для адептов высокочастотных мониторов с понижением частоты в N^2 раз за N бит)
В общем, очередной маркетинг.
Я всё ещё хз о каком вы показателе. Конкретика нужна. Вот пример https://en.wikipedia.org/wiki/Color_depth
24-bit - truecolor. В отображении больше делать смысла нет - человек не отличает. Вот при фотографировании или отображении с особой обработкой разница есть - там deep color(> 24)
Что за 10 бит - хз. Похоже хуйня какая-то маркетинговая.
PS: вообще отображение по мощности условно аналоговое, так что большинство матриц может отображать на много больше цветов, но в разных кадрах
PPS: сейчас почти все мониторы truecolor. Т.е. этот показатель у всех 24+
Так битность пикселя состоит из суммы битности сабпикселей так то
Глубина цвета у монитора всегда отображала кол-во цветов на пиксель. И сейчас норма в 24 бита - обычное дело. То же для картинок(32 с альфой).
Битность матрицы вообще не понятно что за зверь.Может битность физического пикселя? Но это вообще тупо без указания типа матрицы, потому как там многое зависит от физического показателя. А когда дело доходит до матрицы и её показателей, всё становится очень похоже на нм у процессоров - все производители врут и ставят свои стандарты.
Я нескольких таких команд знаю. Брали юньку, думали будет проще и быстрее. Через пару лет поняли, что не получилось. Перешли на анрил. Через пол года-год опять поняли. Стали писать свой. Всё пишут, кто не закрылся.
Если не дураки, то остановятся на том, что есть.
Выбор движка - больше проблема менеджмента. На любом можно сделать конфетку, но любым инструментом надо уметь пользоваться. Движки уже очень сложные становятся, а консультантами студии пользоваться не умеют, не нанимают. Вместе с тем многие даже весьма хорошие спецы не умеют работать в других парадигмах. И так выходит, что команда плюсников встречая шарп начинает из него лепить плюсы, а похожесть в базе и высокая вариативность это дело очень упрощают. Так и по движку - пытаются сделать как уже умеют - квадратное катят, круглое тащат. А подготовка террейна для обкатки квадратных штук весьма затратное дело.
Игры разные. ГК - это даже не такой уж и большой % игровой разработки
Запуск анимаций скорее в VM)
Весь рендер, включая UI элементы, рендер моделей и т.д. По мне так, это всё то, что непосредственно занимается выводом на экран. Но и как более сложная вещь, т.е. может быть просто выводом картинки, а может быть выводом счётчика с анимацией.
Управление этим всем - VM, непосредственно(т.е. прямые ссылки на все компоненты V есть в VM).
Запуск анимаций точно влияет на ход игры? Скорее всего в таком случае надо делить анимацию и действие. Банальный пример - в UI начисление денег можно произвести(VM) после анимации полёта ресурса(V) в каунтер(V). Но начислить деньги в M по ответу сервера. Так же легко реализовать prediction, никак не меняя логику M. Примерно так же с анимацией. При реализации анимации, которая влияет на физику игры, к примеру в игре с катящимся шаром, анимация попадает в M. Но не вывод графики, в т.ч. эффекты, прочее управление ими. Иногда для этого выстраиваю параллельную анимацию для графики.
Если игра содержит много GUI, либо сильно отличный от базового рендер, либо который требует сложного управления, то лучше с MVVM) Промежуточные варианты для проектов попроще - MVC/MVP. Для любого проекта не на пару выходных стоит отделять M от всего остального.
В чём выражалась поддержка именно IT?
Я примерно то же самое слышал про офигенные игры детства от российских разрабов, т.е. "это клон SC(Diablo), только от русских и дерьмовый". Потом про паззлы и HOPA. Где-то там ещё был idle... А так же про 9 из 10 стартапов.
Все ММО так же дерьмо? Больше 9 из 10 - то же самое дерьмо, что и самые донатные мобилки, только обёртка другая.
Примеры есть и в интернете. По ним даже проще - не будет лишнего кода и мусора)
А вот если будут вопросы по конкретной реализации - обращайся.
Вот про чистоту и красоту ничего подобного. С DOP удобнее работать с конвеерной обраткой данных. И всё. Строить на нём сложные программы весьма напряжно. Любой UI среднего игрового магазина без надстройки в виде правил сверху превращается в кашу, где часто проще писать код под конкретное действие, чем разобраться как оно правильно, либо писать так, что будет понижаться производительность даже в сравнении с классикой из-за доп.расходов на пустое оперирование очередями.
Да уж) В командах без практики и хорошего понимания структуры вообще нельзя давать разработчикам работать с контейнерами.
Нельзя просто взять и в лоб сделать правильно, по наитию, как бывает с другими вещами. Контейнеры в принципе требуют предварительного проектирования, которое с новым инструментом отходит куда-то на задний план и всё сводится к "достать нужный объект - уже победа")
Это в моменты инициализации имеется ввиду?
"Достаточно легкая отладка по веткам триад, нежели через контейнеры;"
А что не так с контейнерами и отладкой?
Привожу проекты к виду примерно MVVM, максимально сохраняю компонентную систему. Можно делать с DI, можно без. Тут скорее зависит от способности команды полноценно использовать DI - для Unity проектов это не столь важно как в вебе. Zenject не советую использовать без опыта, требуется много времени на изучение, очень легко скатиться к лапше, божественным структурам, и вообще собрать все грабли. Поглядывал на другие вещи, что попроще, но уже забыл названия)
View - компоненты отображения, коим может быть и стандартный Image и какая-нить панелька с ресурсами. Иерархия с другими View(может содеражать в себе), но у каждого объекта только одна связь с VM. Отображение данных полученных от VM без изменения. Ограничивать можно через интерфейс.
VM - это модель UI, по сути тот же Presenter и управление логикой как в Model, но по отношению к UI. К примеру, это окна, попапы, ну или целый UI магазина. Иерархичен по отношению к другим VM, взаимодействует с другими частями, вызывает методы в Model, но не имеет доступа к его данным(только управление). Передаёт данные в View, получает. Иногда напрямую, иногда как посредник передаёт данные во View. Здесь так же разделение между данными в Model и передаваемыми во View - для Prediction, уборки сетевой задержки и т.п.
Model - логика игры. Тут важно - не стоит пытаться делать все объекты не MonoBehaviour. Если объект на сцене - часть непосредственной логики игры, в т.ч. физики, то так и должно быть. Если надо ту же логику повторить на сервере - тащите как есть и делайте свою реализацию MB на сервере, либо делите через partial(лучше), ну или наследованием и контенерами данных(хуже). Это так же позволяет использовать Photon и другую логику непосредственно игрового процесса на сервере(т.е. с апдейтами или их имитацией).
Так ещё несколько отличительных, часто:
1) нужен Update - это или View или VM.
2) нужен FixedUpdate - Model.
3) Model в любой реализации должен компилится без View и VM. В идеале, Model в новых версиях отделять в отдельную сборку(-и).
Касательно загрузки. Управление загрузкой осуществляется из M и VM. Тут только иногда требуются какие-то общее ожидание загрузки и для M, и для VM, делая эту загрузку независимо друг от друга(для Model обычно ожидания ответа от сервера логики, а для VM сканиявание и загрузка ассетов). C использованием Task это наконец-то получается организовать правильно и легко читаемо, без костылей типа сервис-локатора, синглтонов и т.п..
Очень странная схема. Почему в Model идёт ViewData? В MVP данные Model не должны модифицироваться извне. Данные Model должны отображаться(передаваться в P, использоваться в V), но не должны модифицироваться извне(напрямую). Ну и иерархии тут нет - это одноуровневая реализация схемы.
По тексту выходит что-то вроде контейнеров с древовидным доступом. Почти как DI контейнеры(контексты), но без DI. Получается что-то вроде частичной реализации DI. Но это не HMVP, может даже не MVP(т.к. где тут model не ясно). Надеюсь, не Context)
Рядом с жилыми домами нецелесообразно тушить?) По их словам именно так - сгорела куча населённых пунктов
В их тесном мирке есть кто-то, кто лучше бы разбирался?
Разве я говорил что ты отрицал?)
PS: не стоит строить переводить в демагогию
У конкретно этого произведения существовал перевод вполне хороший(гуглтранс и рядом не стоял). Может и не профессиональный(хотя порой и профи попадаются ужасные), но весьма живой, хотя сравнить с оригиналом не могу. Да, и на сколько помню, был с оригинала. Только место где я читал удалили, да и вообще он пропал. Последние главы не ясно где читать.
Вообще, прямой смысловой перевод с китайского или японского несколько сложен из-за самой специфики рассказа. Получается текст, который очень уж изобилует безсмысленными словами, т.к. воспринимается как сильно мусорный. Видать какие-то то ли культурные, то ли исторически сложившиеся вещи, которые толком и не значат ни чего для русской культуры.
В аниме неплохо переданы некоторые детали, иногда, буквально в несколько кадров, ну и самотерзания ГГ несколько порезали, что пошло только на пользу.
Вообще, удивляюсь на сколько качественно порой стали делать аниме по другим источникам.
Это уже не коррупция, если это законно. Это один из способов решения разногласий. Здесь есть смысл говорить о капитализме и социализме, но не о коррупции