Связность (cohesion) и зацепление (coupling).

Привет, сегодня поговорим про связность и зацепление в коде.

Полагаю, что каждый сталкивался со спагетти-кодом. Он плохо поддерживаемый и плохо структурированный.
Спагетти-код получается, когда при решении задач мы не уделяем должного внимания проектированию и сразу приступаем к написанию кода.

Проведем эксперимент.
Откроем проект А, который мы не трогали больше года. Весь год мы были заняты активной разработкой проекта Б.
Представим, что нам необходимо добавить какую-либо новую фичу в проект А.
Итак мы открываем проект А и пытаемся ответить на вопрос: "Все ли нам понятно по коду и насколько просто добавить новую фичу?".
Возможные варианты ответов:
- "Код непонятен, фичу добавить сходу не получится" - плохой сигнал;
- "Все понятно, фичу добавить просто" - хороший сигнал, вы уделили должное внимание проектированию.

Как научится проектировать хороший код, который легко поддерживать и развивать?

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

Связность - это степень того, насколько методы классов, сами классы и категории сфокусированы на выполнении своих задач.

Зацепление - это степень зависимости классов от классов других категорий. Сильное зацепление снижает читаемость и понятность кода.

Игра, которую мы разрабатываем, представляет из себя предметную область со своим набором правил. В рассматриваемой предметной области есть четко выделенные категории.
Представим, что мы разрабатываем Zombie Survival, для примера выделим следующие категории: "Игрок", "Враг", "Инвентарь", и т.д.
Каждая категория - это набор классов.

Например, категория "Игрок" должна отвечать за бизнес-логику и представление всего, что неотъемлемо связано с игроком.

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

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

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

Хорошим примером будет перенос всей логики работы с инвентарем в классы категории "Инвентарь" и использование этих классов (в виде зависимостей) в классах категорий "Игрок" и "Враг". Это пример сильной связности и слабого зацепления.

Нет никакой необходимости смещать фокус работы с инвентарем в класс, который находится в категории "Игрок" и "Враг".

‼ Необходимо помнить, что сильная связность и слабое зацепление - хороший тон. Слабая связность и сильное зацепление - плохой тон.

Говоря простыми словами.
Связность - это насколько корректно сгруппированы классы по категориям и сфокусированы на задачах своей категории.
Зацепление - это насколько запутаны связи в коде.

✅ Хороший тон

❌ Плохой тон

#библиотека_программиста #геймдев
Сегодняшний пост я хочу посвятить фундаментальной литературе.
Я подготовил небольшую подборку книг, которая будет полезна как для опытных разработчиков, так и для новичков.

1. Фундаментальные алгоритмы на C++, части 1-4, Роберт Седжвик
2. Паттерны объектно-ориентированного проектирования, Ричард Хелм, Роберт Джонсон, Эрих Гамма
3. Одна из двух книг: Архитектура корпоративных программных приложений или Шаблоны корпоративных приложений, Мартин Фаулер
4. Чистая архитектура. Искусство разработки программного обеспечения, Роберт Мартин
5. Multiplayer Game Programming: Architecting Networked Games (Game Design), Josh Glazer, Sanjay Madhav.

📚 Подробнее о каждой из книг:

