Вопрос про пост "Стена ветра Yasuo", там ты спросил зачем там нужен был VFX граф. Так вот, было бы интересно узнать а какую альтернативу можно было бы использовать, старую систему партиклов? И вообще хотелось бы узнать что сейчас лучше использовать для создания различных эффектов и что производительней при создании одного и того же эффекта. Смотрел год назад стрим одного разраба, который делал все эффекты оружия и дамага в своей игре через партикал систем, а потом просто всё переделал через vfx graph, насколько я понял через код управлять им было более гибко

Ну конкретно эффект ясуо я бы вообще сделал через инстансинг мешами. Без графов и партиклов. Если заменять старый и родной шурикен на VFX граф, да можно. VFX граф погибче и поудобнее. Тут просто эффект такой, что мне и частицы не совсем понятны :)

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

А так VFX граф > шурикена (старой партикловой системы). Точнее он просто удобнее для модификации и использования. Тут просто граф то миниатюрный, поэтому я бы это просто шейдером с интансингом сделал бы и нужный меш. Ну это вопрос скорее наверное привычки, чем особого выигрыша играющего какую-то роль. У меня очень много своих меш генераторов для разного VFX и шейдеров, поэтому я до сих пор как-то не особо перешёл на графы. Учитывая что для рендера я пока по старинке на билтин рендере.

Напоминаю что вопросы можно задавать тут.

#вопросы

Очень было бы интересно узнать ваше мнение насчет краудфандинг площадок, как рф так и мировых. Конкретно по AR сервисам, созданных в виде цифровых сервисов на мобильные устройства, и WebAR инициатив. У меня сервис по AR смотрю на эти площадки с интересом, может существует резон на них публиковаться? в может риски не оправданы?

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

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

А так я бы скорее начал дискуссию в комментах, если у кого-то есть опыт работы с краудфандингом. Так как я эту тему изучал, но чтобы прям туда лезть — нет. Я его всегда воспринимал как маркетинговый канал, чтобы привлекать инвест и создавать комьюнити вокруг проекта (что-то по типу Early Access). Просто мне он как-то не был нужен. Я в целом не фанат венчура и инвестиций, и пытался их привлекать только во времена моего инди, когда я ничё не умел. Сейчас я считаю, что инвесторские деньги — это самые дорогие деньги. И пока у меня нет в них необходимости не вижу смысла их даже привлекать.

Я просто не интересуюсь схемами заработка на венчуре. Типа выйти в кеш на каком-то раунде. Или же просто прокушать инвесторские деньги. В стартапах много интересного творится. А чтобы запускать боевые проекты. Мне интереснее экспериментировать на свои. Ответственность перед собой, продукт не сработал — списали, переформатировали и так далее. Типа https://whitelabelgames.ru/ раньше это был продукт. Определённого формата. Но у него юнит экономика по итогу сходилась как-то криво. Поэтому я переформатировал его вместо "открытого калькулятора цен" в закрытый прайс-лист. И по сути он стал портфолио опыта в вебе. А как продукт он уже условно "списан". У него совсем другой формат, принцип финансирования и смысл.

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

#вопросы

Как перестать бояться просить денег за свои услуги?

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

Просто были две вещи которые я всегда обожал. Математику и программирование. И у нас курсачём на первом курсе было сделать какой-то софт чертилку деталей на QT. Детали разной формы с разными параметрами. Основная фишка там была определение клика внутри фигуры сложной формы. И её площади. Но если знаешь первое, то второе дело техники, так как есть метод Монте-Карло. Идея проста. Берём прямоугольник, кидаем в него в случайные места миллион точек. Дальше проверяем сколько попало в нашу фигуру и делим это число на общее число точек. Площадь прямоугольника мы знаем. А площадь фигуры получается как эта площадь умноженная на число попавших точек и делённая на общее число точек. Чем больше точек бросим, тем точнее будет расчёт. Не суть, я отвлёкся :)

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

Да нечего тут бояться. Взрослые люди всегда всё понимают. Что время стоит денег. Никто за это не осудит. Всем нужно платить кредиты, платить за квартиру, да и вкусно кушать хочется, и гулять. Я уже иногда даже заказчикам декомпозирую все косты проекта. Так как слыша от меня 1 миллион или 3 миллиона, такое ощущение складывается (особенно с непрофильными), что я там положу этот миллион или 900 000 себе в карман. У меня не такая маржинальность, и я не такой наглый. На некоторых проектах я зарабатываю 10-15%. Хотя учитывая мои расходы на поиск, привлечение, документы, налоги и многое другое — это мягко говоря невыгодные проекты. Обычно 30-50%. Если брать расчёт костов студии, то со мной работать выходит сильно дешевле, чем с любой студией (да и на самом деле и иногда дешевле чем штат нанимать).

