И ещё немного о работе

Забавная вещь квалификация. Вот уже 12 лет я в IT. Я поработал в 5 компаниях. Пофрилансил 1.5 года. Создал свою компанию. Разорился. Перезапустил свои бренды в новом форм факторе. Занимался разработкой, продажами, составлением документации, строил юнит экономику, считал экономическую эффективность решений, занимался исследованиями. Поработал с медициной, тяжелым производством, легким производством, компьютерным зрением, выставочными стендами, рекламными играми, недвижимостью, автопромом, логистикой, нефтью и газом и так далее. С киношниками, со спортивными клубами. Такое ощущение что я в разной степени коснулся каждой индустрии. И я вот периодически думаю. А вот если бы я пошел на работу, то кем мне работать?

Я то и сейчас спокойно могу что-то на фриланс простенькое взять, когда есть время и желание, помимо каких-то замудреных конслатов. Недавно даже на фриланс бирже чёт искать пытался (ну в в начале лета, так как рынок дохленький) И у меня нет каких-то понтов. Ценник берется по типу работ, а не по тому чего бы мне хотелось. Разработка скажем относительно стандартные 3к в час (что не особо дорого, относительно 15к за консалт). Но это одноразовые истории. Можно сказать халтурки, как студентами мы грузчиками подрабатывали и так далее. А на работу ведь ходить каждый день. И долго ходить. И желательно с ума не сойти.

Линейным разработчиком - умру со скуки. Наверное если бы я и пошел на работу, то ток на С или в продажи. Вот технические продажи это всегда весело. Там действительно не соскучишься. Но вообще с тем скок всего я делал, учитывая мои бренды и так далее. Думаю меня никуда не возьмут. Хотя кажется в прошлом году я даже резюме куда-то кидал, что ли в сбер. Времени слишком много было свободного, так как я все проекты делегировал 🙂 Но меня даже на собес не позвали) Кажется на Unity сеньора) Получается негожусь, что поделать 🙂

#оработе

Инструмент для деформации сетки в Unity
https://80.lv/articles/check-out-this-useful-mesh-deformation-tool-for-unity

Художник под ником t_erenoa разрабатывает инструмент для деформации сетки (mesh deformation tool) в Unity, который может упростить работу креаторам VRChat и VTuber. В последней демонстрации показано, что дополнение позволяет добавлять напряжение движения к отдельным объектам с опцией Connected Only (например, можно двигать ремень, не перемещая всю одежду), а также есть ползунок для управления областью эффекта. Разработчик использует ComputeShader для оптимизации вычислений при увеличении количества вершин.

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

#новости

Создание и использование спрайт-шитов в Unity
https://medium.com/@gaetano.tonzuso/unity-create-and-implement-a-spritesheet-in-unity-034492fd1851

Статья что-то совсем на инди. Суть статьи сложно описать. Тезисно. Мы инди без дизайнера, у нас есть задача сделать гуй, мы находим спрайт шит в интернете, редактируем его в GIMP и InkSpace, и кидаем в юнити проект, а юнити само нарежет нам это на отдельные спрайты. Ну и типа определение, что такое SpriteSheet. Что это у нас соответственно текстура с кучей картинок на прозрачном фоне. Ну допустим.

Но вообще конечно в 2025 у юнити есть много прикольных систем внутри. Если вспомниать древние времена, то все пользовались Texture Packer и без них. Но основной вопрос не что такое спрайтшит или текстурный атлас. А зачем они нужны? Я немного дополню для новичков, так как статья явно для них.

В юнити всё меши. Гуй, спрайты в 2д играх и очевидно 3дшка. В сущности это всё 3д графика. С рендерером как у 3д графики и вот таким графическим конвейером. И вообще стандартно это так не только в Unity. Почти все 2д движки в конечном итоге под капотом работают с 3д. Простые движки 2д графику воспринимают как квады, а в Unity в случе гуя - это квады, в случае просто 2д графики - это меши для оптимизации альфа блендинга.

