Григорий Дядиченко

Цензурирование текстов Речь о нецензурной лексике. Положите ручку, товарисч. Все кто играл в WoW на этапе личкинга должны помнить как близзард ввели сервис цензуры в текстах. И особенно все должен был запомниться квестовый персонаж Змеебой. Или как его пару лет называли близы Зме@!#%ой. Задачка частая, особенно в промо. Ники, UGC и тому подобное не должны содержать похабщины. А в детских промо тем более, так как дети любят баловаться. Стандартный подход это выделение матерщиных корней, как и поступили близы. Просто цензура дала осечку и забанила персонажа (на сколько близы недоверяют разрабам, что поставили это на все тексты, а не только на пользовательские. Статический ресурс локализации в целом проверять будто бы необязательно) Но ведь сейчас эра LLM, может можно отгрузить эту задачу им? Ничего же не мешает системным промтом сказать «отвечай да или нет, цензурное ли слово». И парсить ответ модели. И а целом это относительно работает. Но задача забавно глубже. Потому что по идее там нужны региональные системные промты. Возьмем слово Huesos. На наш слух звучит так себе, но это всего лишь по испански кости, и вполне себе имя. Поэтому если решать задачу так, то региональными системными промтами :) Это конечно на уровне рассуждений, так как дорогой сервис получится учитывая стоимость запросов в сетки. Но забавно, что в таком контексте можно применить LLM. #мысли

MVC и MVP: как избежать технического долга в проектах на Unity https://researchandprogram.blogspot.com/2026/02/mvc-vs-mvp-for-ruthless-unity-developer.html В статье обсуждается важность использования архитектурных паттернов MVC и MVP в разработке игр на Unity для избежания технического долга и упрощения поддержки кода. Автор утверждает, что монолитный код и чрезмерное использование MonoBehaviours приводят к проблемам в дальнейшем, и предлагает применять модульный подход. В общем базово на самом деле статья ни о чём. Без архитектурных паттернов писать плохо, с ними хорошо. Краткое описание MVP и MVC без примеров. Но о чём я захотел написать по этой теме? Я недавно попробовал прикольную связку. Model->Controller->ViewModel->Presenter->View По сути у меня есть модель, с ней работает контроллер. Контроллер описывает бизнес логику (и он внутри разбит на процессоры логики и через группу интерфейсов). Презентер дергает контроллер по события UI, контроллер при обновлении стейта передает вью модел в презентера, а он дальше распихивает их по View. И это оказалось довольно удобно по двум причинам (хотя и не особо быстро, но в контексте это неважно). Первая причина, потом из этого паттерна невозможно выбраться. То есть обойти это флоу в основном модуле ну просто невозможно, там доступ к модели никак по-другому не получишь, не написав явный костыль со статикой. Поэтому всё подчиняется этим законам, и если кого-то пустить в проект, то по дифу сразу будет видно, кто вышел за рамки паттерна. Вторая причина, это так чётко разделяет логику. В основном благодаря формированию ReadOnly ViewModel становится невозможным изменить модель в обход обращения к презентеру и действий в контроллере. Так как контроллер это не монобех, а просто шарповый класс, то отрезав презентера и вью можно навесить любой другой интерфейс обращения. Хошь апи поверх вешай чтобы играть и выноси логику на сервер, хошь играй текстом в телеграм боте. В общем надо будет набросать какой-то пример, который не коммерческий с примером этого подхода. Это конечно не совсем прямая абстракция как я люблю, там нужно немного вкурить, но как паттерн мне понравилась. Конечно при возможности нужно обсерверы (обновление модели и вью модели) декомпозировать или сделать реактивными. Так как сейчас при обновлении стейта модели она по сути отправляется целиком. Но в пошаговом геймплее это не особо то и важно на самом деле. Просто помню, когда я всё делал на реактивных пропертях, и изучал GraphQL для такой же логики взаймодействия с беком по сути, то там данных гонялось поменьше. #новости

