Пум-пурум-пурум

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

2014-10-21T18:10:00.000-07:00

- А вы слышали об энгри бердс? Такая тупая игра и она взлетела!!!111!

- Почему такая тупая механика, и эта игра успешная?

- Что сделать, чтобы твою игру качали?

-А как заработать на игре?

-О, у меня отличная идея! Короче,

давай я поделюсь, ты сделаешь, прибыль - пополам?

(с)ОЛОЛОШИ

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

там вероятность больше

(с)Денчик

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

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

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

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

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

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

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

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

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

Геймдизайнеры бывают трех видов:

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

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

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

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

Так что же делать?

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

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

Unity + winphone = ?

2014-07-28T12:38:00.001-07:00

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

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

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

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

винфоны в большинстве своем слабые, идут с оперативкой 512 Мб - будьте готовы, что придется оптимизировать. Конечно, можно в dev центре ограничить список, но таким образом мы отсечем 80% рынка
unity для винфона собирает с настройкой mscorlib, поэтому вовсю использовать силу c# не получится.
предыдущий пункт может также означать, что некоторые либы, собранные на моно, не пойдут. К примеру, надо качать отдельную сборку для hotween на его официальном сайте
каким образом происходит сборка unity проектов: солюшн собирается в либу unityplayer.dll, далее линкуется с другими плагинах лежащими в соответствующей папке. Два очень важных момента:

в редакторе все компилится под моно, а для винды на .net. Они разные, поэтому можно ожидать кучу приколов
б) для проверки совместимости библиотек используется Mono.Cecil. Ну так вот, если используются платформозависимые библиотеки (Microsoft ads, к примеру), не поставляемые по умолчанию windows phone sdk, mono.cecil может ругаться на отсутствующие рефы. Самый простой и топорный способ разрешить проблему - тупо скопировать dll в C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\WindowsPhone\v8.0 и т. д. Правильный же способ - пересобрать Cecil со включенными библиотеками, начальный взять из гита. Вот эта тема очень полезна для осознания происходящего - http://forum.unity3d.com/threads/wp8-adcontrol-mono-cecil-assemblyresolutionexception.196766/

Microsoft ads легко интегрируется в сборку, но учетка Microsoft ads недоступна для жителей России - вы попросту не получите честно заработанные деньги. Меня такой вариант не устраивал, поэтому ставил admob с помощью плагинов от Reign studios.
Да, не надо считать себя самым умным и сходу попытаться написать плагин под винфон. Для начала надо читать документацию - в unity очень клево все расписано :)

Я так и не понял, почему никто не использует postprocessbuildplayer, хотя его использование очень уместно. К примеру, нужно выставить необходимые разрешения. Или внедрить платформозавсимый код (как в случае инициализации плагинов от Reign Studios). Короче, все разленились, поэтому надо делать кучу неавтоматизированной ручной работы самому.

Неприятная детская грабля - unity собирает проект, где все иконки и сплеш скрины идут по умолчанию. Настроек в unity как в других платформах нет. Надо делать руками в сгенерированном проекте. Более того, в винде есть так называемые плитки - куча мороки и никто их не использует. Плюс один гемморой от майкрософта.
Я так понял, в винфоне нет локальных нотификаций. Remote есть, а локальных - нет. Обидно, очень полезный инструмент.

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

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

2014-06-01T14:55:00.000-07:00

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

О помощи

Несколько советов о том, как надо помогать (некоторые из разряда вредных):

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

О беге

Где-то месяц тому назад начал бегать. Огромное спасибо тем, кто меня подвел к бегу, дал практические советы - без вас бы это не получилось.

А сейчас напишу ощущения, которые пролетают:

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

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

Где-то на половине ощущения усталости нет, но есть ощущение, что ты многого достиг и можно уже останавливаться. На практике ощущаешь, что начинаешь сдавать по скорости. Сдаешь по скорости - начинаешь потеть.

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

На 80% дистанции уже начинаешь чувствовать усталость в мышцах. Пытаешься экспериментировать с ходом бега, есть боль в определенных участках. Понимаешь, что мышцы напряжены и скоро будут болеть. В этот момент коварная мысля "ты не сможешь" вовсю витает над тобой.

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

90%: в наушниках слышишь: "Your distance is ..., average pace: ...". Эта фраза работает как триггер - из неоткуда появляется энергия, непонятными усилиями начинаешь ускоряться. Правда, через минуту устаешь и переходишь в старый режим, потом снова вспоминаешь, что осталось немного и ускоряешься.

95%: Все, что надо - просто поддерживать ритм. Ты уже не можешь остановиться. Надо просто добежать. Мозг как ни странно, включается на полностью, мышцы забывают об усталости. Это очень клевое ощущение

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

О процессе:

Несколько выводов:

если не можешь быстро и доходчиво объяснить идею - значит, идея говно
если идея приводит к усложнениям - идея говно
делегируй правильно!
Иногда просто взять и нафигачить лучше, чем заресерчить и сделать правильно. Но будь готов, что это аукнется в далеком будущем
Не стесняйся делать //TODO
Не стесняйся записывать, все равно не запомнишь
Не стесняйся переспрашивать. Лучше перепонять, чем недопонять
Лучше заплатить и получить качество, чем иметь головную боль и в конечном счете заплатить намного больше. Да, в asset store сейчас есть абсолютно все!
Будь готов, что твои знания инвалидируются в один момент и все надо будет изучать заново

Мысли об игре

2014-05-22T13:23:00.002-07:00

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

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

По свежим ощущениям, кратко:

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

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

