вторник, 21 октября 2014 г.

Весело о грустном или почему твоя первая игра провалится


- А вы слышали об энгри бердс? Такая тупая игра и она взлетела!!!111!
- Почему такая тупая механика, и эта игра успешная?
- Что сделать, чтобы твою игру качали? 
-А как заработать на игре?
-О, у меня отличная идея! Короче, 
давай я поделюсь, ты сделаешь, прибыль - пополам?
(с)ОЛОЛОШИ

- Если хочешь заработать на играх - сыграй лучше в казино, 
там вероятность больше
(с)Денчик

(геймдевелопер: ожидание)



Покажите мне хотя бы одного разработчика игр, у кого первая игра "пошла". Покажите мне хотя бы одного продюссера, гейм-дизайнера, который создал сильную механику, приносящую ему хотя бы сотню долларов в день. Таких тупо не существует.

Печальный факт №1: ваша игра не оправдает ваших ожиданий


А причин этому несколько:

  • разработка игры - это не разработка приложения. Если приложение решает ПРОБЛЕМУ, то игра приносит УДОВОЛЬСТВИЕ. И если можно более-менее оценить пользу от решения проблемы("приложение экономит 15 минут в день" или "оно заставит Вас заниматься спортом"), то понятие удовольствия оценить адекватно сложно.
  • первая игра - это первый ребенок. Поскольку ты его не рожаешь, а как двоечник Папа Карло, будешь строгать, то он получится инвалидом, с одной рукой, тремя щупальцами и уродливым лицом. Тебе все будут говорить, что это отстой, что надо первое, пятое, десятое, но ты не будешь слушать - ведь ты защищаешь своего лебедя.
  • ты нифига не знаешь. Ни как сделать красивую графику, ни оптимизировать под все устройства, ни придумать game loops, ни начальный траффик влить, не говоря уже о банальном маркетинге - тебе ведь достаточно уметь создавать коллайдеры в юньке.


Печальный факт №2: если ты начинаешь делать игру, чтобы заработать "свой миллион", то, естественно, ты сделаешь клон чего-нибудь. И он провалится.
Не, нуачо, вот на твоих глазах flappy bird - саксесс стори, у тебя игра, естественно, лучше чем другие десятки клонов (синдром not invented here, ага). Но первоначальный восторг и ажиотаж сменится полным разочарованием. А все потому что ты не до конца изучил существующую механику оригинала, не позаботился о начальных пользователях, не поработал над retention-ом.

Печальный факт №3: если ты геймер с рождения, то ты выпустишь игру с клевым геймплеем. Но ты не заработаешь. Проект провалится.

А провалится он по простой причине: ты получил ровно то, что хотел. Ты хотел сделать игру - ты ее сделал, ты не хотел заработать на этом деньги. Если изначально не подумать, на чем ты будешь зарабатывать, ничего не получишь.

Геймдизайнеры бывают трех видов: 
  • люди, пришедшие из бизнеса - они смотрят на игру как на бизнес. А предприниматели на игру смотрят в ключе "вложил - получил". Монетизация - ок, игры - нет.
  • геймеры, позже устраивающиеся геймдизами. Умеют делать игры, монетизировать - нет.
  • объединяющие свойства первых двух. Таких не существует :)

Печальный факт №4: На свою первую игру ты потратишь неимоверное количество времени, сил. Но от этого она не станет лучше

Core-часть будет готова через три месяца, обвязочки-эффектики наклепаешь через пять месяцев, багофикс закончишь через девять месяцев после начала проекта. Так вот, если бы ты запустил игру сразу после core-части, результат был бы тем же самым, что и после девятимесячного марафона. Делайте быстрее, помните?


