WS SAWER
Есть вполне очевидные и ряд не очевидных факторов, которые резко повышают шансы оказаться где-то там, где ты не должен быть. Это совсем не нормально, что выполняя обычную коммерческую или передовую деятельность, в т.ч. в обеспечении безопасности родины, оказываешься в жопе, а то и хуже.
С чего бы должно быть легче? Ну если тебя такое же положение выживание устраивает и ты привык, то да, будет полегче. А если сейчас стало получше, то то, что умеешь выживать, не говорит о том, что сумеешь выжить в новой ситуации. И самое главное, что снова захочешь выживать. Обманываться не стоит. В РФ могут быть периоды затишься, везения, но жизнь перемалывает активных, чем ни занимайся и на какой стороне не находись.
Люди с золотыми руками и не мнее умной головой всегда зарабатывали минимум не плохо) Но раньше больше и рисков было меньше.
И риски - это не просто какая-то вещь, что не коснётся. Есть примеры, с самой разным подходом, где в результате теряли в лучшем случае дело и деньги, а в худшем жизнь, да и последние деньки той жизни могли быть адом. И если ты где-то рядом с такими умными и работящими людьми крутишься лет 10, то наверняка из знакомых, с которыми мог работать такие будут.
RT будущее по той простой причине, что сделать графику для игр лучше просто крайне дорого. Это отдельный дизайнер который со старта проекта занимается графикой в целом и светом в основном, всё время разработки игры. Для сравнения, просто сделать сцены для большинства небольших игр - совсем не значительная часть разработки, которую можно и на аутсорс отдать. А качество добавляет минимум 1 не дешёвого спеца, да таких ещё и найти не просто. Местами ещё и программистов надо привлекать. Многие игры же просто не тянут по бюджету хорошую графику. А RT - это расставить свет по сцене, мб ещё прикрутить общее базовое освещение, и готово. Даже не спец поиграясь справится с простой графикой и она будет как минимум весьма не плохой, а для спеца это экономия времени в разы.
Движок - средство запуска и вывода информации об игре. Ещё могут быть проблемы с графикой у движка, и то тут от рук зависит сильнее, ну или совместимостью с железом и системой, сопроцессором и т.п., но никак не с логикой самой игры - это задача самих разрабов игры, а не движка.
Она очень затратная по месту, что тоже не хорошо) ну и другие минусы, вроде возможной блокировки и энергозатрат, нужно балансировать. На бобмоде такое уже и вовсе огромные площади требует.
А вот главная шина довольно простая для новичков и быстрого размещения. А потом для продвинутого уровня можно шину сделать с автоматизацией ввода-вывода, лишив основных минусов(неравномерной загрузки), а затем ещё и заводов, что сильно уменьшит проблему прощадей. Но всё равно с очень большим количеством ресов скорость начнёт крайне быстро деградировать.
Тогда можно прямое подключение сделать, без дополнительных логистических блоков, так будет самая высокая эффективность по площади. Но её уже нельзя перенастроить.
А потом сделать Большие блоки, не обязательно рядом, но внутри которых прямое подключение для расходки и основных узлов, которые попадут в блоки с шинами, а те уже произведут недостающие товары для логистической сети, или что-то новое. + 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)
Рядом с жилыми домами нецелесообразно тушить?) По их словам именно так - сгорела куча населённых пунктов
Ну, например, чтобы шанс был меньше? Прям сильно парится смысла нет. Но и покрасить стёкла очков в розовый - хреновый выход