Хитрые приёмы в разработке игр: как сэкономить ресурсы https://80.lv/articles/game-dev-shared-cheap-visual-tricks-behind-various-games В статье рассказывается о недорогих приёмах в разработке видеоигр, которые используются как в прошлом, так и сейчас. Например, в игре Halo для имитации размытия при быстром вращении колёс меняли текстуру шин на размытую, в Robo Recall тень от вентилятора создавали с помощью вращающегося полупрозрачного меша, а в Half-Life: Blue Shift использовали классический приём фальшивых отражений, размещая под стеклянной поверхностью копию комнаты. Также упоминается, что в демоверсии для мобильных устройств преломление воды в бассейне симулировали с помощью покачивания подводного бетона. Джо Уинтергрин, работавший над игрой Weird West от WolfEye Studios, поделился этими и другими инсайтами из закулисья разработки игр. #новости

Самая дорогая ошибка инженера — принять роль тимлида как повышение https://habr.com/ru/articles/992858/ Автор статьи утверждает, что переход инженера на позицию тимлида — это не повышение, а смена профессии, и навыки, которые сделали инженера успешным, могут помешать ему стать хорошим руководителем. Он предлагает семь вопросов, которые помогут понять, готов ли инженер к роли тимлида: готов ли перестать писать код, важно ли видеть результат работы сразу, любит ли он людей и готов ли работать с ними, готов ли к конфликтам, пугает ли неопределённость, хочет ли учиться убеждать людей, а также хочет ли он именно роль тимлида или просто зарплату выше. Автор также отмечает, что есть альтернатива карьерному треку тимлида — путь Individual Contributor, где инженер может развиваться как специалист без управленческих обязанностей. Классная статья. И я согласен с автором. В целом айти достаточно забавная среда, особенно с точки зрения возможностей и развития для программистов. Во-первых, мне всегда нравилось что ты копаешься в разных предметных областях. Будь то медицина, производства, бизнес процессы, стохастические процессы и так далее. Во-вторых, там очень много забавных профессий. Тимлид это один путь, а ультимативная ступень кстати к переходу в бизнес связанный с B2B продажей софта - это техникал сейл. Технопродажников в целом днём с огнём не сыщешь. Так что с базовой ступеньки "разработчик" можно идти в разные стороны. И забавно, что я не знал, что в РФ наконец-то появилась ветка инженера старше, чем сеньор помидор. На западе то давно можно идти не только по грейдам, но и по уровню позиции. И про это я знал. #новости

Туман в стеклянной призме https://www.reddit.com/r/Unity3D/comments/1qvomop/volumetric_glass_prism_fog_volume_with_realtime/ Mirza продолжает эксперементировать со стеклянной призмой. Выглядит классно. Я кстати понял, что в той статье про акрил упомянул, а ссылку на статью скинуть забыл. #новости

Туман в стеклянной призме https://www.reddit.com/r/Unity3D/comments/1qvomop/volumetric_glass_prism_fog_volume_with_realtime/ Mirza продолжает эксперементировать со стеклянной призмой. Выглядит классно. Я кстати понял, что в той статье про акрил упомянул, а ссылку на статью скинуть забыл. #новости

Прикольный шейдер воды https://github.com/MatrixRex/Uber-Stylized-Water Наткнулся на прикольный шейдер для URP на просторах интернетов. Uber Stylized Water — это шейдер для стилизованной воды в Unity 6. С его помощью можно создавать как полностью непрозрачную, так и прозрачную воду, добавлять пену на поверхности и под водой, анимировать береговую линию и многое другое. Выглядит прикольно, да и под MIT лицензией, что плюс. #интересное

