Всем привет!
Меня зовут Алексей и я Lead разработчик. А последний год CTO Silverfox.Games.
Я самоучка. Всё, что связано с разработкой игр, я изучал самостоятельно. Все мои знания - личный опыт.
Работал над 5 мобильными проектами в разных жанрах (mid-core, simulator, merge-3). А также делал несколько проектов в дополненной реальности.
Какие-то стали успешными, какие-то не очень. Но насколько успех продукта зависит от разработчика?
Проекты:
Magic Battle Arena (Android, IOS)
Combat Quest (Android, IOS)
Pool City (Android)
Overcrowded: Tycoon компания Zeptolab
WSOP Poker (50M+ скачиваний)
Текущий 👉 Hero Wars Alliance (100M+ скачиваний)
О чём я здесь пишу:
- об архитектуре игровых проектов на базе unity
- о создании проектов с нуля
- о своём пути разработчика игр
Я завсегдатый архитектурного чатика. Отвечая там на вопросы, я понял что тема архитектуры очень плохо освещена. А тупорылые best practices от unity часто не имеют ничего общего с реальными проектами.
Так же поделюсь своим отношением к паттернам и модным аббревиатурам. Обсудим, как это можно использовать на реальных проектах.
Меня зовут Алексей и я Lead разработчик. А последний год CTO Silverfox.Games.
Я самоучка. Всё, что связано с разработкой игр, я изучал самостоятельно. Все мои знания - личный опыт.
Работал над 5 мобильными проектами в разных жанрах (mid-core, simulator, merge-3). А также делал несколько проектов в дополненной реальности.
Какие-то стали успешными, какие-то не очень. Но насколько успех продукта зависит от разработчика?
Проекты:
Magic Battle Arena (Android, IOS)
Combat Quest (Android, IOS)
Pool City (Android)
Overcrowded: Tycoon компания Zeptolab
WSOP Poker (50M+ скачиваний)
Текущий 👉 Hero Wars Alliance (100M+ скачиваний)
О чём я здесь пишу:
- об архитектуре игровых проектов на базе unity
- о создании проектов с нуля
- о своём пути разработчика игр
Я завсегдатый архитектурного чатика. Отвечая там на вопросы, я понял что тема архитектуры очень плохо освещена. А тупорылые best practices от unity часто не имеют ничего общего с реальными проектами.
Так же поделюсь своим отношением к паттернам и модным аббревиатурам. Обсудим, как это можно использовать на реальных проектах.
👍9🤯2⚡1🔥1
SOLID
Медийный продукт Роберта Мартина (ака Дядя Боб). Сколько книг он написал и конференций провёл, где рассказывал 5 заветных принципов “как писать код и какими принципами руководствоваться”. Я прочитал не одну его книгу и могу сказать - он хорошо продвигает свою идеологию, проникает в неокрепшие умы и плотно там закрепляется.
Как и любую другую идеологию, её очень сложно выбить из своей головы и посмотреть на вещи с другой стороны. Для этого придется сломать в себе те столпы, на которых она держится.
У меня первый надлом в его принципах произошел из-за постоянных переработок и непопадания в сроки. Зачем писать кучу ненужного кода…
Второй - когда я устроился на второй проект. Там от его принципов не просто отказались, а даже не слышали. И знаете что? Проект в сотни раз проще масштабирутся, дебажить его проще, а самое главное логика лежит на поверхности. Никакой сотни классов и название FooAbstractFactorySingletoneFacade3000, которое можно использовать как стоп-слово 🤔
Тогда я понял, что слепо веровать и следовать - максимально непродуктивно.
Только 2 принципа оказались хоть как-то применимы на практике и хоть чуточку полезными:
DIP — когда вы можете разорвать кольцевую зависимость и развернуть связи в обратном направлении.
ISP — бывает удобно выделить интерфейс или несколько, и написать всего 1 обработчик.
Все. Остальное расплывчато сформулировано (OCP), устарело (LSP) и почти не применимо на практике (SRP).
Дядя Боб — инфлюенсер-зумер. Этакий инфоцыган, до того как это стало мейнстримом. Ведь до эпохи соц.сетей и блогов единственный способ стать известным и заработать на этом — книги.
Что мы имеем в сухом остатке?
— Популярную идеологию, которая распространена по всему СНГ и ближней Европе (за другие локации не скажу).
— Кучу новичков и опытных программистов, которые ей следуют и заставляют следовать других.
— Тысячи загубленных проектов, которые проще написать с нуля, чем поддерживать дальше.
Зафиналить хочу так — есть реальная проблема! Обучающего контента, уровня реальных проектов, очень мало, даже по архитектуре. Я решил это исправить — создал этот канал.
В следующем посте цикла "аббревиатуры" — DI
#аббревиатуры@UniArchitect
Медийный продукт Роберта Мартина (ака Дядя Боб). Сколько книг он написал и конференций провёл, где рассказывал 5 заветных принципов “как писать код и какими принципами руководствоваться”. Я прочитал не одну его книгу и могу сказать - он хорошо продвигает свою идеологию, проникает в неокрепшие умы и плотно там закрепляется.
Как и любую другую идеологию, её очень сложно выбить из своей головы и посмотреть на вещи с другой стороны. Для этого придется сломать в себе те столпы, на которых она держится.
У меня первый надлом в его принципах произошел из-за постоянных переработок и непопадания в сроки. Зачем писать кучу ненужного кода…
Второй - когда я устроился на второй проект. Там от его принципов не просто отказались, а даже не слышали. И знаете что? Проект в сотни раз проще масштабирутся, дебажить его проще, а самое главное логика лежит на поверхности. Никакой сотни классов и название FooAbstractFactorySingletoneFacade3000
Только 2 принципа оказались хоть как-то применимы на практике и хоть чуточку полезными:
DIP — когда вы можете разорвать кольцевую зависимость и развернуть связи в обратном направлении.
ISP — бывает удобно выделить интерфейс или несколько, и написать всего 1 обработчик.
Все. Остальное расплывчато сформулировано (OCP), устарело (LSP) и почти не применимо на практике (SRP).
Дядя Боб — инфлюенсер-зумер. Этакий инфоцыган, до того как это стало мейнстримом. Ведь до эпохи соц.сетей и блогов единственный способ стать известным и заработать на этом — книги.
Что мы имеем в сухом остатке?
— Популярную идеологию, которая распространена по всему СНГ и ближней Европе (за другие локации не скажу).
— Кучу новичков и опытных программистов, которые ей следуют и заставляют следовать других.
— Тысячи загубленных проектов, которые проще написать с нуля, чем поддерживать дальше.
Зафиналить хочу так — есть реальная проблема! Обучающего контента, уровня реальных проектов, очень мало, даже по архитектуре. Я решил это исправить — создал этот канал.
В следующем посте цикла "аббревиатуры" — DI
#аббревиатуры@UniArchitect
⚡6👍6🤔3😁1
СТРУКТУРА ПРОЕКТА
Папка проекта
Перед тем как написать первую строчку кода, нужно решить очень важную проблему — быстрое захламление иерархии проекта. Чтобы последующие N-лет работать с ней без головной боли.
Обычно происходит как: создается проект, в этой же папке создается git репозиторий — profit.
Например:
У вас плание backend с общей shared частью (это общий код для бэка и клиента, например модели). И вам нужно где-то хранить скрипты для копирования shared части.
Или бэкенд лежит в одном репозитории с клиентом.
Или CI/CD пайплайн потребует запуска кастомных скриптов.
Или есть внешние конфиги, которые вы хотите хранить вне папки Assets, чтобы они не попали в билд (например конфигурации сборки билда).
+ unity генерирует кучу папок, которые не попадают в репозиторий, но есть локально (Library, Debug, Temp, obj и прочие).
+ файлы, которые генерирует Rider и VS.
Поздравляю! Ваша когнитивная сложность выросла в 5 раз, а иерархия превратилась ПОМОЙКУ 🤥
КАК ЭТОГО ИЗБЕЖАТЬ?
У себя на проектах я делаю такую иерархию:
— Unity проект отображается в Unity Hub адекватно
— Внешние и внутренние файлы разделены
— Декларативность == низкая когнитивная сложность
Минусов нет 😎
Папка _Project
Поскольку нет единого гайдлайна для именования и структуры папок, то со временем, папка Assets тоже превращается в помойку. И любой импортированный в проект пакет ассетов может наследить в иерархии так, как ему вздумается. Создавая сколько угодно своих папок в корне.
Со временем когнитивная сложность растет и поиск нужной папки отнимает все больше и больше времени.
Отдельная папка выделяет место чисто под файлы вашего проекта. И вы можете выстроить свою иерархию, в которую ни один из импортируемых ассетов не влезет.
Нижнее подчеркивание нужно для сортировки и отображения в вершине иерархии.
Внутри _Project делаю такую иерархию:
— Быстрая адаптация новых людей
— Легкая масштабируемость
— Поскольку наши файлы и файлы импортируемых ассетов лежат отдельно, обновление последних происходит без головняка и без риска задеть наши файлы
Минусы:
— Глубокая иерархия - увеличивает когнитивную нагрузку
— Требуется порядок и правила создания новых папок - чтобы со временем не стало помойки
— Некоторые папки типа StreamingAssets нельзя скопировать к себе в _Project
В следующем посте цикла "проект_с_нуля" — структура сборок
#проект_с_нуля@UniArchitect
Папка проекта
Перед тем как написать первую строчку кода, нужно решить очень важную проблему — быстрое захламление иерархии проекта. Чтобы последующие N-лет работать с ней без головной боли.
Обычно происходит как: создается проект, в этой же папке создается git репозиторий — profit.
Например:
У вас плание backend с общей shared частью (это общий код для бэка и клиента, например модели). И вам нужно где-то хранить скрипты для копирования shared части.
Или бэкенд лежит в одном репозитории с клиентом.
Или CI/CD пайплайн потребует запуска кастомных скриптов.
Или есть внешние конфиги, которые вы хотите хранить вне папки Assets, чтобы они не попали в билд (например конфигурации сборки билда).
+ unity генерирует кучу папок, которые не попадают в репозиторий, но есть локально (Library, Debug, Temp, obj и прочие).
+ файлы, которые генерирует Rider и VS.
Поздравляю! Ваша когнитивная сложность выросла в 5 раз, а иерархия превратилась ПОМОЙКУ 🤥
КАК ЭТОГО ИЗБЕЖАТЬ?
У себя на проектах я делаю такую иерархию:
+-- %project_name%
| +-- .git
| +-- %project_name%.Build
| +-- %project_name%.ExternalConfigs
| +-- %project_name%.ThirdParty
| +-- %project_name%.Keystore
| +-- %project_name%.Backend
| +-- %project_name%.Kubernetes
| +-- %project_name%.Unity
| | + -- Assets
| | | +-- _Project
Плюсы:— Unity проект отображается в Unity Hub адекватно
— Внешние и внутренние файлы разделены
— Декларативность == низкая когнитивная сложность
Минусов нет 😎
Папка _Project
Поскольку нет единого гайдлайна для именования и структуры папок, то со временем, папка Assets тоже превращается в помойку. И любой импортированный в проект пакет ассетов может наследить в иерархии так, как ему вздумается. Создавая сколько угодно своих папок в корне.
Со временем когнитивная сложность растет и поиск нужной папки отнимает все больше и больше времени.
Отдельная папка выделяет место чисто под файлы вашего проекта. И вы можете выстроить свою иерархию, в которую ни один из импортируемых ассетов не влезет.
Нижнее подчеркивание нужно для сортировки и отображения в вершине иерархии.
Внутри _Project делаю такую иерархию:
+-- _Project
| +-- Art
| +-- Develop
| +-- Plugins
| +-- Resources
| +-- Scenes
| +-- прочие папки
Плюсы:— Быстрая адаптация новых людей
— Легкая масштабируемость
— Поскольку наши файлы и файлы импортируемых ассетов лежат отдельно, обновление последних происходит без головняка и без риска задеть наши файлы
Минусы:
— Глубокая иерархия - увеличивает когнитивную нагрузку
— Требуется порядок и правила создания новых папок - чтобы со временем не стало помойки
— Некоторые папки типа StreamingAssets нельзя скопировать к себе в _Project
В следующем посте цикла "проект_с_нуля" — структура сборок
#проект_с_нуля@UniArchitect
🔥6👍2
ПЕРЕЕЗД В ИСПАНИЮ 🇪🇸
Я давно мечтал переехать в одну из стран Европы. После долгих изучений и постоянных переездов из страны в страну, стало понятно что нужно где-то обосноваться. Наш с женой выбор пал на Испанию.
1️⃣ Климат
Жене и мне надоела серая московская погода. Либо дикая аномальная жара, либо аномальный холод или отсутствие снега.
Так же, как человек из Сибири, привыкший к холодам и хорошей студеной зиме со снегом, то что происходит в Москве не поворачивается язык назвать это зимой. А я люблю зиму 😞
Осень/весна занимают половину года, а иногда и все 3/4. Слякоть, дожди, серость, все это очень сильно бьет по моральной и продуктивной составляющей.
2️⃣ Менталитет и отношение
Обеденные сиесты в 2 часа, когда можно сгонять домой, покушать, поспать и вернуться домой.
Женщин, детей и даже животных здесь уважают больше чем мужчин. Не поймите не правильно, просто когда в Москве жену страшно посадить одну в такси это не ок.
3️⃣ ВНЖ выдают с российским ИП
Я уже 3 года работаю удаленно как ИП. Испания в начале этого года открыла nomad ВНЖ программу по которой можно получить вид на жительство на 3 года. Процедура пока очень простая с самым низким порогом входа. + принимаю контракты из РФ и ИП в РФ тут котируется.
Дайте знать если интересно, могу сделать отдельный пост, где опишу весь этот длинный путь.
И сейчас как раз занимаюсь подготовкой и подачей документов на nomad ВНЖ.
В данном цикле хотелось бы больше рассказывать о себе, напишите про что интересно почитать:
— С чего все начиналось (школа, универ, самообучение)
— Последний опыт (своя игровая студия, переезды, события последних 2ух лет)
#моя_история@UniArchitect
Я давно мечтал переехать в одну из стран Европы. После долгих изучений и постоянных переездов из страны в страну, стало понятно что нужно где-то обосноваться. Наш с женой выбор пал на Испанию.
1️⃣ Климат
Жене и мне надоела серая московская погода. Либо дикая аномальная жара, либо аномальный холод или отсутствие снега.
Так же, как человек из Сибири, привыкший к холодам и хорошей студеной зиме со снегом, то что происходит в Москве не поворачивается язык назвать это зимой. А я люблю зиму 😞
Осень/весна занимают половину года, а иногда и все 3/4. Слякоть, дожди, серость, все это очень сильно бьет по моральной и продуктивной составляющей.
2️⃣ Менталитет и отношение
Обеденные сиесты в 2 часа, когда можно сгонять домой, покушать, поспать и вернуться домой.
Женщин, детей и даже животных здесь уважают больше чем мужчин. Не поймите не правильно, просто когда в Москве жену страшно посадить одну в такси это не ок.
3️⃣ ВНЖ выдают с российским ИП
Я уже 3 года работаю удаленно как ИП. Испания в начале этого года открыла nomad ВНЖ программу по которой можно получить вид на жительство на 3 года. Процедура пока очень простая с самым низким порогом входа. + принимаю контракты из РФ и ИП в РФ тут котируется.
Дайте знать если интересно, могу сделать отдельный пост, где опишу весь этот длинный путь.
И сейчас как раз занимаюсь подготовкой и подачей документов на nomad ВНЖ.
В данном цикле хотелось бы больше рассказывать о себе, напишите про что интересно почитать:
— С чего все начиналось (школа, универ, самообучение)
— Последний опыт (своя игровая студия, переезды, события последних 2ух лет)
#моя_история@UniArchitect
🔥9
ВЕРСИОНИРОВАНИЕ Ч.1 СЕМАНТИКА
На многих проектах, на которых удалось поработать, я замечал, что версионирование ведется по принципу увеличиваем последнюю цифру. Если последняя цифра больше условных 10, то мы изменяем предпоследнюю цифру на единицу, а последнюю цифру обнуляем. И так далее.
То есть это работает как какой-то счетчик, разделенный тремя точками.
Практического смысла и какой-то идеи я никогда не наблюдал.
Мы все знаем про семантическое версионирование, но не знаем как его применять для игр. А дело в том, что семантическое версионирование для игр и не работает. Потому что нет как такового публичного API, для которого будут работать его правила.
Мы не можем обновить игру так же, как мы можем обновить Nuget зависимость. Нам не нужно беспокоится об обратной совместимости. Я к тому, что использовать схему major.minor.patch нас никто не заставляет.
Ну как никто, есть один профессиональный объюзер в мире разработки — Apple. Оо, сколько у меня вопросов к этим ребятам. Они заставляют придерживаться схемы major.minor.patch. И остается лишь под это адаптироваться.
В итоге требование к изменению версии всего одно — текущая версия должна быть выше предыдущей. А схема — major.minor.patch.
И с опытом я сформировал такие правила изменения версии:
— major - когда игра не опубликована - 0, после публикации 1. Дальше +1 когда minor достигнет 99 или когда будет очень крупное обновление.
— minor - меняем при каждом релизе
— patch - только для хотфиксов
Пример:
— В develop версия 1.0.0, stable, rc, master версия 0.2.0
— При критической ошибке в 0.2.0 в rc делаем хотфикс и версию меняем на 0.2.1.
— Когда проект будет опубликован в сторах, его версия в master будет 1.0.0, а develop 1.1.0.
— Если в 1.0.0 будет баг, то в stable, rc, master будет вылит фикс, а версия изменится на 1.0.1.
А bundle version code можно формировать по формуле: major * 10000 + minor * 100 + patch. Но с оговоркой что вы готовы менять версию каждый раз при косячной заливке в стор.
Я же отказался от этой формулы и просто перед каждой заливкой в стор ручками увеличиваю bundle version code на 1. И он с версией никак не связан.
При том в вопросе версионирования остается еще один нераскрытый момент — миграция данных между релизами. Об этом мы поговорим в следующем посте данного цикла😊
#проект_релиз@UniArchitect
На многих проектах, на которых удалось поработать, я замечал, что версионирование ведется по принципу увеличиваем последнюю цифру. Если последняя цифра больше условных 10, то мы изменяем предпоследнюю цифру на единицу, а последнюю цифру обнуляем. И так далее.
То есть это работает как какой-то счетчик, разделенный тремя точками.
Практического смысла и какой-то идеи я никогда не наблюдал.
Мы все знаем про семантическое версионирование, но не знаем как его применять для игр. А дело в том, что семантическое версионирование для игр и не работает. Потому что нет как такового публичного API, для которого будут работать его правила.
Мы не можем обновить игру так же, как мы можем обновить Nuget зависимость. Нам не нужно беспокоится об обратной совместимости. Я к тому, что использовать схему major.minor.patch нас никто не заставляет.
Ну как никто, есть один профессиональный объюзер в мире разработки — Apple. Оо, сколько у меня вопросов к этим ребятам. Они заставляют придерживаться схемы major.minor.patch. И остается лишь под это адаптироваться.
В итоге требование к изменению версии всего одно — текущая версия должна быть выше предыдущей. А схема — major.minor.patch.
И с опытом я сформировал такие правила изменения версии:
— major - когда игра не опубликована - 0, после публикации 1. Дальше +1 когда minor достигнет 99 или когда будет очень крупное обновление.
— minor - меняем при каждом релизе
— patch - только для хотфиксов
Пример:
— В develop версия 1.0.0, stable, rc, master версия 0.2.0
— При критической ошибке в 0.2.0 в rc делаем хотфикс и версию меняем на 0.2.1.
— Когда проект будет опубликован в сторах, его версия в master будет 1.0.0, а develop 1.1.0.
— Если в 1.0.0 будет баг, то в stable, rc, master будет вылит фикс, а версия изменится на 1.0.1.
А bundle version code можно формировать по формуле: major * 10000 + minor * 100 + patch. Но с оговоркой что вы готовы менять версию каждый раз при косячной заливке в стор.
Я же отказался от этой формулы и просто перед каждой заливкой в стор ручками увеличиваю bundle version code на 1. И он с версией никак не связан.
При том в вопросе версионирования остается еще один нераскрытый момент — миграция данных между релизами. Об этом мы поговорим в следующем посте данного цикла
#проект_релиз@UniArchitect
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3🔥3
Retention (R)
Первая и базовая метрика, которой измеряется успешность проекта.
Всего 2 типа:
Classic retention — % пользователей, которые открыли игру на следующий день*
Rolling retention — % пользователей, которые открыли игру на следующий день* или позже
Минусы второго — может измениться в любой момент. Даже если пользователь зайдет в игру в следующий раз на 90 день, он попадет в Rolling R1.
Следующий день* — есть 2 типа интервала от которого можно замерять R:
1. 24h — пользователь будет учтен, если откроет приложение в период 24-48 часов после установки.
2. Calendar — пользователь будет учтен, если откроет приложение на следующий календарный день.
Минус второго — пользователь, который скачал игру в 11:50 вечера и открывший ее в 12:05 следующего дня будет учтен.
Из интересного:
▫️ Изменение R1 — динамика развития проекта
▫️ Rolling R на практике используется редко, чаще упоминается на публике или на слайдах в отчетах
▫️ 24h R можно использовать для быстрого определения эффективности компании. Это работает т.к. мы можем в данном случае измерить возврат 0-го дня.
▫️ Calendar Classic R чаще всего просили показать инвесторы. Многие кто слышал цифры ниже бэнчмарков сразу разворачивались
▫️ Если на старте R1 ниже 20%, а FTUE уже отлажен, то потребуются координальные изменения в core части игры, чтобы проект выжил
▫️ Если на старте R1 около 15 и ниже, то проект дешевле убить чем вытягивать
▫️ Если R1 > 35% это успех
#проект_liveOps@UniArchitect
#метрики@UniArchitect
Первая и базовая метрика, которой измеряется успешность проекта.
Всего 2 типа:
Classic retention — % пользователей, которые открыли игру на следующий день*
Rolling retention — % пользователей, которые открыли игру на следующий день* или позже
Минусы второго — может измениться в любой момент. Даже если пользователь зайдет в игру в следующий раз на 90 день, он попадет в Rolling R1.
Следующий день* — есть 2 типа интервала от которого можно замерять R:
1. 24h — пользователь будет учтен, если откроет приложение в период 24-48 часов после установки.
2. Calendar — пользователь будет учтен, если откроет приложение на следующий календарный день.
Минус второго — пользователь, который скачал игру в 11:50 вечера и открывший ее в 12:05 следующего дня будет учтен.
Из интересного:
▫️ Изменение R1 — динамика развития проекта
▫️ Rolling R на практике используется редко, чаще упоминается на публике или на слайдах в отчетах
▫️ 24h R можно использовать для быстрого определения эффективности компании. Это работает т.к. мы можем в данном случае измерить возврат 0-го дня.
▫️ Calendar Classic R чаще всего просили показать инвесторы. Многие кто слышал цифры ниже бэнчмарков сразу разворачивались
▫️ Если на старте R1 ниже 20%, а FTUE уже отлажен, то потребуются координальные изменения в core части игры, чтобы проект выжил
▫️ Если на старте R1 около 15 и ниже, то проект дешевле убить чем вытягивать
▫️ Если R1 > 35% это успех
#проект_liveOps@UniArchitect
#метрики@UniArchitect
👍6🔥3
СЦЕНЫ
Первая проблема, которую я сразу решаю на новом проекте — 4 сцены для управления состоянием проекта.
0.Bootstrap — точка входа и контекст проекта (аналитика, SDK сторов, платежка, конфиги, связь с сервером).
1.Loading — загрузка, авторизация, GDPR, проверка обновлений и прочее что нужно для старта игры.
2.Meta — в основном UI в котором вы тратите накопленные ресурсы на прогресс по игре
3.Core — основная реиграбельная часть
4.Empty — костыль сцена для 100% выгрузки всех ресурсов предыдущей сцены.
Из любой сцены мы можем перейти в любую. Исключение Bootstrap. В нее входим только при запуске игры. И из нее загружаем только Loading.
#проект_с_нуля@UniArchitect
Первая проблема, которую я сразу решаю на новом проекте — 4 сцены для управления состоянием проекта.
0.Bootstrap — точка входа и контекст проекта (аналитика, SDK сторов, платежка, конфиги, связь с сервером).
1.Loading — загрузка, авторизация, GDPR, проверка обновлений и прочее что нужно для старта игры.
2.Meta — в основном UI в котором вы тратите накопленные ресурсы на прогресс по игре
3.Core — основная реиграбельная часть
4.Empty — костыль сцена для 100% выгрузки всех ресурсов предыдущей сцены.
Из любой сцены мы можем перейти в любую. Исключение Bootstrap. В нее входим только при запуске игры. И из нее загружаем только Loading.
#проект_с_нуля@UniArchitect
👍11
(А|а)рхитектура
Общество движется вперед путем увеличения числа операций, которые может осуществлять, не раздумывая над ними.
Архитектурные подходы (паттерны) в разработке ПО универсальны. Их можно применить к любому языку и проекту. Код, следующий этим принципам, будет ➕➖ одинаков с точки зрения масштабируемости и сложности.
Для меня архитектура проекта — это совокупность решений в организации проекта, обеспечивающие удобство работы и масштабируемость, а так же замедление роста когнитивной сложности.
И при проектировании нужно вырабатывать эти решения (правила, подходы, гайдлайны) не только для кода, но и для всего с чем проект связан:
— Именование файлов и папок, структура хранения ассетов, структура сборок
— Утилиты для разработки, тестирование, работа с системой контроля версии
— Билд проекта и его деплой, работа со сторами и выливка хотфиксов
— Мониторинг метрик, ошибок и реагирование на них
#аббревиатуры@UniArchitect
Общество движется вперед путем увеличения числа операций, которые может осуществлять, не раздумывая над ними.
Архитектурные подходы (паттерны) в разработке ПО универсальны. Их можно применить к любому языку и проекту. Код, следующий этим принципам, будет ➕➖ одинаков с точки зрения масштабируемости и сложности.
Для меня архитектура проекта — это совокупность решений в организации проекта, обеспечивающие удобство работы и масштабируемость, а так же замедление роста когнитивной сложности.
И при проектировании нужно вырабатывать эти решения (правила, подходы, гайдлайны) не только для кода, но и для всего с чем проект связан:
— Именование файлов и папок, структура хранения ассетов, структура сборок
— Утилиты для разработки, тестирование, работа с системой контроля версии
— Билд проекта и его деплой, работа со сторами и выливка хотфиксов
— Мониторинг метрик, ошибок и реагирование на них
#аббревиатуры@UniArchitect
🔥2⚡1
С ПОЛЕЙ РАЗРАБОТКИ:
ОПТИМИЗАЦИИ ЗАГРУЗКИ
В этой рубрике я пишу про то, с чем столкнулся вот только что и сразу решил об этом написать пост.
Вводные:
1️⃣ Карта с 5 уровнями. Группа из 5 уровней называется остров.
1ый остров - тутор
ГК - глобальная карта на которой находятся все острова
2️⃣ Игрок прошел последнюю карту 1го острова (т.е. тутор), нажимает кнопку открытия ГК (это scrollRect горизонтальный с 10+ элементами) и получает ANR.
3️⃣ В логах перекати поле. Нет ничего. Ни одной ошибки ни одного warning'a.
ANR коротко — главный поток висит >5 секунд?
— Android ядро грохает приложение.
Причина:
—
—
Решение:
— Если в одном кадре много
— Перед добавлением элементов включаем сам объект в иерархии, на котором будут создаваться объекты
Это позволит не в один кадр обновить все добавленные на канвас элементы (а это куча примерно в 1000 объектов), а в несколько.
p.s. обожаю фиксы в одну строку (см. последний скрин, это весь фикс)
Насколько вообще заходит такой формат, черканите коммент😊
#будни@UniArchitect
ОПТИМИЗАЦИИ ЗАГРУЗКИ
В этой рубрике я пишу про то, с чем столкнулся вот только что и сразу решил об этом написать пост.
Вводные:
1️⃣ Карта с 5 уровнями. Группа из 5 уровней называется остров.
1ый остров - тутор
ГК - глобальная карта на которой находятся все острова
2️⃣ Игрок прошел последнюю карту 1го острова (т.е. тутор), нажимает кнопку открытия ГК (это scrollRect горизонтальный с 10+ элементами) и получает ANR.
3️⃣ В логах перекати поле. Нет ничего. Ни одной ошибки ни одного warning'a.
ANR коротко — главный поток висит >5 секунд?
— Android ядро грохает приложение.
Причина:
—
Instantiate большого кол-ва объектов в одном кадре—
Canvas.ForceUpdateCanvases(); занимает >1000ms на компе. На девайсе замерить не удалось, угадайте почему 🤷♂️Решение:
— Если в одном кадре много
Instantiate - делаем из метода корутину и проставляем delay (или return null) после каждого выполнения тяжелой логики— Перед добавлением элементов включаем сам объект в иерархии, на котором будут создаваться объекты
Это позволит не в один кадр обновить все добавленные на канвас элементы (а это куча примерно в 1000 объектов), а в несколько.
p.s. обожаю фиксы в одну строку (см. последний скрин, это весь фикс)
Насколько вообще заходит такой формат, черканите коммент
#будни@UniArchitect
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍11🆒8
ПЕРЕКЛЮЧЕНИЕ СЦЕН — Additive.
СЦЕНЫ
Нюансы:
— Загрузка и выгрузка асинхронная, требует написания доп. кода
— Нужно ручками в новой сцене дергать
Только после этого делать Instantiate объектов.
— Сторонние плагины все равно создают
Преимущества:
— Можно отказаться от
— Захотели перезапустить игру полностью? Загрузили заново Bootstrap и весь контекст дропнулся без лишних телодвижений
— Очистка памяти и уменьшение используемой RAM без Empty сцен
+ Tutorial можно сделать отдельной сценой, которая при загрузке будет определять какая сцена загружена, какой последний шаг и вести пользователя
#проект_с_нуля@UniArchitect
СЦЕНЫ
Нюансы:
— Загрузка и выгрузка асинхронная, требует написания доп. кода
— Нужно ручками в новой сцене дергать
SceneManager.SetActiveScene Только после этого делать Instantiate объектов.
— Сторонние плагины все равно создают
DontDestroyOnLoad объектыПреимущества:
— Можно отказаться от
DontDestroyOnLoad объектов и использовать Bootstrap сцену для хранения глобального контекста.— Захотели перезапустить игру полностью? Загрузили заново Bootstrap и весь контекст дропнулся без лишних телодвижений
— Очистка памяти и уменьшение используемой RAM без Empty сцен
+ Tutorial можно сделать отдельной сценой, которая при загрузке будет определять какая сцена загружена, какой последний шаг и вести пользователя
#проект_с_нуля@UniArchitect
👍6🔥1
СТРУКТУРА ВЕТОК ПРОЕКТА
У структуры веток всего 1 требование — деление процесса разработки на понятные стадии.
Из опыта создания нескольких проектов с нуля я выделил такую структуру веток:
🔹 develop — разработка.
- В этой ветке происходит контролируемый разработчиками хаос
- Код в ветке может работать, а может и нет
- Окружения разворачивается локально
- Настройки проекта могут быть какие угодно в зависимости от потребностей разработчиков
🔹 art — стабильная версия develop.
- Нужна геймдизайнерам, QA, аналитикам и т.п. для проверки, тестирования текущего состояния приложения
- Cвое серверное окружение
🔹 stable — feature freeze. Выделяет конкретный список, набор фичей, которые получат пользователи в этом обновлении.
- Сюда мержится develop когда все фичи версии сделаны
- Включена вся отладка
- Включены читы
- Фейковый магазин
- Cвое серверное окружение
🔹 rc — Release Candidate. Это пред-релизная версия.
- В данную ветку мержится stable
- Сюда могут быть залиты только hotfix’ы
- Версия максимально приближена к проду
- Отключена вся отладка
- Конфигурация на максимальную производительность
- Реальный магазин
- База данных синхронизирована с продом
🔹 main/master — тот самый prod, который принято ронять 😬
- Сюда мержится rc
- Состояние из этой ветки всегда соответствует состоянию приложения у пользователей на девайсах.
- В нее может напрямую пушить только лид, либо ответственный за релиз.
Кол-во веток и окружение нужно варьировать в зависимости от потребностей проекта.
#проект_в_разработке@UniArchitect
У структуры веток всего 1 требование — деление процесса разработки на понятные стадии.
Из опыта создания нескольких проектов с нуля я выделил такую структуру веток:
🔹 develop — разработка.
- В этой ветке происходит контролируемый разработчиками хаос
- Код в ветке может работать, а может и нет
- Окружения разворачивается локально
- Настройки проекта могут быть какие угодно в зависимости от потребностей разработчиков
🔹 art — стабильная версия develop.
- Нужна геймдизайнерам, QA, аналитикам и т.п. для проверки, тестирования текущего состояния приложения
- Cвое серверное окружение
🔹 stable — feature freeze. Выделяет конкретный список, набор фичей, которые получат пользователи в этом обновлении.
- Сюда мержится develop когда все фичи версии сделаны
- Включена вся отладка
- Включены читы
- Фейковый магазин
- Cвое серверное окружение
🔹 rc — Release Candidate. Это пред-релизная версия.
- В данную ветку мержится stable
- Сюда могут быть залиты только hotfix’ы
- Версия максимально приближена к проду
- Отключена вся отладка
- Конфигурация на максимальную производительность
- Реальный магазин
- База данных синхронизирована с продом
🔹 main/master — тот самый prod, который принято ронять 😬
- Сюда мержится rc
- Состояние из этой ветки всегда соответствует состоянию приложения у пользователей на девайсах.
- В нее может напрямую пушить только лид, либо ответственный за релиз.
Кол-во веток и окружение нужно варьировать в зависимости от потребностей проекта.
#проект_в_разработке@UniArchitect
👍7