Доброго времени суток. Первое что я бы вам хотел сказать относитесь к вашим урокам как к вашему опыту от этого проекта, как и к «урокам» других людей и их проектов. То есть не всегда эти уроки подойдут к другим стартапам. Очень много уникальных проектов, и все они по разному развиваются и монетизируются и так далее.
Насчет того что делать дальше — вам этого никто не скажет точно. Ответ в вас. Вы обладаете аналитикой проекта, у вас навярняка есть всои желания, амбиции, знания что да как у вас в команде. Будьте data driven team — берите потоки данных со всего. Примите эти данные и принимайте осознанное решение, за которое не будете жалеть, даже если что-то пойдет не так, вы будете понимать что это решение было принято из тех данных что вы имели на тот моммент.
Ну а вы не Ванга к сожалению. Конечно инвестиции побольше надо брать для большей маневренности.
Rovio сделали 51 игру прежде чем добились успеха. Они уже собирались закрывать компанию и решили сделать последнюю игру. Эта игра была — Angry Birds. Тут не везение — они опытные разработчики игр + в 2009 году годных игр было очень мало. www.towave.ru/pub/angry-birds-kak-zlye-ptitsy-pokorili-mir.html
Правильно вы меня процитировали. Как и сказано в цитате — «делая маленькие игры больше риска(из-за переизбытка игр)». Делая крупные игры рисков меньше из-за того что в крупных играх меньше конкурентов.
Насчет Wow у Blizzard столько бабла что четверть ярда им не особо по карману ударило. + надо учитывать что Wow они доили больше 10 лет.
Я еще говорил что -«С какой то стороны и крупные игры тоже рисковано делать, то есть студия весь бюджет вложила в эту игру, а она не стрельнула.»
Насчет ваших последних 2 вопросов. Это уже стратегия компании — она может зарабатывать на множества маленьких играх, а может и на 1-2 крупных играх.
+ все очень вариативно: рынок, бюджет компании и т д.
Геймдев можно посчитать, и успешные игровые студии этим пользуются.
Не важно какая стратегия у компании. Они могут делать маленькие, средние, большие игры. Главное подход, AAA подход. Это и препродакш аналитика рынка, и беты, софтлаунчи, постпродакшн аналитика. У казуальных игр закачек очень много(по рынку) если сравнивать с ролевыми(мморпг), но и возврат игроков у ролевых повыше гораздо. Делая маленькие игры больше риска(из-за переизбытка игр), но игра может заработать намного больше чем бюджет игры. С какой то стороны и крупные игры тоже рисковано делать, то есть студия весь бюджет вложила в эту игру, а она не стрельнула. Повторюсь главное подход. И делать все осознанно.
Выносить Unity API в другие thread-ы не советую. Есть большой шанс того что в игре будет кучу рандомных багов. Решение в main-thread-е, просто нужно это все по другому как-то использовать.
Мне лично Rx дает удобство, linq — везде. Ну и скорость разработки соответственно.
Есть куча игр которые были разработанны без Rx. Я бы посоветовал вам пока просто присмотреться к UniRx. А потом если почувствуете надобность вы всегда можете использовать его. Придерживаетесь KISS принципа. en.wikipedia.org/wiki/KISS_principle
1) Выгоды относительно простой подписки нет. Кому как удобнее это реализовывать.
2) Суть показать mvp и reactive properties. someView.AnimateButton вызывается в обработчике событий кнопки потому что анимируется кнопка от нажатия этой кнопки. А не потому что увеличивается каунт.
Спасибо за статью, но есть одно но слово культура очень обширное и возможно не все читатели поняли это слово в правильном понятии. Да и нет в этом ничего плохого это просто сленг. Вы еще не знаете как дота сообщество общается)) пример: steamcommunity.com/sharedfiles/filedetails/?id=455566993
Видно что это ваш первый сервер. Думаю каждый начинающий серверный разработчик написал бы что то типа наподобие вашего творения. Лучше было бы еще пару серверов написать и уже тогда браться за статью.
Советую реализовывать сервер с rpc принципом. А еще лучше как советовали выше использовать netty.
А вообще классно было бы использовать связку netty+protobuf.
https://en.wikipedia.org/wiki/Remote_procedure_call
https://en.wikipedia.org/wiki/Reactor_pattern
Удачи в серверной разработке.
У нас при разработке одной игры издатель отказался нам выдать права админа в гугл плэй сервисах. Тем самым мы не могли правами админа проверять действительно ли игрок получил ачивку. Мы это решили просто, мы отправляли access token игрока нам на сервер, где сервер этим токеном проверялось валидность ачивки. Резюмируя скажу что 2 токена нужны для того чтобы: пользователь мог авторизовываться не светя свой пароль лишний раз, также для удобства обратно же пользователя, ну и для сторонних сервисов как в примере. З.Ы в этой игре у нас тоже были свои токены, access — жил 30 минут, refresh — был перманентен.
Сегментирование пользователей это не есть шардирование. Хорошее шардирование должно распределять все нагрузки поровну. В вашем случае я так понимаю если все старые пользователи решили одновременно поиграть в игру будет нагружаться сервер который отвечает за старых пользователей так? Могу посоветовать вам что-то типа postgres-xl. Которая имеет в себе принципы acid. И уже сверху такого шардинга можете поставить любой кэш.
Я шардировал с помошью citusdb.
https://en.wikipedia.org/wiki/ACID
В таких ситуациях хорошо помогает цель. Например сделать какой нибудь маленький проект игру или приложение. И книги тогда быстро читаются и проект разрабатывается. А без конкретной цели обширную и динамичную сферу ИТ можно и всю жизнь учить.
Насчет того что делать дальше — вам этого никто не скажет точно. Ответ в вас. Вы обладаете аналитикой проекта, у вас навярняка есть всои желания, амбиции, знания что да как у вас в команде. Будьте data driven team — берите потоки данных со всего. Примите эти данные и принимайте осознанное решение, за которое не будете жалеть, даже если что-то пойдет не так, вы будете понимать что это решение было принято из тех данных что вы имели на тот моммент.
Ну а вы не Ванга к сожалению. Конечно инвестиции побольше надо брать для большей маневренности.
www.towave.ru/pub/angry-birds-kak-zlye-ptitsy-pokorili-mir.html
Насчет Wow у Blizzard столько бабла что четверть ярда им не особо по карману ударило. + надо учитывать что Wow они доили больше 10 лет.
Я еще говорил что -«С какой то стороны и крупные игры тоже рисковано делать, то есть студия весь бюджет вложила в эту игру, а она не стрельнула.»
Насчет ваших последних 2 вопросов. Это уже стратегия компании — она может зарабатывать на множества маленьких играх, а может и на 1-2 крупных играх.
+ все очень вариативно: рынок, бюджет компании и т д.
Не важно какая стратегия у компании. Они могут делать маленькие, средние, большие игры. Главное подход, AAA подход. Это и препродакш аналитика рынка, и беты, софтлаунчи, постпродакшн аналитика. У казуальных игр закачек очень много(по рынку) если сравнивать с ролевыми(мморпг), но и возврат игроков у ролевых повыше гораздо. Делая маленькие игры больше риска(из-за переизбытка игр), но игра может заработать намного больше чем бюджет игры. С какой то стороны и крупные игры тоже рисковано делать, то есть студия весь бюджет вложила в эту игру, а она не стрельнула. Повторюсь главное подход. И делать все осознанно.
Есть куча игр которые были разработанны без Rx. Я бы посоветовал вам пока просто присмотреться к UniRx. А потом если почувствуете надобность вы всегда можете использовать его. Придерживаетесь KISS принципа.
en.wikipedia.org/wiki/KISS_principle
2) Суть показать mvp и reactive properties. someView.AnimateButton вызывается в обработчике событий кнопки потому что анимируется кнопка от нажатия этой кнопки. А не потому что увеличивается каунт.
forum.unity.com/threads/unirx-reactive-extensions-for-unity.248535/page-6#post-3064218
en.wikipedia.org/wiki/String_theory
Исправим это.
Источник vk.com/studanal?w=wall-86678270_1269729
MessagePack не пробовали?
Советую реализовывать сервер с rpc принципом. А еще лучше как советовали выше использовать netty.
А вообще классно было бы использовать связку netty+protobuf.
https://en.wikipedia.org/wiki/Remote_procedure_call
https://en.wikipedia.org/wiki/Reactor_pattern
Удачи в серверной разработке.
Я шардировал с помошью citusdb.
https://en.wikipedia.org/wiki/ACID
https://en.wikipedia.org/wiki/ACID