Так как у нас тот же графический конвейер и принципы, то и оптимизации у нас те же. А как мы оптимизируем 3д графику? Используем меньше текстур и материалов, меньше вертексных параметров, упрощаем геометрию. Если пункты 2 и 3 не применимы. То тот факт, что батчатся у нас меши только на которых висит один материал уже роль играет. И тут важны текстурные атласы. Чтобы на всех мешах наших был один материал с одной текстурой. (Помимо нюансов стоимости вызова самплинга текстуры)

Мы хотим всегда минимум дроуколлов. Если у нас весь гуй в одном текстурном алтасе с одним материалом (базовым), то он рисуется в один дроуколл. Собственно всё. И тут стоит дополнить, что да. По простому мы берем спрайтшит из интернета, используем спрайты из него и работает. Но вряд ли он упакован оптимально 🙂 Даже юнитевский паковщик SpriteAtlas пакует не лучшим образом (как я тестировал TexturePacker укладывать в ряде случаев умеет по плотнее) А судя даже по примеру из статьи, там "как дизайнер разложил" так и лежит.

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

#новости

Больше таблиц богам таблиц
https://github.com/JoseGomis299/TableForge

На что наткнулся. Инструмент для редактора для работы с данными ScriptableObjects в виде электронных таблиц. Основные функции: визуализация данных, редактирование ячеек, управление строками/столбцами, фильтрация, транспонирование таблиц, импорт/экспорт CSV/JSON, работа с подтаблицами, привязка к типам ScriptableObject, сохранение метаданных, система отмены/повтора действий, копирование данных в Excel.

Если вдруг вам не хватает гугл таблиц и экселя, то у вас есть новая возможность играть в таблицы 🙂 Не, на самом деле таблицы это удобно. Я уже давно все конфигурации делаю в гуглодоках, так как это удобнее, чем всякие RemoteConfig фаербейса и прочие штуки. Завел табличку, распарсил как csv. Редачишь формулами с полной мощью экселя. А эта тулза может пригодится тем, кто хочет чтобы внутри юнити можно было ещё кофе заварить. Ну либо кому лень парсеры писать 🙂 Но почему бы и нет, больше инструментов - лучше.

#интересное

Meta* решила писать свой движок
https://ru.investing.com/news/stock-market-news/article-93CH-2917020

Реакция рынка всегда мне показывала какое-то базовое непонимание основных концепций мира. До блокировок лондонской биржи и так далее я держал NVIDIA и подобных производителей, потому что пока по происходящему в мире они неубиваемая монополия. Догнать их просто нереально, а зависимость от них есть. Но я там вообще удачно вышел. Всё скинул до блокировок и из доллара вышел по курсу 115 🙂

Тут рынок чёт как-то отреагировал по новости (самому лень даже смотреть) на что. На то, что компания занимающаяся AR&VR по сути вероятно будет делать движок для этого. А Unity сильно зависит от этого сегмента рынка? Нет. Этот сегмент рынка растет? Не думаю. Это будущее? Честно говоря вообще пока не вижу предпосылок для этого. Это рабочий инструмент сейчас в определённом классе задач. И типа, ну делают и делают. Движок сделать если честно не проблема. Я при желании назову сумму и продакшен план на 2 года, как можно сделать неплохой аналог того же Unity. С операционным развитием на 5 лет. Я как-то это прикидывал для разминки. И написать неплохой рендер на понятных технологиях, инструменты импорта и так далее - это технически понятная и оцениваемая задача. Не элементарная, но и не рокет саенс на самом деле. А настоящая проблема собрать на этом движке комьюнити разработчиков. Система евангелистов, внедрение сверху в компании и так далее. Это то, что занимает уйму времени. Поэтому ну пишут и пишут.

Я однажды отказался от одного проекта. Мне предлагали писать на движке, которым я не пользуюсь, аутсорс проект. И разрабов на этот движок нет. Бюджет был неплохой, но я заказчику объяснил свою позицию. Окей, я ща соберу команду, мы обучимся этому движку и сделаем проект. И что нам с этим делать дальше? В те времена у меня ещё был штат, и нанимать людей на проект, а потом увольнять, при том что в результате будет специалист с непонятно зачем нужной экспертизой мне не хотелось. Поэтому с внедрением сверху тоже имеются проблемы, что бизнесу должно быть интересно. Но будем посмотреть, сверху то понятно решается грантами на продукты и так далее. Хотя на XR поприще продуктового B2C рынка я уже несколько лет просто не вижу.