Больше возможностей для роста мобильных игр с Xsolla Web Shop Подробнее Xsolla Web Shop — это готовое решение для прямых продаж внутриигрового контента игрокам через веб. Платформа позволяет запускать собственный магазин без сложной разработки и при этом обходиться без комиссий мобильных сторонов, перенаправляя сэкономленные средства на развитие проекта и маркетинг. Решение представляет собой целую экосистему, в которую уже включены веб-сайт, платежная инфраструктура, инструменты LiveOps и системы лояльности. Разработчики могут запускать эксклюзивные предложения, акции, реферальные программы и A/B‑тесты без необходимости писать код или настраивать сложные интеграции — достаточно активировать нужные инструменты. Xsolla также предоставляет поддержку команды экспертов, которые помогают оптимизировать работу вебшопа и улучшать его показатели. На сегодняшний день более 700 игровых проектов по всему миру используют Xsolla Web Shop как канал прямых продаж. Платформа ориентирована на быстрое внедрение, масштабируемость и снижение операционных затрат, что делает её практичным инструментом для роста мобильных игр. #новости

Глава Unity не видит в генераторе миров Genie 3 угрозы для индустрии https://dtf.ru/gameindustry/4759414-unity-ne-vidit-ugrozy-v-genie-3 29 января Google запустила бета-версию генератора интерактивных 3D-сцен Project Genie, что вызвало бурную реакцию в соцсетях: некоторые пользователи назвали инструмент «концом игровой индустрии». Однако руководитель Unity Мэттью Бромберг считает, что такие технологии могут позитивно повлиять на отрасль, поскольку расширяют возможности создания интерактивного контента. Он отмечает, что нынешние генераторы не обеспечивают нужного уровня погружения и не могут предоставить игрокам постоянный новый опыт. Бромберг уверен, что Unity сможет использовать инструмент для собственного развития и укрепления роли в разработке игр, а технология генерации виртуальных миров ускорит процесс разработки. При этом стоимость акций Unity, а также Take-Two, Roblox и Nintendo упала после презентации Genie 3. Что тут можно сказать. Надо посмотреть презентацию. В целом конечно же паника рынка и про конец индустрии можно говорить не зная как она устроена, так как какая разница что вы умеете генерировать миры. Это просто определенный сегмент. Ну будем посмотреть. #новости

Почему универ не готовит программистов https://habr.com/ru/articles/990892/ А должен? Типа программирование не наука, а ремесло на мой вкус. Учат специализированные курсы (здесь могла быть ваша реклама), а универ немного про другое. Автор считает, что университеты не готовят квалифицированных программистов, так как преподаватели часто не имеют опыта работы в реальных проектах, а учебная программа не учитывает современные требования индустрии и не даёт практических навыков. В то же время в игровой индустрии наблюдается дефицит квалифицированных разработчиков, способных работать с современными движками и решать сложные технические задачи. Автор утверждает, что программирование требует специфических способностей и определённого склада ума, а настоящие навыки приобретаются через самообучение, практику и наставничество, а не через традиционное университетское образование, которое скорее создаёт среду для общения единомышленников и обмена опытом. Но у университета нет задачи "сделать программистов для рынка труда". Университет помимо каких-то сопутствующих вещей учить фундаментальным понятиям, которые "не нужны" в классической работе, но развязывают руки тебе делать что угодно. Я вот окончил МЭИМ ВШЭ по направлению фундаментальной информатики. Программировать меня там не учили, но я знаю теорию графов, теорию информации, матан и многое другое. И я могу решать наукоёмкие задачи. Поэтому ко мне с ними периодически обращаются под заказ. В программировании учить не то чтобы много надо. Оно целиком про логику. Если вы учите паттерны не понимая для каких логических конструкций они нужны и целей, у меня для вас плохие новости. Вы можете знать наизусть реализацию адаптера, декоратора, фабрики и стратегии. Можете даже отскакивая от зубов умными словами рассказывать про композицию и смысл этих паттернов. Только понимать это другое. Понимание этих вещей понимается очень просто, вы можете объяснить вашу идею или мысль не через дебри заумных слов, а на салфетках, ежах или чем-либо угодно ещё. И все концепции в программировании на мой вкус достаточно понятные и логичные. А вуз (особенно с техническим направлением) учит логическому мышлению. А учить тому что такое DI, каким образом под капотом устроен словарь (с его логикой бакетов), что такое замыкание как мы обсуждали вуз и не может, и не должен. Парк языков, технологий и подобмного в программировании огромный. От курса по конкретному языку толку мало. И изучение программирования это путь практики и чтения документации. Достаточно написать один большой проект не пытаясь в чистый код, не используя MVC, MVP, MVVM и тому подобное и сразу станет ясно через боль, почему так делать не стоит. Я уже в разработке 10 лет, и до сих пор есть что нового узнать. Поэтому тут я согласен с автором, что разработка это путь самообучения. Но дело не в том, что знания и фреймворки меняются, не в том что программы вузов по разработке не могут быть актуальными, не в том что в вузах мало специалистов с глубоким коммерческим опытом. А в том что вузы учат фундаментальным понятиям, коих на самом деле в программировании очень мало. Программирование мне чем-то напоминает рисование. Ты просто постоянно оттачиваешь мастерство. #мысли

