Потому как в RCT ребята довольно умные, и понимают, что лучше один раз написать удобную вещь. Понастоящему удобную вещь. Не еще один хренов велосипед, потому что им так захотелось. А инструмент, пользуясь которым, мы, во первых сэкономим свое время, а во вторых нервые клетки, потому что мы не будем думать о том, какой он кривой, не будетм пытатся себя перебороть, заставляя пользоваться вот этим-вот инструментом, и у нас не возникнет желание в следующий раз выбрать что-то другое.
Когда софт пишут умные люди, для других, умных (и чуть менее умных) людей, то он получается именно таким — простым и удобным настолько, что ты забываешь о том, что это инструмент написаный другими людьми а просто его используешь для решения задач.
Для одной из наших социальных игр, с моей подачи (в довесок к тому что было реализовано своими силами), прикручивали аналитику от гугла. Что хочу сказать, заменой ручного написания каких-либо игровых логов: кто что купил, в каком количестве, когда, зачем и для чего — не является, лишь дополнение к этому всему.
Хотя пример с уровнем достаточно хороший — можно даже пойти дальше (как мы и сделали) мы точно знали на каких шагах у нас отсеивается народ, а зачастую это было где-то в середине какого-либо из уровней. Вот почему он там отсеивается с помощью ГА было бы сложновато понять, с помощью sql и хороших логов — пожалуйста. Например можно узнать что у нас между 4 или 5 уровнем огромнейшая дыра (особенно после очень быстрых первых трех: 3 уровня за 5 минут, против 15 минут на 4-м уровне), или что за одну игровую сессию, которая редко превышает 10 минут, народ просто не успевает сделать все, что необходимо либо получает такое количество всего, что у него вскипает мозг.
Клиенская аналитика позволяет взглянуть на приложение с точки зрения пользователя — как он ведет себя в той или иной ситуации. Какие действия совершает, как он это делает, пользуетя ли он одними игровыми механизмами, или нет — все это огромнейший пласт знаний который необходимо иметь под рукой и в нужный момент анализировать. Понятно, что если приложение достаточно успешно и приносит деньги на многие вещи можно просто закрыть глаза, или тем более бояться что-то исправить — потому как есть вероятность что будет еще хуже. А учитывая что у нас социальные игры это самое ярое проявление карго-культа… то такие опасения далеко не напрасны.
80% игр где через 5 минут геймплей блокируется потому как требуется купить кирпич, можно найти, только если постараться. На ios я такое видел лишь однажды, но оно в первый же день было с рейтингом в одну звезду и далеко-далеко от топа. Хотя игра была визуально была неплохая. А к примеру тот же Джаггернаут, где после третьего боса без вливания денег уже нереально проходить висит в топе, потому как те, кому игра понравилась уже заплатят, остальные покричат и успокоятся
Забавно наблюдать как многие комментаторы высказываются в духе: «если меня вынуждают платить, я сразу же удаляю игру, какой бы она ни была».
С одной стороны их можно понять, тут играют сразу несколько чувств: приходиться покупать то, что ты не в состоянии пощупать и ощутить напрямую, например удовольствие, сэкономленное время или возможность (хотя опять же, эти люди совершенно спокойно оставляют суммы во много раз большие, на такие же неосязаемые вещи но в оффлайне: алкоголь, поездка на такси и прочее). Challenge: зачем мне платить за то, что я могу получить бесплатно, если чуть-чуть напрячься. Зачастую это получается, а когда этого не происходит, приходит разочарование, поэтому покупка зачастую сопровождается огромным количеством негативных эмоций, либо игра больше ни разу не запускается. Иногда игрок просто не понимает за что же он платит, либо цена контента слишком высока.
С другой — вам дается замечательная возможность попробовать игру (я лично уже раз десять жалел те самые 0.99 потраченные на не пойми что), и заплатить за нее столько, сколько вы готовы заплатить, правда, приходиться быть мысленно готовым, что эта сумма будет выше стандартного ценника, если бы он был.
По поводу нарушения баланса — увы, я не думаю что где-то есть игры, особенно free2play которые могли бы похвастаться наличием этого самого баланса (касательно мобильных платформ). А на других платформах, я просто уверен, что необходимо быть готовым к тому, что геймдизайнеры знают ту сумму денег, которую вам надо заплатить для того, что бы «баланс сошелся». Без этого никак.
Понять схему очень просто: за игру заплатят либо все купившие но по $0.99 либо небольшой процент, но по $2.99-$159.99 (или какая максимальная сумма, которую можно потратить в магазине)
Проблема документации в том, что она очень часто в своих проектах не соответсвует действительности. Да что говорить о документации-то, когда некоторые личности после рефакторинга тесты мьютят потому что лень править и «ну как-нибудь потом»
Опять держать открытым мануал? А если это функция напиана Васей который сидит в трех метрах от меня и правлена Петей который сидит за васей, а комменты он подправить забыл?
эта фича совершенно не лишняя, если даже у нас 3-4 параметра для функции, один из которых не обязателен, а другие просто можем испльзовать в различных вариациях. Таких функций в пхп over 9k и часто приходиться пропускать аргументы
Может потому, что данный язык не так давно был моим основным и мне интересно дальнейшее его развитие даже не смотря на то, что я вряд-ли когда-нибудь к нему вернусь?
Что htmlspecialchars, что html_entity_decode — не совсем красивые (да, тут наверное можно упомянуть слово кривые) функции, по хорошему они должны выглядеть так:
htmlspecialchars разбивается так же, ну вот не нужно мне указывать какие-то там флаги, зачем мне писать их, если я хочу указать кодировку? Правильно — незачем.
Но, к сожалению, дизайн языка не позволяет делать function overloading и поэтому мы имеем то, что имеем
Думаю тут под валидацией имелось в виду другое. Я думаю если бы можно было бы написать валидатор, который смог понимать при какой нагрузке что как использовать и пинал разработчика, то мы бы жили немного в другом мире.
Аннотация она часть кода — ее можно посмотреть, если поле объявлено как int, то туда не получиться запихнуть строку, а вот в конфиге yaml или xml — без правил пожалуйста, а проблема всплывет уже в рантайме.
Да при любом раскладе лучше не станет, таков мир EE. Он странный, надутый и немного пугающий, сам по себе: смешно выглядит прописывание запросов на несколько строчек в аннотациях в качестве оптимизации запросов которые генерит ORM.
Общую картину на пару десятков (а то и сотен) сущностей думаю вряд-ли можно чем-нибудь посмотреть. Иногда даже схемы не спасение.
Да какая разница, хоть json/bson, хоть любимый бинарный формат.
Это не читаемо, потому что:
1. это лежит хрен знает где.
2. это лежит хрен знает где в хрен знает каком формате.
3. этот формат хреново описан и хреново поддерживается (если конечно не промышленный стандарт, но там другая пичалька)
4. это далеко от того места где я пишу код (иде мне не подскажет где я не прав) а с аннотациями — на раз
5. этих хреней может быть много
Когда софт пишут умные люди, для других, умных (и чуть менее умных) людей, то он получается именно таким — простым и удобным настолько, что ты забываешь о том, что это инструмент написаный другими людьми а просто его используешь для решения задач.
Хотя пример с уровнем достаточно хороший — можно даже пойти дальше (как мы и сделали) мы точно знали на каких шагах у нас отсеивается народ, а зачастую это было где-то в середине какого-либо из уровней. Вот почему он там отсеивается с помощью ГА было бы сложновато понять, с помощью sql и хороших логов — пожалуйста. Например можно узнать что у нас между 4 или 5 уровнем огромнейшая дыра (особенно после очень быстрых первых трех: 3 уровня за 5 минут, против 15 минут на 4-м уровне), или что за одну игровую сессию, которая редко превышает 10 минут, народ просто не успевает сделать все, что необходимо либо получает такое количество всего, что у него вскипает мозг.
Клиенская аналитика позволяет взглянуть на приложение с точки зрения пользователя — как он ведет себя в той или иной ситуации. Какие действия совершает, как он это делает, пользуетя ли он одними игровыми механизмами, или нет — все это огромнейший пласт знаний который необходимо иметь под рукой и в нужный момент анализировать. Понятно, что если приложение достаточно успешно и приносит деньги на многие вещи можно просто закрыть глаза, или тем более бояться что-то исправить — потому как есть вероятность что будет еще хуже. А учитывая что у нас социальные игры это самое ярое проявление карго-культа… то такие опасения далеко не напрасны.
С одной стороны их можно понять, тут играют сразу несколько чувств: приходиться покупать то, что ты не в состоянии пощупать и ощутить напрямую, например удовольствие, сэкономленное время или возможность (хотя опять же, эти люди совершенно спокойно оставляют суммы во много раз большие, на такие же неосязаемые вещи но в оффлайне: алкоголь, поездка на такси и прочее). Challenge: зачем мне платить за то, что я могу получить бесплатно, если чуть-чуть напрячься. Зачастую это получается, а когда этого не происходит, приходит разочарование, поэтому покупка зачастую сопровождается огромным количеством негативных эмоций, либо игра больше ни разу не запускается. Иногда игрок просто не понимает за что же он платит, либо цена контента слишком высока.
С другой — вам дается замечательная возможность попробовать игру (я лично уже раз десять жалел те самые 0.99 потраченные на не пойми что), и заплатить за нее столько, сколько вы готовы заплатить, правда, приходиться быть мысленно готовым, что эта сумма будет выше стандартного ценника, если бы он был.
По поводу нарушения баланса — увы, я не думаю что где-то есть игры, особенно free2play которые могли бы похвастаться наличием этого самого баланса (касательно мобильных платформ). А на других платформах, я просто уверен, что необходимо быть готовым к тому, что геймдизайнеры знают ту сумму денег, которую вам надо заплатить для того, что бы «баланс сошелся». Без этого никак.
Понять схему очень просто: за игру заплатят либо все купившие но по $0.99 либо небольшой процент, но по $2.99-$159.99 (или какая максимальная сумма, которую можно потратить в магазине)
htmlspecialchars разбивается так же, ну вот не нужно мне указывать какие-то там флаги, зачем мне писать их, если я хочу указать кодировку? Правильно — незачем.
Но, к сожалению, дизайн языка не позволяет делать function overloading и поэтому мы имеем то, что имеем
Аннотация она часть кода — ее можно посмотреть, если поле объявлено как int, то туда не получиться запихнуть строку, а вот в конфиге yaml или xml — без правил пожалуйста, а проблема всплывет уже в рантайме.
Общую картину на пару десятков (а то и сотен) сущностей думаю вряд-ли можно чем-нибудь посмотреть. Иногда даже схемы не спасение.
Это не читаемо, потому что:
1. это лежит хрен знает где.
2. это лежит хрен знает где в хрен знает каком формате.
3. этот формат хреново описан и хреново поддерживается (если конечно не промышленный стандарт, но там другая пичалька)
4. это далеко от того места где я пишу код (иде мне не подскажет где я не прав) а с аннотациями — на раз
5. этих хреней может быть много