Цена ошибки

Почему в разных сферах разные процессы разработки, разные принципы работы и так далее? Дело в разных целях и в разной цене ошибки. Допустим возьмём для примера корпорации. У них цена ошибки заоблачная. Если DoDo лежит четыре часа (как было недавно) — это большие потери в деньгах. Поэтому процессы в корпорациях дорогие, медленные, с кучей проверок. Условно классический путь задачи можно описать так.

Фича придумана —> Архитектор вписал её в систему —> её отдали в разработку —> разработка декомпозировала фичу на таски —> под каждую таску делается новая ветка —> есть ветка "релиза фичи" куда льются таски (и проходят ревью и автоматические тексты) —> релиз ветка проверяется тестерами —> релиз ветка проверяется внутренним заказчиком фичи —> релизветка проверяется финальный раз автотестами —> релиз ветка заезжает в мастер

Там конечно есть куча нюансов и по возврату, и в конкретике каждой компании деталей и нюансов. Но +- работает это так. И это очень длинный путь. При этом даже простой фиче нужно пройти этот путь, так как она может положить прод — а это очень дорого.

С другой стороны возьмём аутсорс. Обычно у клиентов нет столько денег (особенно у непрофильных), чтобы оплачивать обслуживание такого процесса (оно требует разработчиков, архитекторов, девопсов, тестеров, продактов и так далее). Но и там чаще всего совершенно другая цена ошибки. Процесс описать можно так:

Проект придуман —> разработка декомпозирует её на таски —> разработка делает таски и выкатывает промежуточные релизы —> релизы идут в тестирование —> заказчик смотрит промежуточные релизные сборки —> собирается финальный релиз —> тестируется тестерами —> смотрится заказчиком и идёт в прод

Тут нет архитектора, тут нет автотестов, тут нет ревью и пулл реквестов, то есть тут нет девопсов. Тестеры тут тоже немного другие. В аутсорсе многие не знают банально, что такое Smoke test, хотя многие и делают то только его. Все процессы упрощены. И цены получаются другие. И всё дело в цене ошибки. Если баг не критический условно сломанный на час проект — это не смертельная проблема. Поэтому цена ошибки другая.

У нас крайне редко на релизе что-то ломалось. Чаще наша цена ошибки "что-то ломается в руках заказчика". И это вполне удовлетворительная цена ошибки. Просто чаще всего очень трудно кому-то объяснить, что дело не в "профессионализме", а в процессах. Можно построить процесс, в котором ошибки будут крайне редкими и баги "пресловутый SLA 99%". Но это просто дорогой процесс, который меняет косты на проект космически.

Тот же TDD подход к разработке. Мне он очень нравится. Перед написанием функционала пишем к нему тест. Но он дорогой, ему нужно обучать людей, особенно как вообще в Unity пишутся тесты, прогоняются, настраивается тест среда. Плюс по хорошему это нужно сразу вплетать в гит с мержем веток, в CI&CD и так далее. Поэтому он просто дороже, чем другие подходы к разработке. Хотя стабильность системы растёт в разы. И так далее.

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

#мысли

DFT самый важный алгоритм?
https://www.youtube.com/watch?v=yYEMxqreA10

Классное видео про DFT. Да и канал классный разбирающий с красивыми визуализациями разные алгоритмы. Кажется что преобразование фурье — это что-то про звук и сигналы. Но всё становится в разы интереснее, когда понимаешь что изображения и вообще любые данные с определённоё точки зрения являются сигналами.

#новости

Разбор визуальных эффектов для Air Shift
https://blog.unity.com/games/designing-a-deeper-space-visual-effects-in-alt-shifts-crying-suns

Забавный разбор VFX игры. Конечно технических деталей маловато, но концептуальное объяснение тоже полезно знать. И между блумом и продюсером, я бы тоже выбрал блум XD

#новости

Быстрый релоад в Unity
https://hotreload.net/

Ещё пока не успел потестить и посмотреть что и как, но выглядит прикольно. Ребята выпустили тулзу для изменения скриптов без рекомпайла.

Есть бесплатная версия, но с любопытным ограничением использования. Два часа в день.

#новости

Лучшие практики мобильного интерфейса. Часть 2
https://blog.unity.com/games/mobile-ui-design-best-practices-part-2

Про первую часть я писал тут. Вторая часть уже немного по глубже и поинтереснее. Плюс мне понравилась концепция Block Element Modifier (BEM) naming convention. Про неё я как-то не слышал, а штука в интерфейсе может быть довольно полезная.

