Как составляются задачи

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

Итак, разберём на примере конуса. У нас есть такая модель. И есть интересные нюансы на тему того, как работает 3д в реалтайм рендере на той же модели ламберта. Ну то есть не все в курсе почему у юнити куба вершин 24, а не 8. Поэтому давайте для эксперимента проследуем моей логике.

Самый широкий вопрос. Сколько вершин у шипа в игре? Вообще строго говоря любое число вершин, а точнее какое захотите. И это не обязательно конус, это может быть и треугольник, и билборд quad для 3д, и много что ещё. Чуть уточним условие.

Сколько вершин у конуса, который используют шипы в вашей игре? Чуть лучше, мы ограничили понятие формы и теперь наш шип — это 3д конус. Условие шипа для нас в среднем убирает случаи усечённого конуса. Так что всё неплохо. Но в данный момент времени верный ответ всё ещё — любое число вершин. Вершина может быть одна, может быть две и так далее. С кастомными шейдерами всё зависит от задачи. А задачка была про нормали и PBR рендер. И по сути это переформулированная задача "почему у юнити куба 24 вершины". Напрямую говорить про PBR — для меня сразу очевидно, что подвох задачи в нормалях. Поэтому просто скажем standard shader. Вот мы и ограничили условие до нужного нам. Тут возможно стоило добавить, что в сцене есть свет. Но вообще зная связь меш-нормали-свет, опять-таки задачка становится слишком тривиальной, как и ответ на вопрос "почему".

При этом задача остаётся открытой. То есть вы можете написать решение "одна вершина" и обосновать его. Но строго говоря, с точки зрения PBR рендера одна вершина даст "устраивающий вас артефакт". И это не будет неверным. Но на самом деле решение единственно. N — по числу граней конуса.

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

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

Задачи я публикую с одной точки зрения. Не чтобы услышать "верное решение". Я никого тут не собеседую XD А чтобы было на чём размять мозги чисто по фану. Так сказать один из "образовательных моментов" канала.

#мысли

How to Program in Unity: Observer Pattern Explained
https://www.youtube.com/watch?v=NY_fzd8g5MU

Прикольное видео про одну из реализаций паттерна Observer. Чаще удобнее его конечно реализовывать через события или типа того в современном шарпе. Но старую добрую явную классическую реализацию тоже полезно знать. Хотя сейчас сахар позволяет писать в разы меньше кода и не делать лишнего наследования и лишних интерфейсов.

#новости

Управление небольшой командой

Это дополнение к ответу на вопрос выше. Так как похожий вопрос на этот есть в вопросах. Да и наверное тут я не сказал про "наш дискорд канал". Но давайте немного разберём путь проекта, когда ко мне приходит заказ. Не берём работу по обсуждению, выяснению бизнес требований и так далее. Задача понятна, пора делать. Что происходит дальше?

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

Первый лист — это у нас диаграмма Ганта или роадмап. Тут мы взяли ТЗ, декомпозировали его на таски, оценили сроки, составили план проекта. Если что-то смещается и съезжает — он корректируется.

Второй лист — это итерации. И это удивительная штука, что многие очень странно сдают контент. Я очень часто и подолгу объясняю заказчикам, что контент можно крутить — вечность. Работа людей — стоит денег. Комментарии даёте вы, а не мы сами из головы придумываем что делать. Поэтому число итераций по любой работе в рамках конкретного бюджета — ограничено. Мне кажется заказчики просто привыкают к тому, что есть фрилансеры с низкой самооценкой, которые готовы пол года перерисовывать одно и тоже. Я против такого и за честную оплачиваемую работу. Итераций может быть несколько, требования могут меняться, процесс может быть херовый (в зависимости от клиента), но всегда ограниченный во времени и в деньгах.

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

В трелло у нас всегда стандартные ToDo -> InProgress -> Review -> Done. Так как я идеологически не вижу смысла "стоять у кого-то над душой" и пристально следить "а работает ли человек". InProgress — это графа скорее по привычке. Я работаю не по T&M, а с фиксированными бюджетами именно по той причине, что мне важен только результат. Ничего не делал человек неделю, а потом за день всё сделано и качественно — отлично. В графе ревью задача улетает на согласование с клиентом, Done значит что она сделана и не вернётся, так как у меня или менеджера есть "да" от клиента. А если есть да, то это новая задача и возможно новый бюджет.

Вообще T&M я считаю злом. Систему на той же работе тоже не совсем удобной и корректной. Есть самый простой путь. Есть бизнес задача, есть бюджет на эту задачу. Если бюджет согласован, сроки согласованы, то нет никакой разницы сколько человек потратил часов на её выполнение. Сидел днём за компом или ушёл по своим делам/в кино. Сроки соблюдены, задача выполнена в бюджет. Всё остальное неважно.

Но это ремарка про аутсорс проекты. Управление небольшой инди командой строится немного иначе, так как это самостоятельный сыгранный юнит должен быть с "неопределённым" заранее результатом. И процессы разработки продуктов отличаются очень сильно. Хотя продукты можно разрабатывать так же, да и игры. Просто не особо эффективно. Чисто из-за скорости коммуникации на каждую итерацию или версию продукта. Если кому-то интересно, то могу написать свои мысли на счёт небольших инди команд "как бы я строил процесс". Ну как всегда, валюта у нас 🔥.

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

#вопросы

Как успевать больше?

Хочется порекомендовать книжку, но она не техническая.

Мозг. Инструкция по применению. Как использовать свои возможности по максимуму и без перегрузок @ Дэвид Рок

На тему того как больше успевать делать есть много техник. Я когда-то даже GTD изучал и следовал и т.п., но это было в универе. По сути самое полезное иметь список дел. И в целом все дела записывать. У этого есть две функции.

1. Вам всегда понятно что делать дальше и вы не тратите на это силы.
2. Вы не держите в голове, что надо сделать.

По второму пункту я могу помнить все свои дела. Но когда их запишешь, чувствуешь как голова разгружается. Так как видимо что-то помнить и вспоминать вызывает напряжение. Не знаю, не изучал эту тему.

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

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

Я не скажу, что живу по всем этим техникам постоянно. Скорее когда у меня завал по делам, много всего нужно сделать, я перехожу в аля "режим-робота". Где появляются все эти списки и трюки для упрощения и ускорения работы. Чтобы разгрести быстро завалы и дальше плевать в потолок. Ведь лень — главный двигатель любого разработчика. Натренироваться так, чтобы вообще ничего не делать — это достойная цель! :)

#мысли

Цена ошибки

Почему в разных сферах разные процессы разработки, разные принципы работы и так далее? Дело в разных целях и в разной цене ошибки. Допустим возьмём для примера корпорации. У них цена ошибки заоблачная. Если 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.

#новости