1. Фундаментальные алгоритмы на C++, части 1-4
Эта книга дает глубокое понимание основных структур данных, с которыми вы будете сталкиваться в своей практике.
Хотя код написан на C++, к каждому алгоритму или структуре данных приводится полное описание работы, что даст понимание и для других языков (в нашем случае C#).
Читать можно обзорно.
Подходит и для новичков, и для профессионалов.

2. Паттерны объектно-ориентированного проектирования
В книге описаны паттерны проектиования, дается детальный разбор каждого из них.
Подходит и для новичков, и для профессионалов.

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

4. Чистая архитектура. Искусство разработки программного обеспечения
Книга содержит много полезной информации, как по архитектуре, так и по основным принципам, которые применяются в разработке.
Рассматриваются базовые принципы ООП.
Книгу легко читать. Большая часть того, что написано применяется в разработке.
Подходит и для новичков, и для профессионалов.

5. Multiplayer Game Programming: Architecting Networked Games (Game Design)
Опционально для тех, кто хочет погрузиться в разработку multiplayer игры.
Книга раскрывает аспекты сетевой разработки.
Рассматриваются базовые принципы построения multiplayer игр.
Подача материала рассчитана на опытных разработчиков.

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

Приятного прочтения 🙂

#паттерны_геймдев
Энтерпрайз vs Геймдев

Привет, предлагаю немного поговорить о разнице подходов для энтерпрайз и геймдев разработки.

Отличительная особенность энтерпрайз разработки - высокая стабильность (неизменность) базовых бизнес-процессов.
Например, если основная задача приложения выставлять счета, то в течение продолжительного времени данное требование остается неизменным.

Энтерпрайз характеризуют достаточно стабильные связи между системами и их компонентами.
Здесь хорошо применимы интерфейсы. Все приложение строится на реализации контрактов и связей между ними.
Такой подход обеспечивает слабое зацепление и сильную связность кода.
Для энтерпрайз характерна простота слоя представления.
Здесь хорошо подойдут большинство стандартных принципов ООП и паттернов проектирования, таких как: MVC, MVP, MVVM, и т.д, в том виде, в котором они описаны в специализированной литературе.

В геймдеве же напротив очень часто меняются бизнес-требования. От спринта к спринту гейм-дизайнер или продюсер могут менять свое видение продукта.
Частое изменения сопряжено с проверкой гипотез, анализом конкурентов и волатильностью рынка.
Приведу в качестве примера эволюцию игрового банка. Допустим, стоит задача добавления в игру первой версии банка (это первая реализация в рамках продукта и ранее ничего подобного мы не делали). Задача может звучать: “дать возможность игрокам покупать игровые предметы, выводя их списком”. Это наш первый банк и цель первой итерации - проверить монетизацию на самой простой версии.
Спустя время банк эволюционирует до разбиения игровых предметов по категориям и объединения их в паки.
Часть ранее выполненных задач могут оказаться ненужными или подвергнуться значительным доработкам.

Реализация кода через интерфейсы и связи между ними в геймдеве в большинстве случаев не позволит обеспечить сильную связанность и слабое зацепление.
Применение интерфейсов в связке с паттернами MVC, MVP, MVVM, и т.д, как правило ведет к росту количества связей между системами. Удержать проект в голове становится всё сложнее. При ротации команды сильно увеличивается технический долг.

Поэтому базовые паттерны, такие как: MVC, MVP, MVVM не подходят в чистом виде (то, как их описывают в специализированной литературе) для использования в геймдеве и требуют дополнительной адаптации.

#паттерны_геймдев #базис_геймдев #структуры_данных

Паттерны, структуры данных, векторная алгебра

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

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

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

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

Структуры данных
Каждая структура данных предназначена под определенных цели.
Знание и уместное применение влияет на:
- простоту алгоритма
- скорость работы кода (например, насколько быстро получим доступ к элементу)
- размер потреблебляемой памяти
- стоимость доработок, и т.д.

Паттерны
Знание основных паттернов проектирования влияет на:
- скорость разработки
- сложность понимания кода
- стоимость доработок
- устойчивость кода к изменениям, и т.д.

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

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

Допустим есть мир, куда каждый интервал времени спавнятся игровые объекты, которые необходимо хранить. Каждый игровой объект с течением времени может превращаться в другой. Описание каждого игрового объекта (экземпляр класса) находится в коллекции с контентом.
Задачу разобьем на 2 части:
- хранение заспавненных объектов
- превращение одного объекта в другой.

Для хранения заспавненных объектов можно использовать List и LinkedList. Сравним их между собой.
List - базируется на массиве, размер которого определен по умолчанию либо задан разработчиком. Размер массива не может меняться динамически. Если в List добавляется большое количество элементов, при выходе за изначально заданные размеры массива происходит перевыделение памяти под необходимый новый размер и копирование старой области данных в новую. Частое перевыделение памяти может сказаться на производительности работы приложения.
LinkedList лишен этого недостатка. При динамическом добавлении элементов не происходит переаллокация памяти.
В данном случае LinkedList будет более оптимален.

Рассмотрим реализацию превращения одного объекта в другой, сравнив List и Dictionary.
Пусть в момент превращения в контентной коллекции необходимо найти объект (по id), в который будет превращен исходный. При использовании List в худшем случае для поиска придется обойти всю коллекцию. Более эффективно создать дополнительную структуру данных или изначально хранить коллекцию в виде Dictionary, где ключом будет выступать требуемый параметр для поиска, например id. Поиск по словарю осуществляется за константное время и не зависит от размера коллекции.

#solid #solid_геймдев
Для чего нужен SOLID

Всем привет, сегодня говорим про SOLID (далее по тексту - классический SOLID).
Публикацию разобьем на 2 части: в первой упростим и выделим суть каждого принципа применительно к геймдеву, во второй рассмотрим проблемы.

SOLID - это набор из 5 принципов ООП, которые сформулировал Роберт Мартин. Аббревиатура была предложена Майклом Фэзерсом.
Определение звучит так: "SOLID - это руководства, которые также могут применяться во время работы над существующим программным обеспечением для его улучшения, например, для удаления «дурно пахнущего кода»".

Про SOLID спрашивают, его обсуждают с докладами на конференциях, его относят к правилам хорошего тона. Те, кто поопытнее пытаются применять SOLID на практике.

Но действительно ли разработчики понимают, как правильно применять SOLID принципы в геймдеве?

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

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

Поехали 🚀🚀🚀
S - Single responsibility principle (SRP)
❗Суть принципа: написанный вами код (реализация) внутри каждой категории (про категории говорили тут) должен максимально соответствовать этой категории.

На примере связи Игрок - Инвентарь. Если в каком-то классе, относящемся к категории игрока, мы решили что-то сделать с ячейками инвентаря, поменять их местами (написать логику свопа в классе, который относится к категории игрока), такой подход будет нарушать SRP.
Более правильной реализацией будет работа с инвентарем в классах, относящихся к категории инвентаря.

O - Open-closed principle (OCP)
На практике этот принцип соблюсти достаточно тяжело.Так как в геймдеве часто меняются бизнес-требования.
❗Суть принципа: класс открыт для добавлений, но закрыт для изменений.
Моя рекомендация - пишите код так, чтобы его было легко менять и удобно расширять.

L - Liskov substitution principle (LSP)
❗Суть принципа: если у вас в коде есть класс A и класс B, который является наследником A, то при замене всех классов A на B в работе кода ничего не должно поменяться.
Моя рекомендация - не злоупотребляете наследованием. Иногда композиция или имплементация интерфейса сработает гораздо эффективнее.

I - Interface segregation principle (ISP)
❗Суть принципа: если и используете интерфейсы, не тащите в них то, что не нужно.
Пример подхода, нарушающего ISP: если какой-то интерфейс в реализации должен работать с игровым объектом, при этом описание игрового объекта есть в коллекции контента. Нарушением принципа будет передача в интерфейс самой коллекции контента и id того объекта, с которым хотим работать.
Чтобы обойти нарушение ISP, необходимо передавать сам интерфейс объекта, который мы предварительно получаем по id из коллекции контента.
Принцип бритвы Оккама тут может быть хорошей аналогией.

D - Dependency inversion principle (DIP)
❗Суть принципа: когда вы пишете какую-либо логику в классе и у вас есть зависимости, пишите логику не опираясь на конкретные реализации этих зависимостей. Работайте с зависимостями через абстракции.
Моя рекомендация - учитывать, что абстракции - это не только интерфейсы и абстрактные классы.

Продолжение следует…

#solid #solid_геймдев

Привет, друзья.
Вернемся к SOLID в разрезе геймдева.
Сегодня рассмотрим проблемы применения принципов в чистом виде и сформируем набор рекомендаций.

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

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

В геймдев проектах можно относительно безболезненно реализовать SRP и LSP, сложности возникнут с OCP, ISP и DIP.

Рассмотрим проблемы, характерные для боевых проектов:
- SRP и LSP желателен постоянный код-ревью, при этом условии возможно безболезненное применение принципов
- OCP достаточно часто нарушается из-за переменчивости бизнес-требований, исходящих от гейм-дизайнеров, меняющих ГДД (гейм-дизайн документ). Это влечет за собой выпиливание части кода и будет сопряжено с трудностями, т.к. классы в коде уже плотно зацепились с классами из других категорий
- ISP и DIP часто интерпретируют неверно, связывая их с интерфейсами. Например: DIP - путают с Dependency Injection
- Дополнительную нагрузку при планировании и проектировании реализации DIP добавляют Dependency Injection фреймворки, наподобии Zenject, Ninject или собственные реализации. Обычно к собственной реализации приходят, если готовый фреймворк оказался сложен или избыточен.

В совокупности применение принципов без адаптации к геймдеву приводит к тому, что приложение обрастает интерфейсами и их реализациями. Задумайтесь, чем больше проект, тем неподъемнее конструкция. Каждая реализация обязана содержать public методы, что раздувает объем кодовой базы и снижает инкапсуляцию с механизмом сокрытия (тут я имею в виду private методы).

Опыт показал, что для геймдева нужен немного другой набор принципов.
✅ Сформулирую набор принципов и рекомендаций, которые я выделяю, исходя из своего опыта:
- В приложении должна быть единая точка входа в код
- Приложение должно быть разбито на слои абстракции
- Должна быть возможность пройти по всему дереву приложения из IDE
- Жизненный цикл всех объектов в приложении должен быть строго детерминирован
- Максимально, где это возможно, должна использоваться инкапсуляции с механизмом сокрытия. А именно: объекты слоя бизнес-логики должны иметь минимальное количество публичных методов, в идеале - не иметь вообще
- Использовать динамический полиморфизм. Причем, который не базируется на интерфейсах или абстрактных классах
- Минимизировать связи между объектами слоев абстракций (аналог ISP)
- Возможность легко менять и расширять код
- Использовать принцип подстановки Барбары Лисков (LSP)
- Код для работы с различными зависимостями должен быть написан декларативно (аналог DIP) и отвечать на вопрос: “что делать”. Подход обеспечит сильную связанность и слабое зацепление в сочетании с динамическим полиморфизмом.
- Простая сериализация/десериализация объектов.

Продолжение следует…

Доброе утро, друзья!
Подведем итоги опроса "Какими механизмами вы обеспечиваете полиморфизм?".
Первым делом хочу поблагодарить всех, кто принял участие и дал обратную связь 👍
Проголосовало чуть меньше 50% участников, это хороший результат.
Вижу, что вы знакомы с понятием полиморфизма 👍

Итак, на момент подведения итогов большинство из участников, принявших участие, выбрали виртуальные методы ~ 70% из 100%, далее следуют интерфейсы ~60% из 100% и другие конструкции языка лишь ~ 20% из 100%.

Что касается меня, для решения задач слоя бизнес-логики приложения я отдаю предпочтение "другим конструкциям языка". А именно реактивным объектам (из библиотеки UniRx).
Кроме этого к другим конструкциям языка относятся делегаты, шина сообщений и т.д.

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

Почему для решения задач слоя бизнес-логики я стараюсь избегать использования интерфейсов и виртуальных методов. Обеспечение полиморфизма такими способом, как правило, влечет за собой организацию связей в коде проекта через публичные методы. Наличие большого количества интерфейсов ведет к разрастанию кодовой базы, так как для каждого интерфейса нужна как минимум 1 реализация.
В итоге мы придем к коду, который мало устойчив к изменениям, в котором сложно ориентироваться.
При изменении состава команды у новых участников возникнут сложности с использованием публичного API приложения (которое уже было спроектировано).
Будет усиливаться зацепление кода.

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

Привет, друзья 🙂

Ниже анонс тем для ближайших публикаций 👇
Все они вместе с затронутыми ранее темами являются важными составляющими разработки игр.

UPD: для удобства навигации заголовок рассмотренных тем дополнен ссылкой на публикацию

1 Деление игры на слои абстракции
Поговорим про:
- представление (view, отвечает на вопрос: "как")
- слой бизнес-логики (presentation model, отвечает на вопрос: "что делать")
- построение дерева приложения (иерархия или граф entity)
- контентный слой (набор контента, с которым стартует игра)
- слой сервисов (например, рекламный сервис, сервис аналитики) не влияющий на бизнес-логику игры
- слой состояний игровых объектов (state)

2 С чего должен начинаться Unity проект
Поговорим про нюансы на уровне Unity: количечтво точек входа, последовательность старта объектов

3 MonoBehaviour
Обсудим его роль в проекте

4 Организация префабов
Поговорим про правильную организацию и роль слоя view в ней

5 Жизненный цикл объектов
Обсудим, кто за него должен отвечать

6 Изолированность классов
Поговорим о том, как ее обеспечить

7 Dependency Injection
Обсудим, как применять. Затронем DI фреймворки. Разберем, как правильно внедрять зависимости

8 Абстракции
Как не использовать интерфейсы, при этом писать абстрактный код. Полиморфизм

9 Связи
Разберем, как выстроить связи между классами со слабым зацеплением в коде. Рассмотрим применение реактивных объектов из библиотеки UniRx

10 Контент
Как должен выглядеть контент, используемый игровыми объектами

11 Состояние объектов в игре
Поговорим про то, как и где хранить состояние объектов в игре, также состояние мира/игрока

12 Плагины
Обсудим, как использовать сторонние плагины, чтобы они вписывались в общую архитектуру проекта

13 Сериализация и десериализация
Как правильно сериализовать и десериализовать объекты внутри игры.

#слои_абстракции_геймдев #архитектура

Приветствую, друзья.
Сегодня мы обсудим важную тему - разделение игры на слои абстракции. Вопрос является ключевым для создания гибкой и масштабируемой игры. Хотя объем информации достаточно велик, буду стараться дать его как можно более лаконично и понятно.

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

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

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

Рассмотрим каждый из слоев подробнее.

Слой бизнес-логики (или presentation model, pm)
Часть, отвечающая на вопрос: "что делать". Содержит правила и логику игры, необходимые для ее функционирования.
Например: идти вперед, собирать предметы, открыть ящик, и т.д.

Слой представление (или view)
Часть, отвечающая на вопрос: "как". Отвечает за отображение игрового мира и взаимодействия с игроком.
Как именно действие должно представляться в игровом мире.
Например: как герой должен бежать вперед, как собирать предметы, как открывать ящик, и т.д.

Проведем аналогию с поездкой на такси:
Мы планируем доехать на такси из пункта "А" в пункт "Б".
Для решения этой задачи мы говорим такси, что нужно сделать.
Что нужно сделать? Доехать из пункта "А" в пункт "Б".
Такси при этом само знает, как именно оно поедет.
В данном случае слоем бизнес-логики (pm) выступает пассажир, который говорит, что делать.
Слоем представления (view) выступает такси, которое знает, как именно нужно ехать.

Слой связей
Отвечает за взаимодействие между объектами в игре.
Например связи между персонажем и окружающим миром или между различными игровыми объектами (враг и оружие). Как правило, cвязи выстраиваются через реактивные объекты: ReactiveProperty и ReactiveCommand.

Слой жизненного цикла объектов
Управляет созданием, удалением и обновлением объектов в игре.
Условно жизненный цикл можно представить в виде дерева или графа, где в каждый определенный момент будут работать определенные ветки.
Узел дерева - это некоторая игровая сущность (или как договорились называть ранее entity), описывающая набор логик, предоставляющая набор представлений, необходимых ресурсов и подготавливающая набор связей (реактивные объекты), которые будут использоваться слоями entity, view и pm для общения.
Игровая сущность (entity) может создавать другие игровые сущности, для связи используются реактивные объекты. Игровые сущности не находятся в иерархии наследования.

Именно слабое зацепление и высокая связность слоев entity, pm, view являются ключевыми факторами для создания гибкого и расширяемого приложения. Слабое зацепление обеспечивается за счет использования реактивных объектов, таких как ReactiveProperty и ReactiveCommand. Это позволяет связывать данные и логику между слоями, не нарушая их инкапсуляцию. В то же время, высокая связность обеспечивает общую логику приложения и облегчает отладку и поддержку кода. Это дает возможность легко модифицировать и расширять приложение без необходимости вносить изменения в другие части кода.

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

Продолжение 👇

#слои_абстракции_геймдев #архитектура

Слои абстракции продолжение 👇

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

Классы находятся в строгой иерархии наследования, общий предок всех контентных классов - класс Content.

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

Рассмотрим пример: предположим в игре есть 2 типа зданий: обычные и те, которые поддерживают апгрейд. Тогда иерархия контентных классов будет состоять из:
Content-Building-UpgradableBuilding.

В этом случае контентные коллекции должны выглядеть следующим образом:
Contents - коллекция содержащие все экземпляры классов, которые могут быть приведены к классу Content (экземпляры классов UpgradableBuilding, Buildings, Content).
Buildings - коллекция содержащая все экземпляры классов, которые могут быть приведены к классу Building (экземпляры классов UpgradableBuilding, Buildings).
UpgradableBuilding - коллекция содержащая все экземпляры классов, которые могут быть приведены к классу Building (экземпляры классов UpgradableBuilding).
Доступ к элементам коллекции должен осуществляться через id.

Слой состояния игровых объектов
Отвечает за хранение и обновление состояния объектов в игре.
Если игровой объект, описанный контентным классом, в процессе игры может менять свое состояние, для него явно должен присутствовать отдельный класс - состояние (state).
Классы состояния могут находится в иерархии наследования и должны иметь поля с публичными модификаторами доступа.
У класса состояния должно быть публичное поле contentId.

Те поля, на изменение которых может реагировать слой представления (view), должны быть оформлены в виде реактивных объектов. У контентного класса такого вида должен быть публичный метод CreateState, который вернет созданный экземпляр класса состояния нужного типа.

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

Слой сервисов
Отвечает за набор дополнительных сервисов, например для сбора и анализа данных об игроках и их действиях в игре.
Представляет собой набор классов с публичными модификаторами доступа. Сервисный класс должен предоставлять публичный доступ к API, который реализует сервис.
Сервис должен быть создан 1 раз в нужном узле дерева приложения. Далее в виде явной зависимости передаваться вниз по иерархии.

📌 UPD: группа желающих сделать тестовое задание для разбора сформирована 💪 всем спасибо за участие 👍
p/s если вы хотели, поучаствовать, но не успели, напишите, что-нибудь придумаем.

Приветствую, друзья 👋
С началом новой недели!

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

Итак тестовое задание 🎮:
Игровая сцена разбита на квадраты 100x100.
При входе в игру в клетки игрового поля спавнятся здания 2х типов: простые (статичные) и те, которые могут апгрейдится до определенного уровня.
Каждый уровень здания - новая модель.
В контенте можно задать цепочки апгрейдов для зданий.
Например здание 1 (level 1) - здание 2 (level 2) - здание 3 (level 3).
Игрок (наблюдатель) может управлять камерой (WASD + мышь), чтобы можно свободно передвигаться по сцене. При перемещении нужно учитывать коллизии на зданиях и террейне.

Критерии оценки:
- Декомпозиция задачи ,
- Связи между слоями,
- Дорабатываемость и устойчивость к изменениям.

❗Визуальная составляющая не важна и полностью на ваше усмотрение.

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

И чур не сходить с дистанции 🧗‍♂️

Всем продуктивной недели 💪

#архитектура

Приветствую, друзья 👋

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

Начнём с единой точки входа.
Единая точка входа - это главный скрипт, который инициализирует и контролирует все другие элементы проекта.
Представляет собой MonoBehaviour класс, который может быть легко просмотрен и понят.

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

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

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

Что касается нескольких точек входа в код проекта.
При таком подходе каждая точка входа представляет собой отдельный вход в код и может быть реализована с помощью GameObject на сцене.
На каждом GameObject расположены MonoBehaviour скрипты, в методах Awake или Start которых выполняется определенный код.
Использование нескольких точек входа проще в реализации, подходит для прототипов но неэффективно для крупных проектов.

Плюсы использования нескольких точек входа в код:
- простота использования (если речь о прототипах)
- отпадает необходимость задумываться о жизненном цикле объектов.

Минусы использования нескольких точек входа:
- усложнение отладки и увеличение времени на ее проведение
- снижение читаемости кода и усложнение его понимания.

Что касается меня, я являюсь сторонником единой точки входа.

Рассмотрим на примере:
В иерархии объектов на сцене я создаю GameObject с названием Root, на котором размещаю компонент EntryPoint. В Awake создаю первую Entity - RootEntity, далее код развивается древовидно.
В каждую из веток кода можно попасть через навигатор кода.
Каждая Entity, Pm, View включается в себя структуру Ctx, которая описывает все зависимости текущего класса.
В итоге код можно представить в виде дерева.
Кроме того, наличие Ctx в каждой Entity, Pm и View позволяет вам легко отслеживать все зависимости, что улучшает читаемость и поддерживаемость кода.

#разбортестового
Приветствую, друзья 👋
Сегодня публикуем разбор одного из присланных тестовых заданий.

Разбор представлен в 2-х форматах:
- Видео. Постарался сделать сжато, выделив суть.
- Текстовый. Для тех, кто не планирует смотреть видео.
Но я рекомендую выделить время как на прочтение, так и просмотр)

