Всем привет 👋 Предлагаю принять участие в опросе! На собесах часто спрашивают ➡️ Сколько поколений (количество) использует GC в Unity? Вводные: используем il2cpp backend с выключенным Incremental GC.
Final Results
35%
не использует поколения
7%
1
26%
2
28%
3
4%
Свой вариант ответа
#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. Это означает, что выполнение кода приложения периодически полностью приостанавливается.
Поэтому правильным ответом на вопрос будет:
В Unity при использовании il2cpp backend с выключенным Incremental GC поколения не используются!
35% участников ответило правильно 🤝
Всем хорошего дня 👋
Приветствую 👋
Подведу итог опроса ➡️ Сколько поколений (количество) использует 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. Это означает, что выполнение кода приложения периодически полностью приостанавливается.
Поэтому правильным ответом на вопрос будет:
В Unity при использовании il2cpp backend с выключенным Incremental GC поколения не используются!
35% участников ответило правильно 🤝
Всем хорошего дня 👋
#архитектура #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.
В вершинах дерева осуществляется создание или получение необходимых компонентов и зависимостей.
Здесь же устанавливаются связи между различными частями приложения, такими как бизнес-логика, пользовательский интерфейс, сервисы и прочее.
Каждая вершина в дереве включает в себя контекст, который содержит все необходимые зависимости для данного участка кода.
Узлы или вершины в дереве соединены между собой через их контексты.
Продолжение 👇
Приветствую 👋
У меня для вас большой блок информации для осмысления и анализа.
Все, кто интересуется архитектурой приложений, знают и стараются опираться на принципы 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.
В вершинах дерева осуществляется создание или получение необходимых компонентов и зависимостей.
Здесь же устанавливаются связи между различными частями приложения, такими как бизнес-логика, пользовательский интерфейс, сервисы и прочее.
Каждая вершина в дереве включает в себя контекст, который содержит все необходимые зависимости для данного участка кода.
Узлы или вершины в дереве соединены между собой через их контексты.
Продолжение 👇
#архитектура #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-Independent Principle):
Используется слоистый подход к архитектуре, в котором каждый слой (UI, бизнес-логика, данные и др.) работает независимо, что повышает модульность и упрощает тестирование.
Слой в архитектуре приложений - это логическое разделение классов приложения, которое обеспечивает разграничение функциональности.
Каждый слой отвечает за определенную область задач и обладает своей ответственностью в контексте многоуровневой архитектуры.
❗Основных слоёв - 7:
- Entity Layer (вершина дерева Composition Tree)
- Presentation Model Layer (слой бизнес-логики)
- View Layer (слой представления)
- Service Layer (слой сервисов)
- Communication Layer (слой связей)
- Content/Data Layer (слой контента/данных)
- State Layer (слой состояний).
Вспомогательными слоями могут выступать сторонние библиотеки.
E - Закрытая инкапсуляция (Enclosed Encapsulation Principle):
Методы и переменные классов бизнес-логики приложения должны быть максимально закрыты (с модификатором доступа "private").
Это снижает зависимость между различными частями кода и упрощает поддержку и изменение приложения.
Благодарю за внимание!
Жду ваши вопросы в комментариях!
Хороших выходных 🖐️
Итак рассмотрим подход на базе 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-Independent Principle):
Используется слоистый подход к архитектуре, в котором каждый слой (UI, бизнес-логика, данные и др.) работает независимо, что повышает модульность и упрощает тестирование.
Слой в архитектуре приложений - это логическое разделение классов приложения, которое обеспечивает разграничение функциональности.
Каждый слой отвечает за определенную область задач и обладает своей ответственностью в контексте многоуровневой архитектуры.
❗Основных слоёв - 7:
- Entity Layer (вершина дерева Composition Tree)
- Presentation Model Layer (слой бизнес-логики)
- View Layer (слой представления)
- Service Layer (слой сервисов)
- Communication Layer (слой связей)
- Content/Data Layer (слой контента/данных)
- State Layer (слой состояний).
Вспомогательными слоями могут выступать сторонние библиотеки.
E - Закрытая инкапсуляция (Enclosed Encapsulation Principle):
Методы и переменные классов бизнес-логики приложения должны быть максимально закрыты (с модификатором доступа "private").
Это снижает зависимость между различными частями кода и упрощает поддержку и изменение приложения.
Благодарю за внимание!
Жду ваши вопросы в комментариях!
Хороших выходных 🖐️
#архитектура
Всем привет 👋
По интенсивности постов в канале, вы могли догадаться, что, к сожалению, у меня сейчас очень сильная загруженность. Оживим канал вместе 🤝
Сегодня поговорим про стратегии разделения логики в игровых проектах: от тонкой к толстой бизнес-логике.
Логика представления - это та часть логики, которая неотъемлемо относится к функционированию этого представления.
Бизнес-логика - это набор правил и алгоритмов, которые описывают, как игра должна работать на уровне взаимодействия объектов, принятия решений и выполнения действий. Она отвечает за то, как игра реагирует на действия игрока, как меняется состояние игры в ответ на эти действия, и т.д.
Подчеркну, что в целом бизнес-логика может работать вообще без представлений.
‼️Важное различие между бизнес-логикой и логикой представления в том, что первая отвечает за правила и процессы, определяющие ход игры, а вторая - за то, как эта информация передаётся игроку в виде визуальных и интерфейсных элементов.
Самый простой пример:
Бизнес-логика: У персонажа уменьшилось здоровье на 10 единиц после атаки врага.
Логика представления: Этот факт отражается на экране в виде уменьшения полосы здоровья и вспышки красного цвета.
Рассмотрим еще некоторые примеры из жизни, которые не всегда являются однозначными.
Вам необходимо попасть из точки А в Б.
Закрыть потребность можно разными способами:
- Вариант 1 - такси;
- Вариант 2 - самостоятельная поездка за рулем.
Вариант 1. Поездка на такси.
Участники:
- Вы, как пассажир задаете точку А и Б;
- Автомобиль;
- Водитель такси - знает как управлять автомобилем, ему известен маршрут поездки.
Садясь в машину, через какое-то время вы оказываетесь в точке Б, считаем что вы полностью доверились водителю и в процессе поездки не влияли на то, как именно она осуществлялась.
В данном примере:
Роль бизнес-логики выполняет пассажир, определяя высокоуровневую задачу, задавая начальную и конечную точки маршрута.
Представление - такси + водитель. Для пассажира и сторонних наблюдателей - виден процесс - машина едет.
Логика представления - навыки водителя и скрытый от глаз механизм работы машины.
Вариант 2 - самостоятельная поездка за рулем.
Участники:
- Вы в роли водителя и пассажира;
- Автомобиль.
В таком случае вы отвечаете за перемещение, выполняя роль водителя и вникая в маршрут, чтобы прибыть в точку Б.
Также вам необходимо владеть навыками вождения и топографии.
Из примеров видно, что в слой представления может быть зашито разное количество логики.
В данном примере:
Машина - представление, имеющее меньше логики, в сравнении с примером, где вы пользуетесь услугами такси.
Садясь за руль в качестве водителя вы выполняете роль бизнес-логики, берёте на себя управление машиной, отвечаете за маршрут.
Толстая бизнес-логика включает в себя большинство или все игровые механики и правила, централизованно управляя поведением игры.
В данном подходе слой представления в основном отвечает за визуализацию и ввод, но не вмешивается в логические операции.
Тонкая бизнес-логика ограничивается минимальным набором действий, делегируя большую часть поведенческой логики слою представления.
Данный подход позволяет представлению адаптироваться и изменяться без необходимости переписывать бизнес-логику.
Продолжение 👇
Всем привет 👋
По интенсивности постов в канале, вы могли догадаться, что, к сожалению, у меня сейчас очень сильная загруженность. Оживим канал вместе 🤝
Сегодня поговорим про стратегии разделения логики в игровых проектах: от тонкой к толстой бизнес-логике.
Логика представления - это та часть логики, которая неотъемлемо относится к функционированию этого представления.
Бизнес-логика - это набор правил и алгоритмов, которые описывают, как игра должна работать на уровне взаимодействия объектов, принятия решений и выполнения действий. Она отвечает за то, как игра реагирует на действия игрока, как меняется состояние игры в ответ на эти действия, и т.д.
Подчеркну, что в целом бизнес-логика может работать вообще без представлений.
‼️Важное различие между бизнес-логикой и логикой представления в том, что первая отвечает за правила и процессы, определяющие ход игры, а вторая - за то, как эта информация передаётся игроку в виде визуальных и интерфейсных элементов.
Самый простой пример:
Бизнес-логика: У персонажа уменьшилось здоровье на 10 единиц после атаки врага.
Логика представления: Этот факт отражается на экране в виде уменьшения полосы здоровья и вспышки красного цвета.
Рассмотрим еще некоторые примеры из жизни, которые не всегда являются однозначными.
Вам необходимо попасть из точки А в Б.
Закрыть потребность можно разными способами:
- Вариант 1 - такси;
- Вариант 2 - самостоятельная поездка за рулем.
Вариант 1. Поездка на такси.
Участники:
- Вы, как пассажир задаете точку А и Б;
- Автомобиль;
- Водитель такси - знает как управлять автомобилем, ему известен маршрут поездки.
Садясь в машину, через какое-то время вы оказываетесь в точке Б, считаем что вы полностью доверились водителю и в процессе поездки не влияли на то, как именно она осуществлялась.
В данном примере:
Роль бизнес-логики выполняет пассажир, определяя высокоуровневую задачу, задавая начальную и конечную точки маршрута.
Представление - такси + водитель. Для пассажира и сторонних наблюдателей - виден процесс - машина едет.
Логика представления - навыки водителя и скрытый от глаз механизм работы машины.
Вариант 2 - самостоятельная поездка за рулем.
Участники:
- Вы в роли водителя и пассажира;
- Автомобиль.
В таком случае вы отвечаете за перемещение, выполняя роль водителя и вникая в маршрут, чтобы прибыть в точку Б.
Также вам необходимо владеть навыками вождения и топографии.
Из примеров видно, что в слой представления может быть зашито разное количество логики.
В данном примере:
Машина - представление, имеющее меньше логики, в сравнении с примером, где вы пользуетесь услугами такси.
Садясь за руль в качестве водителя вы выполняете роль бизнес-логики, берёте на себя управление машиной, отвечаете за маршрут.
Толстая бизнес-логика включает в себя большинство или все игровые механики и правила, централизованно управляя поведением игры.
В данном подходе слой представления в основном отвечает за визуализацию и ввод, но не вмешивается в логические операции.
Тонкая бизнес-логика ограничивается минимальным набором действий, делегируя большую часть поведенческой логики слою представления.
Данный подход позволяет представлению адаптироваться и изменяться без необходимости переписывать бизнес-логику.
Продолжение 👇
#архитектура
Рассмотрим еще один пример: два типа управления самолетом в игровом симуляторе:
- Полностью ручное управление самолетом = толстая бизнес-логика.
На стороне бизнес-логики вся ответственность за управление самолётом: взлёт, полёт, посадку и атаку.
Представление занимается только отображением и передачей команд от пользователя.
В данном случае бизнес-логика помимо описания работы игровой логики будет включать в себя часть, которая отвечает за работу представлений.
- Автоматическое управление самолетом = тонкая бизнес-логика.
Бизнес-логика передает базовые команды, такие как перемещение из точки А в точку Б или выполнение атаки.
Сложные механизмы управления, такие как автовзлёт, посадка, полёт через 2 точки реализованы на стороне представления.
Бизнес-логика при этом может больше концентрироваться на реализации логики игры, а не логике того, как должно работать представление.
👉 Существует мнение:
- принцип работы динамического объекта в игре всегда нужно разделять на бизнес-логику, которая полностью отвечает за поведение этого объекта и представление, которое отображает то, что в него приходит.
На практике такой подход не всегда удобен, иногда проще сделать более толстое представление, так как с ним гораздо проще работать в “песочнице” при построении MVP (см. пример с самолётом выше). При этом логика представления не должна являться частью бизнес-логики игры.
- толстая бизнес-логика легко переносится между проектами, так как она мало зависит от конкретного представления и интерфейса пользователя.
Однако на практике, в большинстве случаев получается, что каждый проект - уникален и такого рода перенос требует существенного времени.
- тонкая бизнес-логика требует значительных изменений при переносе, так как часть поведенческой логики тесно связана с конкретными элементами представления.
На практике, префабы с правильно подготовленными скриптами имеют хорошую переносимость между проектами и их проще тестировать.
‼️Правильное понимание контекста проекта и адаптации стратегий разработки под уникальные требования и цели каждой конкретной игры очень важно.
От этого зависит, как будет читаться код игры, насколько просто будет вносить изменения и интегрировать новые фичи.
⚠️ На мой взгляд во всём должен быть баланс, не стоит пытаться делать тонким слой представления только ради того, чтобы сделать его тонким и наоборот.
Именно вы, как разработчик/лид/тимлид/CTO вносите вклад в решение задачи успеха, качества, удобности разработки и развитии проекта.
Хорошей всем недели 💪.
Рассмотрим еще один пример: два типа управления самолетом в игровом симуляторе:
- Полностью ручное управление самолетом = толстая бизнес-логика.
На стороне бизнес-логики вся ответственность за управление самолётом: взлёт, полёт, посадку и атаку.
Представление занимается только отображением и передачей команд от пользователя.
В данном случае бизнес-логика помимо описания работы игровой логики будет включать в себя часть, которая отвечает за работу представлений.
- Автоматическое управление самолетом = тонкая бизнес-логика.
Бизнес-логика передает базовые команды, такие как перемещение из точки А в точку Б или выполнение атаки.
Сложные механизмы управления, такие как автовзлёт, посадка, полёт через 2 точки реализованы на стороне представления.
Бизнес-логика при этом может больше концентрироваться на реализации логики игры, а не логике того, как должно работать представление.
👉 Существует мнение:
- принцип работы динамического объекта в игре всегда нужно разделять на бизнес-логику, которая полностью отвечает за поведение этого объекта и представление, которое отображает то, что в него приходит.
На практике такой подход не всегда удобен, иногда проще сделать более толстое представление, так как с ним гораздо проще работать в “песочнице” при построении MVP (см. пример с самолётом выше). При этом логика представления не должна являться частью бизнес-логики игры.
- толстая бизнес-логика легко переносится между проектами, так как она мало зависит от конкретного представления и интерфейса пользователя.
Однако на практике, в большинстве случаев получается, что каждый проект - уникален и такого рода перенос требует существенного времени.
- тонкая бизнес-логика требует значительных изменений при переносе, так как часть поведенческой логики тесно связана с конкретными элементами представления.
На практике, префабы с правильно подготовленными скриптами имеют хорошую переносимость между проектами и их проще тестировать.
‼️Правильное понимание контекста проекта и адаптации стратегий разработки под уникальные требования и цели каждой конкретной игры очень важно.
От этого зависит, как будет читаться код игры, насколько просто будет вносить изменения и интегрировать новые фичи.
⚠️ На мой взгляд во всём должен быть баланс, не стоит пытаться делать тонким слой представления только ради того, чтобы сделать его тонким и наоборот.
Именно вы, как разработчик/лид/тимлид/CTO вносите вклад в решение задачи успеха, качества, удобности разработки и развитии проекта.
Хорошей всем недели 💪.
Выбираем тему публикации 👇
Final Results
27%
Портрет хорошего разработчика
27%
Стал лидом, не пишешь код, стоит ли беспокоится?
39%
Современный тренд отрицания знаний
8%
Свой вариант (в комментариях)
С отрывом в 12% победил вариант: "Современный тренд отрицания знаний".
Пока я готовлю публикацию, предлагаю решить небольшую задачку 👇
Красное колесо радиусом R/2 обкатывает черное колесо радиусом R.
На черном колесе зафиксирована точка A - начало обката для красного колеса.
❓Сколько полных оборотов сделает красное колесо, продолжив обкат, вернувшись в точку A?
Ответы пишите в комментариях.
Пока я готовлю публикацию, предлагаю решить небольшую задачку 👇
Красное колесо радиусом R/2 обкатывает черное колесо радиусом R.
На черном колесе зафиксирована точка A - начало обката для красного колеса.
❓Сколько полных оборотов сделает красное колесо, продолжив обкат, вернувшись в точку A?
Ответы пишите в комментариях.
#тренды #мнение
Приветствую 👋.
Сегодня говорим про:
Тренд отрицания знаний в индустрии: "И так сойдет".
В последние годы в игровой индустрии (и не только) нарастающий тренд - отказ от глубокого изучения фундаментальных знаний.
На определенном этапе некоторым разработчикам начинает казаться, что на длинной дистанции можно выехать на интуиции и быстрых решениях, а изучение специализированной литературы, освоение базовых концепций не обязательны.
Однако это может обернуться серьезными последствиями в будущем.
Отрицание знаний в контексте игровой индустрии - это сознательное игнорирование разработчиками фундаментальных аспектов разработки игр,
таких как основы программирования, математические принципы, работа с игровыми движками, проектирование геймплея и изучение/преемственность опыта других студий.
Желание достичь успеха, полагаясь только на популярные инструменты и готовые решения, без глубокого погружения в теорию или опыт других.
"Быстрые победы" дают готовые игровые движки, фреймворки и плагины, чаты GPT и т.д.
Всё это полезные инструменты, важен подход к работе с ними: погружаться или использовать не стремясь понять, как они работают изнутри, что стоит за конкретным решением. Бездумное использование создает потолок для разработчика.
❗Не стоит отрицать новое.
Важен баланс, берешь быстрое решение - понимаешь его ограничения, подводные камни, понимаешь как обойти. Такие решения - доза дофамина “у меня получилось”, можно использовать как ступеньку на следующий уровень погружения.
Продолжение 👇
Приветствую 👋.
Сегодня говорим про:
Тренд отрицания знаний в индустрии: "И так сойдет".
В последние годы в игровой индустрии (и не только) нарастающий тренд - отказ от глубокого изучения фундаментальных знаний.
На определенном этапе некоторым разработчикам начинает казаться, что на длинной дистанции можно выехать на интуиции и быстрых решениях, а изучение специализированной литературы, освоение базовых концепций не обязательны.
Однако это может обернуться серьезными последствиями в будущем.
Отрицание знаний в контексте игровой индустрии - это сознательное игнорирование разработчиками фундаментальных аспектов разработки игр,
таких как основы программирования, математические принципы, работа с игровыми движками, проектирование геймплея и изучение/преемственность опыта других студий.
Желание достичь успеха, полагаясь только на популярные инструменты и готовые решения, без глубокого погружения в теорию или опыт других.
"Быстрые победы" дают готовые игровые движки, фреймворки и плагины, чаты GPT и т.д.
Всё это полезные инструменты, важен подход к работе с ними: погружаться или использовать не стремясь понять, как они работают изнутри, что стоит за конкретным решением. Бездумное использование создает потолок для разработчика.
❗Не стоит отрицать новое.
Важен баланс, берешь быстрое решение - понимаешь его ограничения, подводные камни, понимаешь как обойти. Такие решения - доза дофамина “у меня получилось”, можно использовать как ступеньку на следующий уровень погружения.
Продолжение 👇
#тренды #мнение
Чем это опасно?
Рассмотрим, с какими ошибками можно столкнуться, по мере роста и развития проекта. И к чему может привести пренебрежение определенными набором знаний.
Рассмотрим некоторые примеры.
Поверхностное изучение инструментов разработки.
Использование популярных движков, таких как Unity или Unreal Engine без углубления в их возможности и работу под капотом, приводит к тому, что, столкнувшись с нестандартной задачей, команда не может эффективно её решить, полагаясь на плагины и готовые решения вместо собственного кода.
Алгоритмы и структуры данных.
Речь про подход к выбору алгоритмов и структур данных для решения задач.
На примере работы с коллекциями игровых объектов.
Например, стоит задача хранить и искать предметы инвентаря на карте.
Разработчик может использовать:
- простые массивы или списки
- оптимизированные структуры данных: сбалансированные деревья или хеш-таблицы.
Простые структуры (массивы и списки) будут работать на небольших проектах, но при увеличении масштаба игры (большие миры, сотни или тысячи объектов) производительность резко падает.
Игра начинает "лагать", возникают задержки при взаимодействии с объектами.
Решить проблему можно правильным выбором структур данных и алгоритмов.
Линейная алгебра и векторные операции.
Работа с 3D/2D-объектами и их позиционированием в пространстве требует понимания линейной алгебры, особенно векторов и матриц.
Можно полагаться исключительно на встроенные функции движков, без погружения в работу поворотов, масштабирования и трансформации объектов.
Начинающие разработчики могут сталкиваться с проблемами при работе с камерой или анимацией персонажей.
Например, при попытке запрограммировать плавные повороты персонажа при повороте камеры, возникают дерганые анимации, некорректные повороты.
Уйти от проблемы можно через кватернионы или правильные векторные вычисления.
Проблемы с коллизиями и физикой.
Работа с физическими объектами требует понимания основ механики и физических уравнений.
При использовании встроенных систем физики (например, в Unity или Unreal Engine), проблемы возникают при реализации нестандартных физических взаимодействиях.
Создание точной системы коллизий может быть проблематичным при отсутствии понимания работы основных алгоритмов обнаружения столкновений, таких как AABB (Axis-Aligned Bounding Box) или OBB (Oriented Bounding Box).
Тот самый случай, когда персонажи могут "проваливаться" сквозь стены или застревать в объектах.
Продолжение 👇
Чем это опасно?
Рассмотрим, с какими ошибками можно столкнуться, по мере роста и развития проекта. И к чему может привести пренебрежение определенными набором знаний.
Рассмотрим некоторые примеры.
Поверхностное изучение инструментов разработки.
Использование популярных движков, таких как Unity или Unreal Engine без углубления в их возможности и работу под капотом, приводит к тому, что, столкнувшись с нестандартной задачей, команда не может эффективно её решить, полагаясь на плагины и готовые решения вместо собственного кода.
Алгоритмы и структуры данных.
Речь про подход к выбору алгоритмов и структур данных для решения задач.
На примере работы с коллекциями игровых объектов.
Например, стоит задача хранить и искать предметы инвентаря на карте.
Разработчик может использовать:
- простые массивы или списки
- оптимизированные структуры данных: сбалансированные деревья или хеш-таблицы.
Простые структуры (массивы и списки) будут работать на небольших проектах, но при увеличении масштаба игры (большие миры, сотни или тысячи объектов) производительность резко падает.
Игра начинает "лагать", возникают задержки при взаимодействии с объектами.
Решить проблему можно правильным выбором структур данных и алгоритмов.
Линейная алгебра и векторные операции.
Работа с 3D/2D-объектами и их позиционированием в пространстве требует понимания линейной алгебры, особенно векторов и матриц.
Можно полагаться исключительно на встроенные функции движков, без погружения в работу поворотов, масштабирования и трансформации объектов.
Начинающие разработчики могут сталкиваться с проблемами при работе с камерой или анимацией персонажей.
Например, при попытке запрограммировать плавные повороты персонажа при повороте камеры, возникают дерганые анимации, некорректные повороты.
Уйти от проблемы можно через кватернионы или правильные векторные вычисления.
Проблемы с коллизиями и физикой.
Работа с физическими объектами требует понимания основ механики и физических уравнений.
При использовании встроенных систем физики (например, в Unity или Unreal Engine), проблемы возникают при реализации нестандартных физических взаимодействиях.
Создание точной системы коллизий может быть проблематичным при отсутствии понимания работы основных алгоритмов обнаружения столкновений, таких как AABB (Axis-Aligned Bounding Box) или OBB (Oriented Bounding Box).
Тот самый случай, когда персонажи могут "проваливаться" сквозь стены или застревать в объектах.
Продолжение 👇
#тренды #мнение
Теория пути и ИИ.
Речь про оптимизацию движения персонажей и их взаимодействия с окружением.
На старте можно положиться на готовые решения для навигации ИИ, не разбираясь в основах, таких как графы, алгоритмы поиска пути (например, A*).
Однако, при разработке большой карты или сложного уровня в игре, если не уделить внимание оптимизации алгоритма поиска под условия, можно столкнуться с проблемой, когда персонажи или враги начинают "застревать" в определённых участках или перемещаются слишком медленно, неэффективно прокладывая маршруты.
Работа с анимациями.
Анимация персонажей и объектов в игре требует не только художественного подхода, но и точного управления переходами между состояниями.
Необходимы базовые знания об алгоритмах, управляющих "состояниями" в игре, иначе будут столкновения с проблемами.
Многие анимационные системы работают на основе конечных автоматов, где каждому состоянию соответствует конкретная анимация (например, бег, прыжок, атака).
Если разработчик не понимает, как правильно организовать эти переходы, возникает ситуация, когда анимации "ломаются", например, персонаж начинает бег с неправильной ноги или атакует из странной позы.
Работа с сетевой архитектурой.
Мультиплеерные игры требуют серьёзных знаний сетевой архитектуры и асинхронного программирования.
Недостаток понимания, как работают протоколы, синхронизация данных между клиентами и сервером, может привести к следующим лагам: рассинхронизации данных в многопользовательской игре, когда игроки начинают "телепортироваться", происходят частые отключения от сервера.
Знания в области оптимизации.
Часто разработчики, особенно мобильных и инди-игр, игнорируют важность оптимизации кода и ресурсов.
Вместо того чтобы изучить принципы работы с графикой, памятью и производительностью, они выпускают игры, которые не могут работать на менее мощных устройствах, что сужает аудиторию и ведет к снижению прибыли.
❗Тренд отрицания знаний усиливает доступность упрощающих жизнь разработчика инструментов, дефицит времени и стремление к быстрым результатам.
Продолжение 👇
Теория пути и ИИ.
Речь про оптимизацию движения персонажей и их взаимодействия с окружением.
На старте можно положиться на готовые решения для навигации ИИ, не разбираясь в основах, таких как графы, алгоритмы поиска пути (например, A*).
Однако, при разработке большой карты или сложного уровня в игре, если не уделить внимание оптимизации алгоритма поиска под условия, можно столкнуться с проблемой, когда персонажи или враги начинают "застревать" в определённых участках или перемещаются слишком медленно, неэффективно прокладывая маршруты.
Работа с анимациями.
Анимация персонажей и объектов в игре требует не только художественного подхода, но и точного управления переходами между состояниями.
Необходимы базовые знания об алгоритмах, управляющих "состояниями" в игре, иначе будут столкновения с проблемами.
Многие анимационные системы работают на основе конечных автоматов, где каждому состоянию соответствует конкретная анимация (например, бег, прыжок, атака).
Если разработчик не понимает, как правильно организовать эти переходы, возникает ситуация, когда анимации "ломаются", например, персонаж начинает бег с неправильной ноги или атакует из странной позы.
Работа с сетевой архитектурой.
Мультиплеерные игры требуют серьёзных знаний сетевой архитектуры и асинхронного программирования.
Недостаток понимания, как работают протоколы, синхронизация данных между клиентами и сервером, может привести к следующим лагам: рассинхронизации данных в многопользовательской игре, когда игроки начинают "телепортироваться", происходят частые отключения от сервера.
Знания в области оптимизации.
Часто разработчики, особенно мобильных и инди-игр, игнорируют важность оптимизации кода и ресурсов.
Вместо того чтобы изучить принципы работы с графикой, памятью и производительностью, они выпускают игры, которые не могут работать на менее мощных устройствах, что сужает аудиторию и ведет к снижению прибыли.
❗Тренд отрицания знаний усиливает доступность упрощающих жизнь разработчика инструментов, дефицит времени и стремление к быстрым результатам.
Продолжение 👇
#тренды #мнение
Как избежать отрицания знаний?
Изучение основ: даже если это занимает слишком много времени, является инвестицией в будущее.
Например, понимание принципов геймдизайна, работы движка и оптимизации поможет избежать типичных ошибок и ускорить разработку в долгосрочной перспективе.
Непрерывное обучение: игровая индустрия быстро развивается, важно постоянно обновлять свои знания, изучая новые технологии и подходы.
Преемственность опыта других: изучать чужой опыт решения - читать книги, статьи, посещать конференции и слушать советы более опытных разработчиков.
Одним из серьезных последствий тренда отрицания знаний является атрофия логического мышления.
Если специалист избегает глубокого изучения и понимания фундаментальных концепций, его способность планировать и решать сложные, многоходовые задачи постепенно снижается.
Без практики в разработке многократных шагов для достижения цели мозг привыкает к поиску простых и быстрых решений, не требующих стратегического мышления.
Пример:
Есть команду разработчиков, которая привыкла использовать готовые решения и плагины для реализации игровых механик.
Они редко углубляются в код или пытаются понять, как работают эти инструменты.
И вот перед ними встает задача создать уникальную функцию, требующую нескольких этапов планирования и реализации.
Например, разработка сложной системы ИИ для NPC, которая должна учитывать различные параметры окружающей среды и действий игрока.
Для решения этой задачи необходимо:
Спланировать архитектуру системы, определить основные компоненты и их взаимодействие.
Реализовать базовые алгоритмы поведения, учитывая возможные сценарии.
Оптимизировать производительность, чтобы система не нагружала ресурсы игры.
Провести тестирование и отладку, выявляя и исправляя ошибки в логике.
❗Без навыков планирования и логического мышления на два и более шагов вперед команда не сможет эффективно пройти через эти этапы.
Проект застопорится, сроки будут сорваны, а качество игры пострадает.
Продолжение 👇
Как избежать отрицания знаний?
Изучение основ: даже если это занимает слишком много времени, является инвестицией в будущее.
Например, понимание принципов геймдизайна, работы движка и оптимизации поможет избежать типичных ошибок и ускорить разработку в долгосрочной перспективе.
Непрерывное обучение: игровая индустрия быстро развивается, важно постоянно обновлять свои знания, изучая новые технологии и подходы.
Преемственность опыта других: изучать чужой опыт решения - читать книги, статьи, посещать конференции и слушать советы более опытных разработчиков.
Одним из серьезных последствий тренда отрицания знаний является атрофия логического мышления.
Если специалист избегает глубокого изучения и понимания фундаментальных концепций, его способность планировать и решать сложные, многоходовые задачи постепенно снижается.
Без практики в разработке многократных шагов для достижения цели мозг привыкает к поиску простых и быстрых решений, не требующих стратегического мышления.
Пример:
Есть команду разработчиков, которая привыкла использовать готовые решения и плагины для реализации игровых механик.
Они редко углубляются в код или пытаются понять, как работают эти инструменты.
И вот перед ними встает задача создать уникальную функцию, требующую нескольких этапов планирования и реализации.
Например, разработка сложной системы ИИ для NPC, которая должна учитывать различные параметры окружающей среды и действий игрока.
Для решения этой задачи необходимо:
Спланировать архитектуру системы, определить основные компоненты и их взаимодействие.
Реализовать базовые алгоритмы поведения, учитывая возможные сценарии.
Оптимизировать производительность, чтобы система не нагружала ресурсы игры.
Провести тестирование и отладку, выявляя и исправляя ошибки в логике.
❗Без навыков планирования и логического мышления на два и более шагов вперед команда не сможет эффективно пройти через эти этапы.
Проект застопорится, сроки будут сорваны, а качество игры пострадает.
Продолжение 👇
#тренды #мнение
Последствия для разработки.
Снижение качества продуктов: неспособность решать сложные задачи приводит к упрощению игровых механик, что делает игры менее интересными и конкурентоспособными.
Отсутствие инноваций: без глубокого понимания и способности к многократному планированию разработчики не могут внедрять новые идеи и технологии.
Профессиональная стагнация: разработчики перестают развиваться, их навыки не улучшаются, что ограничивает карьерные возможности.
Долгосрочное влияние на индустрию: если тренд отрицания знаний сохраниться, это может привести к общему снижению уровня профессионализма в индустрии.
Будет меньше специалистов, способных решать комплексные задачи, разрабатывать инновационные продукты и двигать индустрию вперед.
Это негативно скажется на разнообразии и качестве игр, удовлетворенности игроков и экономической устойчивости компаний.
❗Как противостоять атрофии логического мышления.
Практиковаться в решении сложных задач: постоянно ставить перед собой вызовы, требующие многократного планирования и последовательных действий.
Изучение алгоритмов и структур данных: укрепит базовые навыки программирования и логического мышления.
Участие в профессиональных сообществах: обмен опытом с коллегами стимулирует развитие и позволяет взглянуть на проблемы с разных сторон.
Рефлексия и анализ своих решений: после завершения проекта полезно проанализировать, какие шаги были предприняты, что можно улучшить в будущем.
Современный тренд отрицания знаний - это опасный путь, который может казаться быстрым и легким на первых порах, но в долгосрочной перспективе ведет к стагнации и ограничению возможностей, негативно влияет на когнитивные способности.
Осознание ценности знаний и их освоение - ключевые факторы успеха, которые позволяют создавать качественные и востребованные игры.
Атрофия логического мышления затрудняет решение многоходовых задач, что критически важно в разработке современных игр.
Для сохранения конкурентоспособности и профессионального роста необходимо осознанно подходить к своему развитию, постоянно обучаться и практиковаться в решении сложных задач.
Всем хороших выходных 💪.
Последствия для разработки.
Снижение качества продуктов: неспособность решать сложные задачи приводит к упрощению игровых механик, что делает игры менее интересными и конкурентоспособными.
Отсутствие инноваций: без глубокого понимания и способности к многократному планированию разработчики не могут внедрять новые идеи и технологии.
Профессиональная стагнация: разработчики перестают развиваться, их навыки не улучшаются, что ограничивает карьерные возможности.
Долгосрочное влияние на индустрию: если тренд отрицания знаний сохраниться, это может привести к общему снижению уровня профессионализма в индустрии.
Будет меньше специалистов, способных решать комплексные задачи, разрабатывать инновационные продукты и двигать индустрию вперед.
Это негативно скажется на разнообразии и качестве игр, удовлетворенности игроков и экономической устойчивости компаний.
❗Как противостоять атрофии логического мышления.
Практиковаться в решении сложных задач: постоянно ставить перед собой вызовы, требующие многократного планирования и последовательных действий.
Изучение алгоритмов и структур данных: укрепит базовые навыки программирования и логического мышления.
Участие в профессиональных сообществах: обмен опытом с коллегами стимулирует развитие и позволяет взглянуть на проблемы с разных сторон.
Рефлексия и анализ своих решений: после завершения проекта полезно проанализировать, какие шаги были предприняты, что можно улучшить в будущем.
Современный тренд отрицания знаний - это опасный путь, который может казаться быстрым и легким на первых порах, но в долгосрочной перспективе ведет к стагнации и ограничению возможностей, негативно влияет на когнитивные способности.
Осознание ценности знаний и их освоение - ключевые факторы успеха, которые позволяют создавать качественные и востребованные игры.
Атрофия логического мышления затрудняет решение многоходовых задач, что критически важно в разработке современных игр.
Для сохранения конкурентоспособности и профессионального роста необходимо осознанно подходить к своему развитию, постоянно обучаться и практиковаться в решении сложных задач.
Всем хороших выходных 💪.
Всем привет 👋, пока я готовлю статью про тестирование, предлагаю принять участие в опросе. Вы включили dynamic batching и заметили, что на некоторых мобильных устройствах производительность ухудшилась. Из-за чего такое могло произойти?
Final Results
43%
Повышенная нагрузка на CPU
10%
Ограничения по вершинным атрибутам
15%
Проблемы с шейдерами
32%
Все варианты верные
Всем привет 👋, опрос закрыт.
Подводя итог, примерно 30% дали правильный ответ.
ℹ️ Правильный ответ: "Все варианты верные".
Даю разъяснения почему при включении dynamic batching может наблюдаться ухудшение производительности.
👇
Причины могут быть следующими:
- Повышенная нагрузка на CPU.
Dynamic batching выполняется на CPU, где объекты объединяются в один батч перед отправкой на GPU.
Процесс объединения геометрии и перерасчетов требует дополнительных ресурсов CPU.
На мобильных устройствах, где CPU менее мощные, чем на десктопе, эта дополнительная нагрузка может привести к снижению производительности.
- Ограничения по вершинным атрибутам:
Dynamic batching работает только с объектами, у которых количество вершин меньше 300 (для каждого объекта).
Если объекты превышают это ограничение, они не будут объединены, но процесс проверки все равно займет ресурсы.
- Перемещение данных между CPU и GPU:
Частые обновления и пересоздание батчей могут привести к увеличению объема данных, передаваемых между CPU и GPU, что особенно критично на мобильных устройствах с ограниченной пропускной способностью памяти.
- Совместимость материалов и шейдеров:
Объекты должны использовать один и тот же материал и шейдер.
- Transform объектов:
Объекты должны иметь одинаковые параметры Scale в своих transform'ах.
- Не поддерживаются некоторые функции:
Шейдеры с мультипассами или использующие определенные функции могут препятствовать батчингу.
- Dynamic batching не бесплатен:
Процесс батчинга сам по себе требует ресурсов CPU для подготовки данных.
Всем хороших выходных ✌️
Подводя итог, примерно 30% дали правильный ответ.
ℹ️ Правильный ответ: "Все варианты верные".
Даю разъяснения почему при включении dynamic batching может наблюдаться ухудшение производительности.
👇
Причины могут быть следующими:
- Повышенная нагрузка на CPU.
Dynamic batching выполняется на CPU, где объекты объединяются в один батч перед отправкой на GPU.
Процесс объединения геометрии и перерасчетов требует дополнительных ресурсов CPU.
На мобильных устройствах, где CPU менее мощные, чем на десктопе, эта дополнительная нагрузка может привести к снижению производительности.
- Ограничения по вершинным атрибутам:
Dynamic batching работает только с объектами, у которых количество вершин меньше 300 (для каждого объекта).
Если объекты превышают это ограничение, они не будут объединены, но процесс проверки все равно займет ресурсы.
- Перемещение данных между CPU и GPU:
Частые обновления и пересоздание батчей могут привести к увеличению объема данных, передаваемых между CPU и GPU, что особенно критично на мобильных устройствах с ограниченной пропускной способностью памяти.
- Совместимость материалов и шейдеров:
Объекты должны использовать один и тот же материал и шейдер.
- Transform объектов:
Объекты должны иметь одинаковые параметры Scale в своих transform'ах.
- Не поддерживаются некоторые функции:
Шейдеры с мультипассами или использующие определенные функции могут препятствовать батчингу.
- Dynamic batching не бесплатен:
Процесс батчинга сам по себе требует ресурсов CPU для подготовки данных.
Всем хороших выходных ✌️
#Unity3D #тестирование
Тестирование в Unity 3D на платформах Windows, Android и iOS: что, как и какими инструментами?
Тестирование - часть разработки игр, одна из важных составляющих фундамента, на котором строится всё здание вашего проекта.
Оно позволяет выявить узкие места, которые могут возникнуть после выхода продукта в мир, понять, насколько он стабилен и соответствует заявленным критериям по производительности, обеспечивая высокое качество на различных платформах: Windows, Android и iOS.
Особое внимание стоит уделять аспектам, связанным с монетизацией, ведь от их работы напрямую зависит прибыльность и успех игры.
Рассмотрим, что именно следует проверять, какими методами и инструментами это делать и на какие подводные камни обратить внимание.
Что тестировать?
🟢 Функциональность
Здесь мы погружаемся в саму суть игры: игровые механики, логику, взаимодействие пользователя с приложением.
Каждая кнопка, каждый жест должны работать безупречно, чтобы игроки могли полностью окунуться в созданный вами мир.
🟢 Производительность
Высокий FPS, быстрое время загрузки, оптимальное использование памяти и ресурсов процессора - всё это критически важно, особенно на мобильных устройствах с ограниченными ресурсами.
Игра должна не только выглядеть красиво, но и работать плавно.
🟢 Совместимость
Мир мобильных устройств разнообразен: разные модели, разрешения экранов, версии операционных систем.
Убедитесь, что игра корректно функционирует на всевозможных устройствах, чтобы охватить максимально широкую аудиторию.
🟢 Стабильность
Нет ничего хуже, чем игра, которая внезапно вылетает или зависает.
Выявление сбоев, критических ошибок и ситуаций, когда приложение может быть принудительно закрыто системой, должно быть в списке приоритетных задач.
🟢 Пользовательский интерфейс (UI/UX)
Интерфейс - лицо вашей игры.
Он должен быть не только красивым, но и интуитивно понятным и отзывчивым.
Тестируйте отображение и отклик элементов интерфейса на различных платформах и разрешениях экранов.
🟢 Сетевые функции
Если ваша игра включает мультиплеер или другие сетевые взаимодействия, убедитесь в безупречной работе этих функций.
Синхронизация, задержки, соединение с сервером - всё это влияет на впечатление игрока.
🟢 Тестирование локализаций
Ваша игра может достичь игроков из разных стран.
Различные языковые локали могут содержать специфичные символы или использовать различные форматы данных.
‼️Например, отличие в десятичных разделителях ("." и ",") может привести к неправильной работе приложения.
🟢 Монетизация
Монетизация - финансовый показатель востребованности вашего проекта, её проверка становится первоочерёдной задачей на этапе выхода продукта в мир.
Тестирование монетизации заключается в проверке корректной работы встроенных покупок, рекламы и других механизмов.
Без стабильной и надёжной системы монетизации даже самая увлекательная игра может не оправдать ожиданий разработчиков.
Продолжение 🔽
Тестирование в Unity 3D на платформах Windows, Android и iOS: что, как и какими инструментами?
Тестирование - часть разработки игр, одна из важных составляющих фундамента, на котором строится всё здание вашего проекта.
Оно позволяет выявить узкие места, которые могут возникнуть после выхода продукта в мир, понять, насколько он стабилен и соответствует заявленным критериям по производительности, обеспечивая высокое качество на различных платформах: Windows, Android и iOS.
Особое внимание стоит уделять аспектам, связанным с монетизацией, ведь от их работы напрямую зависит прибыльность и успех игры.
Рассмотрим, что именно следует проверять, какими методами и инструментами это делать и на какие подводные камни обратить внимание.
Что тестировать?
🟢 Функциональность
Здесь мы погружаемся в саму суть игры: игровые механики, логику, взаимодействие пользователя с приложением.
Каждая кнопка, каждый жест должны работать безупречно, чтобы игроки могли полностью окунуться в созданный вами мир.
🟢 Производительность
Высокий FPS, быстрое время загрузки, оптимальное использование памяти и ресурсов процессора - всё это критически важно, особенно на мобильных устройствах с ограниченными ресурсами.
Игра должна не только выглядеть красиво, но и работать плавно.
🟢 Совместимость
Мир мобильных устройств разнообразен: разные модели, разрешения экранов, версии операционных систем.
Убедитесь, что игра корректно функционирует на всевозможных устройствах, чтобы охватить максимально широкую аудиторию.
🟢 Стабильность
Нет ничего хуже, чем игра, которая внезапно вылетает или зависает.
Выявление сбоев, критических ошибок и ситуаций, когда приложение может быть принудительно закрыто системой, должно быть в списке приоритетных задач.
🟢 Пользовательский интерфейс (UI/UX)
Интерфейс - лицо вашей игры.
Он должен быть не только красивым, но и интуитивно понятным и отзывчивым.
Тестируйте отображение и отклик элементов интерфейса на различных платформах и разрешениях экранов.
🟢 Сетевые функции
Если ваша игра включает мультиплеер или другие сетевые взаимодействия, убедитесь в безупречной работе этих функций.
Синхронизация, задержки, соединение с сервером - всё это влияет на впечатление игрока.
🟢 Тестирование локализаций
Ваша игра может достичь игроков из разных стран.
Различные языковые локали могут содержать специфичные символы или использовать различные форматы данных.
‼️Например, отличие в десятичных разделителях ("." и ",") может привести к неправильной работе приложения.
🟢 Монетизация
Монетизация - финансовый показатель востребованности вашего проекта, её проверка становится первоочерёдной задачей на этапе выхода продукта в мир.
Тестирование монетизации заключается в проверке корректной работы встроенных покупок, рекламы и других механизмов.
Без стабильной и надёжной системы монетизации даже самая увлекательная игра может не оправдать ожиданий разработчиков.
Продолжение 🔽
#Unity3D #тестирование
Что еще нельзя оставлять без внимания в процессе тестирования игр:
🟢 Шейдеры
Речь о проверке шейдеров для различных графических архитектур в Unity, особенно при ориентации приложения на широкий спектр устройств на платформах Windows, Android и iOS.
Графические процессоры Adreno и Mali охватывают большую часть Android-устройств, в то время как Metal используется на устройствах Apple.
Особенности тестирования шейдеров:
Adreno: Известен своей эффективностью при работе с некоторыми типами вычислений, но может сталкиваться с проблемами при работе со сложными шейдерами, содержащими динамическое ветвление.
Проверять необходимо на различных моделях Adreno (например, серии Adreno 600), чтобы выявить узкие места.
Mali: Шейдеры для этих GPU иногда демонстрируют пониженную производительность при использовании сложных текстурных операций и большого количества инструкций ALU.
Для выявления проблем с производительностью используйте Mali Offline Compiler.
Metal: На iOS-устройствах необходимо удостовериться, что шейдеры работают корректно и оптимизированы для архитектуры Metal.
‼️Важно тестировать шейдеры на реальных устройствах, чтобы проверить, как они обрабатываются на уровне компиляции Metal и избежать потенциальных ошибок рендеринга.
Оптимизируйте ресурсы: старайтесь минимизировать количество draw call'ов и сложность шейдеров, чтобы избежать перегрузки GPU.
🟢 Тестирование нативных окон запроса разрешений
Речь про проверку системы при наличие/отсутствии пользовательских разрешений, таких как запросы на трекинг IDFA и push-уведомления.
Ошибки при реализации данных запросов могут привести к проблемам при модерации приложения в сторе.
Рекомендации по проверке:
- Избегать блокировки логики игры: никогда не делайте так, чтобы игра не могла продолжить работу, если пользователь отклоняет запрос разрешений. Например, если игрок не принял трекинг IDFA, интерфейс должен корректно обрабатывать это событие и не блокировать дальнейший прогресс.
- Тестирование на отказ: проверяйте, что приложение корректно реагирует на случаи, когда разрешение не принято.
Это поможет избежать ситуаций, когда ревьюер App Store или Google Play не может протестировать приложение должным образом, что приводит к отклонению.
🟢 FTUE и воронки игроков
FTUE (First Time User Experience) играет ключевую роль в удержании пользователей.
Анализ воронки игроков позволяет понять, насколько хорошо новая аудитория воспринимает ваш проект.
Рекомендации по тестированию FTUE:
Анализ цепочки действий игроков: аналитическая система должна отслеживать каждый шаг пользователя после первого запуска игры.
Сколько пользователей запустило игру, сколько прошло туториал, сколько достигло первого уровня и т.д.
‼️Метрики удержания: собирайте данные о количестве пользователей, покинувших игру на разных этапах. Это поможет выявить проблемные зоны и улучшить ранний игровой опыт.
Продолжение 🔽
Что еще нельзя оставлять без внимания в процессе тестирования игр:
🟢 Шейдеры
Речь о проверке шейдеров для различных графических архитектур в Unity, особенно при ориентации приложения на широкий спектр устройств на платформах Windows, Android и iOS.
Графические процессоры Adreno и Mali охватывают большую часть Android-устройств, в то время как Metal используется на устройствах Apple.
Особенности тестирования шейдеров:
Adreno: Известен своей эффективностью при работе с некоторыми типами вычислений, но может сталкиваться с проблемами при работе со сложными шейдерами, содержащими динамическое ветвление.
Проверять необходимо на различных моделях Adreno (например, серии Adreno 600), чтобы выявить узкие места.
Mali: Шейдеры для этих GPU иногда демонстрируют пониженную производительность при использовании сложных текстурных операций и большого количества инструкций ALU.
Для выявления проблем с производительностью используйте Mali Offline Compiler.
Metal: На iOS-устройствах необходимо удостовериться, что шейдеры работают корректно и оптимизированы для архитектуры Metal.
‼️Важно тестировать шейдеры на реальных устройствах, чтобы проверить, как они обрабатываются на уровне компиляции Metal и избежать потенциальных ошибок рендеринга.
Оптимизируйте ресурсы: старайтесь минимизировать количество draw call'ов и сложность шейдеров, чтобы избежать перегрузки GPU.
🟢 Тестирование нативных окон запроса разрешений
Речь про проверку системы при наличие/отсутствии пользовательских разрешений, таких как запросы на трекинг IDFA и push-уведомления.
Ошибки при реализации данных запросов могут привести к проблемам при модерации приложения в сторе.
Рекомендации по проверке:
- Избегать блокировки логики игры: никогда не делайте так, чтобы игра не могла продолжить работу, если пользователь отклоняет запрос разрешений. Например, если игрок не принял трекинг IDFA, интерфейс должен корректно обрабатывать это событие и не блокировать дальнейший прогресс.
- Тестирование на отказ: проверяйте, что приложение корректно реагирует на случаи, когда разрешение не принято.
Это поможет избежать ситуаций, когда ревьюер App Store или Google Play не может протестировать приложение должным образом, что приводит к отклонению.
🟢 FTUE и воронки игроков
FTUE (First Time User Experience) играет ключевую роль в удержании пользователей.
Анализ воронки игроков позволяет понять, насколько хорошо новая аудитория воспринимает ваш проект.
Рекомендации по тестированию FTUE:
Анализ цепочки действий игроков: аналитическая система должна отслеживать каждый шаг пользователя после первого запуска игры.
Сколько пользователей запустило игру, сколько прошло туториал, сколько достигло первого уровня и т.д.
‼️Метрики удержания: собирайте данные о количестве пользователей, покинувших игру на разных этапах. Это поможет выявить проблемные зоны и улучшить ранний игровой опыт.
Продолжение 🔽
#Unity3D #тестирование
Также не забываем про потенциально узкие места 🔽
🟢 Папки Resources
Часто разработчики для хранения ассетов используют папку Resources в Unity, это может казаться удобным способом хранения для загрузки во время выполнения.
‼️Однако её чрезмерное использование может привести к проблемам с производительностью и управлением памятью:
Загрузка всех ассетов: При старте Unity загружает все файлы в папке Resources в память, что увеличивает время загрузки и потребление ресурсов.
Сложность управления: ассеты, загруженные через Resources.Load, не могут быть легко управляемы или обновляемы при выпуске патчей.
Рекомендации:
Используйте Addressables - это более гибкий и оптимизированный подход к управлению ассетами, позволяющий загружать их по запросу и лучше контролировать использование памяти.
Addressables поддерживает загрузку ассетов из разных источников, включая удалённые серверы, что значительно улучшает производительность.
🟢 Папка StreamingAssets
StreamingAssets - специальная папка, где можно хранить файлы, которые нужно загружать в неизменённом виде во время выполнения (например, видео, звуковые файлы и другие данные).
Файлы из этой папки не упаковываются в игровые сборки и могут быть загружены напрямую с диска.
Рекомендации по использованию StreamingAssets:
Медиафайлы и конфигурации: используйте эту папку для хранения больших файлов или конфигурационных данных, которые не нуждаются в обработке Unity.
Платформенные особенности: учтите, что на разных платформах пути доступа к этой папке могут отличаться, поэтому важно протестировать корректность загрузки файлов на Windows, Android и iOS.
‼️Вложенные усилия в тестирование помогут создать высококачественный продукт, способный конкурировать на рынке и завоевывать доверие игроков.
В рамках текущей публикации я рассмотрел какие акценты необходимо расставлять в процессе тестирования.
В рамках следующей публикации разберем набор инструментов для тестирования.
Хорошего дня! 👋
Вопросы жду в комментариях!
Также не забываем про потенциально узкие места 🔽
🟢 Папки Resources
Часто разработчики для хранения ассетов используют папку Resources в Unity, это может казаться удобным способом хранения для загрузки во время выполнения.
‼️Однако её чрезмерное использование может привести к проблемам с производительностью и управлением памятью:
Загрузка всех ассетов: При старте Unity загружает все файлы в папке Resources в память, что увеличивает время загрузки и потребление ресурсов.
Сложность управления: ассеты, загруженные через Resources.Load, не могут быть легко управляемы или обновляемы при выпуске патчей.
Рекомендации:
Используйте Addressables - это более гибкий и оптимизированный подход к управлению ассетами, позволяющий загружать их по запросу и лучше контролировать использование памяти.
Addressables поддерживает загрузку ассетов из разных источников, включая удалённые серверы, что значительно улучшает производительность.
🟢 Папка StreamingAssets
StreamingAssets - специальная папка, где можно хранить файлы, которые нужно загружать в неизменённом виде во время выполнения (например, видео, звуковые файлы и другие данные).
Файлы из этой папки не упаковываются в игровые сборки и могут быть загружены напрямую с диска.
Рекомендации по использованию StreamingAssets:
Медиафайлы и конфигурации: используйте эту папку для хранения больших файлов или конфигурационных данных, которые не нуждаются в обработке Unity.
Платформенные особенности: учтите, что на разных платформах пути доступа к этой папке могут отличаться, поэтому важно протестировать корректность загрузки файлов на Windows, Android и iOS.
‼️Вложенные усилия в тестирование помогут создать высококачественный продукт, способный конкурировать на рынке и завоевывать доверие игроков.
В рамках текущей публикации я рассмотрел какие акценты необходимо расставлять в процессе тестирования.
В рамках следующей публикации разберем набор инструментов для тестирования.
Хорошего дня! 👋
Вопросы жду в комментариях!