Шейдер стеклянной призмы https://www.reddit.com/r/Unity3D/comments/1qr44re/glass_prism_shader_with_backface_refraction/ Mirza Beig выложил классный шейдер с эффектом преломления и отражений на задней стенке. Выглядит кайфово. Вообще хитрые прозрачные материалы, симуляция огня и вода - это самое интересное. Я тоже как-то давно выкладывал акрил из подобного класса материалов. Помню когда у меня времени было побольше я хотел сделать проект с забавным названием UMOM (звучит прикольно на мой взгляд, а идея была выложить оптимизированные под мобилки и веб разричные материалы, потому что расшифровка Unity Mobile Opttimized Materials) Но потом меня как обычно завалило делами, И я остановился на акриле. Да и отклика какого-то акрил не получил. 6к просмотров, 6 плюсов 🙂 А я конечно же в публичном поле работаю за классы 🙂 #новости

Шейдер стеклянной призмы https://www.reddit.com/r/Unity3D/comments/1qr44re/glass_prism_shader_with_backface_refraction/ Mirza Beig выложил классный шейдер с эффектом преломления и отражений на задней стенке. Выглядит кайфово. Вообще хитрые прозрачные материалы, симуляция огня и вода - это самое интересное. Я тоже как-то давно выкладывал акрил из подобного класса материалов. Помню когда у меня времени было побольше я хотел сделать проект с забавным названием UMOM (звучит прикольно на мой взгляд, а идея была выложить оптимизированные под мобилки и веб разричные материалы, потому что расшифровка Unity Mobile Opttimized Materials) Но потом меня как обычно завалило делами, И я остановился на акриле. Да и отклика какого-то акрил не получил. 6к просмотров, 6 плюсов 🙂 А я конечно же в публичном поле работаю за классы 🙂 #новости

Способы приближённого моделирования не выпуклых столкновений в Unity https://80.lv/articles/learn-how-to-get-non-convex-collisions-on-dynamic-objects-in-unity Johann Hotzel, инженер-программист, рассказывает о проблеме работы с не выпуклыми столкновениями в Unity. В системе физики Unity динамические MeshColliders должны быть выпуклыми, что создаёт проблемы при работе с мягкими телами: при деформации мешей они часто становятся невыпуклыми, и приближение выпуклой оболочки в Unity перестаёт работать. Это приводит к некорректному поведению столкновений. В статье описаны три метода приближённого моделирования столкновений: Poisson Disc Collider — метод поверхностного приближения, который распределяет точки по поверхности меша и создаёт SphereCollider для каждой точки. Подходит для органических или нерегулярных мешей, деформирующейся геометрии. Voxel Collider — приближает весь внутренний объём меша, используя воксельную сетку и создавая BoxCollider для каждого вокселя внутри меша. Подходит для твёрдых объектов и сценариев, где важна стабильность. Decomposition Collider — делит исходный меш на пространственные области с помощью воксельной сетки и преобразует пересекающиеся треугольники в отдельные выпуклые MeshCollider. Подходит для больших или детализированных мешей, где требуется более высокая геометрическая точность. Каждый из методов имеет свои преимущества и ограничения, но вместе они покрывают широкий спектр практических случаев использования. Проект открыт для сообщества и продолжает совершенствоваться на основе обратной связи от пользователей. #новости