*Запрещенная в РФ организация или что там надо писать

#новости

Расслабляющее путешествие на лодке через 3D-облака в Unity
https://80.lv/articles/relaxing-boat-journey-through-3d-clouds-in-river-made-with-unity

В статье представлен проект, созданный в Unity, — визуализация расслабляющей лодочной прогулки по реке, окруженной объемными 3D-облаками. Демонстрируется атмосферная сцена с реалистичной водой и динамически изменяющимся небом, подчеркивается использование инструментов движка для создания умиротворяющей и визуально привлекательной среды.

Очень красивое. Реймаршинг конечно штука прикольная. Люблю такие маленькие но шикарно выглящие фишки в играх. Если вспоминать It Takes Two, то я в неё больше всего хотел поиграть из-за локации с часами.

#новости

Разработчики и студии! Больше никаких проблем с выплатами от Apple, Steam, Google и других платформ.

🚫 Санкции, блокировки и комиссии — главная боль российских разрабов сегодня. Деньги застревают, переводы отменяются, а прибыль уходит банкам.

dev.cab решает эту проблему раз и навсегда:

✔️ Переводы через проверенного дистрибьютора;
✔️ Выплаты на ИП, ООО или в USDT — без блокировок;
✔️ Комиссия от 6% — прозрачная и прогнозируемая;
✔️ Юридическая и операционная поддержка на каждом этапе.

Надёжное решение для стабильных выплат без риска и бюрократической головной боли.

📌 Подробнее и подключение: dev.cab

📩 Telegram для связи: @dev_cab

Реклама. ИП Чернов Олег Владимирович. ИНН: 691007481228. Erid: 2VtzqwMkcUL

Превращаем квады в живых бабочек
https://80.lv/articles/this-stunning-shader-turns-unity-s-default-quads-into-butterflies

В статье представлен нестандартный шейдер для Unity, который преобразует обычные квадратные полигоны (quads) в реалистично выглядящих бабочек. Шейдер использует методы анимации и текстурирования для создания эффекта порхания, позволяя легко добавлять в сцену динамичных насекомых без сложного моделирования.

Последнее время много красивых эффектов выходит. Этот не самый сложный, но тем не менее выглядит симпатично. И подобные объекты важны. Как-то раз мы делали игру для стенда на выставку для одного крупного банка (проект к сожалению NDA) и там нужно было управлять летающим персонажем. Но так как мы летаем высоко в горах, то очень тяжело чувстовать объём постоянно. Потому что дальний план почти не движется, а интерактивные объекты разнесены по карте. Мы просто добавили пыль. Благодаря частичкам пыли в воздухе в игре в разы лучше ощущался объём сцены и считывалось движение персонажа. Хотя в сущности это те же партиклы.

#новости

Система нацеливания для Unity
https://www.youtube.com/watch?v=aZanRrhBg-8

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

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

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

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

Но я отвлекся. Видео классное. И прикольную реализацию стратегии показывает. Но мне всегда режет глаз когда в реализации визуализация тесно перемешана с логикой. Я считаю, что базово игра должна играться хоть в консоли без привязки к Unity и любому другому фреймворку, а через композицию поверх должна навешиваться визуализация. А тут у нас визуализация в логических классах контейнерах и так далее. Просто видео не о том, поэтому на это можно закрыть глаза, но мне сложно 🙂

#новости

Интерактивный гайд по шейдерам Unity
https://80.lv/articles/check-out-this-upcoming-animated-e-book-on-unity-shaders-vfx

Технический художник Unity Хосуэ Ортигоса Рамос (известный как Дервиш) работает над анимационной электронной книгой «The Shaders Survival Guide», которая будет посвящена работе с шейдерами и VFX в Unity 6 и Shader Graph. Книга включит проект Unity 6 с необходимыми для обучения образцами и ассетами (например, Moonlight Sword), а также охватит различные аспекты разработки шейдеров: базовые концепции, инструкции по настройке, важную терминологию, рендер-пайплайны, текстуры, математику, связанную с VFX, и практические упражнения. Ранее Дервиш создавал множество работ и обучающих видео в Unity, включая шейдеры для слизи, анимации медузы, диарамы для тестирования пиксельных шейдеров и другие.

