GameDev: разработка на Unity3D

#тренды #мнениеЧем это опасно?Рассмотрим, с какими ошибками можно столкнуться, по мере роста и развития проекта. И к чему может привести пренебрежение определенными набором знаний. Рассмотрим некоторые примеры.Поверхностное изучение инструментов разработки.Использование популярных движков, таких как Unity или Unreal Engine без углубления в их возможности и работу под капотом, приводит к тому, что, столкнувшись с нестандартной задачей, команда не может эффективно её решить, полагаясь на плагины и готовые решения вместо собственного кода.Алгоритмы и структуры данных.Речь про подход к выбору алгоритмов и структур данных для решения задач.На примере работы с коллекциями игровых объектов.Например, стоит задача хранить и искать предметы инвентаря на карте. Разработчик может использовать:- простые массивы или списки- оптимизированные структуры данных: сбалансированные деревья или хеш-таблицы.Простые структуры (массивы и списки) будут работать на небольших проектах, но при увеличении масштаба игры (большие миры, сотни или тысячи объектов) производительность резко падает. Игра начинает "лагать", возникают задержки при взаимодействии с объектами. Решить проблему можно правильным выбором структур данных и алгоритмов.Линейная алгебра и векторные операции.Работа с 3D/2D-объектами и их позиционированием в пространстве требует понимания линейной алгебры, особенно векторов и матриц. Можно полагаться исключительно на встроенные функции движков, без погружения в работу поворотов, масштабирования и трансформации объектов.Начинающие разработчики могут сталкиваться с проблемами при работе с камерой или анимацией персонажей. Например, при попытке запрограммировать плавные повороты персонажа при повороте камеры, возникают дерганые анимации, некорректные повороты. Уйти от проблемы можно через кватернионы или правильные векторные вычисления. Проблемы с коллизиями и физикой. Работа с физическими объектами требует понимания основ механики и физических уравнений. При использовании встроенных

#тренды #мнениеПриветствую 👋.Сегодня говорим про:Тренд отрицания знаний в индустрии: "И так сойдет".В последние годы в игровой индустрии (и не только) нарастающий тренд - отказ от глубокого изучения фундаментальных знаний. На определенном этапе некоторым разработчикам начинает казаться, что на длинной дистанции можно выехать на интуиции и быстрых решениях, а изучение специализированной литературы, освоение базовых концепций не обязательны. Однако это может обернуться серьезными последствиями в будущем.Отрицание знаний в контексте игровой индустрии - это сознательное игнорирование разработчиками фундаментальных аспектов разработки игр, таких как основы программирования, математические принципы, работа с игровыми движками, проектирование геймплея и изучение/преемственность опыта других студий. Желание достичь успеха, полагаясь только на популярные инструменты и готовые решения, без глубокого погружения в теорию или опыт других."Быстрые победы" дают готовые игровые движки, фреймворки и плагины, чаты GPT и т.д. Всё это полезные инструменты, важен подход к работе с ними: погружаться или использовать не стремясь понять, как они работают изнутри, что стоит за конкретным решением. Бездумное использование создает потолок для разработчика. ❗Не стоит отрицать новое. Важен баланс, берешь быстрое решение - понимаешь его ограничения, подводные камни, понимаешь как обойти. Такие решения - доза дофамина “у меня получилось”, можно использовать как ступеньку на следующий уровень погружения.Продолжение 👇

Абсолютно правильно ответил один из наших подписчиков, даже добавить нечего 👏

С отрывом в 12% победил вариант: "Современный тренд отрицания знаний".Пока я готовлю публикацию, предлагаю решить небольшую задачку 👇Красное колесо радиусом R/2 обкатывает черное колесо радиусом R.На черном колесе зафиксирована точка A - начало обката для красного колеса.❓Сколько полных оборотов сделает красное колесо, продолжив обкат, вернувшись в точку A?Ответы пишите в комментариях.

