Мемасик на злобу дня. Это я хочу с тулкитом закончить. Но я недавно придумал что буду делать дальше и теперь закончить тулкит стало гораздо сложнее 😌

Все таки купил билет на Игропром 11 марта (суббота, так что работе не помеха) в Москве. Если думаете - решайте скорее, с 1го января там повышение цены на билеты. Я взял обычный билет. Не увидел анонса выступлений и не уверен, что меня заинтересуют лекции. По ощущениям, они будут общего характера, а я люблю хардкорные лекции, чтобы копали вглубь. Планирую смотреть стенды, общаться, впитывать атмосферу. Гоу вместе.

И так, продолжаю доделывать проект по UI Toolkit. В чем его суть? Делаю такой конструктор, который позволяет накинуть несколько компонентов и сразу получить готовое меню. Чтобы просто настраивалось, все кликалось, нажималось, запускалось на разных экранах и хорошо выглядело. Скоро выложу видос где все покажу.

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

Так, ну вроде оливье уже доели, можно попрограммировать. Небольшое видео для тех, кому интересно увидеть техническую сторону, что там получается с Simple UI Kit (такое название я дал своему инструменту).
Показываю как пользоваться и вот основные вопросы, которые я поднимаю:
- Удобно ли таким пользоваться\внедрять?
- Фидбек\критика.
- Нормальный звук у видео?
#девлог

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

Сейчас приходится делать акцент на рабочих проектах, перестраивайся в рабочий режим. Уверен, что в воображаемой воронке «отвалов блогеров от своих блогов» в такие моменты отсеивается половина трафика. В общем, что я хочу сказать: сейчас понемногу вернусь в стабильное состояние и доделаем 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. Темы подбираются заранее и если нужно подготавливаются кем-то из кодеров в виде презентаций. Иногда можем даже кого-то позвать из вне проекта.

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