Игровая индустрия является самой доходной нишей если не на всем IT-поле, то на мобильных уж точно. И не секрет, что в индустрии крутятся миллиарды-триллионы долларов. Печальный факт заключается в том, что большинство из этой лавины достается динозаврам индустрии. Инди, работающие ради искусства и питающиеся роллтонами, миллионов не видят.
Так что же делать?
  1. Сделать свою первую игру. Да, она провалится. Да, будет отстой. Зато наберешься опыта. И либо уйдешь, либо захочешь еще попробовать. Оба варианты ведут к лучшему.
  2. Если уже есть игра - ты крут. Это не сарказм. Всего лишь 20% людей берутся делать и заканчивают. Если ты зарелизил - ты уже в тех 20%.
  3. Не берись за все подряд. Сделай анализ рынка, определись со своей нишей. 
  4. Изучи, что популярно, поиграйся. Пойми, что цепляет, если не понимаешь - проведи коридорное тестирование.
  5. Читай. МНОГО. Начиная от Art of Game design, заканчивая блогами успешных разработчиков и геймдизов.
  6. Работай. Вкалывай. Не, не так. Вджобывай. Клепай десятки игр, экспериментируй, пробуй, ошибайся.
  7. Учись. На своих ошибках, на чужих. Принимай знания и перерабатывай.
  8. Когда количество выпущенных игр перевалит за пяток, у тебя появится ощущение, как надо делать "правильно". Это как увидел тучи, значит скоро будет дождь - ты будешь на уровне интуиции понимать, что если сделать так, получишь такой импакт. Объяснить не сможешь, но будешь осознавать.
  9. Делай на совесть. Чтобы игра была успешной(то есть с большим количеством закачек, с хорошим процентом ретеншна), она должна быть ИГРОЙ, а не плевком в лицо игроку. Делайте годноту - получите лояльных клиентов. 
  10. Слушай пользователей, прислушивайся к фидбеку. Чаще показывай свое "тварение" другим, получай фидбек. Чем раньше получишь предупреждение, тем раньше сможешь среагировать.
  11. Контактируй с другими людьми из индустрии. Дружи командами. Помогай. Это никогда не вредно.
  12. Получай удовольствие от геймдева. Разработка игр - это ведь действительно фан:)
  13. И еще раз РАБОТАЙ. Сделай уже свою angry birds!



(как пацаны к успеху пришли)

понедельник, 28 июля 2014 г.

Unity + winphone = ?

UPD: всех мусульман с праздником ураза-байрам! По этому случаю татарский словарь на ios в течение трех дней будет бесплатным. Православных поздравляем с днем крещением Руси и тоже советуем скачать этот словарик :)

Ок, опыт по разработке и паблишингу win phone приложений появился.

Я научился делать как нативные приложения (к примеру, на основе дефолтного шаблона сделан словарь lugat, а также мультипайвотный турецко-русский и русско-турецкий словарь), так и unity игр. При разработке нативных приложений надо следовать тем же паттернам, что при разработке на iOS. Если понимаешь, что такое делегат и как работает data provider, проблем не будет. Однако верстка страницы больше напоминает андроид - там больше работаешь вручную с XML-ками, нежели тянешь курсором за констрейны.

Как и ожидалось, больше всего проблем было с юнити. Процесс портирования пробовали на старом бедном матаке, который уже пережил 100к закачек на андроиде и только недавно вышел на iOS. Не хочется особо рассусоливать, пройдемся списком по граблям, которые встретил в процессе:

воскресенье, 1 июня 2014 г.

Сопливый пост: о помощи, о беге, о процессе

Disclaimer: поскольку более-менее технические и полезные посты собираюсь писать на technoballgame.com, в этом блоге буду писать свои мысли, вести сопливый дневник. Вряд ли ты что-нибудь полезное почерпнешь отсюда, дорогой читатель, это все я пишу для себя.


О помощи

Несколько советов о том, как надо помогать (некоторые из разряда вредных):
  1. Если не можешь помочь, то не трать свое и чужое время - скажи, что не можешь. Не делай медвежью услугу, просто осознай, что не будешь делать. Если есть маленькая возможность - не обнадеживай. 
  2. Не предлагай помощь, если не уверен в своих силах. Отсутствие помощи хуже чем невыполненное обещание
  3. Если взялся, то делай на совесть
  4. Не лезь помогать, когда тебя не просят. Тебя не ждут, так зачем строить из себя всезнающего? В случае, когда человек явно тупит, можно заметить, что "что-то не так", но помогать тогда и только тогда, когда человек попросит помочь. Наверное, этот совет применим везде, кроме обучения детей