#архитектураРассмотрим еще один пример: два типа управления самолетом в игровом симуляторе: - Полностью ручное управление самолетом = толстая бизнес-логика. На стороне бизнес-логики вся ответственность за управление самолётом: взлёт, полёт, посадку и атаку. Представление занимается только отображением и передачей команд от пользователя. В данном случае бизнес-логика помимо описания работы игровой логики будет включать в себя часть, которая отвечает за работу представлений. - Автоматическое управление самолетом = тонкая бизнес-логика. Бизнес-логика передает базовые команды, такие как перемещение из точки А в точку Б или выполнение атаки. Сложные механизмы управления, такие как автовзлёт, посадка, полёт через 2 точки реализованы на стороне представления. Бизнес-логика при этом может больше концентрироваться на реализации логики игры, а не логике того, как должно работать представление.👉 Существует мнение: - принцип работы динамического объекта в игре всегда нужно разделять на бизнес-логику, которая полностью отвечает за поведение этого объекта и представление, которое отображает то, что в него приходит. На практике такой подход не всегда удобен, иногда проще сделать более толстое представление, так как с ним гораздо проще работать в “песочнице” при построении MVP (см. пример с самолётом выше). При этом логика представления не должна являться частью бизнес-логики игры. - толстая бизнес-логика легко переносится между проектами, так как она мало зависит от конкретного представления и интерфейса пользователя. Однако на практике, в большинстве случаев получается, что каждый проект - уникален и такого рода перенос требует существенного времени. - тонкая бизнес-логика требует значительных изменений при переносе, так как часть поведенческой логики тесно связана с конкретными элементами представления. На практике, префабы с правильно подготовленными скриптами имеют хорошую переносимость между проектами и их проще тестировать.‼️Правильное по

#архитектураВсем привет 👋 По интенсивности постов в канале, вы могли догадаться, что, к сожалению, у меня сейчас очень сильная загруженность. Оживим канал вместе 🤝Сегодня поговорим про стратегии разделения логики в игровых проектах: от тонкой к толстой бизнес-логике.Логика представления - это та часть логики, которая неотъемлемо относится к функционированию этого представления. Бизнес-логика - это набор правил и алгоритмов, которые описывают, как игра должна работать на уровне взаимодействия объектов, принятия решений и выполнения действий. Она отвечает за то, как игра реагирует на действия игрока, как меняется состояние игры в ответ на эти действия, и т.д. Подчеркну, что в целом бизнес-логика может работать вообще без представлений.‼️Важное различие между бизнес-логикой и логикой представления в том, что первая отвечает за правила и процессы, определяющие ход игры, а вторая - за то, как эта информация передаётся игроку в виде визуальных и интерфейсных элементов.Самый простой пример:Бизнес-логика: У персонажа уменьшилось здоровье на 10 единиц после атаки врага.Логика представления: Этот факт отражается на экране в виде уменьшения полосы здоровья и вспышки красного цвета.Рассмотрим еще некоторые примеры из жизни, которые не всегда являются однозначными.Вам необходимо попасть из точки А в Б. Закрыть потребность можно разными способами:- Вариант 1 - такси; - Вариант 2 - самостоятельная поездка за рулем. Вариант 1. Поездка на такси. Участники:- Вы, как пассажир задаете точку А и Б;- Автомобиль;- Водитель такси - знает как управлять автомобилем, ему известен маршрут поездки.Садясь в машину, через какое-то время вы оказываетесь в точке Б, считаем что вы полностью доверились водителю и в процессе поездки не влияли на то, как именно она осуществлялась.В данном примере: Роль бизнес-логики выполняет пассажир, определяя высокоуровневую задачу, задавая начальную и конечную точки маршрута. Представление - такси + водитель. Для пассажира и сторонних наблюдателей - виден процесс

#архитектура #solid #новые_подходы #simpleИтак рассмотрим подход на базе Composition Tree и концепции реактивного программирования.❗Подход включает в себя 6 основных принципов, название каждого из которых образует аббревиатуру SIMPLE.Рассмотрим каждый из принципов:S - Принцип разделения на основе потоков данных (Stream-based Segregation Principle):Потоки данных описываются как последовательности событий или значений, которые меняются со временем.В реактивном программировании потоки данных играют ключевую роль.Принцип разделения на основе потоков данных подразумевает, что классы в приложении должны быть организованы вокруг потоков данных, которые они обрабатывают, обеспечивая тем самым отзывчивость и простоту управления состоянием.Основой могут быть реактивные объекты: ReactiveProperty, ReactiveCommand.I - Независимость от интерфейсов в бизнес-логике (Interface Free In Business Logic Principle):Бизнес-логика должна быть свободна от традиционных интерфейсов, предпочитая вместо этого изменения и подписки на потоки данных для взаимодействия классов. Это облегчает динамичное взаимодействие между классами и улучшает отзывчивость приложения.‼️При этом слой сервисов и внешних библиотек допускает использование интерфейсов.M - Модульное разделение (Modular Decoupled Principle):В приложении должно быть четкое разделению ответственности между различными модулями, аналогично принципу единственной ответственности из SOLID. Это подразумевает независимость бизнес-логики, пользовательского интерфейса, сетевых запросов и других частей приложения.P - Принцип проактивной предсказуемости (Proactive Predictability Principle):Системы, построенные с использованием реактивного подхода, должны обеспечивать легкость предсказания поведения и взаимодействий потоков данных. Это требует четкой структуризации и отслеживания зависимостей, что упрощает тестирование и отладку.Все потоки данных должны иметь чёткое назначение и иметь только необходимую ответственность.L - Независимость слоёв (Layered-