#новости

MVC

Продолжим описывать какие-то термины. Ранее я писал, что такое модель. Она была первой, так как этот термин многие не совсем корректно понимают думая, что модель "это просто данные". Но ещё наверное стоит написать, что такое MVC в целом. И почему он появился.

MVC или model-view-controller — это архитектурный паттерн. Сам по себе термин model-view-controller появился в конце 1970-ых годов при разработке языка SmallTalk компании Xerox. Сам паттерн был привязан к концепциям специфичным для SmallTalk, таким как screens и tools, но более широкое его применение и сейчас применимо для приложений (особенно для веба).

Одной из основных фишек этого паттерна, что View остаётся stateless (всё состояние определяет модель), что отлично ложится на http запросы и отрисовку веб страниц. Поэтому он так широко применялся и применяется в вебе.

В контексте Unity можно писать в MVC стиле, и в любом случае как минимум два пункта полезны во многих архитектурных паттернах — это понимание domain model и view, и во всех современных приложениях View всегда Stateless, если оно написано правильно.

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

Источник:
Pro ASP.Net MVC 5 @ Адам Фримен

#термин

Фундаментальные знания

Это может показаться скучным и неинтересным, но учить лучше всего фундаментальные знания. Многие считают, что «вуз бесполезен». Что там преподают что-то устаревшее, а потом в работе вы пользуетесь вещами, которые придумали ещё до 2000 года. Так как все практические знания опираются на фундаментальные.

Зная архитектуру. Все архитектурные паттерны вроде MVC, MVP, MVVM, MVI — вам становится плевать на фреймворк, о котором идёт речь. Зная алгоритмы триангуляции, вам плевать речь о генерации мешей или о триангуляции блютус сигнала для определения позиции телефона. Многие ошибочно считают, что «игры это другое». Хотя игры это точно такая же предметная область. И правила написания качественного софта там не совпадают в нюансах. По сути основным нюансом игр является наличие тактов в виде кадров. То чего нет в среднем проекте из другой области. В играх важны фреймы. В остальном игры — это точно такое же ПО.

Изучая фундамент вам по сути не важно Unity или Godot, C# или JS, ShaderLab, hlsl или glsl. Так как зная на чём это всё основано вы легко узнаёте и усваиваете все производные. Любые языки и любые фреймворки. Какие-то языки и фремворки имеют больше нюансов и деталей, какие-то меньше. Но принципы везде одинаковы.

Поэтому вузовские знания могут звучать скучно, книжки сухо, но их пользы это не отменяет. Обязателен ли вуз разработчику? Нет. Можно ли писать код не зная фундаментальных вещей? Да, и даже хороший наверное. Но их знание упрощает жизнь в разы. Когда вы понимаете принципы, вам просто становится пофиг на технологии и языки. Так как это всё воспринимается как «предметная область».

Это как разница между теми кто в школе зубрил, а кто понимал предметы. Не зная фундамента вы просто зубрите мантры и конструкции. И как и в школе это работает с оценками, так и в работе с проектами. В свою же очередь когда понятны принципы, то становится вообще не нужным что-либо заучивать и запоминать. Просто есть понимание «как оно устроено».

#мысли

Этот кейс я даже репостну из своего второго канала, так как он прекрасен. AR маска с игровой механикой и коллекционированием покемонов, чтобы дети правильно чистили зубы. Я бы сам такое по коллекционировал :)

Addressables лучшие практики
https://blog.unity.com/technology/addressables-planning-and-best-practices

Пост в блоге Unity про аддрессаблы. Ничего особо нового из него я правда не узнал, хотя я так и не начал ими пользоваться. Аддресаблы прикольные, просто мне почему-то удобнее мой ресурсный менеджер. Хотя я помню с ними одну проблему, которая в статье не упоминается. Как с ними работать в вебе, так как в нём мы переделывали как-то на свою систему, так как там были какие-то косяки. Но пост всё равно прикольный.

#новости

Гайд по устранению зависимостей в Addressables
https://habr.com/ru/post/715810/

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

#новости

VFX Graph + NeRF
https://www.reddit.com/r/Unity3D/comments/10x8mxj/vfx_graph_point_cloud_composited_with_nerf_from/?utm_source=share&utm_medium=ios_app&utm_name=iossmf

Красивая визуализация neural radiance field с помощью VFX Graph. Вообще облака точек часто выглядят залипательно.

#новости

Туториал VFX энергетического щита
https://youtu.be/_vIM5fWYGiM