четверг, 22 мая 2014 г.

Мысли об игре

Ок, игра закончилась.

Она не является новой, это вольная интерпретация игры бм (которая в свою очередь является интерпретацией тренингов Кови), в которой, если выражаться игровой терминологией, были исправлены некоторые косяки баланса


По свежим ощущениям, кратко:
  • игра держит в тонусе
  • ты реально начинаешь ценить свое время, пытаться его максимально эффективно использовать
  • ты начинаешь более детально планировать свой день, отказываться от ненужных временных затрат
  • начинаешь делать то, что не сильно хочешь, но надо.
  • создаешь привычку, даже иногда не связанные с целями
  • переосмысливаешь свои приоритеты - некоторые из целей оказываются ненужными: хрен ты будешь делать, если это действительно не надо
  • начинаешь активно размышлять, искать варианты, идешь на риск
  • из неоткуда появляются новые возможности

воскресенье, 20 апреля 2014 г.

Большие и маленькие компании


Ты хочешь всю оставшуюся жизнь продавать сладкую газировку? Или хочешь пойти со мной и изменить мир? 
(с)Джобс

Небольшой совет молодым и талантливым разработчикам, которые ищут работу, — никогда не идите работать в большие компании. Никогда, ни за какие деньги, ни при каких обстоятельствах. Даже если Вы проработаете всего год, оттуда Вы уйдете уже другими людьми, лишитесь лучшего, что у Вас сейчас есть. Поработав «по графику» с унылым пузатым менеджерьем, Вы станете беспомощным отработанным материалом с рабско-потребительской ментальностью. Ваш опыт работы в Google, Яндексе или Mail.ru — мощная антирекомендация для любого здравого руководителя маленькой команды.
Бездельничайте, учитесь, играйте, рисуйте, создавайте музыку, занимайтесь фрилансом, открывайте стартапы, делайте никому не нужные проекты, голодайте — но никогда не идите работать в корпорации. Помните: всякий раз, когда молодой и талантливый разработчик идет работать в большую компанию, умирает котенок. 
(с)Дуров

Все совпадения случайны и являются выдумками читающего индивидуума


Как-то меня спросили: куда идти работать юристом - в Тошиба или менее известную DS Law. Вопрос был непрофильным для меня, тем не менее его можно перефразировать как-то так: где лучше работать - в большой компании-корпорации или маленькой студии-стартапе?

Для меня ответ простой: it depends.
У каждой стороны есть свои "особенности". Плюсами или минусами это назвать сложно, потому что положительность зависит от восприятия человека, поэтому просто опишу эти особенности. Начнем с больших компаний:

пятница, 14 марта 2014 г.

Сжатие текстур андроида в Unity

В айфонах почти все хорошо. Сделал приложение, потестил на паре девайсов (iphone 4s, ipad2) и можешь быть почти уверен, что с остальными не будет головной боли.

У андроида зоопарк устройств. Это приносит огромные проблемы. В первую очередь, с тестированием и оптимизацией. Далеко не факт, что оптимизация для одних девайсов положительно скажется для других девайсов тоже.

Поскольку очень много оптимизации связывается с отрисовкой, нужно уделить большое внимание отрисовываемым текстурам, а именно сжатию. Unity поддерживает несколько видов сжатия для разных видеокарт: ETC1, ATC, DXT, PVRTC, ETC2. Более того, можно не только руками для каждой текстуры выставлять желаемое сжатие, а задать AndroidBuildSubtarget - при билде все запакуется в лучшем виде.
Внимание, вопрос: в какой формат нужно запаковывать? Ответ: зависит от того, сколько APK вы хотите вылить в google-play.
Дело в том, что магазин приложений гугл поддерживает выливку нескольких билдов для разных девайсов. Это сделано специально для того, чтобы приложения поддерживало как можно больше устройств. Там можно задать разные apk для разных видеокарт, разных пропорций экранов, разных разрешений и т.д. Но есть одно большое НО: рекомендуется использовать эту возможность только тогда, когда есть полное понимание, что одним билдом не обойтись.  Потому что разработку нескольких билдов тяжело поддерживать, а также должна быть правильная систематизация версий, ведь в том же мануале сказано, что гугл отдает поддерживаемый билд с наивысшей версией. То есть, если видеокарта поддерживает etc билд и для нее предпочтительнее atc, но версия etc > версии atc, гугл отдаст etc билд.