Итак, приступим, начнем с замечаний
1. Отсутствует единая точка входа.
Вход в код осуществляется в 2 классах:
- SceaneLoader, Awake
- Player, Start.

2. Разделение на слои абстракции.
Выполнено, но не до конца.
Есть классы отвечающие за несколько зон.

Так, например, класс UpgradableBuilding содержит в себе следующие ответственности:
- контент
- бизнес-логика смены зданий
- слой представления.

Класс Player содержит избыточную ответственность:
- бизнес-логику (управление и передвижение камеры)
- слой представления.

3. Слой State.
В текущей реализации будет невозможно создать BuildingController из State в случае сохранения игрового состояния мира на диск и его последующего восстановления.

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

5. Организация префабов с UpgradableBuilding.
Префабы изначально содержат все возможные уровни апгрейда зданий, по умолчанию все кроме первого уровня находятся в неактивном состоянии.
В идеале UpgradableBuilding не должен знать свою цепочку апгрейда.
Возможность задавать цепочку апгрейда должна быть доступна через контент. Это необходимо для того, чтобы гейм-дизайнер или контент-менеджер могли управлять апгрейдом самостоятельно при настройке баланса игры без участия разработки.
Для этого необходим отдельный контентный класс, в котором прописывается:
- уровень,
- id здания, которое апгрейдим,
- id здания, на какое апгрейдим.