Игра держит тремя аспектами:
1) спор - ты споришь, что при не выполнении теряешь. Надо сделать условие, что теряешь что-то значимое, но не сильно критичное. Не отдаешь во благо, не спасаешь голодающих негров, тупо теряешь. И в этом никто кроме тебя не виноват
2) общественное обещание: ты на всю Ивановскую заявляешь о своих целях, обещаешь выполнять
3) контроль - каждый день ты следишь за ходом своих действий

Будет ли игра работать при послаблении или отсутствии какого-то из параметров?

Давайте проверим гипотезу:
в понедельник мы определяемся с целями, во вторник начинается новая игра. Какие будут изменения:
есть закрытая группа vk.com/thatgame, куда приглашаются все желающие поиграть. Можно играть "в закрытую": писать прогресс только на стене в этой группе. Можно играть стандартно "в открытую": дублировать/шарить себе на стену. Каждый выбирает как хочет. Я лично буду играть вторым способом.

Остальные правила остаются те же: поставить десять целей, выполнить хотя бы пять, в случае проигрыша отдать 10% своей зарплаты (для неработающих придумать себе наказание), отписываться каждый день о прогрессе. Подробнее о постановке и тонкостях напишу завтра.

Играть стоит, если:

относиться к этому серьезно
хочется изменить свое положение
нужно добиться нового
нужно выработать новые привычки

Играть не стоит, если:

не готов выполнять правила
читер
"просто попробовать"

Итак, кто готов?

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

2014-04-20T10:33:00.000-07:00

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

(с)Джобс

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

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

(с)Дуров

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

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

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

У больших компаний есть имя, статус. Это очень клево, когда при знакомстве с незнакомыми людьми можешь описать работу в двух словах.
Хорошие плюшки. Бесплатная еда, лазерные шоу на корпоративах, интересные события, недоступные простым смертным - все это для тебя.
Как правило, большие деньги. А если редкий специалист, то платят непомерно много.
Своя субкультура - начиная от стиля кода, заканчивая отношениями между сотрудниками. Это вправляет мозги, особенно если ты зеленый джуниор, но жди беды, если ты не согласен с такой субкультурой - ты идешь против большой системы.
В больших компаниях найдется человек, у которого можно поучиться новому. Иногда даже по непрофилю. Достаточно подойти и спросить.
Большие парни имеют свою экосистему управления - трекинг времени, документация, дизайны, концепт-документы, бла-бла-бла. Это сделано с разумными целями - для контроля, оптимизации организации (как известно, в команде с N людьми количество взаимоотношений O(N^2) ) и т. д. На quora спрашивали, почему так много людей работают на фейсбук, офигенное сравнение дал Balaji Viswanathan(кофаундер belimitless.co) - почитайте, вы не пожалеете.
Бюрократия на своем уровне. У кого-то в меньшей степени, в гос. корпорациях РФ - просто over9000. Проявляется это чаще всего необходимостью никому не нужные отчеты, писать документацию, будто их будут читать одни идиоты, читать простыню документации и в каждой строке чувствовать себя идиотом.
Иметь шефа, шефов, контролирующих тебя людей. С одной стороны, можно иметь китайское видение жизни и думать, шеф - это твой наставник. С другой - а если работа строится по принципу "я начальник - ты дурак"?(Вот именно поэтому разрабы ненавидят продюссеров и подобных)
Иметь строгий распорядок дня: прийти на работу, отработать 8 часов, уйти. Идеально для женатых людей или людей с советским укладом жизни. Есть особо непонятные компании, которые ставят нормативные часы выше выполненным целям. Я таких не понимаю.
Ты станешь узким специалистом. Всего ты не сможешь знать просто из-за объема данных, поэтому будешь отвечать только за одну часть всего проекта.
В больших компаниях трудно вырасти. Как в карьерном плане, так и профессионально-личностном. Ты являешься одной деталью в огромном механизме, который работает неведомым образом. Ты делаешь одну маленькую вещь в огромном конвейере. Более того, если занимаешься одной лишь работой, ты ступоришься, начинаешь видеть мир слишком однобоко. Поэтому очень важно кроме основной работы заниматься еще чем-то другим для себя.
Еще в больших компаниях не приветствуется, чтобы ты занимался чем-то другим, кроме работы :) Это вполне объяснимо - они платят тебе деньги и хотят выжать из тебя весь максимум.
В больших компаниях стирается ответственность. Вот серьезно, в любых МС и прочих есть люди, которые являются балластом - они вроде чем-то занимаются, а результата - ноль.

Вот как-то так. А теперь поговорим про малышей:

Тебя никто не знает. Это ок, смирись с этим :)
Никто не организует для тебя ничего. Как ты проведешь праздник, корпоратив и т.д. - зависит только от тебя.

