Термин недели

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

1. Обсудить в комментариях
2. Кто-то для себя узнать и понять

Но мне интересно ваше мнение. Так что поставьте:
🔥 — если это интересно
👎 — если нет

Если наберём штук 50, то введу новый хештег и буду подбирать термины в переводе от меня со ссылками на источники. Сегодня я пол дня провёл в архитектурных обсуждениях в чате по архитектуре. Так что возьмём довольно полезный термин из этого обсуждения. При этом довольно базовый — модель в MVC, MVVM и т.п.

Модель — представляет из себя набор классов, которые представляют данные приложения. Но в архитектурных схемах MVC и MVVM чаще всего имеется ввиду более сложное понятие под названием доменная модель.
Доменная модель — представляет из себя поведение, бизнес-логику и данные в рамках приложения (или его определённого домена).

Пример:
У вас есть класс Auction, который представляет из себя логическую единицу аукциона в приложении. У него могут быть поля Title и CurrentBid, а так же метод Bid с описанной бизнес логикой ставки. И всё это будет моделью.

Источники:
Programming ASP.NET MVC 4 @ Jess Chadwick, Todd Snyder, and Hrusikesh Panda
https://learn.microsoft.com/en-us/xamarin/xamarin-forms/enterprise-application-patterns/mvvm

#термин

Анимация ударов One Punch Man в Unity
https://80.lv/articles/one-punch-man-s-punch-barrage-animation-set-up-in-unity/

Классно сделанный VFX анимации ударов из аниме ван панч мен. Да и само аниме прикольное. Такая классная сатира на супергероику.

#новости

Путь в фриланс игрового разработчика — Биржи

Вот и подобрались к самому интересному и самому сложному. Где привлекать клиентов? Я разобью это на несколько постов, так как тут тоже много информации.

Фриланс биржи — один из источников клиентов. Есть много фриланс бирж. Приведу несколько ссылок тех, где я сидел и сижу.
https://www.fl.ru/
https://freelance.habr.com/
https://workspace.ru/freelance/

Тут есть две задачи. Оформление профиля и отслеживание заказов.

Профиль должен быть хорошо оформлен. Вы должны описать свой опыт, свои экспертизы. Если есть что положить в портфолио, то лучше положить в портфолио. Как пример. https://freelance.habr.com/freelancers/Nox7atra И по этому описанию я не работал на самой бирже. Но меня находили заказчики и писали мне в ТГ. В идеале у вас должны быть указаны все возможные формы связи которые вам комфортны. Телеграм, ватсап, почта и т.п. И их должно быть легко найти. Я допустим иногда не могу работать с ребятами с artstation того же, так как у них в профиле нет контактов.

Второе это отслеживание заказов и отклики. Вообще когда вам пишут по заказу, когда вы откликаетесь на заказ. Чем быстрее вы ответите, тем выше шанс что заказ будет ваш. Это абсолютно логично, но многие будто про это забывают. И тут минутка саморекламы, но я правда слежу за заказами с помощью своего бота http://hermesbot.ru/ Дело в том, что у фриланс бирж часто есть фильтруемые rss ленты (ток у хабр фриланса нет, но скоро появится в боте возможность подключать вк, а там публикуются заказы с хабр фриланса) И подписка на:

https://workspace.ru/tenders/rss/
https://www.fl.ru/rss/all.xml?category=16

Позволяет видеть новые заказы сразу и откликаться бысрее. Я не настроил целиком ленту с другими биржами (так как даже на апворк есть rss), но я уже и не особо сижу на биржах. У меня другие каналы привлечения, о которых будет в следующих постах.

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

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

#фриланс

Пока вам не сказали нет — это не нет

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

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

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

И вторая важная часть. Вам отказали, что делать дальше? Вот мне в примере выше отказали грубо. Я уже частично объяснил что я сделал. Но подумайте, как поступили бы вы и самое важное, что вы ответите. А потом читайте дальше. Подумали? Так вот, мой ответ был лаконичен и прост. С учётом меточки я ответил человеку. "Спасибо. Жаль, что так получилось. Может в будущем ещё поработаем. Остаёмся в любом случае на связи". И убрал проект из CRM. Нет получен, отказ отработан, я молодец. Грубить в ответ, огрызваться, обвинять заказчика ни в коем случае нельзя. Однажды мне предъявил исполнитель, что "вообще-то вы должны были написать, что мы не будем работать" и послал меня. И он в чёрном списке. У клиента который работает с хорошими заказами и бюджетами. Его выбор. Но лично я никому и ничего не должен. Я просто делаю свою работу. Поэтому, так сказать, в идеале от вас всегда должно быть в таких случаях "позитивное послевкусие".

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

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

Так как разбило на два поста уточню — огоньки на посте с хештегами :) Ужас скок я текста настрочил :)

#бизнес #фриланс

Молния от Cyanilux
https://twitter.com/Cyanilux/status/1616426730033397766

На красивый VFX всегда приятно смотреть. Вот и подъехал новый. Классная такая молния.

#новости

Самый важный вопрос — «зачем?»

Я считаю, что одним из самых важных навыков в жизни умение вовремя задать себе вопрос: «Зачем?»

Все люди некоторые вещи делают вообще без осознания причины или чего они хотят добиться. В посте про фриланс был пример грубости заказчику. Хотя если перед ответом задать себе вопрос: «Зачем я это пишу?» То проблемы бы и не было. Так как если поставить задачей «переписываюсь с заказчиками чтобы зарабатывать деньги» то ответ сам по себе отвалится.