6. Использование большого количества MonoBehaviour.

7. Утилитарные классы можно не инстанцировать, вместо этого использовать статические классы и методы. Например, сделать статическим класс GridGenerator, метод GetGrid.

8. Использования постфикса Controller в классах.
Уйти от использования постфикса Controller в классах, это может вызвать диссонанс у проверяющего.
Controller из MVC - это слой, который отвечает за пользовательский ввод и уведомляет модель, далее слой представления рендерит изменения.

8. Использовать namespace.

---
Что понравилось в тестовом:
1. Простота кода
2. Единообразие с методом Init.

Тестовое выполнено довольно неплохо
Спасибо автору за проделанную работу и предоставленный для разбора материал 💪
Всем хорошего дня и прекрасных выходных!

#библиотека_программиста #геймдев #слои_абстракции

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

К сожалению, хорошей литературы по слоям абстракции в геймдеве я не встречал.
Но для понимания на концептуальном уровне могу посоветовать следующие варианты:
📚
1. Предметно-ориентированное проектирование (DDD). Структуризация сложных программных систем, Эванс Эрик, стр. 79.
2. Архитектура корпоративных программных приложений, Мартин Фаулер, стр. 43.
3. Программист-прагматик. Путь от подмастерья к мастеру, Эндрю Хант, Дэвид Томас, стр. 32.