Своя субкультура. Только она уже не корпоративная, а "семейно-котанская". Все друг друга знают, нет чинов и погонов.
Как следствие, нет шефа "за спиной", ты любому человеку можешь сказать: "Чувак, ты не прав", "Твоя идея - говно", и никто не обидится и не даст в бубен (конечно, если ты сможешь аргументировать свою точку зрения или внезапно являешься внуком Мохамеда Али :-) ).
По минимуму бюрократии. Никого не интересует, что ты делаешь, как это работает изнутри. Главное, чтобы это работало и легко модифицировалось и ты успевал в оцененные сроки.
Не ожидай, что вступив в проект в студии, ты увидишь get-started, how-to, вообще, нечто похожее на документацию. Скажи спасибо, если кто-то иногда пишет тесты. В конце каждого проекта каждый разраб может написать вот такую книгу:
Как следствие предыдущих двух - минимум бюрократии. Тебе не надо собирать консилиум, не надо документировать каждое слово. Надо взять - договориться с котаном и зафигачить. Иногда удобнее сделать наоборот - зафигачить, а потом договориться с котаном :-)
У тебя будет больше выбора - от используемых инструментов до договоренности по рабочему дню. Сейчас мы приезжаем в офис в двенадцать, ухожу в восемь вечера. Это ок, если ты пришел в два дня или ушел довольно рано или наоборот поздно. Это норм поработать из дома или выйти поработать в выходные дни. Да, и не надо ждать, пока прогонят плагин за 10 баксов через всю тикет систему - ты тупо берешь и покупаешь.
В маленьком стартапе ты должен уметь делать все - потому что кроме тебя больше никого нет. И такой подход нехило тебя развивает. Ты начинаешь разбираться везде, где раньше все это было rocket science.
Как следствие, ты очень быстро растешь, всегда учишься новому. Чем больше обязанностей и меньше времени - тем быстрее ощущается ускорение.
Большая свобода - ты можешь привнести идей, даже если ты вроде как не этим занимаешься. Поскольку направлений обязанностей там много, ты можешь заниматься почти всегда чем хочешь.
Ответственность. Ты не имеешь права сказать: "это говно, потому что мы делаем по его указанию", ведь ты когда-то ему не сказал: "Чувак, это говно". Только ты ответственен за то, что ты делаешь этот проект.
Да, саморазвитие только приветствуется. К примеру, вот continuous integration в asset store - плагин, выросший из ресерча на тему разных сжатий текстур в андроиде. Сейчас используется повсеместно. Каждый опыт активно переиспользуется. И твои знания РЕАЛЬНО работают.

Как примерно делается большой проект в больших компаниях:

"Здравствуйте, у нас есть идея проекта, сейчас продюсеры напишут диссертацию на 100500 страниц"
"Бюджет проекта - овер9000 долларов, вот вам команда художников, программистов, массажистов"
Каждый менеджер в команде собирает скрам, задает цели, работящие люди скурпулезно вникают в детали, пишут свою оценку.
Менеджер умножает оценку на (e+pi)/2, все начинают фигачить.
Позже команды начинают скрещивать результаты, у них ничего не получается, собирается митинг, долго обсуждается, начинают переделывать.
Позже происходит тестирование, находится фатальный недостаток, надо переделывать, времени мало
С опозданием на два месяца выпускается продукт.

Как делается в маленьком стартапе:

-"Котаны, я тут внезапно подумал..." -"О, ты думать умеешь?" -"Да слушай же! Короче так..." -"Клево, давайте зафигачим!"
(Около доски, где есть еще место для новых идей) "А давайте добавим няш-мяш и вертолет взрывающийся!"
"Короче, у нас всего три месяца, быстрее делаем".
Быстрая приблизительная оценка, фигачим.
"Нет времени объяснять, пиши в api магический метод FixEverything()"
"Так, мы не успеваем. Либо продлеваем, либо урезаем фичи. И давайте хоть в этот раз протестируем что ли?"
С опозданием на два месяца выпускается продукт :)

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

Можно ли так сделать, чтобы объединить плюсы больших компаний с плюсами маленьких(и при этом постараться выкинуть минусы). Можно, но не каждая компания в состоянии. Вернее даже так - почти никто не может. Я знаю всего две компании, умудрившиеся успешно объединить первое со вторым. Это facebook и unity. Вот, к примеру, слайды из выступления Араса по поводу, как работает unity. У меня все.

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

2014-03-14T14:15:00.000-07:00

В айфонах почти все хорошо. Сделал приложение, потестил на паре девайсов (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);
        }
    }

Как-то так. Да, при выливании в сторы, нужно заливать билды в том же порядке. Если перепутать, то стор просто отвергнет билд с меньшим номером.

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

2014-03-13T14:46:00.002-07:00

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

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

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

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

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

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

Не знаю, как остальные ребята, лично я получил огромное удовольствие. Это было подобно очень короткому кэмпу, где ты просто делаешь то, что тебе нравится. Результат не заставил себя ждать.
Эта игра уже окупила наши трудозатраты. Доход до сих пор растет :)

Не знаю, как другие программисты, но я очень хочу, чтобы моими продуктами пользовались. Очень сладостно ощущение того, что ты делаешь не зря. И совершенно пофиг, сколько денег от этого ты зарабатываешь.

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

Делайте быстрее!

2014-02-13T20:43:00.000-08:00

Вася и Петя одновременно начали писать один и тот же продукт.

Вася был «ориентирован на результат» и начал сразу писать говнокод не продумав толком архитектуру.

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

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

Итого, через пять месяцев у Васи было два работника, куча клиентов и сносно работающее приложение отвечающее желаниям клиентов.

У Пети было вылизанное никому не известное приложение, минус на банковском счёте и ни одного клиента.

В завершение этого выдуманного примера можно сказать, что через полгода Вася купил все наработки Пети, Петю взял в штат тестировщиком, а сам по пьяни разбился на своём новеньком Туареге

(с)http://bash.im/quote/420672

История №1

В мае 2013 мы начали делать технобол, сделали прототип, придумывали фишки, участвовали в конкурсах (в результате которых появлялись забавные модификации). Все вроде хорошо. Первая действительно хорошая демка была готова к ноябрю. Между маем и ноябрем было сделано две промежуточные версии, людям была показана вообще только одна. И совершенно немногие знали о том, что делается игра.К первой демке мы осознали, что делаем все неправильно и надо сильно менять геймплей (техническим языком - выкидывать половину того, что все написано). Было принято волевое решение: выливаем существующую демку как есть и, учитывая ошибки, начинаем делать нормально.

Итог: игра на гугл-плее, утонувшая в тысячах ей подобных, получен бесценный опыт.
Совершенные ошибки: распыление на фичи, что повлекло за собой долгий срок разработки, разработка, никому не показывая - не было объективного фидбека.