Да, у меня тоже когда-то было много идей для интерактивных туториалов. В целом на примерах пользовательского софта (игры и приложения) интересно что в профессиональном софте крайне редко встречаются интерактивные туториалы. Сейчас их конечно частично заменяют ИИ ассистенты, а раньше гугл. И забавно что дело в мотивации. Если приложение не профессиональное, то игрок может бросить его что-то непоняв. А в профессиональном софте ты кактус готов сожрать и перерыть весь гугл, чтобы понять как сделать Х (особенно блендер как пример с его тонной хоткеев). А так круто, больше материалов по шейдерам - лучше.

#новости

Менталитет «Поймать за руку»

Сегодня случайно наткнулся на этот термин. Достаточно забавная штука с точки зрения и работы, и жизни. Что это? «Менталитет поймать за руку» — это установка, при которой главной целью становится поиск чужих ошибок, а не помощь или созидание. Уходящий корнями в историю тотального контроля, этот подход проявляется в бюрократии, работе и быту, порождая атмосферу страха, формализм и подавление инициативы, что в итоге тормозит развитие общества, основанного на доверии.

По сути наверное это привычка классического менеджмента. Человек должен показать что он работает, но не понимает в чем его работа заключается. И я был таким. И в этом есть и свои плюсы, и свои минусы.

Это удобно когда ты участвуешь в переговорах. Переговоры — это игра аргументов. Сейчас я уже так не делаю, но когда-то я искал все ошибки для аргументации. Плюсы — позволяет защищать свои интересы. Минусы — деструктивно и не ведёт к основным целям работы. Поэтому это перестало быть основой. Принцип «хочешь мира, готовься к войне» ведёт к предсказуемым результатам, но далеко не самым оптимальным. Есть техники мягче и элегантнее.

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

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

#интересное

Как в Hear Tell of Hauntings имитируют движение фонаря
https://80.lv/articles/fake-lantern-physics-for-unity-powered-wild-west-survival-horror-indie-game#conversation

Шон Гоуз продолжает работу над своей будущей игрой в жанре survival horror с вестерн-тематикой Hear Tell of Haunings: он продемонстрировал имитацию движения фонаря. Гоуз отметил, что хотя для других объектов он использует физические соединения, например, для фонарей, висящих на столбах, которые реагируют на удары или выстрелы, в сложной иерархии костей персонажа-игрока они не работают, поэтому пришлось искать другой подход. В игре, где главная героиня Аделаида Клэнси исследует поместье Wraith после получения приглашения на свадьбу от двух давно умерших влюблённых.

Симпатичный эффект. Ничего сверх естественного, но сделано красиво.

#новости

Обучение GPU-программированию: подход compute-first вместо традиционного рендеринга
https://themaister.net/blog/2025/10/05/a-case-for-learning-gpu-programming-with-a-compute-first-mindset/

Автор считает, что традиционный подход к изучению программирования графики сложен и неэффективен, и предлагает обучать GPU-программированию с акцентом на вычисления (compute-first), а не на графику, начиная с отладки и профилирования, а не с рендеринга «Hello Triangle». Он рекомендует использовать Vulkan для изучения вычислений, упоминает свой инструмент Granite как промежуточную абстракцию API, подчёркивает важность RenderDoc для отладки, предлагает начинать с Vulkan GLSL, а затем рассматривает такие темы, как работа с дескрипторами, ISA, шейдерные замены и другие аспекты программирования GPU. В конце автор перечисляет направления для дальнейшего изучения, включая атомики, безблокировочное программирование, операции с подгруппами и работу с текстурами.

