Решение «Проектируем гриды»

Мне не нравится, как выглядят огромные спойлеры. Поэтому если хотите подумать сами, сначала сами и не видели задачку — не читайте дальше. А теперь к решению.

Сразу скажу. Тут нет «единственного верного решения». Если решение обосновано и чётко, то вероятно и оно окей. Но я хочу поговорить с точки зрения моей идеологии в таких случаях.

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

Почему это две не связанные системы? Потому что это разные сущности и разные домены. Не должно из-за изменений логики игры ломаться поведение интерфейсов. Это должны быть две независимые системы, чтобы изменения влияли только на этот домен. И даже в Unity это сделано так. Но пойдём по порядку.

Вариант 1. Общий класс. Самое опасное решение ведущее к проблемам в разработке и костылям, можно сразу откинуть. Этот вариант не особо рабочий. Так можно сделать если вам нужно написать за 5 минут, сдать и забыть. Но в среднем — это худшее решение.

Вариант 2. И вариант 4. Общий базовый класс и наследование. Чуть лучше, но тоже вызывает вопросы, а зачем вам такая абстракция. С общим базовым классом в том, что вынесено в него ведёт к рискам обозначенным выше. Вы правите какой-то баг грида в гуе, вы его исправили, и у вас вылезла проблема в игре. Такого происходить не должно. Общий интерфейс. А для чего? Какой контекст применения и использования такого интерфейса? Вы когда-то будете его юзать в рантайме? Я не вижу особой проблемы в композиции. Но при развитии системы могут появится сложные системы интерфейсов или компромиссы нарушающие солид (второе просто ошибка). То есть не реализованные методы интерфейса в одной из частей. Это усложнение системы, да убирающее дублирование, но не дающее никакой супер функиональности. Это не та система, где сложные алгоритмами и спустя год вы будете менять в двух местах реализацию, что гемморой. Если появятся разные виды гридов в рамках одного домена, я бы пошёл по пути интерфейса. А в разных я бы делал так.

Я бы делал так же, как и сделали юнити. Так как в юнити у вас есть и грид для 2д игр, и грид лейаут груп. И они никак не связаны. Это даёт нам разрабатывать системы с «похожим поведением» из разных доменов независимыми. Не сидеть и думать и долго проектировать «какая тут правильная композиция». А просто писать две разные системы, потому что они находятся в разных доменах приложения. И удобнее их разрабатывать независимо. Там нет каких-то сложных алгоритмов, которые нужно обобщать. Но если и выносить именно алгоритмы, то в отдельный статик класс, который будет в домене части системы, которая отвечает за алгоритмы. Типа для примера ту же сортировку вы не будете писать каждый раз. У вас будет генерик реализация самого алгоритма.

#задачка

Какие есть проблемы у корутин и где лучше использовать таски/асинки?

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

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

Если описывать асинхронность на пальцах. Представьте что у вас есть переменная A и функция B. Переменная A — это состояние функции B. И в рамках выполнения вашей программы мы не исполняем функцию B до конца, а получив в ней какое-то значение состояния A ставим её "на паузу" и идём выполнять другую функцию.

Что корутина-юнити, что таски — это два механизма асинхронного программирования. Только таски в отличии от корутин-юнити могут быть асинхронными многопоточными (посредством ThreadPool), а корутины-юнити — только однопоточными (исполняются только в MainThread). Что такое в общем корутина, а не Unity-корутина — это прям надолго.

А отвечая на вопрос. У корутин вообще нет "проблем. У них есть принцип работы. И корутины юнити чаще всего удобнее во всём связанным с Unity Event Loop, чем таски. Таски не работают в WebGL, но есть удобное и среднее решение — это UniTask. Вполне себе хорошая либа для использования async/await и т.п. без гемора с Unity методами. Это просто немного разные механизмы в которых скорее важно понимать принцип их работы.

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

#вопросы

Туториал VFX удара когтями
https://www.youtube.com/watch?v=3gnm4eAIcc0

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

#интересное

Асинхронность VS Многопоточность VS Параллелизм
https://habr.com/ru/post/337528/

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

#интересное

Путь в фриланс игрового разработчика — Постоянные Заказчики

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

Нормальный заказчик не говорит. "Мы сейчас сделаем за 100 рублей, а потом будет и 1000 рублей." (если работа стоит 1000 рублей). Не оперирует будущими золотыми горами и т.п. Вообще всё хорошее и качественное определяется очень просто — по аналитике. У меня был забавный случай когда меня кинули. Это было с 3д, называть имён я не буду, так как не люблю в целом "публичные скандалы". Поэтому расскажу ситуацию.