Короче говоря, если вы не хотите запариваться, юзайте только один билд и сжимайте в etc. Конечно, вы немного потеряете в производительности (потому что не-etc видеокарты распаковывают etc-сжатую текстуру), но можете быть почти уверены, что ваши текстуры будут выглядеть нормально.
Что делать тем, кто хочет по максимуму: надо организовать правильную генерацию номера версии и в будущем всегда ее поддерживать. Я для себя поставил за правило следующую схему генерации версии:

0411079, или более наглядно 04 1 1079, где первые две цифры - min android sdk(04 - это что-то типа android froyo или еще древнее), второе число - это номер сжатия(об этом позже), а последние цифры - это номер версии билда, без точек(1.07.9).

Как правильно выбрать номер сжатия, чтобы приоритетный билд попал в нужное устройство. Надо исходить из логики: что реже используется, то и надо выше ставить приоритет. А статистика такова: etc > atc > dxt > pvrtc > etc2. Именно в таком порядке их можно и занумеровать.

А чтобы не мучиться каждый раз с генерацией билда и билд-номера, стоит завести один маленький скрипт:

[MenuItem("Custom/Build apks for all Texture Compressions")]
    private static void BuildApksForAllCompressions()
    {
        BuildAndroid(AndroidBuildSubtarget.DXT);
        BuildAndroid(AndroidBuildSubtarget.ATC);
        BuildAndroid(AndroidBuildSubtarget.PVRTC);
        BuildAndroid(AndroidBuildSubtarget.ETC);

        Debug.Log("Finished building");
    }

    //Version code looks like this: 04 1 1079
    //first two numbers = API LEVEL (04)
    //second two numbers = Android Subtarget (1)
    //Last numbers = version number, revision (1079, got from "1.07.9")
    private static int GenerateVersionCode(AndroidBuildSubtarget target)
    {
        string number = string.Format("{0}{1}{2}", ((int) PlayerSettings.Android.minSdkVersion).ToString("D2"),
            GetTargetVersion(target), PlayerSettings.bundleVersion);
        number = number.Replace(".", "");
        int result = int.Parse(number);
        Debug.Log("Android " + target + " version: " + number + ", " + result);
        return result;
    }

  //all devices support etc, so it has lowest value
    private static int GetTargetVersion(AndroidBuildSubtarget target)
    {
        switch (target)
        {
            case AndroidBuildSubtarget.ETC:
                return 4;
            case AndroidBuildSubtarget.ATC:
                return 5;
            case AndroidBuildSubtarget.DXT:
                return 6;
            case AndroidBuildSubtarget.PVRTC:
                return 7;
            default:
                return 0;
        }
    }

    private static void BuildAndroid(AndroidBuildSubtarget target)
    {
        if (EditorUserBuildSettings.activeBuildTarget != BuildTarget.Android)
            EditorUserBuildSettings.SwitchActiveBuildTarget(BuildTarget.Android);
        EditorUserBuildSettings.androidBuildSubtarget = target;

        //to include more build options use bitwise OR, for instance: BuildOptions options = BuildOptions.Development | BuildOptions.ShowBuiltPlayer;
        var bo = BuildOptions.None;
        PlayerSettings.Android.keystoreName = "keystore_location";
        PlayerSettings.Android.keyaliasName = "alias";
        PlayerSettings.Android.keystorePass = "password";
        PlayerSettings.Android.keyaliasPass = "password";

        PlayerSettings.bundleIdentifier = "yourbundle";
        PlayerSettings.Android.bundleVersionCode = GenerateVersionCode(target);

        try
        {
            string apkName = "your_apk_name"
            BuildPipeline.BuildPlayer(
                (from scene in EditorBuildSettings.scenes where scene.enabled select scene.path).ToArray(), apkName,
                BuildTarget.Android, bo);
        }
        catch (Exception e)
        {
            Debug.Log("Error: " + e.Message);
        }
    }
