20$ — вполне нормальная цена если у тебя уже есть имя и аудитория. если же ты независимый разработчик, не стоит рассчитывать, что за те 30 секунд, что будущий пользователь проведёт на твоей странице в апп сторе, ты сможешь убедить отдать 20$ за может быть и не плохую игру. с другой стороны, если ты небольшой разработчик — у тебя нет и таких вложений, как у больших.
я всё же думаю проще это делать на уровне студии-производителя. It's toasted!
опять же не обязательно совсем отказываться от in-app, вполне можно ввести подписку, например: 10$ в год и вы получаете все наши текущие и будущие игры. лично я был бы доволен, если б набралась база в, скажем, 10000 таких пользователей. а это вполне реально. вполне могу себе представить, что $100К в год (максимум) тем же ZeptoLab обходится их команда в беларуси.
то есть варианты есть, просто сейчас эксплуатируются самые грубые и примитивные. очень может оказаться, что сейчас формируется некий user-novus который через 2 года уже будет доминировать среди пользователей и воротить нос от f2p.
4 доллара.
психологический барьер в мобильном мире — 1 доллар. игру на андроиде купили 144 человека, то есть 576 долларов. то есть при цене в один доллар это было бы 576 человек, рекомендующих знакомым(а игра на двоих) «прикольную и недорогую игрушку».
то есть просто сделать хорошую игру совершенно не обозначает заработать на ней. точно так же, к сожалению, получается, что заработать можно и на плохой. был бы правильный маркетинг.
гуглу, в принципе, должно быть всё равно. они, конечно, получают свой процент от внутриигровых покупок, но если я помню их больше всего интересует размер аудитории. их free 2 use приносит им основную прибыль.
так что вложить деньги в разработку и имидж и стать «той самой конторой, игры которой люди не боятся себе ставить». у меня, например, уже рефлекс: если GameLoft — будет аггресивная дойка, невысокое качество (миньоны тормозили на nexus 7), реклама в нотификациях (мои дети были жутко рады, когда я им показал, как в настройках апп можно выключить уведомления) и скорей всего ещё и непонятно зачем постоянный сервис в фоновом режиме.
подозреваю и зинга и кинг постепенно формируют подобный отрицательный имидж.
это как раз та причина почему я спокойно рассказываю эту идею. ни времени, ни денег на её реализацию у меня нет. а у кого есть — их интересует, подозреваю, прибыль в первую очередь. а это F2P.
как раз для этого и есть бизнес план. точней нет. но если составить и будет он реалистичным, ниша-то — вот она. а плюсов придумать можно много. мои дети, например, мне уже поднадоели с просьбой купить им какой-нибудь фигни в очередной игре. объясняю, как могу, но думаю я не один такой родитель.
Именно поэтому в последнее время в голове мысль, что вполне можно сделать гейм-студию, которая для привлечения аудитории будет (помимо качества) официально заявлять, что «наши отношения с игроком честные. купил игру один раз — играй до бесконечности и без ограничений.»
можно даже ради развлечения просто выпускать немного платные клоны всех этих candy crash, draw something и прочих зинг.
Моя текущая контора наняла нового тим лида. крайне некомпетентный в разработке. зато профессиональный бюрократ и защитник своей задницы. через месяц-два его работы стало понятно, что его интересует исключительно правильная отчётность. для него ТДД — идеальный инструмент, потому что он сразу может рапортовать, что покрытие кода 100% и ошибок в нём «просто не может быть»™. Реальное качество кода его не интересует. Для него кодеры — зоопарк в котором приходится работать потому что он любит деньги. К счастью у нас уже давно оговорено покрытие не меньше 75% как прагматичный критерий.
Пример 2. Выдуманый.
Вы — тех лид и начальство приходит с радостной новостью — вам выделена команда. Правда в индии. Правда в конторе про которую никто не слышал. Но зато вот команда и вот срок когда продукт нужно сдать.
В этой ситуации нужно либо написать такую подробную спецификацию, что, в принципе, она не будет отличаться от готовой программы, либо организовать с командой ТДД. Во-первых она вынуждает хотя бы слабую связанность — иначе код невозможно тестировать, во-вторых появляется вторая «перспектива» для ревью и, как следствие, шанс быть уверенным, что пишется то, что нужно. В этом случае ТДД — это зеркало спецификации.
спецификация — это перечень пожеланий клиента. обычно очень абстрактно в виде «хочу апп, чтоб такси вызывать»
архитектура — это перечень решений, как эти пожелания будут реализованы, но всё ещё абстрактно. «будет апп для платформ Х, У и Z, поставим сервак с REST интерфейсом и прочая. REST должен уметь то и сё, апп имеет следующие функции.»
дизайн — это набор решений какие библиотеки, классы и паттерны использовать. Так как уже определено, что должен делать сервак/апп — можно говорить о модели классов и их общей функциональности. При этом ещё ни строчки кода не написано.
Некоторые моменты существуют и без TDD
2. Тесты не должны полагаться на знание внутренней логики тестируемого субъекта. Если спецификация не меняется, тогда рефакторинг не должен ломать тест. Если поменялась спецификация — тогда это фактически новый код.
4. То есть в других местах есть копированый код?
5. Любые тесты должны минимум покрывать спецификацию и граничные условия. Всё предусмотреть невозможно. Вон в жаве нужно ловить или заявлять все исключения а толку особо нет.
6.1 Как раз здесь становится понятно, что дизайн неудачен. Если поменять нельзя и код не будет развиваться — здесь стоит вообще отказаться от покрытия. Если код сильно связан, то он не только плохо тестируется, он и развивается плохо.
Но, в общем, согласен. Трудозатраты при ТДД не всегда оправданы.
То есть TDD — это Test Driven Design? Хотя в статье дизайн настойчиво называется архитектурой.
Немного странно звучит «мы не знаем, что нам нужно, поэтому давайте напишем тесты и по пути разберёмся». Всё же вначале нужны по возможности чёткие спецификации, потом хорошая модульная архитектура, затем слабо связанный дизайн и потом уже, в принципе, и не важно делается POUT или TDD — код уже достаточно неплохо структурирован и юнит тесты становятся неформальным описанием контракта.
Честно говоря, мне кажется, что TDD был ответом на экспоненциальный рост количества программистов на рынке. Количества но не качества. Т.е. хороший инструмент, если в подчинении оказалась орда code monkeys.
Во втором проекте совершенно непонятно делает ли оно вообще что-то относительно MVC. Документации нет, в коде есть даже свой ThreadPool. Его, кстати, единственого я находил.
Первая и третья идут путём объявления связей в Xml. Мы делали это с Html и, как говорил Лесь Поддеревянский: «Это тупиковый ход».
Я не о том, что мой вариант единственно верный, но пока получается, что именно моей реализации никто не делал. Ну а опен сорс тем и хорош, что вариантов много и в итоге обычно вызревает лучшее среднее решение.
мне кажется это вполне реалистичная оценка
опять же не обязательно совсем отказываться от in-app, вполне можно ввести подписку, например: 10$ в год и вы получаете все наши текущие и будущие игры. лично я был бы доволен, если б набралась база в, скажем, 10000 таких пользователей. а это вполне реально. вполне могу себе представить, что $100К в год (максимум) тем же ZeptoLab обходится их команда в беларуси.
то есть варианты есть, просто сейчас эксплуатируются самые грубые и примитивные. очень может оказаться, что сейчас формируется некий user-novus который через 2 года уже будет доминировать среди пользователей и воротить нос от f2p.
психологический барьер в мобильном мире — 1 доллар. игру на андроиде купили 144 человека, то есть 576 долларов. то есть при цене в один доллар это было бы 576 человек, рекомендующих знакомым(а игра на двоих) «прикольную и недорогую игрушку».
то есть просто сделать хорошую игру совершенно не обозначает заработать на ней. точно так же, к сожалению, получается, что заработать можно и на плохой. был бы правильный маркетинг.
так что вложить деньги в разработку и имидж и стать «той самой конторой, игры которой люди не боятся себе ставить». у меня, например, уже рефлекс: если GameLoft — будет аггресивная дойка, невысокое качество (миньоны тормозили на nexus 7), реклама в нотификациях (мои дети были жутко рады, когда я им показал, как в настройках апп можно выключить уведомления) и скорей всего ещё и непонятно зачем постоянный сервис в фоновом режиме.
подозреваю и зинга и кинг постепенно формируют подобный отрицательный имидж.
можно даже ради развлечения просто выпускать немного платные клоны всех этих candy crash, draw something и прочих зинг.
Моя текущая контора наняла нового тим лида. крайне некомпетентный в разработке. зато профессиональный бюрократ и защитник своей задницы. через месяц-два его работы стало понятно, что его интересует исключительно правильная отчётность. для него ТДД — идеальный инструмент, потому что он сразу может рапортовать, что покрытие кода 100% и ошибок в нём «просто не может быть»™. Реальное качество кода его не интересует. Для него кодеры — зоопарк в котором приходится работать потому что он любит деньги. К счастью у нас уже давно оговорено покрытие не меньше 75% как прагматичный критерий.
Пример 2. Выдуманый.
Вы — тех лид и начальство приходит с радостной новостью — вам выделена команда. Правда в индии. Правда в конторе про которую никто не слышал. Но зато вот команда и вот срок когда продукт нужно сдать.
В этой ситуации нужно либо написать такую подробную спецификацию, что, в принципе, она не будет отличаться от готовой программы, либо организовать с командой ТДД. Во-первых она вынуждает хотя бы слабую связанность — иначе код невозможно тестировать, во-вторых появляется вторая «перспектива» для ревью и, как следствие, шанс быть уверенным, что пишется то, что нужно. В этом случае ТДД — это зеркало спецификации.
спецификация — это перечень пожеланий клиента. обычно очень абстрактно в виде «хочу апп, чтоб такси вызывать»
архитектура — это перечень решений, как эти пожелания будут реализованы, но всё ещё абстрактно. «будет апп для платформ Х, У и Z, поставим сервак с REST интерфейсом и прочая. REST должен уметь то и сё, апп имеет следующие функции.»
дизайн — это набор решений какие библиотеки, классы и паттерны использовать. Так как уже определено, что должен делать сервак/апп — можно говорить о модели классов и их общей функциональности. При этом ещё ни строчки кода не написано.
Некоторые моменты существуют и без TDD
2. Тесты не должны полагаться на знание внутренней логики тестируемого субъекта. Если спецификация не меняется, тогда рефакторинг не должен ломать тест. Если поменялась спецификация — тогда это фактически новый код.
4. То есть в других местах есть копированый код?
5. Любые тесты должны минимум покрывать спецификацию и граничные условия. Всё предусмотреть невозможно. Вон в жаве нужно ловить или заявлять все исключения а толку особо нет.
6.1 Как раз здесь становится понятно, что дизайн неудачен. Если поменять нельзя и код не будет развиваться — здесь стоит вообще отказаться от покрытия. Если код сильно связан, то он не только плохо тестируется, он и развивается плохо.
Но, в общем, согласен. Трудозатраты при ТДД не всегда оправданы.
Немного странно звучит «мы не знаем, что нам нужно, поэтому давайте напишем тесты и по пути разберёмся». Всё же вначале нужны по возможности чёткие спецификации, потом хорошая модульная архитектура, затем слабо связанный дизайн и потом уже, в принципе, и не важно делается POUT или TDD — код уже достаточно неплохо структурирован и юнит тесты становятся неформальным описанием контракта.
Честно говоря, мне кажется, что TDD был ответом на экспоненциальный рост количества программистов на рынке. Количества но не качества. Т.е. хороший инструмент, если в подчинении оказалась орда code monkeys.
Я думаю каждый может найти для себя значение по желанию.
Первая и третья идут путём объявления связей в Xml. Мы делали это с Html и, как говорил Лесь Поддеревянский: «Это тупиковый ход».
Я не о том, что мой вариант единственно верный, но пока получается, что именно моей реализации никто не делал. Ну а опен сорс тем и хорош, что вариантов много и в итоге обычно вызревает лучшее среднее решение.