И так во всём. Как подход из поста выше подходит к общению с инвестором, издателем игры, платформой, партнёрами по рекламе. Так и вопрос «зачем» подходит в таких задачах близких разработчикам, как проектировка архитектуры. Больше всего в коде я не люблю бесполезные вещи. Я не люблю за это «свидетелей SOLID», которые пишут бесполезные куски кода, которые ничего не делают в рамках системы, чтобы соблюсти солид. У любой вещи в архитектуре должна быть цель, тогда код получается простым и логичным. Поэтому так важен вопрос зачем.

Да даже если вы просто где-то работаете. Вы можете делать больше, чем от вас требуют или меньше. Это ваш выбор. Но лучше предварительно задать себе вопрос «Зачем?». На работе, как можно заниматься бесполезными делами, так и ставить себе понятные цели. Вы работаете на компанию, чтобы получить опыт и сделать игру мечты скажем потом самостоятельно. Вот ответ на зачем. А раз работаете вы ради этого, то за время работы вам нужно постараться вникнуть во все части работы продакшена студии. Общаться с коллегами (может потом вы вместе пойдёте делать эту игру) и так далее. Если же ради денег, то это стратегия получения повышения и другой путь. Чем чаще задаётся вопрос «зачем», тем проще себя мотивировать и в принципе делать хоть что-то, определять как это делать и так далее.

#мысли

Где взять ассеты для проекта?
https://80.lv/articles/80-level-digest-free-asset-libraries-for-artists/

Я писал как-то про скайбоксы. И в комментах к посту мне подсказали вариант получше. А LVL80 подготовили шикарную коллекцию мест, где можно найти бесплатные ассеты. Модели, материалы и многое другое. Не знаю, почему они назвали это “for artists”. Где же моё любимое “creators”? Но дайджест прям неплох.

#новости

Новости игровой индустрии и разработки игр, а также авторские мысли в блоге Андрея Апанасика.

Если хочется начать разрабатывать игры, узнавать про интересные новости, статьи, инструменты из мира геймдева — подписываемся на канал.

Реалистичный дым
https://blog.unity.com/technology/realistic-smoke-with-6-way-lighting-in-vfx-graph

Шикарный пост в блоге Unity про визуализацию дыма с помощью техники 6D лайтмапов с помощью VFX Graph.

#новости

«Свидетели SOLID»

Я не имею ничего против солид, DI и архитектурных паттернов. Это всё важные и нужные инструменты в руках разработчика. Но есть определённый вид разработчиков которые описываются старой поговоркой: «Заставь дурака молиться, он себе лоб расшибёт». Свидетелями SOLID я называю людей, которые на определённую архитектурную парадигму чуть ли не молятся.

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

И они главные враги SOLID отпугивающие от него разработчиков. Архитектура — это не вера, чтобы доказывать её истинность. Я не вижу смысла во всех этих холиварах, так как я больше за дискуссии в терминах конкретных преимуществ и результатов. Проще на старте определиться с терминами, и что вы обсуждаете, чем из-за разного понимания терминов получать спор за разряда «разговора глухого со слепым». Инструменты не хорошие и не плохие. Им пофиг, они инструменты. И ими нужно пользоваться. И всё.

Иногда похоливарить конечно весело, но в разы полезнее говорить не «лучше или хуже», а «зачем?».

#мысли

Путь в фриланс игрового разработчика — Привлечение Клиентов. Часть 1

В прошлом мы разобрали биржи (можно найти по хештегу внизу). Это первый и самый простой уровень. То что будет дальше описывается так. Чтобы зарабатывать как бизнес, нужно думать как бизнес.

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

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

Сначала было слово. И слово было сайт. Сразу скажу давайте забудем про директ, таргет, стандартные механизмы привлечения траффика на сайт. Сайт вам нужен не для того. Сайт сам по себе не продаёт. Для того, чтобы продажи — нужны инструменты. Оружием в руках сейла является навык красиво разговаривать, умение питчить, презентации и сайт. И да, вам как аутсорс студии и как фрилансеру нужен сайт. Зачем? Так как для каналов привлечения о которых мы будем говорить сейчас вести клиентов на "профиль на fl.ru" не солидно. Как пример сайта вам пойдёт даже по аналогии с моим личным сайтом https://noxatra.ru/ (у него скоро выйдет новая версия дизайна). Где описывается кто вы, что умеете, что продаёте и так далее. Самое главное — как с вами связаться. Это простое представление, которое можно собрать даже на той же тильде или виксе. Любом конструкторе. Там не нужен супер сложный дизайн, его не надо заказывать и так далее.

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

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

Пока сделаем перерыв. Если серия получилась интересной, то ставьте 🔥. 100 штук и постараюсь ускорится с продолжением по доп. каналы привлечения и нюансы работы фрилансером.

#фриланс

Задачка «Проектируем гриды»

Кстати, по тому что обсуждали сегодня. У вас есть 2д игра, в ней карта, на ней есть поле. Поле является гридом из ячеек, которые расставлены по определённой логике. Так же есть магазин с карточками. Карточки в магазине имеют лейаут являющийся так же гридом. Есть отступы между ячейками, отступы от краёв контейнеров и логика выравнивания. А теперь вопрос.

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

#задачка

Прикольные математические задачки
https://teacher.desmos.com/activitybuilder/custom/5b32a8caa1cff72b67a45578?lang=ru

Я люблю математику. У меня даже есть небольшое обзорное выступление на митапе «зачем нужна математика в геймдеве» и одноимённая серия статей на хабре. Вот одна из них про векторы и интегралы https://habr.com/ru/post/430146/

А тут я наткнулся на прикольный набор задач для разминки. Может стоит тоже такие посоставлять, но ближе к контексту игровой разработки.

#интересное

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

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

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

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/

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

#интересное