У меня был 3д моделер. Прикольно делал. Умел ещё и ригать, и анимировать. Не так, как мои аниматоры профессиональные из крупных студий, но на проекты с бюджетом средним — попрёт. Я за квартал на фрилансе человеку принёс заказов на три зарплаты сеньор моделера в Мск при том, что он не из Мск (я никогда в целом не делаю поправку на регион. Мне нужен результат за деньги, исходя из имеющегося бюджета). Начался крупный проект в сжатые сроки. Я наехал на человека (в чём я не прав, можно было быть помягче) за то, что у моделей кривой скейл, которые он прислал. И он психанул, удалился из чатов и исчез. Фиг с ней со сгоревшей предоплатой. Проект сдавать через неделю, а у меня нет моделера. А модели самый внушительный набор работ в том проекте. Это гемор побольше чем потерянные деньги (хотя бюджет очевидно сократился, но это уже мой головняк, а не заказчика. Так как косяк мой — значит я его молча решаю). Я быстро нашёл нового человека и переключил задачу на него, и мы уложились. Конечно пришлось сильно поморочится чтобы это провернуть, даже с моим опытом продюсера. Но вот так делать нельзя.

Особенно, что логично, когда клиент тебе приносит большую долю выручки. То и в бизнесе ты идёшь на уступки и поблажки. И когда клиенты постоянные надо идти на уступки чуть чаще, поддерживать, помогать и так далее.

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

Правда тут мне хочется сделать и ремарочку для заказчиков. Никогда не нужно думать что фрилансер вам жизнь свою должен за то что вы заплатили ему 20 000 рублей. Чтобы рассчитывать на бонусы и иметь их возможность получать сначала нужно стать постоянным клиентом с которым хочется работать. Если вы работаете в первый раз, то обе стороны смотрят на то, как идёт работа и принимают решение о дальнейшем сотрудничестве.

#фриланс

OpenCV + Stable Diffusion
https://youtu.be/ISr_gTkO42M

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

#новости

Клиент всегда прав

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

Клиент всегда прав — это абсолютно неверное утверждение. Вернёмся к истории. А как оно вообще появилась эта фраза? Впервые её употребил Гарри Селфридж в качестве слогана. Ещё в 1909 году. И вообще не предполагалось, что кто-то будет воспринимать эту фразу буквально. Это по сути слоган показывающий, что клиент всегда на первом месте и так называемый customer-first подход. Но не означало буквально правоту клиента.

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

Почему клиент почти всегда не прав?

Чаще всего он:
- не разбирается в том, что вы делаете на уровне эксперта
- не интересуется из чего складывается цена и почему что-то стоит столько
- не умеет правильно оценивать и принимать результат

Особенно это касается контента. Мне всегда жалко контентщиков, которым говорят "говно" клиенты, которые не умеют принимать результаты творческой работы и творческого процесса. Фидбек говно плох тем, что с ним ничего не сделаешь. Он не даёт направления. И так далее.

Но как я обозначал в посте ранее, почему эта концепция — это путь в ад?
По сути это означает, что вы не хотите вести переговоры и любой конфликтный клиент будет этим пользоваться. Вы зря гоняете своих исполнителей (а качественные исполнители долго этого терпеть не будут), и вы теряете контроль. В работе есть такое понятие, которое я вывел когда-то давно.

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

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

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

Поэтому концепция "клиент всегда прав" — это очень опасная практика. Лучше вести здоровые переговоры, обсуждать условия и идти к взаимовыгодному сотрудничеству. А если это не получается и не работает, то возможно это и не ваш клиент. И нужно просто идти дальше на поиски тех, с кем вам будет комфортно и приятно работать.

#бизнес

Press F for MRTK
https://www.tomshardware.com/news/microsoft-firings-indicate-abandoned-xr-ambitions

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

#новости

Мне очень понравилась Ваша задачка про архитектуру для оружия! В геймдеве есть отдельная профессия, в которой человек занимается решением подобных задач, или это побочный навык, нужный всем разработчикам? Если отдельная профессия, то как в неё попасть?

Продолжим отвечать на вопросы. Напоминаю, что задавать их можно вот тут. В геймдеве не уверен что в РФ встречал процесс в студии с архитектором. Может тут есть кто из пиксоника или мейла, чтобы подсказать есть ли там сейчас такое. Я архитектуру пишу под заказ в рамках консультаций периодически для проектов. Просто это стоит уже дорого, так как на один такой документ уходит 1-2 неделя работы. А у меня час довольно дорогой.

В энтерпрайсе — это обычно есть. Особенно в крупном айти. Там есть отдельно архитектор, который занимается конкретно за тем, что следит за архитектурой проекта. А так это важный навык каждого разработчика. Конечно в крупных компаниях может быть выделенный архитектор, но даже в таком случае он думает больше над доменами и их взаимодействиями, не всегда спускаясь на уровень "а как реализовывать конкретный сервис". Поэтому разработчик уровня Senior+ должен разбираться в паттернах, в архитектуре и тому подобном. Поэтому можно считать её побочным навыком. Ну и да, на тему как попасть, думаю архитектором даже по навыкам нельзя стать не позанимавшись долгое время разработкой. Чтобы понимать зачем это всё вообще делается и строится. Ну в архитекторов обычно вырастают из разрабов. Это один из двух условных классических треков развития карьеры: менеджерского и технического. Это ветка технического развития.