#архитектура #solid #новые_подходы #simpleПриветствую 👋 У меня для вас большой блок информации для осмысления и анализа. Все, кто интересуется архитектурой приложений, знают и стараются опираться на принципы SOLID и паттерны проектирования.Впервые принципы SOLID были представлены в 2000 году в статье Design Principles and Design Patterns Роберта Мартина, также известного как Дядюшка Боб. https://web.archive.org/web/20150906155800/http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdfС тех пор прошло: 24 года.Паттерны проектирования были адаптированы в 1987 году под язык SmallTalk Кентом Бэком и Вардом Каннингемом.https://c2.com/doc/oopsla87.htmlС тех пор прошло: 37 лет.Предлагаю рассмотреть альтернативный подход, базирующийся на Composition Tree и концепции реактивного программирования. Подход направлен на улучшение масштабируемости, поддержания чистоты кода, учитывая прогресс современных языков.❗При разработке серьезных проектов тех руководитель должен решать задачу многокритериальной оптимизации: - минимизация сроков разработки - сдерживание роста кривой сложности доработок - сохранение максимального уровня чистоты кода (понятность, читабельность, разделение на слои, и т.д.) - контролируемость технического долга - рост компетентности сотрудников - bus фактор в отделе разработки > 1. Предлагаемый подход позволяет решить такую задачу.Напомню ключевые моменты Composition Tree. ⬇️Каждое приложение начинает свою работу с определенной точки, называемой точкой входа (Entry Point). Из данной точки происходит дальнейшее разветвление и исполнение кода.Структура этого разветвления похожа на дерево и называется Composition Tree. Места, где происходит разветвление, называются вершинами/узлами.Самая первая вершина - это Entry Point.В вершинах дерева осуществляется создание или получение необходимых компонентов и зависимостей. Здесь же устанавливаются связи между различными частями приложения, такими как бизнес-логика, пользовательский интерфейс, сер

#GC #Unity3DПриветствую 👋Подведу итог опроса ➡️ Сколько поколений (количество) использует GC в Unity? Вводные: используем il2cpp backend с выключенным Incremental GC.Поясню, что такое поколения: - Поколения (одно и более) означают, что к частям (фрагментам) кучи применяются критерии возраста.Даже в алгоритме с одним поколением объекты сортируются по возрасту. GC выполняет подчистку, в том числе опираясь на эти критерии. - При отсутствии поколений GC все объекты обрабатываются одинаково, независимо от того, как долго они существовали в памяти.❗В Unity при использовании il2cpp backend с выключенным Incremental GC используется Boehm-Demers-Weiser (BDW) garbage collector.Алгоритм работы - Mark-and-Sweep.Основные этапы работы алгоритма: - Mark Сборщик мусора начинает с набора объектов, называемых "корневыми" (Root). Корневые объекты это те, которые напрямую доступны из стека (например, локальные переменные и параметры функций) или из глобальных переменных. Сборщик мусора обходит все объекты, доступные из корней, следуя ссылкам между объектами. Каждый достижимый (доступный) объект отмечается как "живой". Этот процесс продолжается рекурсивно, пока не будут найдены все объекты, доступные из корней. - Sweep Сборщик мусора просматривает все объекты в управляемой куче и ищет те, которые не были отмечены на этапе отметки. Все неотмеченные объекты считаются "мусором" и удаляются, то есть память, которую они занимали, освобождается. После завершения этапа очистки сборщик мусора снимает отметки с всех оставшихся объектов, чтобы подготовить их к следующему циклу сборки мусора.Важные моменты в реализации BDW: - Сканирование Root - Трассировка объектов. Строит граф объектов и вычисляет их доступность - Ведет подсчет ссылок на объекты. Требуется для того, чтобы определить, когда на объект больше никто не ссылается - ❗Не поддерживает поколения - Выполняет процедуру финализации для недоступных объектов - Работает в режиме stop the world. Это означает, что

Дорогая женская часть нашего канала ❤️Поздравляем вас с 8 Марта, с Международным Женским Днем 🥳🥂🍾Желаем реализации в каждой из выбранных сфер и интересных задач! Больше улыбок и положительных эмоций! С праздником 💐