Вывод: не бояться показывать продукты, делать мало, но быстро.

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

(с) Олег Придюк

История №2

Игра road smash делается с февраля 2013, скоро ожидается полноценный релиз, я присоединился в конце сентября. Ребята делали игру, завели блог разработчика, к первой публичной бете (которая была, честно говоря, пре-альфой) были фанаты, игра за месяц набрала миллион загрузок без рекламы и продвижения. Мы пережили падение сервера, кучу клиенстких багов, вопли детей "Разраб, верни галду!", факапы длиной в месяц, разработка фич, которые никому не нужны. Большинство факапов связано с привычкой все усложнять, болезнью абстрактно ориентированного программиста.

Итог: игра делается в сумме год, публичная бета(которая пре-альфа) неожиданно взлетела.

Совершенные ошибки: over-engineering, построение сложных систем, вместо того, чтобы сделать по простому. Разработка того, что не принесет пользы.

Вывод: yagni и почаще думать головой. Головой думать всегда полезно, не только в разработке.

Простота - ключ к надежности

(с)Дейкстра

Хотел еще историю написать, лучше ограничусь этими двумя.

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

P.S. Потратил полтора часа на написание статьи, а у самого лежит бизнес-план, пишущийся с января и сделанный на 80%. Ну не идиот ли я?

UIViewController for dummies

2014-01-25T15:56:00.001-08:00

UIViewControllers became harder to understand with Storyboards - there are lots of auto-layouts you might not handle.

Just a liitle hint to help debugging:

UIViewController's method invoke sequence is as below

awakeFromNib
viewDidLoad
viewWillAppear
viewWillLayoutSubviews
viewDidLayoutSubviews
viewDidAppear
viewWillLayoutSubviews
viewDidLayoutSubviews

So, if you have views building by code, make sure that storyboard layout will not break it into mess.

5 things you need to implement in any mobile game

2013-12-09T12:57:00.003-08:00

русская версия - здесь

I have three posts in drafts(called "You don't need server" and "3 reasons to switch from Asset Server", "Execute impossible to pardon: how to deal with hackers"), but decided to write this one just because it seems more timely than others.

We had discussion with Yuri about what makes any game perfect and what features must be implemented and come up with some common and must-have features:

in-app-purchases. No comments here. If you want to make money from your game, you'd better have well-tested, stable in-apps;
analytics. The thing is you can not predict user behaviour unless you have any clue what your user is doing in the game. And it's better to have as much information as possible - you know where is your problem in your game mechanics and can easily fix it up;
local and remote push notifications. We didn't implement them in the first releases of Road Smash and we feel regret about it. What is the easiest way to let the users play updated game? Obviously, push notifications.I know that users may hate pushes and remove your app just because they are got annoyed by your app, but in 70% it works.
Anticheat protection. You know, cheaters always exist, especially on android and you need to prevent your game from being hacked. Somebody may say that you need to protect everything, somebody have an opinion that you need to give up on hackers and let them play. I think that hackers wouldn't pay. They would keep hacking the game until they find something or even delete it from their devices, but they would never pay. So I came up with the decision here: protect only that things that cost money or may affect other users. In business terms there are two most important things for developer: users that bring money. When I say money, I mean in-apps, when I say affect other users, I mean scoreboard, social, competition parts of your game. And you need to keep tiny balance between letting gamers play comfortably and prevent players from stealing your money.
Ads. I underestimated role of ads, thought it's annoying and may push your user away. But I was wrong. Firstly, you can integrate ads, so they will become part of your gameplay. Users will want to see some ads just to get some goods instead. And of course, it is a great chance to get money from users that will never pay :)

The main purpose of any game is to have a lot of users in game and keep them as long as long as possible, letting them pay for any reason. In that meaning these five features described must be implemented, well-tested as soon as possible.

And to make this post more concrete, I have some links to assets to share with you to get that features implemented in the easiest way.

in-apps: use unibill. It supports app store, google play, windows store out-of-box, including receipts, subscriptions, etc. Must-have!
analytics: there's a wonderful and free plugin, called GameAnalytics. It supports events, heat maps, gameplay stats. If you are fan of old-school analytics, you may check out for my wrapper to Flurry plugin in my github repository, I'll push all the code as soon as I find free time for it.
push notification: there are too many good plugins in assets, so I don't know what's the best option here. I'd recommend pushwoosh service, because it provides a lot of features out-of-box, but let me leave this topic open.
anticheat: well... there's no common solution as it really depends on what kind of game you are working on. Maybe some kind of playerprefs encryption, in-apps encryption? Did I miss something?
ads: there is a bunch of different options: admob, tapjoy, adcolony, applifier. Some of them provide banner and image ads, some of them kind of video or partnership ads. Choose one you like the most.

Unity Continuous Integration

2013-11-19T14:39:00.001-08:00

And finally Unity Continuous Integration (CI) plugin is on Unity Asset Store! Check it out: https://www.assetstore.unity3d.com/#/content/12695.

I spent a day setting up Jenkins build machine on Road Smash project and spent one more day to unify builder script and writing documentation, so I can use it on any unity project with any CI framework and any CVS systems, including asset server, git, svn. It works out-of-box, the only thing you need is to call the right method(like BuildAndroid, BuildIOS) from command line(OSX, Windows).

For now Unity CI supports:

iOS build
Android builds (including different builds for different textures format, including ATC, ETC, DXT & PVRTC). You can call a method to build 5 different apks, which will support different textures from AndroidManifest.xml and may be uploaded to Google Play as multiple apks.