Как-то так. Да, при выливании в сторы, нужно заливать билды в том же порядке. Если перепутать, то стор просто отвергнет билд с меньшим номером.

четверг, 13 марта 2014 г.

Успешная игра - каждому по приоритету

Мою квартиру обокрали. Тупо взломали дверь ломом. Видно, взломали первую попавшуюся квартиру, все шкафчики открыты - видимо, искали повсюду. Самое странное - сперли только ноутбук. Хотя у меня, гиканутого нерда, окулусов, райзер хидр и прочей техники было на гораздо большую сумму. Люди не знали их стоимость, поэтому сперли только один ноутбук - можно сказать, легко отделался.


У каждого вида деятельности при разработке игр есть свои приоритеты. Например, для предпринимателей - количество принесенных денег, маркетологов - количество пользователей и ARPPU. У разработчиков игр свои приоритеты, свои идеалы: количество и качество фичей, а так же реакция пользователей на них. Вполне очевидно, что проггер становится счастливым, когда он добавляет вроде как маленькую фичу, а юзеры оценивают ее, начинают играть, радуются. Таким же образом программист бесится, когда чувствует, что фича не приносит ожидаемого отклика, ведь по факту, он делает ее зря. Всегда лучше ничего не делать, чем делать ничего.

Совсем недавно нам удалось реализовать игру, которая подходит под мое определение успешности, как программиста. Нет, это не road smash, хотя, судя по статистике, она очень понравилась пользователям и наверняка приносит хороший доход.

Игра называется Clumsy Fino (тыц для ios), это очередной клон Flappy Bird с респавном и дракончиком. Вроде ничего примечательного, но игра успешна. Объясню почему:

  1. У нас отличная команда - множество непересекающихся скиллов. Альберт Александровский взял на себя роль издателя, он занимался продвижением, поиском подходящих запросов, делал завораживающие картинки. Игорь Фомичев делал игровую часть, делал баланс. Я прикручивал плагины, занимался неигровой частью. Каждый занимался тем, что он лучше всего умеет. В условиях "экстремальной разработки" эта тактика сыграла как нельзя лучше.
  2. С самого начала мы решили делать максимально быстро. Первая версия игры была сделана за два дня по вечерам, содержала в себе все мастхэвы и вылита в сторы. Это была самая продуктивная итерация на моей памяти.
  3. Вторая итерация заняла чуть больше времени(пять дней "грязного времени", где-то три человекодня на всех), за это время мы полностью обновили GUI, добавили важную фичу - респавн птицы при смерти. После апдейта количество скачиваний удвоилось (спасибо, Альберт!), а игровая сессия стала больше в среднем на три минуты (спасибо, Игорь).
  4. В разработке не было факапов. Вообще. Причины две: 
    1. мы делали только те фичи, которые казались нам нужными. Те, которые не очень привлекательны игрокам или трудозатратны - мы не делали. Наконец-то смогли применить принцип Парето.
    2. Никто не лез в чужую область, каждый делал то, что умел лучше всего. Минимум ресерча, просто берешь и получаешь результат. А через четыре часа люди радуются этому результату.
  5. Не знаю, как остальные ребята, лично я получил огромное удовольствие. Это было подобно очень короткому кэмпу, где ты просто делаешь то, что тебе нравится. Результат не заставил себя ждать. 
  6. Эта игра уже окупила наши трудозатраты. Доход до сих пор растет :)
Не знаю, как другие программисты, но я очень хочу, чтобы моими продуктами пользовались. Очень сладостно ощущение того, что ты делаешь не зря. И совершенно пофиг, сколько денег от этого ты зарабатываешь.




За ноутбук не сильно обидно - там стоял deep freeze, хрен они там смогут им воспользоваться. При более тщательной ревизии всех вещей оказалось, что эти уроды сперли купленный вчера торт! Спереть ноутбук и торт вместо того, чтобы спереть дорогостоящую технику? У меня нет слов.