Есть мобильная клиент-серверная бесплатная игра (C++, Java, Objective-C), которая была выпущена на iOS и Android. С каждым годом её поддержка становится всё дороже. Компоненты игры (FacebookSDK, NDK, Android и т.д.), способы сборки для Android/iOS, а также изменения в политиках выпуска игр на маркетплейсах меняются так быстро, что это буквально хоронит любые планы по развитию игрового процесса или сюжета. Рутина поддержки убивает развитие. Каждый год — новые устройства с монобровью, с новыми параметрами к хай-денсити, с новыми слепыми зонами новых устройств, с новыми требованиями к тач-интерфейсам — всё это превращает поддержку написанного продукта в настоящий ад. Китайский рынок каждый год выпускает столько новых девайсов, что голова идёт кругом, и в итоге еще твоя игра оказывается на всех китайских варезных сайтах.
Для небольших мобильных проектов, вероятно, поддержка менее затратна. Но когда речь идёт о проекте с серверной частью, игровыми событиями, CMS для управления, маркетинговыми материалами и группами в соцсетях — это превращается в настоящий кошмар и постоянный источник проблем. Я прикинул: чтобы просто собрать новый билд под Android, исправление ошибок сборки займёт не меньше недели (конфликты даже между версиями разных компонентов). Даже если идет контроль версий, сборка через Jenkins с тестированием в контейнере. Все равно галактика подкидывает тебе больше проблем — чем сможешь решить.
Вывод
Поддерживать бесплатные мобильные игры в одиночку — это крайне затратная идея. Со временем поддержка превращается в бесконечный цикл обновлений и согласований с внешними библиотеками, которые, в свою очередь, не предлагают обратной совместимости. Никаких других вариантов, кроме как нанимать людей только для поддержания проекта на плаву, просто нет. Сейчас кажется, что идея инди-студий мобильных игр себя исчерпала. Уже жалею что изначально не пошел в Steam.
А обязательно в проект тащить кучу библиотек? Я всегда скептически относился к этим всем SDK. Понимаю SDK для гугл-карт, там рисование, самому такое делать будет непросто. А так — такое ощущение, что 90% этих SDK, это тупо обёртки вокруг HTTP-запросов, причём эти обёртки как раз и создают проблемы.
Понятно, что сами HTTP запросы и ответы могут меняться со временем, но по крайней мере они не будут конфликтовать с этими SDK. HttpURLConnection работал в 1995 году, он будет точно так же работать в 2025 году.
Пока что такое ощущение, что проблема в подходе к разработке, а не в самой разработке.
On Oct 20, 2024, 6:22 PM, vsb <55595@users.rsdn.org> wrote:
vsb>Пока что такое ощущение, что проблема в подходе к разработке, а не в самой разработке.
Ни разу не сталкивался с проблемами в HTTP-запросах, поэтому не могу ничего сказать об описанной ситуации. Но если ты хоть раз интегрировал (к примеру) Facebook, то точно поймёшь, о чём я. Проблема Facebook заключается в постоянных изменениях «контракта» его клиентской части. Каждый год они меняют способы получения данных о пользователях и требуют, чтобы разработчики обновляли свои библиотеки (например, для обмена информацией между соклановцами, получения изображений и т.д.). И это ещё не считая различных проверок (вроде поиска шпионов КГБ, которые скрываются под играми а сами получают информацию в иных целях), которые Facebook устраивает регулярно. В итоге имеем постоянную головную боль с версиями и работой с KYC-данными и дополнительными запросами на получение прав, активностей итд.
И это только Facebook. А ведь есть ещё Game Center, Play Store, Google Analytics, выходят новые устройства, выходят новые Developer SDK с новыми требования к разработке, кроме того рекламные SDK и множество других компонентов.
Или возьмем сборку под Андроид. Вот банально. Вся сборка под X джавой. Но все равно найдутся уроды, которые обязательно переведут свою библиотеку под Java Y+ и все лесом сразу же идет. И такой фигни валом.
On Oct 20, 2024, 6:55 PM, falcoware <81622@users.rsdn.org> wrote:
F>Как же Плейрикс поднялся на Мобилках?
А ты что, знаешь, как было в Плейрикс? Ты б еще Blizzard привел в качестве оторванной от реальности аргументации в качестве примера с его известным DI. У Blizzard же получилось или нет?
Здравствуйте, r0nd, Вы писали:
R>Поддерживать бесплатные мобильные игры в одиночку — это крайне затратная идея.
У тебя один в один написано тоже самое, что я читал в статьях много лет назад. И про отдельного мейнтейнера для iOS проектов. И про китайские магазины с варезом.
В последнее время я размышлял о разрезании программы на dlc, то есть скачиваемое содержимое.
Очевидно же, что у многих людей нет денег на программу единовременно. А вот постепенно они могли бы потратить гораздо больше.
Смысл в том, что это не классический фритуплей и не основной функционал программы с дополнениями. А программа, которая умеет только загружать и связывать модули и больше ничего.
Каждый модуль отвечает за небольшой функционал и может работать вместе с другими модулями, а самое главное стоит немного.
Но вот если покупать все модули вместе цена будет конской. Потому люди будут покупать сначала только то, что им надо, а потом получив доверие к платформе втянутся.
А модель монетизации с чужими мобильными коммерческими платформами, ещё и с бесплатностью изначально была гнилой.
На мобильном рынке основную прибыль забирают платформодержатели. За ними идут несколько успешных компаний. А большинство просто тратят время зря.
Чтобы было понятно на сколько-то очень успешных компаний миллионы неудачников. По большому счёту разработчики занимаются благотворительностью, ну или свои хобби.
Здравствуйте, velkin, Вы писали:
V>Чтобы было понятно на сколько-то очень успешных компаний миллионы неудачников. По большому счёту разработчики занимаются благотворительностью, ну или свои хобби.
Друг сделал хит на мобилках — Мини-хоккей и Мини-футбол.
Миллионы регистраций было в его своей соцсети.
Стал маленький фейсбук. Короче нехилый сервачок арендовал за большие бабки, чтобы все это поддерживать.
А как монетизировать это всё?
Плюнул, пошел на "Завод" рисовать клипы для Киркорова.
Сказал: игры не кормят.
Здравствуйте, r0nd, Вы писали:
R>Этот рассказ полон боли.
R>Есть мобильная клиент-серверная бесплатная игра (C++, Java, Objective-C), которая была выпущена на iOS и Android.
R>Поддерживать бесплатные мобильные игры в одиночку — это крайне затратная идея. Со временем поддержка превращается в бесконечный цикл обновлений и согласований с внешними библиотеками, которые, в свою очередь, не предлагают обратной совместимости. Никаких других вариантов, кроме как нанимать людей только для поддержания проекта на плаву, просто нет. Сейчас кажется, что идея инди-студий мобильных игр себя исчерпала. Уже жалею что изначально не пошел в Steam.
Мммм. Есть мнение что проблема в выделенном. Т.е. задачи которые должен решать движок, приходиться решать вам.
У меня, на работе, сейчас примерно 90 проектов на Unity, на сотни миллионов инсталов, в оперировании который превращаются в 300+ билдов на различные платформы — ios/android/amazon/huawei/web
Проекты от 7 лет давности.
Да, переодически бывают необходимости что-то где-то обновить и прочее. Но в целом я готов утверждать что в одиночку такое количесво проектов можно поддерживать и обновлять и прочее, прочее.Ну там приходится кое какие действия предпренимать — ну типа патчить какие-то файлы налету на сборке, чтобы решение применить сразу ко всем играм и не коммить в репу изменения, но в целом все норм.
On Oct 21, 2024, 2:29 PM, Young <2893@users.rsdn.org> wrote:
Y>У меня, на работе, сейчас примерно 90 проектов на Unity, на сотни миллионов инсталов, в оперировании который превращаются в 300+ билдов на различные платформы — ios/android/amazon/huawei/web Y>Проекты от 7 лет давности.
Выделенная фраза противоречит сама себе: "у меня сейчас 90 проектов" или все-таки "На работе сейчас 90 проектов"? Ты в одиночку написал за 7 лет 90 проектов на Unity? Все ж определяется размером, просто если проект достаточно простой и в нем нет сторонних интеграций ни с чем, то действительно, допускаю что может показаться, что проблема в Objective-C и C++ с Java
Здравствуйте, r0nd, Вы писали:
R>Ни разу не сталкивался с проблемами в HTTP-запросах, поэтому не могу ничего сказать об описанной ситуации. Но если ты хоть раз интегрировал (к примеру) Facebook, то точно поймёшь, о чём я. Проблема Facebook заключается в постоянных изменениях «контракта» его клиентской части. Каждый год они меняют способы получения данных о пользователях и требуют, чтобы разработчики обновляли свои библиотеки (например, для обмена информацией между соклановцами, получения изображений и т.д.). И это ещё не считая различных проверок (вроде поиска шпионов КГБ, которые скрываются под играми а сами получают информацию в иных целях), которые Facebook устраивает регулярно. В итоге имеем постоянную головную боль с версиями и работой с KYC-данными и дополнительными запросами на получение прав, активностей итд. R>И это только Facebook. А ведь есть ещё Game Center, Play Store, Google Analytics, выходят новые устройства, выходят новые Developer SDK с новыми требования к разработке, кроме того рекламные SDK и множество других компонентов. R>Или возьмем сборку под Андроид. Вот банально. Вся сборка под X джавой. Но все равно найдутся уроды, которые обязательно переведут свою библиотеку под Java Y+ и все лесом сразу же идет. И такой фигни валом.
Ну так этим целые компании занимаются, а не одиночки. Ну либо одиночки делают это full time, а не как хобби.
Ты б еще Blizzard привел в качестве оторванной от реальности аргументации в качестве примера с его известным DI. У Blizzard же получилось или нет? 
Все ж определяется размером, просто если проект достаточно простой и в нем нет сторонних интеграций ни с чем, то действительно, допускаю что может показаться, что проблема в Objective-C и C++ с Java