Основы работы с памятью GPU: ключевые концепции и примеры https://github.com/cverrier/tinygrad-tutos/blob/main/tutos/gpu_memory.md В руководстве рассматриваются основы работы с памятью графических процессоров (GPU), включая три этапа вычислений (чтение данных из VRAM, обработка данных и запись результатов обратно в память), архитектуру GPU (VRAM, вычислительные блоки, интерфейс памяти), понятия скорости памяти, пропускной способности и ширины интерфейса, а также различия между операциями, ограниченными памятью (memory-bound) и вычислительными ресурсами (compute-bound). Объясняется концепция арифметической интенсивности, которая помогает определить тип ограничения для конкретной операции. В общем любопытно и полезно почитать. #новости

Стоит ли учить Unity в 2026 году? Увидел такую статью на хабре случайно. Сама статья это что-то копирайтерски-нейросетевое, и по сути реклама, судя по блогу в котором размещена. А давайте я скажу со своей колокольни ответ на этот вопрос. Как инструмент разбирать нет смысла, это неинтересная вещь. Unity и UE два главных кита игровой разработки. И ответ на вопрос звучит так. Вы хотите заниматься играми? Берите любой движок не ошибетесь. На Unity чуть больше работы, чем на Unreal'e, но на самом деле это не так важно. Разницу вы поймете с годами, и когда скорее поймете как устроен бизнес, нежели какие-то секретные нюансы каждого движка. У меня есть статья сравнение движков довольно простая, можете пролистать. А как же годот? Пикси, кокос, бебилон, трижс и продолжаем до бесконечности называя весь парк движков. Ну я предпочитаю думать что люди любят есть, при этом желательно вкусно есть. И поэтому анализирую со второй точки зрения. А найдете ли вы работу? Вот допустим даже вы энтузиаст который решил сделать игру своей мечты. И так бывает - не полетела. Вы потратили время, может быть деньги. Это нормально, этого не надо бояться, этим занимаются все предприниматели (и в среднем успешные бизнесмены). Но пока вы это делали вы получили навык, а он на рынке стоит - ничего. Поэтому их можно не рассматривать. В целом самый простой поверхностный анализ стоит ли учить технологию. Идём на площадку с вакансиями, ищем вакансии по технологиям. Узнаем что на Unity3d находит 163 вакансии, на Unreal Engine 63, а на Godot 0. Забиваем на Godot. Так как если кушать захочется, полезно обладать востребованными навыками. А стоит ли вообще делать игры? И тут ответ на вопрос у каждого свой. Мой ответ. По любви - да, ради денег - нет. И обратимся опять таки к вакансиям. И выясним, что вне геймдева зарплаты на 20-30% выше, и чисто ради денег в целом можно всё ещё учить Java. Потому что там 500+ вакансий в Москве и многие с хорошими зарплатами. У меня из-за этого долгая моральная дилемма с курсами и их созданием. Не хотелось бы никого учить тому, что потом не имеет ценности на рынке. Хотя на самом деле давно уже пора на это забить, так как все сами решат и придумать, как курс произвести собственно. Чем то поделиться у меня навалом? Да какая работа? Я сделаю свой крузис! (кто не понял отсылку, может подставить свою GTA). И тут мы возвращаемся к цифрам (кстати 100 огоньков уже набрали, так что следующий пост не за горами). И узнаем что в 4% случав вы заработаете деньги, которые вы почувствуете. Либо же вам нужен консультант, типа меня, который в случае провального продукта знает, а как из него ещё можно извлечь выгоду (b2b лицензирование и тому подобное) чтобы хоть на сухари отбиться (с готовым продуктом можно работать в разных форматах). Но так как у меня ценник высокий по меркам РФ, то моими консультациями чаще всего пользуются только технологическими, да и в основном корпорации по разным видам трекинга. А делать игру мечты дорого. Не один энтузиаст костьми лег на эту задачу, не один миллион долларов закопан в такие проекты. Поэтому если вы ещё не в играх, идти туда стоит только по любви. Потому что все остальные перспективы там смотрятся не так радужно. А если вы уже в нашей веселой лодке. Пристегивайтесь, мы скоро полетим, пока я их отговариваю. На сухари заработаем 100%. Ладно шучу, просто держитесь там. Плюс игровой индустрии, по крайней мере старого формата, что это был довольно дружный рынок. Где друг другу готовы помогать, так что вместе как-то выкрутимся. Хотя я не в истинном геймдеве, а в продаже игровиков корпорациям по сути. Но тут тоже последние годы довольно весело. #мысли