I didn't include changing version code to plugin, because every project may have its own policy and I may break it, but it is really easy to add there. I'll write another post about all android building stuff later.

I'm planning to include unit-testing plugin to CI and make it portable. I'll finish it up as soon as I'll have a free time for it.

P.S. Unity Technologies rejected my Flurry plugin(full iOS & Android, Windows Phone beta support) for its own internal business reasons. Is anybody interested in it?

Codility prefix problem

2013-11-13T04:24:00.002-08:00

I got a problem from codility site and was asked to solve it. Here's a link on stackoverflow. In two words: assume we have a string S and we need to choose such a prefix P of S, that product of its length and occurrence in S will be maximum.

For example, S = "abababa" has the following prefixes:

"a", whose product equals 1 * 4 = 4,
"ab", whose product equals 2 * 3 = 6,
"aba", whose product equals 3 * 3 = 9,
"abab", whose product equals 4 * 2 = 8,
"ababa", whose product equals 5 * 2 = 10,
"ababab", whose product equals 6 * 1 = 6,
"abababa", whose product equals 7 * 1 = 7.

I like problems like that. It has obvious solution in O(N ** 3) time, elegant and easy to guess if you know z-algorithm O(N ** 2) solution and tricky O(N) solution.

Ok, first solution is naive brute-force. You choose length from 1 to N, get a prefix of its length and count occurences by brute-force searching. So, choosing length takes O(N) time and brute force takes O(N ** 2) time, totally O(N ** 3).

Ok, it doesn't really what we want to achieve. Let's think how we can reduce complexity. Anyone who ever learned strings knows that string occurence can be searched in O(N) time, so with a little code we can achieve O(N ** 2) time compexity solution. I used Z-algorithm. Here's the code:

vector<int> z_function(string &S); //z-function, z[0] = S.length()

int calculate(string &S) {
 vector<int> z = z_function(S);

 int ans = 0;
 for (int i = 1; i <= S.length(); ++i) { //iterate on length
  int k = 0; //counter of occurrences
  for (int j = 0; j < S.length(); ++j) 
   if (z[j] >= i) ++k;  

  //update answer
  ans = max(ans, i * k);
 }
        return ans;
}

But it is still not enough though. How we can get rid of nested loop? We can precalc prefix occurences with Z-algo and finding them in constant time. Initially Z-algo returns an array, where z[i] is the length of longest substring starting from S[i], which is also prefix of S. For "abacaba" it will return {7, 0, 1, 0, 3, 0, 1}. And we know that if prefix of S with length i has N occurrences, then all smaller prefixes of S will have at least N occurrences. So, we create an array of occurrences, iterate over z-array, updating new created array and finally iterate over it backwards, updating as explained above.

vector<int> z_function(string &S); //z-function, z[0] = S.length()

int calculate(string &S) {
 vector<int> z = z_function(S);

 int n = S.length(); 
 vector<int> cnt(n + 1);


 //cnt[i] - count of i-length prefix occurrences of S 
 for (int i = 0; i < n; ++i) 
  ++cnt[z[i]];

 //if cnt[i] is in S, cnt[i - 1] will be in S
 int previous = 0;
 for (int i = n; i > 0; --i) {
  cnt[i] += previous;
  previous = cnt[i];
 }

 int ans = 0;
 for (int i = 1; i <= S.length(); ++i) { //iterate on length
  int test = cnt[i] * i;
  //update answer
  ans = max(ans, test);
 }

 return ans;
}

We separately count occurrences in O(N) time and find the answer in O(N) time as wanted.

For me it is the most easiest way to solve this problem. If anyone knows better solution, please kindly share.

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

2013-10-31T04:07:00.003-07:00

Unity! Я тебя обожаю! Ты из под-коробки поддерживаешь разные типы сжатия в билдах! Не надо руками конвертить, нет больше извратов с AndroidManifest. Поменял опцию и билди! It just automagically works!

Для любителей CI - поменять значение

EditorUserBuildSettings.androidBuildSubtarget

http://docs.unity3d.com/Documentation/ScriptReference/AndroidBuildSubtarget.html

Для ленивых: разные типы сжатия и девайсы, поддерживающие их:

DXT	S3 texture compression, nonspecific to DXT variant. Supported on devices running Nvidia Tegra2 platform, including Motorala Xoom, Motorola Atrix, Droid Bionic, and others.
PVRTC	PowerVR texture compression. Available in devices running PowerVR SGX530/540 GPU, such as Motorola DROID series; Samsung Galaxy S, Nexus S, and Galaxy Tab; and others.
ATC	ATI texture compression. Available on devices running Adreno GPU, including HTC Nexus One, Droid Incredible, EVO, and others.
ETC	ETC1 texture compression (or RGBA16 for textures with alpha), supported by all devices.

Баг шейдера при операции mul

2013-10-23T09:14:00.000-07:00

Натолкнулись на баг в шейдере unity:

шейдер ломается частично, а именно: чем ярче пиксель, тем больше он стробит (если оттенок черного - все норм, ярче - становится заметней). То есть шейдер работает, fallback-a не происходит!
происходит только при операции умножения матрицы 4x4 на вектор4.
воспроизводится только на адрено устройствах.

И это при условии, что мы потом отбрасываем последнюю часть и приводим полученный ответ к vector3.

Называется, поймали эксепшн, который никак нельзя додуматься поймать.

В общем, у кого стробление пикселей в шейдере, напишите собственный mul (благо, это просто несколько операций dot).

Интересное об app store review

2013-10-08T20:29:00.000-07:00

Кто хоть раз заливал приложение в app store, знает, что нужно пройти этапы ожидания ревью, самого ревью и ready for sale. Ну так вот, несколько интересных моментов об ожидании в app store и ускорении ожидания (только ios и под каждым словом надо ставить имхо, ибо только мой опыт):

