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

Сейчас приходится делать акцент на рабочих проектах, перестраивайся в рабочий режим. Уверен, что в воображаемой воронке «отвалов блогеров от своих блогов» в такие моменты отсеивается половина трафика. В общем, что я хочу сказать: сейчас понемногу вернусь в стабильное состояние и доделаем ui kit, поговорим про игры, покажу ещё один из предрелизных своих проектов.

Всем хорошего начала недели)

Знаю, что сейчас многие в процессе поиска работы, а у нас в компании только что открылась вакансия на позицию Unity Developer. Вот описание вакансии на hh, но тут я могу неофициально дополнить, что ищем ребят от мидла и выше, локации - Сербия, Грузия, RF. По ЗП от 150к, работа над крупным мобильным проектом с онлайном игроков более 100к в сутки. Если вам или вашим знакомым интересно пособеседоваться - пишите мне в личку @KotikovD

UPD: Уже нашли нашего чела)

Вчера был на лекции об истории российского геймдева. Проводили ребята из студии Брезгъ (For the People и Благими Намерениями). Вот прям все было максимально в питерском стиле. Всех принял маленький уютный книжный магазин Листва, находится он внутри двора-колодца. Слушателей ждал самовар с овсяным печеньем. Аудитория небольшая, но самая разная, от интересующихся темой до разработчиков всех специальностей.

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

Я дальше буду стараться отслеживать подобные мероприятия и если вам интересно - могу давать тут анонсы, дайте об этом знать реакцией 🔥 или в комментах.
#события

Новость - Сервис Xsolla передал свои активы под контроль компаний США (rb.ru).

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

У меня есть устойчивое ощущение, что для клиентов сервиса ничего принципиально не изменится. Во-первых, компания нечисто русская уже была давно. Во-вторых, заявлений об прекращении работы в РФ не было. В третьих бизнес сделает все возможное, чтобы сохранить свои рынки. Даже если возникнут какие-то обстоятельства, которые будут вынуждать их сворачивать деятельность - в одночасье это не произойдёт, будет время перейти на что-то ещё.
#новость

Внезапно ворвалось в мою жизнь понимание, что я неправильно понимал принцип SRP из SOLID. Я перечитываю «Чистую архитектуру» Мартина и в третьем разделе разбираются принципы солид. Про SRP буквально Мартин пишет, что это самый трудно понимаемый принцип и вы наверняка думаете, что он отвечает за то, что один модуль должен отвечать за какую-то одну функцию, которую реализует.

Я даже подвис на этом месте, как бы, а что ещё надо думать? Далее, спустя несколько примеров, автор формулирует этот принцип по-другому, перефразировать его можно так: модуль должен отвечать за изменения только от одного заказчика изменений.

Что это значит? Мы пишем код для кого-то, например, для бизнеса, где в реальных лицах это - менеджер проекта, лиды, ещё какие-то главные люди итп. Каждый из них заинтересован в функционале, который реализует ваш код и допустим каждый может поставить вам задачу на изменения или доработку какой-то части программы. То есть каждый из них «заказчик изменений». Таким образом, вы получаете разные таски на доработку, которые могут плохо стыковаться и при этом затрагивать какую-то общую логику программы. Вы можете получить проблему, где надо согласовывать и мержить эти изменения. А это время, риски и лишняя работа.

Что предлагает дядя Боб? Все разделять и при необходимости дублировать код. Например, если у вас игре есть какая-то общая функция расчёта дополнительных наград за победу в режиме PVP и за выполнение игровых квестов, то следуя этому правилу эту функцию надо засунуть в модуль PVP и скопировать ее в модуль квестов. Изменяя один из этих модулей, другой гарантированно не будет затронут.
#техничка

Давайте мериться у кого больше.

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

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

Кто какие профильные каналы читает в ТГ? Предлагаю поделиться в комментариях. На тему разработки, игр и геймдева в целом. Большие или маленькие - не важно. Даже если у вас есть свой канал - тоже делитесь. Прикрепите ссылку и пару слов чем вам нравится.