Ландшафт частиц на Shader Graph https://www.reddit.com/r/Unity3D/comments/1qiyta0/animated_particle_terrain_shader_graph/ Классный и красивый эффект. Но лично для меня частая проблема что такие эффекты классно смотрятся в паре с Bloom в реалтайме и так далее, поэтому это требует настройки построцессинга. А постобработка часто для того же веба или AR веба жрет слишком много ресурсов. Но для того же десктопа — кайф, и не сложно. #новости

Steam уточнил правила использования ИИ в видеоиграх https://80.lv/articles/steam-has-clarified-its-rules-on-the-use-of-ai-in-video-games В конце 2025 года активно обсуждался вопрос о том, должны ли онлайн-магазины видеоигр требовать от разработчиков раскрывать информацию об использовании генеративного искусственного интеллекта (ИИ) в своих играх. Хотя Тим Суини утверждал, что такое раскрытие информации не имеет смысла, именно Steam, а не Epic Games Store, оказался в центре дискуссии из-за уже существующего (но слабо исполняемого) требования о раскрытии информации об ИИ. В ответ на споры Steam обновил форму, которую разработчики должны заполнять при публикации игр, уточнив, что она относится только к контенту, с которым взаимодействуют игроки (например, к искусству, аудио, локализации, нарративу), и не требует раскрытия информации об использовании ИИ-инструментов исключительно в процессе разработки. Короче говоря контент который доходит до пользователей надо маркировать, а внутренние инструменты студии, которые не производят контент для пользователей - не надо. #новости

И немного примеров по замыканию для понимания Завершим тему замыкания полностью примерами. 1. Лямбда использует только свои параметры и локальные переменные внутри себя Func<int, int> inc = x => x + 1; Console.WriteLine(inc(10)); // 11 Console.WriteLine(inc.Target); // null (обычно), т.к. нечего захватывать Почему нет замыкания: нет ссылок на переменные “снаружи”; всё, что нужно, приходит через параметр x. 2. Лямбда обращается только к static членам Func<int, int> f = x => Math.Abs(x); Console.WriteLine(f(-5)); // 5 Console.WriteLine(f.Target); // null (обычно) Почему нет замыкания: Math.Abs — статический метод, ему не нужен объект/окружение. 3. Используется const (константа), а не переменная const int k = 10; Func<int, int> add = x => x + k; Console.WriteLine(add(5)); // 15 Console.WriteLine(add.Target); // null (обычно) Почему нет замыкания: const — не “переменная”, это значение, которое компилятор подставляет напрямую. Захватывать нечего. 4. Method group на статический метод static int Square(int x) => x * x; Func<int, int> sq = Square; Console.WriteLine(sq(4)); // 16 Console.WriteLine(sq.Target); // null Почему нет замыкания: делегат просто указывает на статический метод, окружение не нужно. 5. static-лямбда (C# 9+) — гарантирует отсутствие захват Func<int, int> ok = static x => x + 1; // захват запрещён int y = 10; // Func<int, int> bad = static x => x + y; // ошибка компиляции: нельзя захватить y Почему нет замыкания: ключевое слово static у лямбды запрещает захват внешних переменных и this. Если “захватить” всё же пытаешься — код не компилируется. Наберем 50 🔥️️ могу сделать подборку примеров где замыкание часто появляются и составить пост с задачками и ответом под спойлером, чтобы вы могли себя проверить. #интересное