Что сказать. Тут вспоминаются истории битв в начале моей карьеры. В основном битв с С++ программистами. Ведь GC для слабых духом, сильные пишут смарт поинтеры и в ручную управляют памятью. На мой взгляд подобный подход это что-то на староверческом и очень далеком от реалий бизнеса и устройства реального мира. Нафига изобретать лопату и понимать как её сделать если твоя задача выкопать яму?

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

Я лично ушел когда-то в игры и в фронт в основном, так как бек мне не нравился тем, что я будто бы не вижу сразу результат своих действий. Я всегда любил, чтобы то что ты сделаешь сразу давало какой-то визуальный результат. Да и учиться я начал по стечению обстоятельств с создания сайтов. Поэтому изучать абстрактные знания без практического понятного применение для меня около невозможная задача. Мне банально скучно. Скажем первым языком был питон, и я всем знакомым рекомендую начать с Python, потому что там проще всего взять и запустить програму. Так сказать самый низкий порог входа. Потому что в школе я забил на программирование сайтов, так как тупо не понял как развернуть Apache, чтобы сайт открывался не только со статик html у меня на компе. А в Волгограде в то время курсов по разработке или тех кто мог бы мне это объяснить не было. Когда же я начал учиться в универе я понял, что объяснить человеку который далек от разработки как в те времена написать и скомпилировать простейшую программу на плюсах - это прям сложно. А на питоне всё элементарно и материалы были даже тогда.

Поэтому точка зрения автора любопытная, но я с ней не согласен 🙂

#интересное

Сниппеты и нейросети

С нейросетями я чёт потерял цель хранить интересные сниппеты. Многие задачи которые концептуально простые, но при этом муторные в плане реализации стало проще спросить. Допустим сейчас мне для одной задачки понадобился в Unity парсер Markdown который переведёт эту разметку в RichText для TMP. Взял, спросил, пару уточнений добавил и готово. Удобный сниппет, чтобы не писать долго и муторно перевод спец символов в html теги. Хотя задача и так не сложная, но времязатратная. И такого много.

Да, конечно с комплексными задачами и с теми, где я сходу сам не понимаю "а как это вообще делается" нейросети не справляются. Что разумно. Потому что если о чём то не написано в интернете, то нейросети неоткуда узнать как это делать. Но какие-то утилитарные задачи, которые я бы во времена работы в компаниях скинул бы на джунов, делаются за секунды. Эхх, прощайте сохраненки с алгоритмами типа пирамидальной сортировки, A* или DFS. Вас заменил один запрос в чат с неиронкой. Удалять я конечно не буду, вдруг за этот бесплатный сыр прийдется когда-то платить огромные деньги. И тут мы сдуем пыль с технологий древних.

#мысли

О вызовах в разработке современной пререндеренной игры The Goddess's Will: работа с графикой
https://habr.com/ru/articles/956148/

В статье автор делится опытом разработки игры The Goddess's Will с использованием пререндеренной графики — технологии, при которой 3D-сцены и анимации заранее рендерятся и затем используются в игре. Описываются этапы создания статичных объектов, анимированных элементов (например, растений) и персонажей, проблемы с настройкой света, камер, рендерингом, постобработкой и импортом в движок, а также трудности, связанные с потреблением видеопамяти. Автор затрагивает вопросы автоматизации процессов, сравнивает пререндер с 3D, рассуждает о роли сюжета и лора в играх и объясняет выбор C# вместо GDScript для работы в Godot, перечисляя плюсы и минусы такого решения.

Итак. Про свои 5 копеек. Меня заинтересовал в конце ответ на вопрос: "А зачем нужен пререндер, если можно в реалтайм 3д сделать тоже самое?" И ответ мне не совсем нравится, так как он спекулятивный. Сейчас все используют комбинацию подходов. Потому что запеченный свет даже можно считать пререндером. Потому что по сути мы хитро натянули текстуру на геометрию вместо квада, но это всё та же 2д текстура, которую мы пренедернули. Так же есть техники вроде импостеров для дальнего плана и многое другое, где по сути пререндер.