#вопросы

7 кругов ада инди разработки
https://habr.com/ru/post/712398/

Прикольная статья про «путь инди». Вспоминаются времена, когда я был инди разрабом пишущим головоломку про вампира, и не прошёл ряд барьеров так и не дойдя до релиза. Но было прикольно и был довольно полезный опыт по навыку сбора команды и общения с людьми :)

#новости

Эффективные менеджеры…
https://www.noob-club.ru/index.php?topic=81993.0

Или про натягивание совы на глобус дальше. Математика хороша, когда ей пользуется профессионал, а не гадалка. Я не понимаю зачем распределение Гаусса применять и насильно навязывать в "управлении персоналом". Сейчас в целом идёт волна сокращений. Но привязывание к зарплате плохих оценок и т.п. и при этом выставление оценок по какой-то кривой, потому что можно много где встретить это распределение. Это бред. Вообще все системы KPI выглядят достаточно забавно, так как за частую они привязаны непонятно зачем и непонятно к каким результатам. Но это уровень.

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

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

Часть такого можно оправдать "стоимостью ошибки". Так как для корпорации ошибка — это миллионы или сотни миллионов. А для небольшой компании "забыли и поехали дальше". Но активижн близзард по-моему из негативного инфополя уже три года не вылезает со своими эффективными техниками управления.

#новости

Деформация изображений в Shader Graph
https://youtu.be/tWCyfqjl1ek

Интересный обзор нод в шейдер графе для деформации текстур и разбор по сути базовой техники uv-сдвига.

#интересное

Редактирование изображения ИИ
https://80.lv/articles/instructpix2pix-editing-images-based-on-text-prompts/

Этот год явно будет годом искусственного интеллекта. Конечно ИИ давно с нами, но такого хайпа не было. Увидел в новостях прикольную тулзу, которая позволяет редактировать изображение с помощью текста. Выглядит прикольно.

#новости

В игровой разработке можно заниматься консультациями? Сколько на этом можно зарабатывать?

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

Во многих понятиях я можно сказать разбираюсь не супер глубоко или поверхностно. Например в игровом ИИ — их я за карьеру почти не писал. (поэтому я про него и не пишу) Или в ECS. Я его не юзаю, так что что мне про него говорить.

Но с другой стороны я с 2016 года занимаюсь технологиями трекинга. Я работал с большей частью оптики (Vicon, Optitrack), с магнитным трекингом, с радиоэлектронным, с ультразвуковым. Писал под заказ технологии на OpenCV и т.п. технологиям. От банальных классификаторов до задач аля трекинга зрачков, где я узнал что такое саккады (прикольная штука кстати). Занимался VR/AR разработкой, когда игрушки были деревянными, и не было удобных сдк. Ну и работал наверное со всеми AR/VR устройствами, разве что кроме Magic Leap (просто руки не дошли). Помимо этого разбираюсь в рендере под это всё дело, ну и в общем в Unity, в оптимизациях, в сложной математике. Например по математике я писал под заказ алгоритмы укладки трёхмерных графов, разрабатывал различные математические модели для разных задач. В общем есть определённый спектр разных тем опосредованно связанных с Unity, по которым я консультировал, да и консультирую до сих пор. Просто так сложилось что с 2016 года у меня проекты с самыми модными игрушками и технологиями. Были проекты с распознаванием голоса, с генерацией голоса, с распознаванием автомобильных номеров и тому подобном. Мой любимый из старичков такого плана генерация датасетов с помощью Unity для распознавания лего. И он даже без NDA.

А про заработок на консультациях. Ну если это кому-то интересно, то я не особо скрываю расценки. Общее описание звучит как-то так.

Установочный созвон — бесплатно.
Анализ проекта (верхнеуровневый) — бесплатно.
Анализ кода и архитектуры проекта — от 50к рублей.

Созвон/Встреча — 10к рублей/час
Но есть но, я работаю с пакетами от 3 часов. Предоплата 100%. Использовать их можно как угодно. Время больше 40 минут округляется до часа. Созвон минимум час.

Код, исследования, отчёты и документы — по договорённости.

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

#вопросы

Ещё одна успешная VR игра
https://www.gamedeveloper.com/business/-i-among-us-vr-i-hits-1-million-copies-sold

Among Us VR продалась 1 миллионом копий. Один из немногих успехов VR платформ за последнее время. Уверен, что на платформе всё ещё доминация битсейбера. Но новые миллионники — это всегда хорошо. Пусть и на раскрученный бренд.