Давайте подробнее поговорим про замыкание И начнем мы с определения. Что такое замыкание? Замыкание (closure) в C# — это ситуация, когда лямбда-выражение или анонимный метод использует переменные из внешней области видимости, и компилятор обеспечивает, чтобы эти переменные продолжали существовать (и оставались общими для всех таких лямбд), даже если внешний метод уже завершил работу. И сразу же думает про боксинг в этом случае. Но классический пример замыкания самый простой будет выглядеть как-то так: static Func<int> MakeCounter() { int x = 0; // захваченная локальная переменная return () => ++x; // замыкание: лямбда использует x из внешней области } static void Main() { var counter = MakeCounter(); Console.WriteLine(counter()); // 1 Console.WriteLine(counter()); // 2 Console.WriteLine(counter()); // 3 } Почему это так работает? Потому что при таком использовании казалось бы странном, создается объект закмыкания, и разворачивается как-то так (грубо говоря): // Скрытый класс замыкания (display class) private sealed class DisplayClass { public int x; // сюда переезжает захваченная локальная переменная public int Lambda() { return ++x; // тело лямбды } } static Func<int> MakeCounter() { var closure = new DisplayClass(); closure.x = 0; // Делегат хранит ссылку на closure (Target) и на метод closure.Lambda return new Func<int>(closure.Lambda); } static void Main() { var counter = MakeCounter(); Console.WriteLine(counter()); // 1 Console.WriteLine(counter()); // 2 } и вот тут у нас value-type, local scope и всем всё привычно. Да, замыкание, знаем проходили. А для понимания примера из прошлого поста нужно внимательно прочитать определение и осознать фразу "использует переменные из внешней области видимости, и компилятор обеспечивает, чтобы эти переменные продолжали существовать". Потому что в том примере это по сути превращается в this.name. Но мы же не можем гарантировать в лямбде, что объект родитель этого name продолжает существовать? Можем, замыканием. Потому что это создаст скрытый объект замыкания со ссылкой на объект родитель этого поля. О чем и говорится в видео. И я обратил внимание на это, так как в этом плавают прям очень многие. Замыкание - это не про боксинг. Замкание это гарантия того, что то, что находится в лямбде или анонимной функции на момент обращения к нему будет сущестовать (в рамках механизмов .Net). Ибо это вам не плюсы, которые позволят вам выстрелить себе в ногу, сделают Undefained Behavior и без логов ищите где-то происходит пару недель. .Net позволяет разработчику "ошибаться", но берет плату обычно памятью. А то что чаще всего во всех мануалах говорится про стек и о том, что там с value-type и локальными переменнами, это из-за непонимания сути работы этого механизма. Там даже не боксинг происходит в общем смысле на самом деле. Так как боксинг это обычно запаковка в класс object. А тут создается именно объект замыкания. Поэтому выделяется память, но это по своей сути не боксинг. #интересное

Делегаты, события и замыкания https://www.youtube.com/watch?v=za91AjX-V7M Неплохое видео про делегаты. Единственно что важно воспринимать именно так как объяснил автор в двух словах с замыканиями (так как мне знакомый задал вопрос). Конкретно этот пример: // Mistake #2: Capturing This Implicitly void SetupTemporaryCallback() { // This lambda implicitly captures `this` Action callback = () => Debug.Log($"Enemy name: {name}"); callback?.Invoke(); } Мне задали вопрос по формулировке автора, а что тут создается целиком копия объекта? Нет, созадется "объект замыкания" (он довольно небольшой) со ссылкой на исходный объект. И в этом создается две проблемы: 1) Вызывать часто = куча мелких аллокаций 2) Не совсем очевидно когда объект можно будет собрать сборщиком мусора, он дольше задержится в памяти, потенциальный мемори лик. А так видео хорошее, и инверсию управления затронули и так далее. Я бы ещё сказал, что сейчас ключевым словом delegate почти не пользуются. Как и анонимными делегатами. С появлением generic-делегатов, а точнее Action<T> и Func<T> в .Net 3.5 что ли. Это банально удобнее, да и статическую таблицу типов не засоряем лишними типами, хотя это не так важно. UnityEvent и UnityAction - те же generic-делегаты, только связанные с системой сериализации Unity. #новости