🛠️ Удобный способ работы с коллекциями через Builder
Представьте, что вы разрабатываете игру, где есть много врагов, например, survival.io. И есть юнит, который должен атаковать ближайшего юнита ближнего боя.
Как бы выглядел поиск этого юнита в классической реализации
⚠️ Минусы:
* Использование коллайдеров для Physics2D.OverlapCircleNonAlloc.
* Необходимость добавлять специальный слой на врагов (и не забывать добавлять его новым врагам).
* Дорогой вызов GetComponent<Enemy>.
* Сложность восприятия метода при чтении кода.
⚙️ Альтернативный вариант: коллекция + Builder
Я часто использую подход через коллекцию и паттерн Builder.
✅ Преимущества:
* Упрощение кода и повышение читаемости.
* Отсутствие необходимости работать с коллайдерами и слоями.
* Избавление от вызова GetComponent.
⚠️ Минусы:
* Увеличение времени разработки: требуется написать систему фильтрации и поддерживать коллекцию в актуальном состоянии.
✍️ Пример реализации коллекции
Код, приведеный выше служит лишь примером, что бы передать главнную мысль об использовании кастомных коллекций в связке с Builder. В реальных проектах такие коллекции могут иметь альтернативные реализации, содержать различные кеши для ускорения поиска или фильтрации и многие другие "удобные".
Напишите в комментариях ваше мнение о таком решении! 🚀
Представьте, что вы разрабатываете игру, где есть много врагов, например, survival.io. И есть юнит, который должен атаковать ближайшего юнита ближнего боя.
Как бы выглядел поиск этого юнита в классической реализации
private Enemy GetEnemyClassic()
{
var size = Physics2D.OverlapCircleNonAlloc(center.position, radius, results, layerMask);
for (var i = 0; i < size; i++)
{
var enemy = results[i].GetComponent<Enemy>();
if (enemy.IsDead)
continue;
if (enemy.EnemyType != EnemyType.Melee)
continue;
return enemy;
}
return default;
}
⚠️ Минусы:
* Использование коллайдеров для Physics2D.OverlapCircleNonAlloc.
* Необходимость добавлять специальный слой на врагов (и не забывать добавлять его новым врагам).
* Дорогой вызов GetComponent<Enemy>.
* Сложность восприятия метода при чтении кода.
⚙️ Альтернативный вариант: коллекция + Builder
Я часто использую подход через коллекцию и паттерн Builder.
private Enemy GetEnemyViaBuilder() =>
enemyCollection
.InRadius(center.position, radius)
.IsAlive()
.Melee()
.FirstOrDefault();
✅ Преимущества:
* Упрощение кода и повышение читаемости.
* Отсутствие необходимости работать с коллайдерами и слоями.
* Избавление от вызова GetComponent.
⚠️ Минусы:
* Увеличение времени разработки: требуется написать систему фильтрации и поддерживать коллекцию в актуальном состоянии.
✍️ Пример реализации коллекции
public class EnemyCollection
{
private readonly FilterData filter = new();
private IEnumerable<Enemy> enemies;
public EnemyCollection(IEnumerable<Enemy> enemies)
{
this.enemies = enemies;
}
public EnemyCollection IsDead()
{
filter.IsDead = true;
return this;
}
public EnemyCollection IsAlive()
{
filter.IsDead = false;
return this;
}
public EnemyCollection Melee()
{
filter.EnemyType = EnemyType.Melee;
return this;
}
public EnemyCollection InRadius(Vector3 center, float radius)
{
filter.InFilterByRadius = true;
filter.Center = center;
filter.Radius = radius;
return this;
}
public Enemy FirstOrDefault()
{
return Build().FirstOrDefault();
}
public IEnumerable<Enemy> Build()
{
if (filter.IsDead.HasValue)
{
enemies = enemies.Where(e => e.IsDead == filter.IsDead);
}
if (filter.EnemyType.HasValue)
{
enemies = enemies.Where(e => e.EnemyType == filter.EnemyType);
}
if (filter.InFilterByRadius)
{
enemies = enemies.Where(e => Vector3.Distance(filter.Center, e.transform.position);
}
filter.Clear();
return enemies;
}
private class FilterData
{
public bool? IsDead;
public EnemyType? EnemyType;
public bool InFilterByRadius;
public float Radius;
public Vector3 Center;
public void Clear()
{
IsDead = null;
EnemyType = null;
InFilterByRadius = false;
Radius = 0;
Center = new Vector3();
}
}
}
Код, приведеный выше служит лишь примером, что бы передать главнную мысль об использовании кастомных коллекций в связке с Builder. В реальных проектах такие коллекции могут иметь альтернативные реализации, содержать различные кеши для ускорения поиска или фильтрации и многие другие "удобные".
Напишите в комментариях ваше мнение о таком решении! 🚀
🔥4❤2👌2
Мои неудачи
Всегда приятно говорить о достижениях и успехах, но мой 2024 год – это история неудач
В конце 2023 года я принял решение, что хочу приложить максимум усилий, чтобы в 2024 году выпустить игру, которая бы приносила доход. Я решил подойти к вопросу основательно и долгое время изучал информацию перед тем, как начать
В результате поставил себе цель – выпустить 10 игр за год
Спойлер: удалось выпустить 5 игр, а еще одна выйдет в 2025 году
Краткая история игр
1️⃣ Drill Master
Я разрабатывал эту игру параллельно с основной работой. Сидел в выходные и в свободное время в будни, но все же довел проект до маркетинговых тестов. Провел маркетинговые тесты – провал. Проект заморожен.
2️⃣ Bouncing Ball
Сделал эту игру за 7 дней, пока был в отпуске. Быстро провел маркетинговые тесты – результат снова отрицательный. Не раздумывая, выкинул проект и пошел дальше.
💬 На этом этапе я понял, что совмещать разработку с основной работой невероятно тяжело. Тогда я принял решение нанять программиста, чтобы ускорить процесс. Это оказалось правильным шагом – разработка действительно пошла быстрее.
3️⃣ Galaxy Expansion
Это самая крутая игра из всех, что я сделал за год. Но на ее разработку ушло 4 месяца, что оказалось слишком долго и дорого. За это время можно было сделать 4 прототипа и протестировать их.
💬 После этого я решил поменять стратегию. Поговорил с продюсерами разных издательств и договорился о сотрудничестве. Однако начали возникать небольшие конфликты с программистом. Меня все больше не устраивала скорость его работы.
4️⃣ Chase Car Arcade
Первая игра, которую мы сделали быстро и передали на полноценный тест издательству. Результат предсказуем – игра не прошла по метрикам.
💬 К этому моменту я работал почти без выходных уже 8 месяцев. Переутомление, наложившиеся личные проблемы, а также низкая скорость работы программиста заставили меня взять паузу, расстаться с программистом и переосмыслить подход. В результате мой новый проект Draw Cooked так и остался лежать в репозитории.
💬 Я решил замедлить темп, изучить рынок и опыт других студий. Решил нанимать фрилансеров под конкретные задачи – это оказалось лучшим решением и снизило стоимость прототипа в 2-3 раза
5️⃣ Karlson. Parkour Runner
Первая игра, сделанная с командой фрилансеров. У нее были хорошие метрики, но требовалось много доработок для их улучшения. Я принял решение не вкладываться в доработки и двигаться дальше.
Чему я научился за этот год:
1️⃣ Если ты новичок без опыта продаж своих игр, начинать нужно с коротких проектов, чтобы совершать дешевые ошибки.
2️⃣ Делегируйте разработку. Если проект делаете сами, обязательно делайте паузы и смотрите на него с позиции продюсера.
3️⃣ Изучайте информацию и опыт других. Чем больше учитесь на чужих ошибках, тем выше шансы их избежать.
Поставьте ♥️, если интересно услышать про каждый проект подробнее!
Всегда приятно говорить о достижениях и успехах, но мой 2024 год – это история неудач
В конце 2023 года я принял решение, что хочу приложить максимум усилий, чтобы в 2024 году выпустить игру, которая бы приносила доход. Я решил подойти к вопросу основательно и долгое время изучал информацию перед тем, как начать
В результате поставил себе цель – выпустить 10 игр за год
Спойлер: удалось выпустить 5 игр, а еще одна выйдет в 2025 году
Краткая история игр
1️⃣ Drill Master
Я разрабатывал эту игру параллельно с основной работой. Сидел в выходные и в свободное время в будни, но все же довел проект до маркетинговых тестов. Провел маркетинговые тесты – провал. Проект заморожен.
2️⃣ Bouncing Ball
Сделал эту игру за 7 дней, пока был в отпуске. Быстро провел маркетинговые тесты – результат снова отрицательный. Не раздумывая, выкинул проект и пошел дальше.
💬 На этом этапе я понял, что совмещать разработку с основной работой невероятно тяжело. Тогда я принял решение нанять программиста, чтобы ускорить процесс. Это оказалось правильным шагом – разработка действительно пошла быстрее.
3️⃣ Galaxy Expansion
Это самая крутая игра из всех, что я сделал за год. Но на ее разработку ушло 4 месяца, что оказалось слишком долго и дорого. За это время можно было сделать 4 прототипа и протестировать их.
💬 После этого я решил поменять стратегию. Поговорил с продюсерами разных издательств и договорился о сотрудничестве. Однако начали возникать небольшие конфликты с программистом. Меня все больше не устраивала скорость его работы.
4️⃣ Chase Car Arcade
Первая игра, которую мы сделали быстро и передали на полноценный тест издательству. Результат предсказуем – игра не прошла по метрикам.
💬 К этому моменту я работал почти без выходных уже 8 месяцев. Переутомление, наложившиеся личные проблемы, а также низкая скорость работы программиста заставили меня взять паузу, расстаться с программистом и переосмыслить подход. В результате мой новый проект Draw Cooked так и остался лежать в репозитории.
💬 Я решил замедлить темп, изучить рынок и опыт других студий. Решил нанимать фрилансеров под конкретные задачи – это оказалось лучшим решением и снизило стоимость прототипа в 2-3 раза
5️⃣ Karlson. Parkour Runner
Первая игра, сделанная с командой фрилансеров. У нее были хорошие метрики, но требовалось много доработок для их улучшения. Я принял решение не вкладываться в доработки и двигаться дальше.
Чему я научился за этот год:
1️⃣ Если ты новичок без опыта продаж своих игр, начинать нужно с коротких проектов, чтобы совершать дешевые ошибки.
2️⃣ Делегируйте разработку. Если проект делаете сами, обязательно делайте паузы и смотрите на него с позиции продюсера.
3️⃣ Изучайте информацию и опыт других. Чем больше учитесь на чужих ошибках, тем выше шансы их избежать.
Поставьте ♥️, если интересно услышать про каждый проект подробнее!
❤13
Проект Drill Master
Спасибо всем за лайки и активность в канале! Это мотивирует меня делиться с вами ещё больше полезной информации. 🙏
В 2020 году я выпустил свой последний проект, который, увы, оказался неуспешным. 😔 Я потратил на него много сил, и его провал отбил у меня желание продолжать. В результате я переключился: путешествовал, развивался как разработчик и техлид, женился. Эти годы дали мне заряд сил и желание снова делать игры. 🎮
И вот я решил начать заново!
Drill Master — мой первый проект после перерыва.
🎮 Ссылочка на Google Play
Для подготовки я:
🔍 Изучал рынок и анализировал игры через телеграм-каналы:
@hyper_casual_news — новости гиперказуальных игр
@storeglide — 5 роликов новых гиперказуальных игр каждый день
@hyper_casual — обсуждения и советы по теме гиперказуальных игр
📊 Для аналитики использовал:
Sensor Tower
💡 В каналах я увидел игру Idle Mine Dig: Drill & Collect.
🎮 Ссылочка на Google Play
Идея: сделать клон, но вместо ковша, собирающего ресурсы, добавить бур, который отбивается от монстров и находит ресурсы. Спойлер: Механику отбивания от монстров я потом убрал
🕒 Потрачено: 120 часов (2 месяца разработки в свободное время)
📈 Результаты:
D1: 16%
D7: 2%
Для сравнения: топовые издатели хотят D1 от 40%.
Выводы, которые я сделал:
1️⃣ Работать без отдыха тяжело. Постоянная загруженность мешает принимать правильные решения. Такой режим не подходит, если планируешь сделать 10 игр за год.
2️⃣ Воспринимал проект лиш как одну игру из десяти. Это помогло мне не терять мотивацию и двигаться дальше. 💪
Пишите в комментариях, если вам интересно узнать еще какую-то информацию или аналитику про проект 👇
Спасибо всем за лайки и активность в канале! Это мотивирует меня делиться с вами ещё больше полезной информации. 🙏
В 2020 году я выпустил свой последний проект, который, увы, оказался неуспешным. 😔 Я потратил на него много сил, и его провал отбил у меня желание продолжать. В результате я переключился: путешествовал, развивался как разработчик и техлид, женился. Эти годы дали мне заряд сил и желание снова делать игры. 🎮
И вот я решил начать заново!
Drill Master — мой первый проект после перерыва.
🎮 Ссылочка на Google Play
Для подготовки я:
🔍 Изучал рынок и анализировал игры через телеграм-каналы:
@hyper_casual_news — новости гиперказуальных игр
@storeglide — 5 роликов новых гиперказуальных игр каждый день
@hyper_casual — обсуждения и советы по теме гиперказуальных игр
📊 Для аналитики использовал:
Sensor Tower
💡 В каналах я увидел игру Idle Mine Dig: Drill & Collect.
🎮 Ссылочка на Google Play
Идея: сделать клон, но вместо ковша, собирающего ресурсы, добавить бур, который отбивается от монстров и находит ресурсы. Спойлер: Механику отбивания от монстров я потом убрал
🕒 Потрачено: 120 часов (2 месяца разработки в свободное время)
📈 Результаты:
D1: 16%
D7: 2%
Для сравнения: топовые издатели хотят D1 от 40%.
Выводы, которые я сделал:
1️⃣ Работать без отдыха тяжело. Постоянная загруженность мешает принимать правильные решения. Такой режим не подходит, если планируешь сделать 10 игр за год.
2️⃣ Воспринимал проект лиш как одну игру из десяти. Это помогло мне не терять мотивацию и двигаться дальше. 💪
Пишите в комментариях, если вам интересно узнать еще какую-то информацию или аналитику про проект 👇
❤6
Всех с наступающим годом! Желаю каждому из вас выпустить игру мечты и заработать кучу денег!
А в следующем году расскажу про неудачные проекты этого года и про новые, разработка которых уже идет.
Поделюсь с вами полезной информацией о прохождении собеседований и расскажу про архитектурные лайфхаки
С новым годом! 🎄🎉🎁
А в следующем году расскажу про неудачные проекты этого года и про новые, разработка которых уже идет.
Поделюсь с вами полезной информацией о прохождении собеседований и расскажу про архитектурные лайфхаки
С новым годом! 🎄🎉🎁
❤5🔥1🎉1🤝1
Проект Bouncing Ball
Листая как-то раз Instagram, я наткнулся на видео, где мяч прыгает внутри круга, постепенно увеличиваясь в размерах, пока не заполнит его полностью. Помню, как сильно я тогда залип на этот видос и подумал: "А что, если сделать игру с такой механикой?"
🎮 Ссылочка на Google play
🎬 Маркетинговое видео
💡 Вдохновившись, я решил потратить выходные на разработку. Итог: игра готова, и я сразу запустил маркетинговые тесты.
📈 Результаты тестов:
Playtime: 6 минут
D1: 16%
D3: 3.7%
D7: 1%
И вот что удивительно: проект, сделанный за выходные "на коленке", показал метрики не хуже, чем игра, на которую ушло два месяца работы. Я был реально в шоке!
Эта игра стала для меня экспериментом: мне хотелось понять, как аудитория отреагирует на такую простую механику. Честно, я думал, что играть в неё никто не будет. Но всё оказалось не так плохо.
Забавный факт:
Среди всех моих выпущенных игр именно Bouncing Ball в итоге принесла мне больше всего денег. Вот такой неожиданный результат! 😄
Листая как-то раз Instagram, я наткнулся на видео, где мяч прыгает внутри круга, постепенно увеличиваясь в размерах, пока не заполнит его полностью. Помню, как сильно я тогда залип на этот видос и подумал: "А что, если сделать игру с такой механикой?"
🎮 Ссылочка на Google play
🎬 Маркетинговое видео
💡 Вдохновившись, я решил потратить выходные на разработку. Итог: игра готова, и я сразу запустил маркетинговые тесты.
📈 Результаты тестов:
Playtime: 6 минут
D1: 16%
D3: 3.7%
D7: 1%
И вот что удивительно: проект, сделанный за выходные "на коленке", показал метрики не хуже, чем игра, на которую ушло два месяца работы. Я был реально в шоке!
Эта игра стала для меня экспериментом: мне хотелось понять, как аудитория отреагирует на такую простую механику. Честно, я думал, что играть в неё никто не будет. Но всё оказалось не так плохо.
Забавный факт:
Среди всех моих выпущенных игр именно Bouncing Ball в итоге принесла мне больше всего денег. Вот такой неожиданный результат! 😄
❤9👌1
Проект Galaxy Expansion 🚀
Часто в разговорах с отцом мы касались игры Cell Expansion. Отец прошёл десятки тысяч уровней, а я сам наиграл около тысячи. И вот однажды вечером я подумал: "А почему бы не попробовать сделать игру с похожей механикой, но в космической тематике?" Так и родилась идея проекта Galaxy Expansion.
Этот проект стал для меня самым долгим, серьёзным и затратным. Мы с программистом потратили на него 4 месяца, допустив множество ошибок. Давайте разберёмся, что пошло не так, и чему я научился.
Концепция 💡
Идея была объединить:
Кор-механику из Cell Expansion (пазл-игра 🧩);
Мета-механику из Leek Factory Tycoon (idle-игра ⚙️).
Кор-механика — основная игровая механика, которая привлекает и удерживает игрока. Например в симуляторе футбола кор механика это сам матч
Мета-механика — дополнительная механика, которая добавляет цели 🎯, прогресс 📈 и долгосрочный интерес. Например в симуляторе футбола это покупка и продажа членов команды
🎮 Ссылочка на Google play
🎬 Маркетинговое видео
Что было сделано ✅
1️⃣ 100 уровней кор-геймплея.
2️⃣ Редактор уровней для упрощения их создания.
3️⃣ Система Remote Config для добавления новых уровней без обновления приложения.
4️⃣ Мета-геймплей для повышения удержания.
Результаты маркетинговых тестов 📊
Тест 1:
Playtime: 12:27 ⏱️
D1: 15.5%
D3: 4.8%
D7: 1.3%
D30: 0.2%
Метрики оказались хуже, чем у предыдущих, менее затратных проектов. 😓
Изменения:
Перенёс мета-геймплей с 5 на 10 уровень. 🔄
Убрал рекламу. 🚫
Добавил аналитику по каждому уровню. 📊
Тест 2:
Playtime: 13:21 ⏱️
D1: 13.4%
D3: 4.3%
D7: 1.7%
D30: 0.6%
Метрики почти не изменились. Аналитика показала, что до мета-геймплея доходит всего 3% игроков, что говорит о слабом кор-геймплее. 🤔
Решение:
Полностью убрал мета-геймплей ❌, провёл техническую оптимизацию ⚙️, переделал несколько уровней.
Тест 3:
D1: 20%
D3: 20%
D7: 7.5%
D30: 2.5%
Эти метрики не являются релевантными, так как трафик огранический, а не рекламный, в отличии от прошлых тестов, а выборка составляет всего 50 человек. Однако я привел его тут, что бы показать главную мысль - D1 меньше 25%, что является минимум для самых маленьких издательств. А значит проект можно закрывать и не продолжать его развитие, что я и сделал
Работа над ошибками 🔍
1️⃣ 100 уровней: Не нужно. Достаточно 10 для теста.
2️⃣ Редактор уровней: Бессмысленно. Ушло 3 недели вместо дня работы без него.
3️⃣ Remote Config: Не нужен, если игроки не доходят до новых уровней.
4️⃣ Мета-геймплей: Не нужен. Его почти никто не видел.
Итог 💬
Из 4 месяцев работы 3 месяца были потрачены впустую. Эти ресурсы лучше было направить на тесты кор-геймплея и эксперименты с дизайном.
Этот проект научил меня важному правилу: в первом маркетинговом тесте важно проверять только кор-геймплей. 🎮
Как вам уроки из этого проекта? Делали ли вы когда-нибудь такие же ошибки? 😅
Часто в разговорах с отцом мы касались игры Cell Expansion. Отец прошёл десятки тысяч уровней, а я сам наиграл около тысячи. И вот однажды вечером я подумал: "А почему бы не попробовать сделать игру с похожей механикой, но в космической тематике?" Так и родилась идея проекта Galaxy Expansion.
Этот проект стал для меня самым долгим, серьёзным и затратным. Мы с программистом потратили на него 4 месяца, допустив множество ошибок. Давайте разберёмся, что пошло не так, и чему я научился.
Концепция 💡
Идея была объединить:
Кор-механику из Cell Expansion (пазл-игра 🧩);
Мета-механику из Leek Factory Tycoon (idle-игра ⚙️).
Кор-механика — основная игровая механика, которая привлекает и удерживает игрока. Например в симуляторе футбола кор механика это сам матч
Мета-механика — дополнительная механика, которая добавляет цели 🎯, прогресс 📈 и долгосрочный интерес. Например в симуляторе футбола это покупка и продажа членов команды
🎮 Ссылочка на Google play
🎬 Маркетинговое видео
Что было сделано ✅
1️⃣ 100 уровней кор-геймплея.
2️⃣ Редактор уровней для упрощения их создания.
3️⃣ Система Remote Config для добавления новых уровней без обновления приложения.
4️⃣ Мета-геймплей для повышения удержания.
Результаты маркетинговых тестов 📊
Тест 1:
Playtime: 12:27 ⏱️
D1: 15.5%
D3: 4.8%
D7: 1.3%
D30: 0.2%
Метрики оказались хуже, чем у предыдущих, менее затратных проектов. 😓
Изменения:
Перенёс мета-геймплей с 5 на 10 уровень. 🔄
Убрал рекламу. 🚫
Добавил аналитику по каждому уровню. 📊
Тест 2:
Playtime: 13:21 ⏱️
D1: 13.4%
D3: 4.3%
D7: 1.7%
D30: 0.6%
Метрики почти не изменились. Аналитика показала, что до мета-геймплея доходит всего 3% игроков, что говорит о слабом кор-геймплее. 🤔
Решение:
Полностью убрал мета-геймплей ❌, провёл техническую оптимизацию ⚙️, переделал несколько уровней.
Тест 3:
D1: 20%
D3: 20%
D7: 7.5%
D30: 2.5%
Эти метрики не являются релевантными, так как трафик огранический, а не рекламный, в отличии от прошлых тестов, а выборка составляет всего 50 человек. Однако я привел его тут, что бы показать главную мысль - D1 меньше 25%, что является минимум для самых маленьких издательств. А значит проект можно закрывать и не продолжать его развитие, что я и сделал
Работа над ошибками 🔍
1️⃣ 100 уровней: Не нужно. Достаточно 10 для теста.
2️⃣ Редактор уровней: Бессмысленно. Ушло 3 недели вместо дня работы без него.
3️⃣ Remote Config: Не нужен, если игроки не доходят до новых уровней.
4️⃣ Мета-геймплей: Не нужен. Его почти никто не видел.
Итог 💬
Из 4 месяцев работы 3 месяца были потрачены впустую. Эти ресурсы лучше было направить на тесты кор-геймплея и эксперименты с дизайном.
Этот проект научил меня важному правилу: в первом маркетинговом тесте важно проверять только кор-геймплей. 🎮
Как вам уроки из этого проекта? Делали ли вы когда-нибудь такие же ошибки? 😅
❤9🔥5👌3
Проект Chase Car Arcade 🚗
После провала Galaxy Expansion я решил попробовать другой подход — сделать игру с объемом контента только на маркетинговый креатив. Главная цель такого проекта — отснять маркетинговый креатив и проверить стоимость привлечения пользователя (CPI). На разработку игры ушло всего 2 недели.
📊 Метрики
1️⃣ CPI: >3$
2️⃣ D1: 2%
Ссылочка на Google Play
Результаты оказались неудовлетворительными, и мы решили не продолжать развитие проекта. Вместо этого я перешёл к следующей идее.
Плюсы такого подхода ✅
1️⃣ Возможность быстро проверять идеи и гипотезы.
Минусы такого подхода ❌
1️⃣ Плохой ретеншн в подобных проектах.
2️⃣ Метрики сильно зависят от качества маркетингового креатива.
Уроки из проекта Chase Car Arcade 💡
Этот подход хорош для проверки трендов или экспериментальных механик, но он имеет свои ограничения. Например, без тестирования ретеншна трудно понять долгосрочный потенциал игры.
Даже при высоком CPI проект с хорошим ретеншном может приносить доход. Поэтому чаще имеет смысл потратить чуть больше времени и ресурсов, чтобы создать игру с 10-20 минутами полноценного геймплея.
Рекомендации для Hypercasual игр
Многие продюсеры советуют:
🎯 Разрабатывать игру с минимальным, но полноценным контентом, например, 10 уровнями или 10-20 минутами геймплея.
Когда я начинал Chase Car Arcade, я знал это правило, но не понимал его на практике. Этот проект помог мне (и, надеюсь, вам) увидеть, почему важно следовать такому подходу.
Сравнение подходов
* Galaxy Expansion показал недостатки долгой разработки и большого количетва контента
* Chase Car Arcade продемонстрировал минусы минималистичного подхода.
А как вы проверяете свои идеи? Делали ли вы похожие эксперименты? 😅
После провала Galaxy Expansion я решил попробовать другой подход — сделать игру с объемом контента только на маркетинговый креатив. Главная цель такого проекта — отснять маркетинговый креатив и проверить стоимость привлечения пользователя (CPI). На разработку игры ушло всего 2 недели.
📊 Метрики
1️⃣ CPI: >3$
2️⃣ D1: 2%
Ссылочка на Google Play
Результаты оказались неудовлетворительными, и мы решили не продолжать развитие проекта. Вместо этого я перешёл к следующей идее.
Плюсы такого подхода ✅
1️⃣ Возможность быстро проверять идеи и гипотезы.
Минусы такого подхода ❌
1️⃣ Плохой ретеншн в подобных проектах.
2️⃣ Метрики сильно зависят от качества маркетингового креатива.
Уроки из проекта Chase Car Arcade 💡
Этот подход хорош для проверки трендов или экспериментальных механик, но он имеет свои ограничения. Например, без тестирования ретеншна трудно понять долгосрочный потенциал игры.
Даже при высоком CPI проект с хорошим ретеншном может приносить доход. Поэтому чаще имеет смысл потратить чуть больше времени и ресурсов, чтобы создать игру с 10-20 минутами полноценного геймплея.
Рекомендации для Hypercasual игр
Многие продюсеры советуют:
🎯 Разрабатывать игру с минимальным, но полноценным контентом, например, 10 уровнями или 10-20 минутами геймплея.
Когда я начинал Chase Car Arcade, я знал это правило, но не понимал его на практике. Этот проект помог мне (и, надеюсь, вам) увидеть, почему важно следовать такому подходу.
Сравнение подходов
* Galaxy Expansion показал недостатки долгой разработки и большого количетва контента
* Chase Car Arcade продемонстрировал минусы минималистичного подхода.
А как вы проверяете свои идеи? Делали ли вы похожие эксперименты? 😅
Google Play
Chase Car Arcade - Apps on Google Play
Become a racing legend in the thrilling game Chase Car Arcade!
🔥5❤4👍1
На днях наткнулся на прекрасный пост про "Сочность" в играх
Оригинал тут
На мой взгляд обязательные знания для всех, кто работает в геймдев индустрии, особенно тем, кто делает прототипы
Всем советую посмотреть гифку из поста!
Это, кстати, то, что мы в первую очередь тестируем у кандидатов во время Live coding на прототипы. Потому что, часто, именно программист отвечает за "сочность"
Коротко смысл в том, что что-бы сделать игру более сочной нужно добавить для действий такие реакции
* Изменение цвета объекта
* Изменение пропорций или другая Tween анимация
* Добавление VFX
* Дрожание камеры
* Звуковой эффект
* Другие эффекты, напрмер замедление времени
Оригинал тут
На мой взгляд обязательные знания для всех, кто работает в геймдев индустрии, особенно тем, кто делает прототипы
Всем советую посмотреть гифку из поста!
Это, кстати, то, что мы в первую очередь тестируем у кандидатов во время Live coding на прототипы. Потому что, часто, именно программист отвечает за "сочность"
Коротко смысл в том, что что-бы сделать игру более сочной нужно добавить для действий такие реакции
* Изменение цвета объекта
* Изменение пропорций или другая Tween анимация
* Добавление VFX
* Дрожание камеры
* Звуковой эффект
* Другие эффекты, напрмер замедление времени
🔥7
Всем привет!
На хабре вышла моя новая статья про процесс автоматизации CI/CD в Unity
Автоматизируй всё! Настройка CI-CD в Unity для ленивых (и умных) разработчиков. Часть первая
На хабре вышла моя новая статья про процесс автоматизации CI/CD в Unity
Автоматизируй всё! Настройка CI-CD в Unity для ленивых (и умных) разработчиков. Часть первая
🔥11👍5👌1
3 приёма, которые мгновенно сделают ваш код чище! 🚀
На этой неделе провел серию код ревью и решил сформировать 3 простых, но мощных совета, чтобы ваш код был читаемым и поддерживаемым!
✅ 1. Разбивайте сложные лямбда-выражения
Лямбда-методы удобны, но слишком сложные выражения ухудшают читаемость.
🔴 Плохо:
🟢 Хорошо (разбиваем на методы):
Теперь код понятнее и легче отлаживать.
---
✅ 2. Используйте ранний return вместо вложенных if-else
Чем меньше вложенность, тем чище код.
🔴 Плохо:
🟢 Хорошо:
Ранний return делает код проще и понятнее.
---
✅ 3. Избегайте глубокой вложенности логики
Чем меньше if в if, тем лучше.
🔴 Плохо:
🟢 Хорошо (разбиваем на методы):
Теперь основная функция короткая, а обработка вынесена в отдельный метод.
---
💡 Вывод:
✅ Разбивайте сложные выражения на методы
✅ Используйте ранний return, чтобы избежать лишних if-else
✅ Минимизируйте вложенность для лучшей читаемости
Используете ли вы эти методы на практике или они для вас вновинку?
Поделитесь в комментариях👇
На этой неделе провел серию код ревью и решил сформировать 3 простых, но мощных совета, чтобы ваш код был читаемым и поддерживаемым!
✅ 1. Разбивайте сложные лямбда-выражения
Лямбда-методы удобны, но слишком сложные выражения ухудшают читаемость.
🔴 Плохо:
var evenNumbers = numbers
.Where(n => n % 2 == 0)
.Select(n => n * n)
.OrderByDescending(n => n)
.ToArray();
🟢 Хорошо (разбиваем на методы):
private bool IsEven(int number) => number % 2 == 0;
private int Square(int number) => number * number;
var evenNumbers = numbers
.Where(IsEven)
.Select(Square)
.OrderByDescending(n => n)
.ToArray();
Теперь код понятнее и легче отлаживать.
---
✅ 2. Используйте ранний return вместо вложенных if-else
Чем меньше вложенность, тем чище код.
🔴 Плохо:
public void Attack(int damage)
{
if (damage > 0)
{
health -= damage;
if (health <= 0)
{
Die();
}
else
{
Debug.Log("Player took damage");
}
}
else
{
Debug.Log("Invalid damage value");
}
}
🟢 Хорошо:
public void Attack(int damage)
{
if (damage <= 0)
{
Debug.Log("Invalid damage value");
return;
}
health -= damage;
if (health <= 0)
{
Die();
return;
}
Debug.Log("Player took damage");
}
Ранний return делает код проще и понятнее.
---
✅ 3. Избегайте глубокой вложенности логики
Чем меньше if в if, тем лучше.
🔴 Плохо:
public void ProcessEnemies(List<Enemy> enemies)
{
foreach (var enemy in enemies)
{
if (enemy.IsAlive)
{
if (enemy.DistanceToPlayer < 10)
{
if (enemy.HasWeapon)
{
enemy.Attack();
}
}
}
}
}
🟢 Хорошо (разбиваем на методы):
public void ProcessEnemies(List<Enemy> enemies)
{
foreach (var enemy in enemies)
{
HandleEnemy(enemy);
}
}
private void HandleEnemy(Enemy enemy)
{
if (!enemy.IsAlive)
return;
if (enemy.DistanceToPlayer >= 10)
return;
if (!enemy.HasWeapon)
return;
enemy.Attack();
}
Теперь основная функция короткая, а обработка вынесена в отдельный метод.
---
💡 Вывод:
✅ Разбивайте сложные выражения на методы
✅ Используйте ранний return, чтобы избежать лишних if-else
✅ Минимизируйте вложенность для лучшей читаемости
Используете ли вы эти методы на практике или они для вас вновинку?
Поделитесь в комментариях👇
👍13🔥7❤2👌1
🍊"Сочность ревью"
Всем привет! 👋
На работе ломаем голову, как найти крутого программиста, который умеет быстро и качественно собирать прототипы и придавать им тот самый "вау-эффект".
💡 И тут родилась идея — "Сочность ревью".
Суть простая: нужен программист, который сможет на лету настраивать "сочность" игры, используя готовые ассеты. 🎨✨
🛠️ Идея тестового задания:
Хотим проверить навык через лайвкодинг — чтобы кандидат показал, как он видит и делает эффект по-настоящему вкусным.
Пример задания:
На сцене — пол из кубов (100x100) и круг, который прыгает по этим кубам.
Нужно сделать эффект на кубах и круге при приземлении — чтобы выглядело сочно! 🍑💥
🔥 Вопрос к вам:
Как вам такое тестовое? Подходит для проверки скиллов?
И... может, кто-то хочет попробовать себя в этом задании just for fun? 😉
Ставьте 🍓 если идея огонь и 💩 если идея не очень
А если хотите попробовть, то пишите в комменты или в личку!
Всем привет! 👋
На работе ломаем голову, как найти крутого программиста, который умеет быстро и качественно собирать прототипы и придавать им тот самый "вау-эффект".
💡 И тут родилась идея — "Сочность ревью".
Суть простая: нужен программист, который сможет на лету настраивать "сочность" игры, используя готовые ассеты. 🎨✨
🛠️ Идея тестового задания:
Хотим проверить навык через лайвкодинг — чтобы кандидат показал, как он видит и делает эффект по-настоящему вкусным.
Пример задания:
На сцене — пол из кубов (100x100) и круг, который прыгает по этим кубам.
Нужно сделать эффект на кубах и круге при приземлении — чтобы выглядело сочно! 🍑💥
🔥 Вопрос к вам:
Как вам такое тестовое? Подходит для проверки скиллов?
И... может, кто-то хочет попробовать себя в этом задании just for fun? 😉
Ставьте 🍓 если идея огонь и 💩 если идея не очень
А если хотите попробовть, то пишите в комменты или в личку!
💩14🍓5🔥1
💡 Немного мыслей с текущего Game Jam'а
Сейчас менторю команды на гейм джеме и решил поделиться наблюдениями. Плюс вспомнил прошлый джем, где участвовал как разработчик.
🎮 1. Игровые движки
Примерно 40% проектов делают на Unreal Engine 5 и около 30% — на Unity (субъективно, джем ещё идёт). Часто вижу проекты на Godot, а также на менее популярных движках вроде Phaser.
🐍 2. Godot
Удивило, сколько новичков выбирают Godot. Кажется, даже больше, чем Unity и Unreal вместе. У движка явно светлое будущее — ждём волну новых инди-игр на нём.
👥 3. Роли участников
Очень много ребят в сфере UI/UX и 2D арта, да и саунд-дизайнеров хватает. А вот разработчиков явно не хватает — многие команды страдают от нехватки кодеров.
🤖 4. Все используют AI
Художники и саунд-дизайнеры активно юзают ChatGPT для генерации простых скриптов. Этого хватает для базовых механик в хоррорах или простых third-person играх.
💬 А что вы думаете по этому поводу? Повлиет ли такое соотношение на игровую индустрию в ближайшее 3-5 лет?
Сейчас менторю команды на гейм джеме и решил поделиться наблюдениями. Плюс вспомнил прошлый джем, где участвовал как разработчик.
🎮 1. Игровые движки
Примерно 40% проектов делают на Unreal Engine 5 и около 30% — на Unity (субъективно, джем ещё идёт). Часто вижу проекты на Godot, а также на менее популярных движках вроде Phaser.
🐍 2. Godot
Удивило, сколько новичков выбирают Godot. Кажется, даже больше, чем Unity и Unreal вместе. У движка явно светлое будущее — ждём волну новых инди-игр на нём.
👥 3. Роли участников
Очень много ребят в сфере UI/UX и 2D арта, да и саунд-дизайнеров хватает. А вот разработчиков явно не хватает — многие команды страдают от нехватки кодеров.
🤖 4. Все используют AI
Художники и саунд-дизайнеры активно юзают ChatGPT для генерации простых скриптов. Этого хватает для базовых механик в хоррорах или простых third-person играх.
💬 А что вы думаете по этому поводу? Повлиет ли такое соотношение на игровую индустрию в ближайшее 3-5 лет?
👍2🔥2❤1
🔧 Как я упрощаю рефакторинг
Последние пару недель я активно рефакторю систему для HTTP-запросов в нашем проекте. Хочу поделиться несколькими советами, которые помогают делать это чисто и безопасно.
🎯 Совет 1. 1 коммит — 1 правка
🔹 Внесли изменения
🔹 Проверили, что ничего не сломалось
🔹 Закоммитили
🎯 Совет 2. Атомарные изменения
Каждый коммит должен содержать 1 логически завершённое изменение.
Пример:
Вынесли код в отдельный метод — уже повод для коммита.
Допускаю объединение нескольких стилистических изменений в один коммит, но логические изменения лучше разделять.
🎯 Совет 3. Чётко ставьте цель коммита
Пример:
🔹 Коммит 1: Вынести обработку ошибок в отдельный класс.
🔹 Коммит 2: Разделить обработку ошибок на классы с общим интерфейсом.
🎯 Совет 4. Автотесты — если возможно
Покрытие рефакторинга тестами сильно упрощает жизнь.
⚠️ У меня редко получается писать тесты до начала рефакторинга, но если код позволяет — очень советую.
✅ Плюсы подхода:
🔹 Фокусируетесь на каждом этапе, а не рефакторите всё подряд.
🔹 Можно в любой момент прервать работу, завершив текущий коммит.
🔹 Держите в голове меньше контекста.
🔹 Легче понять, где что сломалось, так как каждая правка — отдельная итерация.
Последние пару недель я активно рефакторю систему для HTTP-запросов в нашем проекте. Хочу поделиться несколькими советами, которые помогают делать это чисто и безопасно.
🎯 Совет 1. 1 коммит — 1 правка
🔹 Внесли изменения
🔹 Проверили, что ничего не сломалось
🔹 Закоммитили
🎯 Совет 2. Атомарные изменения
Каждый коммит должен содержать 1 логически завершённое изменение.
Пример:
Вынесли код в отдельный метод — уже повод для коммита.
Допускаю объединение нескольких стилистических изменений в один коммит, но логические изменения лучше разделять.
🎯 Совет 3. Чётко ставьте цель коммита
Пример:
🔹 Коммит 1: Вынести обработку ошибок в отдельный класс.
🔹 Коммит 2: Разделить обработку ошибок на классы с общим интерфейсом.
🎯 Совет 4. Автотесты — если возможно
Покрытие рефакторинга тестами сильно упрощает жизнь.
⚠️ У меня редко получается писать тесты до начала рефакторинга, но если код позволяет — очень советую.
✅ Плюсы подхода:
🔹 Фокусируетесь на каждом этапе, а не рефакторите всё подряд.
🔹 Можно в любой момент прервать работу, завершив текущий коммит.
🔹 Держите в голове меньше контекста.
🔹 Легче понять, где что сломалось, так как каждая правка — отдельная итерация.
👍3🔥2
This media is not supported in your browser
VIEW IN TELEGRAM
🔥 5 советов, как писать код быстрее
Хотите ускорить свою работу в коде? Вот 5 приёмов, которые помогают мне писать быстрее и эффективнее.
🚀 Совет 1. Используйте HotKeys в Rider или Visual Studio
Чем меньше вы используете мышку, тем быстрее работаете. Горячие клавиши позволяют мгновенно переключаться между вкладками, перемещаться по коду, быстро выполнять рефакторинг и автодополнение.
Я предпочитаю Rider — он удобнее, на мой взгляд. Но знаю ребят, которые любят Visual Studio. Главное — выучить основные HotKeys и активно использовать их в работе.
Полезные комбинации в Rider:
🔹 Ctrl + Shift + R — рефакторинг кода
🔹 Alt + Enter — быстрые исправления
🔹 Shift + Shift — глобальный поиск
В Visual Studio тоже есть мощные комбинации, например:
🔹 Ctrl + D — дублирование строки
🔹 Ctrl + K, Ctrl + D — автоформатирование кода
Советую посмотреть обучающие видео на Youtube и потратить несколько дней на их изучение
🤖 Совет 2. AI-ассистент — must-have
Современные инструменты на базе ИИ значительно ускоряют написание кода. Я уже несколько лет использую GitHub Copilot, и он экономит уйму времени.
Как помогает Copilot:
🔹Генерирует повторяющиеся конструкции (геттеры, сеттеры, циклы и т. д.)
🔹Подсказывает возможные решения, основываясь на контексте кода
Также можно использовать ChatGPT для генерации кода, объяснения алгоритмов и поиска оптимальных решений.
📌 Совет 3. "Live Templates" — код за секунды
Live Templates — это готовые заготовки кода, которые можно вставлять по коротким командам. Они особенно полезны для шаблонных конструкций, которые приходится писать часто.
Примеры:
🔹 prop → public int MyProperty { get; set; }
🔹 for → for (int i = 0; i < length; i++) { }
🔹 ctor → создание конструктора класса
В Rider можно создавать свои шаблоны. Например, если вы часто пишете "[field: SerializeField] public type Type { get; private set; }", можно использовть шаблон sprop, который автоматически развернётся в этот код
⌨ Совет 4. Навык слепой печати
Если вы печатаете вслепую, то не тратите время на поиск клавиш, а концентрируетесь на коде. Это значительно ускоряет процесс.
Лет 5 назад я целенаправленно выучил слепую печать на русском и английском. Сейчас я даже не задумываюсь о наборе текста, и это повышает продуктивность.
Как научиться?
🔹 Сайты типа https://klavogonki.ru помогут натренировать навык.
🔹 Практика каждый день хотя бы 10 минут
У меня скорость печати - 300 символов на Русском и 200 на Английском
👇Пишите в комментариях вашу скорость!
🎛 Совет 5. Программируемая клавиатура
Я использую Moonlander, и это одна из лучших инвестиций в продуктивность. Можно настроить кастомные слои для разных задач, что значительно ускоряет работу.
Как это помогает?
🔹 Первый слой — стандартное управление, клавиши WASD
🔹 Второй слой — стрелки навигации (без отрыва от основной позиции)
🔹 Третий слой — перемещение по методам в Rider
🔹 Четвёртый слой — управление вкладками, перемещение блоков кода
Такая настройка позволяет снизить нагрузку на пальцы и ускорить работу с кодом.
Ставьте 🔥, если было полезно, и делитесь в комментариях, какие фишки вы используете уже сейчас!
Хотите ускорить свою работу в коде? Вот 5 приёмов, которые помогают мне писать быстрее и эффективнее.
🚀 Совет 1. Используйте HotKeys в Rider или Visual Studio
Чем меньше вы используете мышку, тем быстрее работаете. Горячие клавиши позволяют мгновенно переключаться между вкладками, перемещаться по коду, быстро выполнять рефакторинг и автодополнение.
Я предпочитаю Rider — он удобнее, на мой взгляд. Но знаю ребят, которые любят Visual Studio. Главное — выучить основные HotKeys и активно использовать их в работе.
Полезные комбинации в Rider:
🔹 Ctrl + Shift + R — рефакторинг кода
🔹 Alt + Enter — быстрые исправления
🔹 Shift + Shift — глобальный поиск
В Visual Studio тоже есть мощные комбинации, например:
🔹 Ctrl + D — дублирование строки
🔹 Ctrl + K, Ctrl + D — автоформатирование кода
Советую посмотреть обучающие видео на Youtube и потратить несколько дней на их изучение
🤖 Совет 2. AI-ассистент — must-have
Современные инструменты на базе ИИ значительно ускоряют написание кода. Я уже несколько лет использую GitHub Copilot, и он экономит уйму времени.
Как помогает Copilot:
🔹Генерирует повторяющиеся конструкции (геттеры, сеттеры, циклы и т. д.)
🔹Подсказывает возможные решения, основываясь на контексте кода
Также можно использовать ChatGPT для генерации кода, объяснения алгоритмов и поиска оптимальных решений.
📌 Совет 3. "Live Templates" — код за секунды
Live Templates — это готовые заготовки кода, которые можно вставлять по коротким командам. Они особенно полезны для шаблонных конструкций, которые приходится писать часто.
Примеры:
🔹 prop → public int MyProperty { get; set; }
🔹 for → for (int i = 0; i < length; i++) { }
🔹 ctor → создание конструктора класса
В Rider можно создавать свои шаблоны. Например, если вы часто пишете "[field: SerializeField] public type Type { get; private set; }", можно использовть шаблон sprop, который автоматически развернётся в этот код
⌨ Совет 4. Навык слепой печати
Если вы печатаете вслепую, то не тратите время на поиск клавиш, а концентрируетесь на коде. Это значительно ускоряет процесс.
Лет 5 назад я целенаправленно выучил слепую печать на русском и английском. Сейчас я даже не задумываюсь о наборе текста, и это повышает продуктивность.
Как научиться?
🔹 Сайты типа https://klavogonki.ru помогут натренировать навык.
🔹 Практика каждый день хотя бы 10 минут
У меня скорость печати - 300 символов на Русском и 200 на Английском
👇Пишите в комментариях вашу скорость!
🎛 Совет 5. Программируемая клавиатура
Я использую Moonlander, и это одна из лучших инвестиций в продуктивность. Можно настроить кастомные слои для разных задач, что значительно ускоряет работу.
Как это помогает?
🔹 Первый слой — стандартное управление, клавиши WASD
🔹 Второй слой — стрелки навигации (без отрыва от основной позиции)
🔹 Третий слой — перемещение по методам в Rider
🔹 Четвёртый слой — управление вкладками, перемещение блоков кода
Такая настройка позволяет снизить нагрузку на пальцы и ускорить работу с кодом.
Ставьте 🔥, если было полезно, и делитесь в комментариях, какие фишки вы используете уже сейчас!
🔥13
Всем привет!
Выпустил вторую часть про CI/CD где в формате туториала показываю как сделать сборку через Unity Cloud Build
https://habr.com/ru/articles/891160/
Решил отделить создание сборки в отдельную статью, так как вместе с интеграцией в Team City получается довольно много информации. И в третьей часте уже расскажу про интеграцию Unity Cloud build и Team City
Выпустил вторую часть про CI/CD где в формате туториала показываю как сделать сборку через Unity Cloud Build
https://habr.com/ru/articles/891160/
Решил отделить создание сборки в отдельную статью, так как вместе с интеграцией в Team City получается довольно много информации. И в третьей часте уже расскажу про интеграцию Unity Cloud build и Team City
Хабр
Автоматизируй всё! Настройка CI-CD в Unity Часть вторая. Сборка Unity Cloud build
Привет, читатель! В предыдущей статье я рассказал о существующих CI/CD системах и объяснил, почему мы выбрали связку Unity Cloud Build + TeamCity. В этой и следующих статьях я покажу вам как вы можете...
👍8🔥3👏2
🔥 Автоматизируй заливку сборки в Testflight
Делюсь с вами скриптом для автоматической заливки сборки в Testfligh через Unity cloud build
Как его настроить:
Часть 1. Создаем shell script
Шаг 1.
В папке с проектом, там, где находится папка Assets, Library создаем папку "Scripts"
Шаг 2.
В папке "Scripts" создаем файл с именем "upload_to_testflight.sh"
Шаг 3.
Добавляем Shell script
Часть 2. Добавляем скрипт в Post-build scripts в testflight сборке
Шаг 1.
Заходим в настройки конфигурации билда => Advanced settings => Script hooks
Шаг 2.
В поле Post-build script добавляем поле "Scripts/upload_to_testflight.sh"
Часть 2. Настраиваем параметры в UnityCloud build
Шаг 1.
Заходим в настройки конфигурации билда => Advanced settings => Environment Variables
Шаг 2.
Добавляем переменную с именем "BUILD_TARGET_ID", в качестве значение указываем название конфигурации, которую вы редактируете
Шаг 3.
Добавляем переменную с именем "ITUNES_USERNAME", в качестве значение указываем вашу почту, с коротой у вас есть доступ к appstoreconnect
Шаг 4.
Добавляем переменную с именем "ITUNES_PASSWORD", в качестве значение указываем вашу пароль приложения, не путать с личным паролем
Создать пароль приложения можно тут https://appleid.apple.com/
для этого
1. Заходим в аккаунт
2. Нажимаем пароли приложения (App specific passwords)
3. Идем по шагам и получаем ваш пароль. Сохраните его, он вам может потребоваться в будущем
4. Именно этот пароль нужно добавить в поле "ITUNES_PASSWORD"
Если вы все сделали правильно, то после сборки запуститься скрипт, который зальет вашу сборку в testflight
FAQ
1. Если у вас есть мак с установленным Xcode, то локально проверить параметры можно с помощью этого кода
xcrun altool --validate-app -f <Путь к IPA сборке> -t ios -u <email для доступа к appstoreconnect> -p <пароль приложения>
2 Можно добавить код, для нотификаци, например в Discord, тогда скрипт будет выглядеть так
{WEBHOOK_ID} — уникальный идентификатор вебхука
{WEBHOOK_TOKEN} — секретный токен, который нужен для отправки сообщений
Возможно мог упустить какие-то детали или нюансы, тогда пиши в комментариях, разберем и дополню пост 👇
А если было полезно то ставьте 🔥. Ваш фидбек очень важен для меня и дает мотивацию делать больше полезных постов и понимать, что вам интересно
Делюсь с вами скриптом для автоматической заливки сборки в Testfligh через Unity cloud build
Как его настроить:
Часть 1. Создаем shell script
Шаг 1.
В папке с проектом, там, где находится папка Assets, Library создаем папку "Scripts"
Шаг 2.
В папке "Scripts" создаем файл с именем "upload_to_testflight.sh"
Шаг 3.
Добавляем Shell script
#!/bin/bash
#Unload to testflight
echo "Uploading IPA to Appstore Connect..."
#Path is "/BUILD_PATH/<ORG_ID>.<PROJECT_ID>.<BUILD_TARGET_ID>/.build/last/<BUILD_TARGET_ID>/build.ipa"
path="$WORKSPACE/.build/last/$BUILD_TARGET_ID/build.ipa"
if xcrun altool --upload-app -f $path -t ios -u $ITUNES_USERNAME -p $ITUNES_PASSWORD ; then
echo "Upload IPA to Appstore Connect finished with success"
else
echo "Upload IPA to Appstore Connect failed"
fi
Часть 2. Добавляем скрипт в Post-build scripts в testflight сборке
Шаг 1.
Заходим в настройки конфигурации билда => Advanced settings => Script hooks
Шаг 2.
В поле Post-build script добавляем поле "Scripts/upload_to_testflight.sh"
Часть 2. Настраиваем параметры в UnityCloud build
Шаг 1.
Заходим в настройки конфигурации билда => Advanced settings => Environment Variables
Шаг 2.
Добавляем переменную с именем "BUILD_TARGET_ID", в качестве значение указываем название конфигурации, которую вы редактируете
Шаг 3.
Добавляем переменную с именем "ITUNES_USERNAME", в качестве значение указываем вашу почту, с коротой у вас есть доступ к appstoreconnect
Шаг 4.
Добавляем переменную с именем "ITUNES_PASSWORD", в качестве значение указываем вашу пароль приложения, не путать с личным паролем
Создать пароль приложения можно тут https://appleid.apple.com/
для этого
1. Заходим в аккаунт
2. Нажимаем пароли приложения (App specific passwords)
3. Идем по шагам и получаем ваш пароль. Сохраните его, он вам может потребоваться в будущем
4. Именно этот пароль нужно добавить в поле "ITUNES_PASSWORD"
Если вы все сделали правильно, то после сборки запуститься скрипт, который зальет вашу сборку в testflight
FAQ
1. Если у вас есть мак с установленным Xcode, то локально проверить параметры можно с помощью этого кода
xcrun altool --validate-app -f <Путь к IPA сборке> -t ios -u <email для доступа к appstoreconnect> -p <пароль приложения>
2 Можно добавить код, для нотификаци, например в Discord, тогда скрипт будет выглядеть так
#!/bin/bash
DISCORD_WEBHOOK_URL="https://discord.com/api/webhooks/{WEBHOOK_ID}/{WEBHOOK_TOKEN}"
#Unload to testflight
echo "Uploading IPA to Appstore Connect..."
#Path is "/BUILD_PATH/<ORG_ID>.<PROJECT_ID>.<BUILD_TARGET_ID>/.build/last/<BUILD_TARGET_ID>/build.ipa"
path="$WORKSPACE/.build/last/$BUILD_TARGET_ID/build.ipa"
if xcrun altool --upload-app -f $path -t ios -u $ITUNES_USERNAME -p $ITUNES_PASSWORD ; then
echo "Upload IPA to Appstore Connect finished with success"
MESSAGE="✅ Deploy to testflight success: $BUILD_TARGET_ID#$UCB_BUILD_NUMBER!"
else
echo "Upload IPA to Appstore Connect failed"
MESSAGE="❌ Deploy to testflight failed: $BUILD_TARGET_ID#$UCB_BUILD_NUMBER!"
fi
# Отправка уведомления через curl
curl -H "Content-Type: application/json" \
-X POST \
-d "{\"content\": \"$MESSAGE\"}" \
"$DISCORD_WEBHOOK_URL"
{WEBHOOK_ID} — уникальный идентификатор вебхука
{WEBHOOK_TOKEN} — секретный токен, который нужен для отправки сообщений
Возможно мог упустить какие-то детали или нюансы, тогда пиши в комментариях, разберем и дополню пост 👇
А если было полезно то ставьте 🔥. Ваш фидбек очень важен для меня и дает мотивацию делать больше полезных постов и понимать, что вам интересно
🔥11💩1🤝1
Мнение подписчиков. Какой ECS-фреймворк выбрать в 2025 году?
Привет, разработчики! У меня назрел интересный вопрос: если делать игру на ПК, похожую на Factorio, где очень много объектов и ключевой момент — высокая производительность, какой ECS-фреймворк использовать?
Последний раз я работал с ECS три года назад, решил обновить знания, но ресерч оказался… разочаровывающим. 😅
Разбирал такие варианты:
1️⃣ DOTS – постоянные проблемы, нестабильность для больших проектов.
2️⃣ LeoECS – кажется, давно не поддерживается.
3️⃣ ECSLite – рабочий вариант, но разработка остановлена.
4️⃣ Morpeh ECS – активно развивается, но выглядит сырым.
5️⃣ Entitas – давно не обновлялся, что настораживает.
6️⃣ Самописный ECS – полный контроль, но сомнительное удовольствие.
А что выбрали бы вы? Может, есть годные альтернативы, о которых я не знаю? Делитесь мнениями в комментах! 👇
Привет, разработчики! У меня назрел интересный вопрос: если делать игру на ПК, похожую на Factorio, где очень много объектов и ключевой момент — высокая производительность, какой ECS-фреймворк использовать?
Последний раз я работал с ECS три года назад, решил обновить знания, но ресерч оказался… разочаровывающим. 😅
Разбирал такие варианты:
1️⃣ DOTS – постоянные проблемы, нестабильность для больших проектов.
2️⃣ LeoECS – кажется, давно не поддерживается.
3️⃣ ECSLite – рабочий вариант, но разработка остановлена.
4️⃣ Morpeh ECS – активно развивается, но выглядит сырым.
5️⃣ Entitas – давно не обновлялся, что настораживает.
6️⃣ Самописный ECS – полный контроль, но сомнительное удовольствие.
А что выбрали бы вы? Может, есть годные альтернативы, о которых я не знаю? Делитесь мнениями в комментах! 👇
🔥1