Приятного прочтения 🙂

Привествую, друзья.
Одна из тем, которой я касаюсь при отборе в команду - использование интерфеса IDisposable.

Перед очередной нашей публикацией предлагаю вам принять участие в опросе 👇

#idisposable #управление_ресурсами

Приветствую, друзья!

Подведем итоги опроса про интерфейс IDisposable 👇
На момент подведения итогов получены следующие результаты:
✅ 44% - разработчик решает, что произойдет
16% - освободится память
26% - освободятся неуправляемые ресурсы
14% - затрудняются ответить.

Как показал опрос использование интерфейса IDisposable в C# часто некорректно связывают только с освобождением памяти или освобождением неуправляемых ресурсов.
‼️ На самом деле сам разработчик может задать сценарий происходящего.

Понимание работы IDisposable понадобится нам для дальнейших публикаций и разбора кода, поэтому приступим.

Один из вариантов использования интерфейса IDisposable в C# - реализация паттерна "ресурсов", суть которого состоит в управлении использованием ресурсов, таких как: файлы, сетевые подключения, базы данных и других неуправляемых ресурсов.

Управляемые ресурсы - это ресурсы, которыми управляет сборщик мусора, такие как объекты ref типа, созданные с использованием оператора new.
Сборщик мусора автоматически освобождает память, выделенную под управляемые ресурсы, когда они больше не используются.

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