Среднее время review - 5 рабочих дней
Походу действительно весь штат apple сидит в США, поэтому надо еще рассчитывать их часовой пояс(где-то -7 UTC), их локальное рабочее время. Это важно в случае написания писем.
Expedited app review(это запрос на review без ожидания в случае, если там оказался критический баг или вот-вот начнется пиар-кампания) работает магическим образом. Более того, мне кажется, это сильно зависит от настроения отвечающего на запрос. Однажды я нашел некритичный баг после двух часов релиза и получил добро на expedited review. В другом случае я за пять дней до пиар-выставки отправил приложение и получил отказ в досрочном ревью. В общем, сделал следующий вывод: на expedited app review нельзя полагаться.
Форма Contact us работает оперативно. Даже если они не отвечают, в течение часа что-то происходит.
Статья хабра не сработала. Или я не перескочил минимальный порог приложений для ожидания, или звезды ушли в параллельную вселенную, но это нисколько не повлияло на время ожидания.
Если прошло более пяти рабочих дней, то стоит черкнуть письмецо через Contact us. Реально, они начинают проверять!
А теперь самое интересное: если в ожидании ревью висит несколько приложений и написать письмо(а там в форме надо написать id-шник приложения, у которого ты хочешь обновить статус проверки/ожидания проверки), то начинают проверять сначала не то приложение, которое ты упомянул в письме. Я думал, это одноразовый баг, но такое поведение повторялось у меня несколько раз! И до сих пор в ожидании ревью висит приложение, на которое я отправил запрос проверить в первую очередь, хотя остальные давно проверены.

Unity3d optimization in one presentation

2013-09-20T17:33:00.001-07:00

Let me just leave this here:
presentation

... and that links...

Practical Guide to Optimization for Mobiles (Unity Manual)
Optimizing Graphics Performance (Unity Manual)
Profiler (Unity Manual)

ShadowGun: Optimizing for Mobile Sample Level (Unity Blog)
“Fast Mobile Shaders” talk at SIGGRAPH 2011 (Unity Blog) - highly recommend to anyone who writes unity shaders
http://malideveloper.arm.com/
OpenGL ES 3.0 Developer Resources (Mali Developer Center) - now it's not widespread, but it seems to be very popular and effective in near future!
ASTC Texture Compression: ARM Pushes the Envelope in Graphics Technology (ARM Blogs)

Optimize performance in Unity3d: practical notes

2013-09-16T14:19:00.001-07:00

(Russian post goes here)
I wrote an article in russian about unity performance optimization recently. In this topic I want to share some small, but efficient practical tips with you. Here we go:

if you're running out of memory, use proper texture compression. PVRTC is acceptable for iOS, DXT for android. And don't forget about mip-maps. I know, it gonna increase binary size by 30%, but it's worth it. Don't be so modest to limit max size to textures.
If you don't need shadows in renderers (for example, in UI or something), just uncheck "Receive shadows" & "Cast shadows" options. They are always on by default.
Don't forget about batching. And yes, static batching allows much more than dynamic, so you don't move object, mark it as static. If you want to combine meshes runtime, use StaticBatchingUtility.Combine.

Take into account renderer settings, physics settings of project (Edit->Project settings)
Anti-aliasing, texture quality, shadows and vsync have many options. Just experiment with them to gain best performance/quality.
Uncheck layer collision checks you don't need to calculate.
If you don't really need physics, change fixed timestep.
Don't move static objects.
Design your level, so your camera will not take a lot of objects, then camera culling will save a lot of frames for you.
Mesh collider checks are very expensive! It's better to use double-check technique: firstly make a capsule or box collider and check with it's collision, then check with mesh collider.
Lights. Know the difference between point & directional, use them properly.
Cache transform, collider, rigidbody. We use CachedMonoBehaviour in our projects and happy with that (P.S. From 4.1 Unity did a lot of work with GetComponent optimization, but CachedMonoBehaviour is still faster).

You may achieve better results if you know instruments you use. These tips are really easy to use and sometimes they give more performance than it's expected. Use it and know, premature optimization is root of all evil.

P.S. We are applying all this tips in game named technoball, so please free to try it and tell me what you think about it.
P.P.S We made a lot of work and prepared an awesome update, stay in touch!

Мысля про скриншоты

2013-09-08T13:14:00.000-07:00

Оказывается, "бухгалтероподобным" людям тяжело сделать скриншот и поделиться с друзьями. И вправду, я не умею стандартными средствами делать скриншот быстрее, чем следующими операциями:

нажать prtscr
открыть paint(быстрее, чем нажать пуск, набрать mspaint я не умею)
вставить рисунок
сохранить
открыть файлопомойку, залить файл
получить ссылку, поделиться

Как можно убыстрить этот процесс:

Воспользоваться связкой макинтош+дропбокс(кхе-кхе). В маке я делаю в три операции: делаю скриншот сразу в десктоп (cmd+shift+3), кидаю в паблик дропбокс, получаю ссылку из дропбокса
Воспользоваться сервисом snag.gy. Смысл таков: нажимаете prtscr, открываете сайт, нажимаете вставить(если нужно, корректируете встроенным редактором), сохраняете, делитесь. Примерно так же быстро, как в маке.
Наверняка есть уже готовые сервисы-демоны, которые висят в системе, при нажатии магического шортката делают скриншот, аплодят в файловую помойку и показывают ссылку. Если кто знает о таких, пожалуйста, поведайте! Если нет, скажите, если бы была такая прога, скажите, пользовались бы вы им?

Facebook left-side menu with storyboards

2013-08-22T10:11:00.000-07:00

