Хех, рад, что статьи принесли хоть какую-то пользу!
P.S. — работа идет, думаю в сентябре-октябре сделаю новую статью по продвижению, с уже гораздо большим опытом. Так же думаю стоит как-нибудь уделить время да написать статью про монетизацию. Тоже очень важный момент. Можно хорошо раскрутить игру, но если монетизация плохая — хороших результатов вряд ли получится достичь.
С размером вы можете глянуть через консоль что и как занимает. Просто соберите билд, потом откройте табу Console, в правом верхнем углу над консолью будет маленькая кнопка для вывода контекстного меню. Кликните по ней и нажмите Open Editor Log. В нем можно будет отыскать что-то вроде подобной информации:
По нему можно будет с большего понять, в каком направлении стоит поработать. Это конечно Uncompressed Size, но тем не менее.
Например если много занимают текстуры, можно посмотреть, установлена ли компрессия для текстур. Я например использую Crunched ETC, иногда просто Compressed ETC (порой на некоторый текстурах Compressed ETC меньше жрет памяти, чем Crunched, хотя Crunched в 90% случаях лучше в плане размера.
Звуки так же стоит пересматривать, порой без компрессии они очень даже много жрут памяти.
В общем и целом, в Unity можно достаточно мощно сократить размер билда.
100$ в год, можно отнять от бюджета на рекламу. Хотя в App Store ещё сложнее набрать установки. В Google Play с этим делом все обстоят куда лучше, да и реклама на ресурсах с уклоном на iOS гораздо дороже, чем в Android, вот такая вот беда.
Другой момент, в iOS более платежеспособная аудитория, но её набрать конечно же гораздо сложнее.
Не боись, все под контролем :). Возможно кто-то сделал это из-за навязывания короны вместо Unity.
Вообще Unity хорош тем, что если автор задумает создать 3д проект в будущем, то это будет уже гораздо легче, чем потом пытаться с короны спрыгнуть на другой движок.
Я просто что-то подобное для Animator-а делал в одном из проектов. Так же отключал при выходе из кадра, получался хороший прирост. В текущем проекте нет необходимости в этом.
Переключился в новом проекте на TextMesh Pro, нарадоваться не могу. Выглядит великолепно, первое время пришлось повозиться с изучением, но зато на выходе получаешь красивую картинку со множеством настроек и способами форматирования текста. Возвращаться на обычный UI Text и в мыслях не было.
В остальном, не понятно почему в статье выделили TextMesh Pro Sprite Asset как отдельный способ работы с текстом. Это прямая возможность TextMesh Pro работать со спрайтами в одной линии с текстом. Они неразрывны.
Думаю пока стоит все-таки поработать над игрой. Вернее попробовать сделать полностью новый проект.
Например на Unity есть готовый проект для обучения Space Shooter. Вот небольшой отрывок игры на YouTube. Это обучающий проект и к сожалению он выглядит привлекательнее, чем описанный в статье ремейк прошлой игры.
Если бы вы работали на Unity, то смогли бы просто скачать готовый проект Space Shooter, добавить уровней, различных ачивок и вышла бы вполне увлекательная игра. По времени не заняло бы больше месяца.
Я это к тому, что ремейк вашей игры выглядит визуально контрастно, посвежее чем предыдущая версия, но в целом геймплей, общий визуальный ряд немного скудноват.
Я бы вливал в продвижение только в том случае, если бы был уверен, что игра сможет найти свою аудиторию.
Если вернуться к ремейку, то геймплей должен быть ярким и динамичным. Игра думаю позиционируется как убивалка времени, имеет портретный режим, значит можно играть в общественном транспорте по пути на работу (или в любое иное место). Игре стоит добавить динамичности. Для этого можно оживить игровую камеру, добавить эффект тряски, приближения, отдаления. Игровые препятствия сделать разнообразными, чтобы это были не просто палки с натянутой текстурой космоса, а например космический мусор, обломки космических станций, метеориты, вспышки каких нибудь излучений. Можно представить, что мы играем за мчащуюся звезду, добавить возможность её апгрейда (например добавить здоровье, мол, каждое столкновение с объектом отнимает определенное количество здоровья, чем больше объект — тем больше он отнимет здоровье). Добавить возможность улучшить скорость маневрирования, добавить способность выпускать вспышку, которая будет отнимать ваше здоровье, но при этом будет разрушать все близ находящиеся осколки, метеориты и прочие препятствия. Сделать движущимся вниз задний фон, чтобы было ощущение движения.
Что-то вроде такой игры была бы куда веселее, ну, в общем, смотрите сами, можете попробовать вложиться в продвижение игры, но как уже говорил, по видеороликам пока все выглядит грустно.
Понятно, спасибо. Просто я так понимаю сие дело позиционируется как ассет, значит должно быть гибким. Допустим движение противников у всех может быть реализовано разными способами, каким образом ассет определит, что отключать следует, а что нет, а что стоит отключить наполовину. Ну да ладно :)
А какие именно объекты отключаете? Ведь меши и так не отрисовываются, если они не попадают в кадр (или скрыты другими, более громоздкими объектами при настроенном Occlusion Culling). Вроде бы только Animator разумно отключать вне поля видимости, но ведь там и так есть способы, при которых Animator не будет жрать ресурсов за пределами кадра.
Невозможно решить уравнение, в котором из ста параметров известен только один.
— где выдают FPS, в редакторе или в конечном билде?
— проект на мобильную платфору или PC?
— включена ли вертикальная синхронизация?
— какой вообще FPS? 30? 60? 360? 2042?
— что это за проект такой? Сколько вертексов в кадре, сколько вызовов отрисовки?
Может быть у вас процессор — bottleneck, а вы тут пытаетесь видеокарты менять. Да хоть 10 титанов в sli поставьте, если bottleneck в процессоре/скорости оперативки или ещё в каких параметрах, смена видеокарты не поможет. Нужно смотреть профайл, смотреть что дольше всего обрабатывается. Может у вас видеокарта на 10% загружена.
Зделаю ремарку, что я из Беларуси, хотя с Россией обычно одно и то же.
А в чём проблема?
Проблема с оплатой в том, что для этого нужно завести отдельную карточку ИП, ибо оплачивать можно только с карточки ИП для нужд бизнеса (конечно можно нарушать закон и платить как физ лицо, в надежде что не найдут)
Зачем ломать голову? УСН 6% – и расходы не учитываешь.
Если в России это так, то вам невероятно повезло. В Беларуси есть налог на доходы иностранной организации. Оплачивая % от прибыли, придется 15% от этой суммы платить налог. Конечно, этого можно избежать, если Epic Games (или кому там идут выплаты) зарегистрирован в той стране, в которой есть закон об избежании двойного налогообложения, но для этого придется писать письма в Epic Games с просьбой предоставить справку, подтверждающие, что они действительно находятся в стране, с которой у нас есть закон об избежании двойного налогообложения. В общем, головная боль. Плюс помимо этого нужно смотреть, возникает ли агентский НДС (даже если ИП без НДС, от агентского НДС никто не освобождал), что опять же, геморрой.
От суммы свыше $3000/квартал. Это однозначно прописано, даже FAQ есть.
В Unity данная сумма равна 100к$ в год. Что равняется 25 000$ в квартал. Куда приятнее, причем при превышении нужно будет просто купить подписку, без всяких отчислений на банковские счета.
какие ещё документы?
Ну нужно же как-то показать, что ты заработал 5000$ (например) а не 250 000$, им же нужно понять, с какой суммы ты должен платить процент. Видимо нужно будет составлять инвоисы, или ещё что, что опять же, лишняя головная боль по сравнению с Unity, где при превышении нужно будет всего лишь купить платную подписку (которая будет гораздо дешевле, чем требуемый процент у конкурента).
Потому в этом плане останусь при мнении, что Unity куда проще и привлекательнее в этом плане.
«Конкурент» требуют % от прибыли со всеми вытекающими проблемами в виде «как его нормально платить», «как потом ломать голову над уплатой налогов с такими оплатами», «от какой суммы считать процент», «какие дополнительные документы нужно будет создавать» и прочий бред, над которым большинству разработчиков не будет желания тратить и так не достающее время.
Не нужно быть прямолинейным, думаю Kos-Boss имел в виду тот случай, если разработчик надумает развивать игру, добавить возможность замедления времени, сделать паузу, сделать разные типы шариков с разной скоростью.
При таких манипуляциях придется полностью перелопачивать весь код. Вспоминать, где ты там скорость захардкодил и другие неприятные вещи.
Как сказал автор статьи, да, не стоит нагружать начинающих сразу же огромным объемом информации, что Kos-Boss и решил прокомментировать, добавив свое мнение, и это здорово. Начинающий разработчик прочитает статью, посмотрит комментарий и сделает вывод, мол: «понятно, можно написать как в статье, а можно сделать все более гибким, что позволит мне в дальнейшем с легкостью внедрять изменения».
От себя хотелось бы добавить:
void Update() {
rb.velocity = new Vector3 (speed, 0f,0f);
}
Значение speed стоит умножать на Time.deltaTime, чтобы предотвратить разную скорость при разном количестве fps. К примеру, если один человек запустит игру и у него будет 60 fps, а у другого компьютер более слабый, будет допустим 30 fps, то у второго человека машина будет перемещаться в два раза медленнее, по сравнению с первым, потому что у перого машина 60 раз в секунду получает ускорение speed, а у второго игрока только 30 раз в секунду, что в два раза медленнее.
Все дело в том, что функция Update() выполняется каждый кадр. Умножение любой скоростной переменной на Time.deltaTime позволит сделать её независимой от количества кадров в секунду.
Time.deltaTime изменяется в зависимости от fps, например если у человека 60 fps, Time.deltaTime образно говоря будет равен 0.25f, а если у человека игра подвисает и идет в 30 fps, то Time.deltaTime будет равен 0.5f (в два раза больше), таким образом у первого игрока 5f * 0.25f (будет выполняться 60 раз в секунду), а у второго 5f * 0.5f (будет выполняться 30 раз в секунду). В результате за реальную секунду у обоих игроков машина сдвинется на абсолютно одинаковое расстояние.
Time.deltaTime нужно применять в функциях Update() везде, где есть какие-либо переменные, отвечающие за скорость передвижения того или иного объекта.
P.S. — Нужно будет только увеличить значение speed, иначе после добавления Time.deltaTime скорость машины будет очень медленной.
Все конечно здорово, но в конечном итоге в 90% случаев успех игры зависит от маркетинга. Как бы человек не вылизывал игру, какие бы невероятные механики не придумывались, в 90% случаев все решит маркетинг. Если в игре будет хорошая монетизация, грамотное продвижение — игра будет успешной, в противном случае, никакие уникальные идеи не спасут (конечно же, в 90% случаев, оставим 10% на исключения). На своем примере, за полтора месяца в своей игре набрал еле-еле 50к установок, передал игру другому разработчику, он за 2,5 месяца смог превысить рубеж в 1млн установок. В общем, нужно учиться продвигать игры, сейчас это к сожалению гораздо важнее, чем сама игра.
А на самом деле — нет, это весьма «составит труда», и вообще одна из главных печалей тех, кто делает серьезные проекты на юнити. Прям такая, что немало слёз разработчиков об этом пролито.
Можно этот момент закрыть, в юнити есть корпоративная подписка (как раз для серьезных проектов от серьезных компаний), где дается полный доступ к исходному коду.
P.S. — работа идет, думаю в сентябре-октябре сделаю новую статью по продвижению, с уже гораздо большим опытом. Так же думаю стоит как-нибудь уделить время да написать статью про монетизацию. Тоже очень важный момент. Можно хорошо раскрутить игру, но если монетизация плохая — хороших результатов вряд ли получится достичь.
По нему можно будет с большего понять, в каком направлении стоит поработать. Это конечно Uncompressed Size, но тем не менее.
Например если много занимают текстуры, можно посмотреть, установлена ли компрессия для текстур. Я например использую Crunched ETC, иногда просто Compressed ETC (порой на некоторый текстурах Compressed ETC меньше жрет памяти, чем Crunched, хотя Crunched в 90% случаях лучше в плане размера.
Звуки так же стоит пересматривать, порой без компрессии они очень даже много жрут памяти.
В общем и целом, в Unity можно достаточно мощно сократить размер билда.
Другой момент, в iOS более платежеспособная аудитория, но её набрать конечно же гораздо сложнее.
Вообще Unity хорош тем, что если автор задумает создать 3д проект в будущем, то это будет уже гораздо легче, чем потом пытаться с короны спрыгнуть на другой движок.
В остальном, не понятно почему в статье выделили TextMesh Pro Sprite Asset как отдельный способ работы с текстом. Это прямая возможность TextMesh Pro работать со спрайтами в одной линии с текстом. Они неразрывны.
Например на Unity есть готовый проект для обучения Space Shooter. Вот небольшой отрывок игры на YouTube. Это обучающий проект и к сожалению он выглядит привлекательнее, чем описанный в статье ремейк прошлой игры.
Если бы вы работали на Unity, то смогли бы просто скачать готовый проект Space Shooter, добавить уровней, различных ачивок и вышла бы вполне увлекательная игра. По времени не заняло бы больше месяца.
Я это к тому, что ремейк вашей игры выглядит визуально контрастно, посвежее чем предыдущая версия, но в целом геймплей, общий визуальный ряд немного скудноват.
Я бы вливал в продвижение только в том случае, если бы был уверен, что игра сможет найти свою аудиторию.
Если вернуться к ремейку, то геймплей должен быть ярким и динамичным. Игра думаю позиционируется как убивалка времени, имеет портретный режим, значит можно играть в общественном транспорте по пути на работу (или в любое иное место). Игре стоит добавить динамичности. Для этого можно оживить игровую камеру, добавить эффект тряски, приближения, отдаления. Игровые препятствия сделать разнообразными, чтобы это были не просто палки с натянутой текстурой космоса, а например космический мусор, обломки космических станций, метеориты, вспышки каких нибудь излучений. Можно представить, что мы играем за мчащуюся звезду, добавить возможность её апгрейда (например добавить здоровье, мол, каждое столкновение с объектом отнимает определенное количество здоровья, чем больше объект — тем больше он отнимет здоровье). Добавить возможность улучшить скорость маневрирования, добавить способность выпускать вспышку, которая будет отнимать ваше здоровье, но при этом будет разрушать все близ находящиеся осколки, метеориты и прочие препятствия. Сделать движущимся вниз задний фон, чтобы было ощущение движения.
Что-то вроде такой игры была бы куда веселее, ну, в общем, смотрите сами, можете попробовать вложиться в продвижение игры, но как уже говорил, по видеороликам пока все выглядит грустно.
— где выдают FPS, в редакторе или в конечном билде?
— проект на мобильную платфору или PC?
— включена ли вертикальная синхронизация?
— какой вообще FPS? 30? 60? 360? 2042?
— что это за проект такой? Сколько вертексов в кадре, сколько вызовов отрисовки?
Может быть у вас процессор — bottleneck, а вы тут пытаетесь видеокарты менять. Да хоть 10 титанов в sli поставьте, если bottleneck в процессоре/скорости оперативки или ещё в каких параметрах, смена видеокарты не поможет. Нужно смотреть профайл, смотреть что дольше всего обрабатывается. Может у вас видеокарта на 10% загружена.
Проблема с оплатой в том, что для этого нужно завести отдельную карточку ИП, ибо оплачивать можно только с карточки ИП для нужд бизнеса (конечно можно нарушать закон и платить как физ лицо, в надежде что не найдут)
Если в России это так, то вам невероятно повезло. В Беларуси есть налог на доходы иностранной организации. Оплачивая % от прибыли, придется 15% от этой суммы платить налог. Конечно, этого можно избежать, если Epic Games (или кому там идут выплаты) зарегистрирован в той стране, в которой есть закон об избежании двойного налогообложения, но для этого придется писать письма в Epic Games с просьбой предоставить справку, подтверждающие, что они действительно находятся в стране, с которой у нас есть закон об избежании двойного налогообложения. В общем, головная боль. Плюс помимо этого нужно смотреть, возникает ли агентский НДС (даже если ИП без НДС, от агентского НДС никто не освобождал), что опять же, геморрой.
В Unity данная сумма равна 100к$ в год. Что равняется 25 000$ в квартал. Куда приятнее, причем при превышении нужно будет просто купить подписку, без всяких отчислений на банковские счета.
Ну нужно же как-то показать, что ты заработал 5000$ (например) а не 250 000$, им же нужно понять, с какой суммы ты должен платить процент. Видимо нужно будет составлять инвоисы, или ещё что, что опять же, лишняя головная боль по сравнению с Unity, где при превышении нужно будет всего лишь купить платную подписку (которая будет гораздо дешевле, чем требуемый процент у конкурента).
Потому в этом плане останусь при мнении, что Unity куда проще и привлекательнее в этом плане.
При таких манипуляциях придется полностью перелопачивать весь код. Вспоминать, где ты там скорость захардкодил и другие неприятные вещи.
Как сказал автор статьи, да, не стоит нагружать начинающих сразу же огромным объемом информации, что Kos-Boss и решил прокомментировать, добавив свое мнение, и это здорово. Начинающий разработчик прочитает статью, посмотрит комментарий и сделает вывод, мол: «понятно, можно написать как в статье, а можно сделать все более гибким, что позволит мне в дальнейшем с легкостью внедрять изменения».
От себя хотелось бы добавить:
Значение speed стоит умножать на Time.deltaTime, чтобы предотвратить разную скорость при разном количестве fps. К примеру, если один человек запустит игру и у него будет 60 fps, а у другого компьютер более слабый, будет допустим 30 fps, то у второго человека машина будет перемещаться в два раза медленнее, по сравнению с первым, потому что у перого машина 60 раз в секунду получает ускорение speed, а у второго игрока только 30 раз в секунду, что в два раза медленнее.
Все дело в том, что функция Update() выполняется каждый кадр. Умножение любой скоростной переменной на Time.deltaTime позволит сделать её независимой от количества кадров в секунду.
Time.deltaTime изменяется в зависимости от fps, например если у человека 60 fps, Time.deltaTime образно говоря будет равен 0.25f, а если у человека игра подвисает и идет в 30 fps, то Time.deltaTime будет равен 0.5f (в два раза больше), таким образом у первого игрока 5f * 0.25f (будет выполняться 60 раз в секунду), а у второго 5f * 0.5f (будет выполняться 30 раз в секунду). В результате за реальную секунду у обоих игроков машина сдвинется на абсолютно одинаковое расстояние.
Time.deltaTime нужно применять в функциях Update() везде, где есть какие-либо переменные, отвечающие за скорость передвижения того или иного объекта.
P.S. — Нужно будет только увеличить значение speed, иначе после добавления Time.deltaTime скорость машины будет очень медленной.
Можно этот момент закрыть, в юнити есть корпоративная подписка (как раз для серьезных проектов от серьезных компаний), где дается полный доступ к исходному коду.