Таким образом использование интерфейса IDisposable для реализации паттерна "ресурсов" помогает управлять ресурсами и предотвращать утечки памяти.

Рассмотрим другие сценарии.

Реализация паттерна "заимствования" (borrowing).
Паттерн будет полезен при работе с потоками данных или потоковыми операциями, где необходимо убедиться, что определенные ресурсы используются только одним потоком в определенный момент времени, и избежать ошибок при многопоточной обработке данных.
При данном подходе интерфейс IDisposable используют для создания блоков кода, в которых происходит заимствование (borrowing) ресурса и автоматическое освобождение этого ресурса после завершения блока.

Рассмотрим пример реализации паттерна "заимствования", где использование интерфейса IDisposable позволит гарантировать правильную обработку ресурса и избежать ошибок при работе с потоками данных.

class StreamResource : IDisposable
{
    private Stream _stream;

    public StreamResource(Stream stream)
    {
        _stream = stream;
    }

    public Stream GetStream()
    {
        return _stream;
    }

    public void Dispose()
    {
        _stream = null;
    }
}

// Использование ресурса в блоке using
using (var resource = new StreamResource(new FileStream("file.txt", FileMode.Open)))
{
    var stream = resource.GetStream();
    // обработка потока данных
}

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

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

Продолжение 👇