Well, facebook-like left-side menus became really trendy UI pattern, so everyone tries to insert it to their projects.
Functionally it's primitive: you have left-view in background, and there's drag gesture recognizer, which "catches" foreground view and moves it on xz-direction.

There are lots of open source implementations for ios:

ECSlidingViewController

MWFSlideNavigationViewController

MFSideMenu

HHTabListController

MTSlideViewController

SlideViewController

MTStackViewController

MMDrawerController

I'd recommend to use ViewDeck and SASlideMenu, because they are the most functional and easiest to integrate (For android developers it's worth to mention this stackoverflow answer).

But there was a problem related to storyboards: there's no out-of-box solution to integrate left-side menu with storyboards power! Recently I found really easy to use framework: ViewDeckStoryBoards. Hooray, there's no need to revert back to xibs nightmare! It's based on viewDeck, there's a little code needed(just to overwrite left side & main windows). It supports arc, storyboards.

Принцип самурая или почему надо радоваться преждевременным ошибкам

2013-06-29T14:37:00.001-07:00

Делаем игру с командой и часто инспектируем код друг друга.
Натолкнулся вот на это:(ссылка)

  void Awake ()

  {

    saveDirPath = Application.dataPath + "/Levels/";



    if (buttonSave != null) {

      UIEventListener.Get (buttonSave.gameObject).onClick += OnButtonSave_Click;

    }

    if (buttonLoad != null) {

      UIEventListener.Get (buttonLoad.gameObject).onClick += OnButtonLoad_Click;

    }

    if (buttonInputDialogOk != null) {

      UIEventListener.Get (buttonInputDialogOk.gameObject).onClick += OnButtonInputDialogOk_Click;

    }

    if (buttonInputDialogCancel != null) {

      UIEventListener.Get (buttonInputDialogCancel.gameObject).onClick += OnButtonInputDialogCancel_Click;

    }

    if (buttonselectLevelDialogClose != null) {

      UIEventListener.Get (buttonselectLevelDialogClose.gameObject).onClick += OnButtonselectLevelDialogClose_Click;

    }

  }

Коротко: есть кнопки, и при запуске подписываются обработчики. Все хорошо, код абсолютно безопасен. Но он плох. Почему?

Все очень просто. Если кто-нибудь забудет указать связь кнопки с кодом, то это значение будет равно null => подписка обработчиков не будет работать => обработчик никогда не вызовется. То есть как-бы все хорошо, все работает, но по факту кнопки не работают, ничего не работает.

Казалось бы, фигня вопрос, мы при первом нажатии это заметим. Но на самом деле проблема лежит глубже, чем хотелось бы.
Это хорошо, если наш код будет простым, там не будет цепочки действий, мы сможем легко локализовать проблему. Но при разрастании навигация по коду утяжеляется, ошибку приходится искать бинарным поиском по коду, тратится куча времени. Более того, каждый раз ловя критическую ошибку и продолжая при этом работать, любая программа становится полурабочей, обваливает другие системы. Грубо говоря, такая программа - бомба замедленного действия.

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

Из этого принципа следует, что «глотать» исключения – это плохо, поскольку вы, фактически, скрываете свои проблемы от глаз вызывающего кода и не даете внешнему коду возможности узнать об этом. Не нужно брать на себя слишком многого, пусть голова болит у вашего «клиента», что делать с «вашим телом» (то есть с исключением), когда вы не справились со своей задачей и решили последовать принципам самурая.

Как поступить в этом примере?
Первое, что приходит в голову - просто убрать проверки на null. Поскольку это делается в awake(то есть конструктор-методе Unity),
этот способ применим, потому что этот код вызовется сразу же, упадет c null-pointer-ом, мы сразу о нем узнаем. Но в общем случае, это родственник предыдущего кода.

Более общим и правильным решением является старый assert(ссылка), знакомый всем составителям задач:

  void Awake ()

  {

    saveDirPath = Application.dataPath + "/Levels/";



    Tools.Assert (buttonSave != null, "buttonSave is not assigned");

    UIEventListener.Get (buttonSave.gameObject).onClick += OnButtonSave_Click;



    Tools.Assert (buttonLoad != null, "buttonLoad is not assigned");

    UIEventListener.Get (buttonLoad.gameObject).onClick += OnButtonLoad_Click;

    Tools.Assert (buttonInputDialogOk != null, "buttonInputDialogOk is not assigned");

    UIEventListener.Get (buttonInputDialogOk.gameObject).onClick += OnButtonInputDialogOk_Click;

    Tools.Assert (buttonInputDialogCancel != null, "buttonImputDialogCancel is not assigned");

    UIEventListener.Get (buttonInputDialogCancel.gameObject).onClick += OnButtonInputDialogCancel_Click;

    Tools.Assert (buttonselectLevelDialogClose != null, "buttonselectLevelDialogClose is not assigned");

    UIEventListener.Get (buttonselectLevelDialogClose.gameObject).onClick += OnButtonselectLevelDialogClose_Click;

  }

//in Tools class

  public static void Assert (bool condition, string message)

  {

#if UNITY_EDITOR

    if (!condition) {

      throw new UnityException (message);

    }

#endif

  }

Значит ли это, что надо везде придерживаться предусловий и постусловий? И да, и нет. Конечно, можно начинать любой метод с кучи проверок на случай ядерной войны. Можно поступить лучше: для каждого метода должно быть объявлено некое соглашение - контракт, на основании которого он работает. Если по контракту обработка неправильного поведения происходит на уровне интерфейсов, тогда функция, у которой core обязанности, никогда не примет невалидные данные.

Почему Unity?

2013-06-23T10:50:00.003-07:00