С тем сколько я видел реализаций force field каждый тутор по энергетическому щиту уже выглядит как «решение классической задачи». И вот я наткнулся на такой туториал с реализацией на шейдер графе. Может кому пригодится. И туторы всё равно полезно смотреть для ознакомления с разными техниками.

#новости

Интересное из мира Unity #2 (03.02.23 — 09.02.23)
https://habr.com/ru/post/716086/

Новая пятница, а значит новый дайджест на хабре.

- Изменил оформление. Новостей по Unity выходит не так много, так что думаю так будет удобнее.
- Изменили обложку. Она теперь выглядит симпатичнее

#дайджест

Сделали промо-ролик для XR Cases

Пока межсезонье занимаемся "подготовительными работами". Вот сделали промо-ролик тизер для моего второго канала с кейсами разных интерактивов AR&VR. Unity это конечно геймдев, но моя основная работа всё же связана с созданием всяких интересных штук для рекламы, для выставок, сложных интерактивов и так далее. Это конечно не игры, но у всего есть свои плюсы. Например у меня "самые модные игрушки" в плане технологий.

Ролик получился красивым. Если кому-то интересно для вдохновения смотреть какие технологии есть, какие технологии можно как применять на примере кейсов разных компаний, то подписывайтесь на канал!

#интересное

Бесплатная модель Нью-йорка
https://www.youtube.com/watch?v=l5nWfpty7To

Интересный инструмент, где можно скачать бесплатную 3д модель. Ссылка сразу на сам инструмент GeoPipe, а не на видео о нём. Выглядит прикольно. Как я понимаю развитие этой истории — это оцифровка гео-данных, чтобы делать те же игры по "реальным городам" быстрее.

Скоро получить оцифрованный город в своей игре сможет каждый, а не как в олд-скульные времена Ubisoft сами собирали все данные делая Assasins Creed.

#новости

И ещё один NeRF
https://www.youtube.com/watch?v=CHrQ_94iw64

Случайно наткнулся на видео на Youtube. Не так атмосферно, как вечерний визуал, но тоже выглядит залипательно.

#новости

Wave Function Collapse
https://www.youtube.com/watch?v=2SuvO4Gi7uY

Прикольное видео двухлетней давности про Wave Function Collapse. Сам по себе WFC интересный алгоритм, который очень полезен для процедурной генерации уровней игры или карты.

#интересное

Процедурная генерация дороже

Пост про WFC и комментарий к нему вдохновил меня на небольшой пост. Разрабатывая игры вы всегда должны помнить. Процедурная генерация случайных уровней в разы дороже, чем реализация конкретного набора уровней. Тут конечно стоит сделать ремарку. Чтобы в это было интересно играть)

Рандом написать в среднем не так сложно. Любой. Базово раннеры бесконечные пишутся через просто сборку тайлов. Но мне повезло по карьере с первым проектом в геймдеве на котором я работал. Я сразу попал в Vector 2. И я люблю этот проект. Но это процедурно генерируемый рогалик о котором до сих пор можно услышать историю о "проекте где было 14 геймдизайнеров". И я был там, Гендальф. Это было 3000 лет назад. Причём в те времена я был геймдизайнером. Вектор 2, это раннер с механиками рогалика. Мне он нравился, он был прикольный, в него было интересно играть. И по сути все геймдизайнеры настраивали и дорабатывали этот супер-генератор :)

А зачем нужен рандом вообще? Ну точнее говоря не рандом, а процедурная генерация? В теории она должна увеличивать реиграбельность проекта. Но многие я думаю с удовольствием пройдут ещё раз какой-то интересный сингл плеер, чем будут играть в бесконечные уровни скучной игры. Поэтому действительно крутой и реиграбельный рандом, не наскучивающий, очень сложно делать. В разы проще сделать Game of Chance с PvP. Там потенциал реиграбельности выше и делается это проще. Балансируется проще. И так далее.

Стоит помнить какой цели вы пытаетесь добиться. Игра должна быть весёлой, и если вы хотите увеличивать реиграбельность игры — есть пути проще. А чистый рандом — дико скучный. Алгоритмы типа WFC полезны пониманием принципа и того, что такое существует. Но в чистом виде он для генерации тех же уровней игры абсолютно бесполезен.

#мысли

Шейдер для карточной игры в ShaderGraph
https://youtu.be/BLO6hZ1yyjY

Туториал про то, как сделать шейдер двухсторонней карты в шейдерграфе. Для какой-нить карточной игры — полезно. Плюс можно узнать про ноды вроде isFrontFace и Branch.

#интересное