#новости

Dependency Injection

Один из двух знаменитых DI. Не путать с Dependency Inversion из SOLID.

Dependency Injection (или внедрение зависимостей) — это подход к проектировке классов, в котором зависимости объекту даются внешней сущностью.

Многие по неизвестной мне причине связывают всё в куче, и что DI без Composition Root или DI Containers не существует. Хотя изначально это вообще про другое и другие проблемы решает. Тут проще привести несколько примеров кода.

Примеры нарушения DI:

public class Foo
{
private Bar _Bar = new Bar();
}

public class Foo
{
private Bar _Bar = Bar.Instance;
}

Примеры кода по DI:

public class Foo
{
private IBar _bar;

public Foo(IBar bar)
{
_bar = bar;
}
}

public class Foo : MonoBehaviour
{
[SerializeField] private AbstractBar _bar;
}

Тут может возникнуть у кого-то короткое замыкание. Как это [SerializeField] DI? А где Zenject? DI — это вообще концепция проверяемая и соблюдаемая в рамках класса. Это просто внешнее внедрение зависимости. Абстрактный класс и сериализованное поле позволяет нам сделать такое внешнее внедрение. Позволяет подсунуть туда мок объект, написать юнит тест и так далее. Просто у нас в качестве места, где мы внедряем наши зависимости используются конфиги (префабы) и это опять-так не code-first подход, а config-first.

Неудобство в Unity вводить DI через [SerializeField] в том, что юнити не умеет в SerializeField с интерфейсами и так получится только с абстрактными классами. И у этого есть логика, так как интерфейс нельзя сериализовать. Хотя к этой концепции у меня есть вопросы. Так как если есть конкретный инстанс объекта и конкретная реализация на уровне сборки или на уровне рантайма, которая испоьзуется в качестве имплементации интерфейса, то в чём проблема её сериализовать?

В целом ничто не мешает написать свой Composition Root или Dependency Injection Container, но есть удобные и готовые типа того же Zenject.

#термин

У меня нет портфолио. Что делать?

Продолжим небольшие стори из бизнеса. Это кстати относится и к фрилансу. Вы решили сделать аутсорс студию. Но у вас вообще нет примеров работ (вы же только начали). Что делать?

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

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

https://foxsys.pro/beringia-concept
https://foxsys.pro/jagex-concept
https://www.youtube.com/watch?v=4PVpuwRGhLY

На них было одно ограничение. Одни должны быть сделаны максимум в неделю. Цена такого процесса была условные 10-20к рублей на концепт, что со средним чеком проекта 600-700к не так много. И в итоге большая часть концептов на долгое время стала по сути портфолио. Поэтому если нет портфолио и кейсов, то можно их создать.

Вторая часть это подход к оформлению проектов. В последствии это слишком геморно и надолго такой процесс, на мой взгляд, делать не стоит. Можно оформлять каждый проект очень заморочено.

https://foxsys.pro/beringia-game

Это тоже отлично заменяет огромное число проектов и показывает экспертизу в начале. Потом из-за сложности в оформлении такого часть проектов просто не оформляются (у нас порядка 4-5 не оформленных в портфолио проектов). Поэтому мы переходим уже к типовому оформлению проектов + шоурилу. Это удобнее и быстрее, хотя и выглядит менее эффектно. Но сейчас в моём новом формате работы так удобнее + уже есть чем похвастаться при желании.

#бизнес

Идеальное объяснение дивана/стула с одеждой дома — найдено

Имя попроще

Так как dyadichenkoga сложно и долго пишется, то я решил себе купить более благозвучное имя в телеграм https://news.1rj.ru/str/dev_game

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

Эхх, а может тряхнуть стариной?

Хочется с кем-то вживую пообщаться, чёт интересное послушать и может стоит взять да тряхнуть стариной. Ведь когда-то я организовывал Unity Moscow Meetup и CGDevs Meetup. И снова организовать какую-нить встречу про разработку. В целом логотипчики, название и т.п. лежат в нужной папочке. Сайт собрать тоже не трудно. Маленький бесплатный митапчик с полезной инфой. Ну вот пару примеров, как это было "из сохранившегося".

https://www.youtube.com/watch?v=Ns1acAZ8PDU

Можно было бы обсудить что-то про Unity, что-то про графику, что-то про разработку. Конечно думаю в Москве сейчас народ сложнее собрать, но может получится организовать трансляцию или запись. Как думаете, стоит что-то такое сделать? 🔥 — да, 👎 — нет, ну как обычно :)

Стена ветра Yasuo
https://www.youtube.com/watch?v=TJdtV8ZaDSM

Gabriel Aguiar продолжает делать туториалы со скиллами из LoL. Выглядит прикольно, правда мне не до конца понятно зачем тут VFX граф.

#новости