Я скорее больше понимаю даже такой вопрос. А как посчитать стоимость своей работы? Вот не умеете вы оценивать себя. Или работу других людей. И тут всё довольно просто на базовом уровне. Давайте посчитаем ставку часа адекватную для скажем Senior Unity фрилансера. Пойдём мы для этого на hh. Если посмотреть, Unity сеньору есть предложения от 180к рублей до 300к. Возьмём среднее даже 250к. В месяце у нас 168 рабочих часов. То есть ставка получается 1488р в час на работе. Поэтому адекватной ставкой сеньора является 1500р в час. Можно ещё поправку сделать на соц. пакет и поиск заказов получится 2000р в час. Дизайнера, художника, да для кого угодно можно посчитать точно так же.

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

#вопросы

Что такое тексел?
https://habr.com/ru/post/714278/

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

#статья

Оптимизация физики
https://youtu.be/ukgHS9HyNlU

Классное видео по оптимизации физики в Unity. Кроме экономии на спичках со «скейлом без дробей на коллайдерах» у меня слух ничего не резануло. Этот тезис верный по сути, но для новичков по смыслу кривоватый. А что если скейл коллайдера будет единичным, а скейл трансформа будет дробным? Не скажу что совет вредный, скорее бесполезный и нереализуеммый в среднем :) Но в остальном классное видео.

#новости

Hex Tiling
https://www.youtube.com/watch?v=GjO8XLOzNQM

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

#новости

Как организована работа с проектами? Какими техническими инструментами и организационными приемами пользуешься для управления проектами и задачами, ведения учета информации о клиентах.

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

А так сейчас всё довольно просто. Сейчас вся моя работа ведётся в четырёх инструментах:

Google Sheets/Docs — документация по проектам. Сметы, бюджеты, ТЗ, материалы, билды — всё там. Есть огромная таблица с расписанными бюджетами по всему. Каждый проект отдельно + сводный лист по всем проектам. Чисто для учёта.

AmoCRM — для клиентов и финансовой части проектов. Я конечно в основном Amo пользуюсь как Trello почти. Есть воронка, двигаю карточки, смотрю кому надо написать и когда. Функционалом задач и автоматизаций я там даже не пользуюсь. Ток настроил чтобы заявки с сайта тоже туда падали. Ну и аналитикой, чтобы смотреть "как прошёл год".

Notion — личный таск борд. Я пытался структурировать ноушен под другие задачи, но я не могу слезть с гугла. А вот таскборд там удобный. Я просто его настроил, чтобы он "автоматом чистился". И у меня там ведутся "мои дела на день". От "написать по такому-то проекту" до "заплатить за квартиру".

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

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

#вопросы

Задачка “Шипы”

Вам нужно сгенерировать меш конуса в Unity для того, чтобы в игре из земли вылезали шипы. Шипы используют standard shader. Сколько вертексов будет у конуса в вершине и почему?

#задачка

Я решил делать дайджесты
https://habr.com/ru/post/714634/

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

Я и так являюсь живым фильтром того, какие новости в общем потоке связаны с Unity или игровой разработкой, а какие нет. А тут ещё будет метрика интересности завязанная на читающих блог, так что думаю подборки будут выходить не огромными, но действительно с самым интересным из мира Unity.

P.S. Ищу Гермиону Грейнджер чтобы обменять/купить маховик времени :)

#дайджест

Классный язык скриптинга диаграм
https://play.d2lang.com/

Наткнулся на любопытную штуку. D2 — клёвый скриптовый язык, чтобы рисовать диаграммы. А по ссылке интерактивный тул, чтобы посмотреть как оно работает.

Я в целом люблю такие штуки. Формулы писать на LaTEX, когда его знаешь, тоже в разы удобнее, чем сидеть, чёт выдумывать как это сверстать в figma или в фотошопе :)

#интересное

Попробуем писать на vc
https://vc.ru/future/598906-daydzhest-interaktivnyh-keysov-nachalo

Теперь пятница будет — днём дайджестов. А я написал ещё один дайджест по своему второму каналу с xr кейсами. Вообще думаю на VR ещё стоит написать про white label и его историю. И может историю про разорение моей студии тоже. И тому как я пришёл к новому формату работы. Не знаю. Площадка для меня новая, сначала бы понять её правила и куда там вообще такое писать.

#новости

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

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

Итак, разберём на примере конуса. У нас есть такая модель. И есть интересные нюансы на тему того, как работает 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 @ Адам Фримен

#термин