Меня попросили написать короткую статью о том, зачем нужен unity3d и почему я пользуюсь именно им. Решил поделиться своими мыслями здесь, в блоге и постраться не создать очередной холливарной статьи :)

Рынок мобильных приложений, в частности, мобильного гейм-дева, такой, как сейчас, появился совсем недавно - в 2008-2009 году, почти сразу после появления революционного по тем меркам гаджета под названием iphone. А поскольку игры на мобильных начали пользоваться бешенным спросом, то программисты начали делать все, чтобы этот спрос удовлетворить. Совсем скоро начали появляться движки для создания мобильных игр, такие как shiva3d, cocos2d, airplay sdk(сейчас marmalade), corona sdk, unreal engine для мобилок(ограниченный udk), unity3d и так далее. У меня был совсем маленький опыт разработки под marmalade, немножко поигрался с udk, но больше всего мне понравился unity3d.

Чем же привлекателен лично для меня unity3d:

огромные возможности. Действительно, у unity, как у любого высокоуровнего движка, огромный потенциал: графический, физический движок, звуковая система, использование нативных плагинов, импорт моделей, текстур в два клика - и все это работает из-под коробки. Те, кто перешли на ~~темную сторону силы~~ юньку с низкоуровневых движков, отмечают, что много функционала уже написано за них и надо написать только логику;
сама экосистема unity3d. У юнити огромное общество, сидящее на форумах и

стэковерфловах, помогающее тебе при проблемах. Также хитрые юнитеки сделали очень важную фичу - запилили удобные инструмены для создания собственных плагинов. Более того, они сделали Asset Store - это магазин плагинов, созданные пользователями. Хочешь добавить оплату - ищи in-app purchases в ассет сторе, нужно быстро сделать поддержку жестов, 2d, плейлистов музыки - обязательно найдется нужный плагин. Теперь создание игры представляет собой некий конструктор, где ты собираешь из мелких деталей одну большую игру. Использование плагинов в подавляющем большинстве оправдывает себя, несмотря на то, что ты можешь реализовать все это сам: плагин за 20 баксов вполне заменит день твоей разработки. "К сожалению, слишком много компаний отказываются потратить 500 долларов на инструмент, способный устранить противную ошибку за несколько минут, но с легкостью тратят тысячи долларов, платя разработчикам за барахтанье в коде в течение нескольких недель в попытках решить ту же проблему." (с)Джон Роббинс, отладка приложений для Microsoft.Net. Советую прочитать, годная книжка

ну и конечно же удобство разработки. Тут можно провести аналогию между wysiwyg

редакторами и чистым текстом. Первые хороши тем, что ты видишь результат непосредственно в процессе редактирования и ты получаешь фидбек почти мгновенно и на основе этого можешь получать потрясающие результаты(более красиво эту мысль раскрыл Брет Виктор - inventing on principle). Вторые рулят там, где нужна экстрафункциональность (естественно, при должном уровне знаний). Те, кто пользовались tex-ом, понимают о чем я говорю. unity примечателен тем, что в нем есть редактор, позволяющий человеку, совершенно незнакомому с программированием, визуально создавать невообразимые фичи, в то же время ты можешь переключиться на уровень "хард-кодинг" и сделать свой собственный лунапарк(c). И конечно, все кроссплатформенно.

В разработке больше всего важен результат, нежели процесс. Конечно, unity имеет свою область применимости и всегда можно сделать производительнее или красивее. Но функцию сделать качественно и с минимальными временными затратами unity выполняет безукоризненно.

All you need to know about serialization in Unity3D

2013-06-21T05:07:00.000-07:00

upd: video is removed, so check out this link.

Lugat sozluk

2013-06-12T19:23:00.000-07:00

Do you remember our osman-turkish ios dictionary? I've been asked for android version many times.
To those people: there's android version with more than 50000 words! It's really cool app!

On these holidays I reverse-engineered it and now I have their words database. I just need to convert it to my own format, solve licence issues. I think to finish this by the end of June.

Так, ни о чем

2013-05-24T01:35:00.002-07:00

один файл, а внутри: два энама, три класса, две руками написанные стейт-машины, 400 строк кода. Здравствуй, быдлокод:

Some materials from knowledge sharing seminar

2013-05-14T01:56:00.000-07:00

Two months ago we started our unity knowledge sharing seminars. I forgot to share materials I promised to, so let me do it here.

2D UI - NGUI (Presentation on russian)

2D in Unity3D from Рустам Ганеев

Useful links:

NGUI: http://www.tasharen.com/?page_id=140
Optimizations for mobile devices: http://docs.unity3d.com/Documentation/Manual/iphone-OptimizedGraphicsMethods.html
Developing apps for different resolutions (russian): http://rustam-kot.blogspot.ru/2013/03/blog-post_25.html
Cool plugin for NGUI speeds up development and make life easier: http://u3d.as/content/monster-juice/fast-gui-for-ngui/3vJ

Unity shaders (Presentation on russian)

Shaders from Рустам Ганеев

Useful links:

UPD: Dustin Lee, the Unity evangelist kindly shared awesome slides about shaders, just check it out:

Unity Shader System Introduction from Lee Dustin

UPD #2:

Habr: 2D in Unity3D http://habrahabr.ru/post/122197/

46 advices on 2D game development. http://sicklebrick.com/?p=411

Orthelo 2D. http://www.wyrmtale.com/products/unity3d-components/orthello

SM1. http://wiki.unity3d.com/index.php?title=SpriteManager

SM2. http://www.anbsoft.com/middleware/sm2/

ex2D (http://www.ex-dev.com/ex2d/)

2D Toolkit (http://unikronsoftware.com/2dtoolkit/)