Пост - приветствие 👋

Новый год - время новых начинаний, и к наступающему новому 2023 году мы подошли с решением и готовностью создать канал, посвященный разработке игр на Unity.
Мы - это Сергей и Ирина Жильниковы.

О Сергее:
Более 15 лет в разработке от простого программиста до СТО игровых проектов (от гиперкэжа до AAA).

Кроме разработки сфера интересов Сергея включает все области математики и немного физики.
Из интереса к физике вырос патент: “Устройство для функционирования искусственного источника света”.

Об Ирине:
В прошлом Project Manager / Product Owner на проектах от корпоративного сайта до портала футбольного клуба и крупных радиостанций.
Сменила вектор и перешла из области управления командами в область их построения.

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

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

Вы решили начать свой путь в олимпиадной математике.
Олимпиадная математика - определенный набор тем, подходов и задач, все есть в открытом доступе и при желании можно найти и изучить самостоятельно.
Но путь человека с ментором и самостоятельный путь - две разные истории.
При одних и тех же вводных данных и способностях человек, заручившись поддержкой ментора, проходит путь успешнее и эффективнее.
Ментор подбирает задачи под ваш уровень таким образом, чтобы сложности стимулировали к взятию новой высоты, а не ставили блок в голове “это невозможно”. Ментор комбинирует задачи с разными подходами. Отслеживает насколько аргументировано построено доказательство. Завернет ли ваше “правильное”, но не достаточно аргументированное решение, жюри или засчитает.
Если смотреть на количество знаковых олимпиад в году, то цена ошибки очевидна как никогда, если не знаешь тонкостей - жди следующего года. Если нет ментора - ты как слепой котенок идешь в темноте.

Рассмотрим более абстрактную ситуацию: вам очень нравятся автомобили, и вы хотите принять участие в их создании, но ранее никогда этим не занимались.
Уберем формальности и представим, что вас взяли в команду, сможете ли вы самостоятельно, без подсказок разобраться с тем, что вам доверили?
Если поставленная задача совсем простая, да. Но при этом вряд ли можно говорить о существенном вкладе в автомобиль.
Кроме вас в команде будут те, кто занимается фундаментальными задачами. К ним можно отнести тех, кто проектирует и реализует двигатель, АКПП, тормозную систему, рулевое управление, проводку, и т.д.
Что вам нужно сделать, чтобы быть одним из них?
Определиться с областью, за которую вы будете отвечать и далее сделать следующие шаги:
Изучить документацию;
Подготовить вопросы, которые возникли в процессе;
Найти наставника с реальным опытом;
Составить план;
Приступить к выполнению задач.
При данном подходе вас будут корректировать, направлять и фокусировать в тех местах, где высок риск ошибки. Процесс обучения и получение собственного опыта пойдет куда быстрее. При этом вы испытаете удовольствие от процесса и будете довольны результатом.

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

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

Пусть наступающий год принесет новые знания и профессиональный рост 🎉
С Новым Годом!

Связность (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 игр.
Подача материала рассчитана на опытных разработчиков.

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

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