В чем же спекулятивный ответ? Очень мало слов про недостатки. Вроде оперативной и внешней памяти для хранения всего этого многообразия рендеров. Ведь прикол 3д, что это в некотором смысле тоже самое, что и векторная графика. И часто она будет весить ощутимо меньше, чем куча отрендеренного 2д. Но больше всего я обратил внимания на фразу условия освещения. В пререндере мы вообще соглащаемся на отсутствие динамических источников света или делаем их влияние какими-то хаками, потому что мы не можем пререндерить ничего под динамические условия освещения.

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

#новости

В 40 лет в геймдев: от корпоративного архитектора к инди-разработчику
https://habr.com/ru/articles/958874/

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

Считаю без увольнения и жизни на дошиках - несчитово 🙂 А если серьезно прикольная статья о хобби человека. Пока игры это хобби это вообще кайф, самое веселье когда пытаешься на них зарабатывать 😆 У многих игры это хобби или начинается как хобби. Но вообще это фишка основы старой школы разработки в целом - иметь пет проект. Ведь все кто пришли в разработку "по-любви", а не за бабками - любят разработку. Холивары и прочее происходит от того, что пока из каждого утюга не стали кричать что "айти это выгодно", это был мир энтузиастов. Где каждый готов с пеной у рта доказывать своё мнение (хотя никто не знает как правильно).

Мне надоело именно разрабатывать спустя 7 лет в разработке. А раньше я приходил с работы и писал свои личные проекты, часть из которых уехала в паблик репозитории на моём гитхабе 🙂 И я нашел себе хобби не связанные с разработкой 😆 Я ща начал потихоньку изучать игру Го. И поразительно конечно как доска с камешками и клеточки могут заставить тебя размышлять о тактике и насколько это комплексная тактически игра.

#новости

Руководство по оптимизации памяти в Unity 6
https://habr.com/ru/companies/otus/articles/959150/

В статье речь идёт об управлении памятью в Unity: рассматриваются типы памяти (нативная, управляемая, память GPU и др.), проблема фрагментации памяти, а также способы оптимизации — использование Memory Profiler для анализа снимков памяти, сжатие текстур, отключение ненужных функций при импорте мешей и анимаций, управление вариантами шейдеров; кроме того, затрагиваются утечки памяти и методы их обнаружения с помощью Memory Profiler.

Классное руководство. Допустим на моем опыте самая частая проблема, и топочему в проектах сцены грузятся тысячелетие, это незнание того, как Unity кладет ресурсы в память. Допустим вы решили сделать небольшой веб проект. У вас есть какие-то спрайты, меши, не так важно. В общем ассеты. Скажем на примере системы стилей. Частый кейс в геймдеве с точки зрения монетизации когда-то был (да может и есть) вип аккаунты. И часто скины персонажей или целого интерфейса отличаются для таких пользователей. Вы сделали ScriptableObject и сохранили в нем ссылки на ассеты, а ссылку на скриптабл обжект положили в мейн сцену. В память пойдут сразу оба скина. Поэтому для грамотного управления ресурсами удобнее ленивая инициализация ресурсов по запросу. Так проще управлять лайфтаймом, не ловить Out Of Memory эксепшн и так далее. Но из-за того что часто люди не понимают цикл загрузки ресурсов в память я вычищал такие ссылки в проектах.

Тут ещё важно понимать продуктовые метрики. Для меня в рекламе вообще критически важна оптимизация времени загрузки, но так же это очень важно в играх. Потому что это влияет на конверсию и удержание аудитории. В первую очередь на стоимость привлечения. Представим вы сделали крутую рекламу своей игры, но 20% аудитории отваливается из-за того что игра грузится слишком долго (в современном мире очень легко потерять фокус внимания пользователя). По сути что это означает? Конверсия в инсталл снизилась на 20%, то есть стоимость привлечения пользователя увеличилась на 20%. А ведь в играх как в любом продукте по сути помимо капитальных расходов на разработку ключевой формулой явлется ALTV - CPA (среднее число денег которые приносит пользователь за время игры в игру - стоимость привлечения пользователя). Соответственно чтобы увеличивать прибыль вы хотите наращивать ALTV и снижать CPA. И если из-за мелкого косяка у вас идет рост расхода вы можете терять много денег, да и в целом бизнес модель может не биться.

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

#новости