Технический приём, который может сильно пригодиться на практике, но не только лишь каждый его вспомнит и применит. Покажу на примере. Допустим у нас шариться логика на сервере и клиенте. Там у нас есть класс инвентаря, он хранит Dictionary c ресурсами и количеством. Его мы не можем в чистом виде отдавать свойством, потому что это небезопасно. При этом данные из него нужны не только на сервере, но и на клиенте (например, инициализация UI ресурсов, заполнение окна инвентаря). Как быть? На самом деле все просто.

Наследование класса от IEnumerable даёт возможность бегать по классу в цикле. Обратите внимание, что в GetEnumerator отдаём копию.

class Inventory : IEnumerable<KeyValuePair<Resource, int>>
{
Dictionary<Resource, int> _inventory;

public IEnumerator<KeyValuePair<Resource, int>> GetEnumerator()
{
lock (_inventory)
return new Dictionary<Resource, int>(_inventory).GetEnumerator();
}

IEnumerator IEnumerable.GetEnumerator()
{
return GetEnumerator();
}
}

Ещё один вариант, который не исключает, а дополняет первый приём - индексатор. С помощью него вы можете брать значение по ключу и обращаться к классу как к дикшарю. При этом можете сделать все обработки и безопасное обращение внутри проперти. Ещё индексатор можно декларировать в интерфейсе. Обращение к классу может выглядеть так: var amount = _Inventory[Resource.Gold];

class Inventory
{
Dictionary<Resource, int> _inventory;

public int this[Resource resource]
{
get
{
lock (_inventory)
{
if (_inventory.TryGetValue(resource, out int amount))
return amount;
return 0;
}
}

set
{
lock (_inventory)
_inventory[resource] = value;
}
}
}
#техничка

Жизненная тема. Как прокачиваетесь на работе? Есть ли у вас какие-то способы для этого?

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

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

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

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

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

Это вторая часть про Контрразведку. Часть 1
Порадовало:
⁃ Игра честно бесплатная и это сингл плеер на мобилку. Даже звучит странно. На сколько могу заметить, например, Apple Arcade себя позиционирует как стор с премиальными мобильными играми. И вот только там я видел подобные примеры.
⁃ Стильная графика. Хороший баланс проработки, деталей и выбранный визуальный стиль. Да, есть к чему прикопаться, но эмоции приятные, разглядывать хочется.
⁃ Хорошей анимации и их много. Хотя и многих переходов между состояниями нет, это не мешает.
⁃ Не напряжено вписали исторические сводки. Вообще этот момент очень напоминает мне 2 вещи. Я делал обучающий детский проект для музея на деньги гос. гранта. И там была специфика, что проект должен однозначно реализовывать тему заявки гранта. У меня там все внимание было на обучающих хинтах, фотках к ним и озвучке этого справочного материала. Тут тоже есть такой след. Второй проект, который приходит на ум, бесспорно крутой и известный - Чёрная книга. Про мифы и сказания Пермского края. Там все мифы вписаны в геймплей, вам реально надо разбираться в ста сортах чертей, чтобы решать игровые задания и влиять на сюжет. А народные песни излечивают главного героя. Это мои домыслы, но не удивлюсь, если среди инвестиций Чёрной книги тоже есть гранты.

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

Почему когда мы пишем [SerializeField] напротив поля List оно появляется в инспекторе, а когда напротив поля типа Dictionary инспектор нам его не рисует?

Если вкратце, то Unity ленивые жопы. Либо, как сказал мой друг, они планируют купить Odin, где это реализовали.

Суть в том, что Unity добавили стандартную сериализацию для всех базовых и встроенных типов, а также типов наследуемых от UnityEngine.Object. Плюс для любых (почти) классов, явно помеченных атрибутом [System.Serializable].

Так вот, List по сути это дженерик класс. А дженерики не сериализуются, то есть во вьюшке так писать нельзя:

public class MyView : MonoBehaviour
{
   // Инспектор ничего не нарисует
   [SerializeField] private MyClass<AnyType> _myClass;
}

Магия в том, что Unity написали персональный серилизатор для листа. А для дикшаря не написали. При настоящем и неподдельном желании можно написать свой сериализатор самостоятельно. А также есть способ добавить свой собственный класс, унаследованный от Dictionary или любого дженерика и выводить его в инспекторе. Суть в том, чтобы сразу определить тип, таким образом:

public class GenericClass<T>
{
   public T Value;
}

[Serializable]
public class MyClass : GenericClass<int> { }

public class MyView : MonoBehaviour
{
   // Будет в инспекторе
   [SerializeField] private MyClass _myClass;
}

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

Недавно делал пост про то, что мы ищем Юнити-девелоперов себе в компанию. И хочется немного подтолкнуть тех, кто может ещё, думает мне написать и не хватает решающего толчка чтобы это сделать.
Ищу я классного чела, не просто в компанию, а конкретно себе в проектную команду. Работать будем над мидкорным Idle RPG - MightyParty. Широкий стек технологий и масса пространства для творчества.
Кроме моего проекта, есть и другие. А также есть вариант присоединиться к межпроектной технической команде над созданием разных тулз и расширений. Это если вы любите копать в глубину и у вас айтишная бородатая душа.
Чтобы лучше донести, что нужно будет делать я лично переписал разделы в описании вакансии на hh "Чем предстоит заниматься" и "Круто, если ты". В общем ребят, пишите в ЛС, расскажу подробнее какие проекты.

PS: Реально старались сделать особое описание вакансии, чтобы передать общий вайб. Получилось?)

Чем отличается Composition Root от Service Locator?

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

Composition Root
Его назначение внедрить зависимости во все объекты, которые создаёт. В ручном режиме, в методе сборки систем есть определённый порядок инициализации. Сначала создаются системы, которые не имеют зависимостей, например, WebClient, InputSystem. Далее системы с зависимостью на первую группу, например, контроллер управления персонажем с зависимостью на InputSystem. Далее третья группа с зависимостями на первые две. И так далее.

Таким образом создаются все объекты игры, которые имеют все необходимые зависимости на этапе создания. Тоже самое но в автоматическом режиме и со своими наворотами делают DI-контейнеры, например, Zenject. Хранить эти объекты и предоставлять к ним доступ CR не обязан, но может.

Service Locator
Должен хранить в себе все сервисы, которые создаёт и отдавать их всем кто попросит. При регистрации своих сервисов локатор не обязан заниматься внедрением зависимостей, например, он может регистрировать созданные ранее объекты.

Таким образом вы в любом месте игры можете обратиться по статическому методу у локатора и попросить нужную службу. Именно по этому его называют анти-паттерном. Можете сказать чем он лучше синглтона? 😏

А по факту в игре вы можете увидеть гибрид, который отвечает признакам и того и другого. Но главный признак локатора - это метод, с помощью которого вы можете получить прямой доступ к какой-либо службе откуда угодно. Совсем кратко: правильный CR внедряет зависимость, SL предоставляет доступ.

Вот такие мысли в слух. Появились, когда тут на днях пошёл изучить новый проект. Если у вас есть свои истории и дополнения про эти паттерны - делитесь, интересно почитать.
#техничка

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

Когда Hogwarts Legacy и Atomic Heart борются за то, кого из них геймеры пройдут первым, я решил запустить BioShock.

В BioShock есть мини игра для взлома устройств (на скрине). Сама игра 2007 года. Мини игры обычно позволяют разбавить основной геймплей. И получается! Чувствуешь жёсткую скуку занимаясь взломом. Я попытался вспомнить примеры годных мини игр, но такое ощущение, что их не делают интересными в больших проектах.

Например, взлом замков в Thief. Но он тривиальный. Взлом устройств в Киберпанке - на мой вкус вообще неказистый. Хороший пример, пожалуй, Гвинт в Ведьмаке.

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

Интересно, почему для мини игр часто используют неинтересные механики. Хотелось бы вдохновиться качественной подборкой. Наподобие такого ролика про 100 игровых механик или вот такой сайт, где тоже разложена сотня механик. Может кто-то, может накинуть ещё подобных референсов.
#игры