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

- А вы слышали об энгри бердс? Такая тупая игра и она взлетела!!!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!

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

Unity + winphone = ?

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

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

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

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

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

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

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

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

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

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

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

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

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

История №1

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

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

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

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

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

История №2

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

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

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

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

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

(с)Дейкстра

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

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

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

Особенности национальной верстки или привет зоопарк устройств

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

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

• (дизайнерам) Забудьте о pixel-perfect верстке. Ее не будет. Но именно благодаря этому на всех экранах все будет выглядеть одинаково.
• (программистам) Свыкнитесь, что будут грязные хаки. Это вначале все будет идти гладко да хорошо, а потом вдруг запустишь аpk на 320x240 и удивляешься, что все друг на друга наплыло.

А теперь описание процесса, как мы достигаем вселенского счастья:

• Есть UI (кнопки, слайдеры, менюшки), а есть бэкграунд(бэк). Ну так вот, бэк - это просто картинка(чаще всего однородная) на заднем фоне. Она нужна для того, чтобы по бокам не было черных фонов.
• Мы делаем картинку бэка максимально большим и широким, а потом на каждом девайсе скейлим вниз пропорционально по высоте. К примеру, у нас бэк размером 2764 x1536.  На айфоне 5 отрисуется центральные 2726x640 пикселей. Таким образом, получается, что на самом деле наш бэк будет выходить за границы отрисовки. Скейл вверх нежелателен, но если есть ограничение по памяти, то тут никуда не денешься - никто не даст тебе рисовать картинки 4096x4096.
• Бэк центрируется. Ваш кэп.
• В нарезке UI сюрпризов нет, нарезаем по обычному.
• При верстке UI абсолютно все располагаем относительно UIAnchor-ов. Каждый элемент экрана должен принадлежать к какой-то отдельной части. Да, на каждый чих индивидуального пространства создаем отдельный якорь. Типично используемых якорей хотя не так уж и много: центр, левый верхний угол, правый верхний угол, нижние углы по краям, верх и низ. Остальные используются редко.

Да, еще одно ограничение: надо уложиться в 50МБ выходного файла. Это было интро, а теперь требования и настоятельные рекомендации:

• (дизайнерам) Размеры бэкграундов: 1460x768(HD), 1090x460(SD).
• (дизайнерам) Верстка под экраны: 1024x768(HD), 2048x1536(если совсем не жалко памяти). 
• (дизайнерам) Формат картинок: png
• (дизайнерам) По максимуму избегать альфы (особенность unity - чем больше площадь наложения альф, тем сильнее просаживается fps)
• (дизайнерам) По максимуму избегать градиента (из-за проблем со скейлом)
• (дизайнерам) По возможности, используем nine-patch везде, где только можно.
• (дизайнерам) Шрифты в растровом формате. Более подробно: на ютубе
• (программистам) UI элементы пакуем в одну текстуру с помощью NGUI, бэки оставляем как отдельные картинки(преимущество от запаковки бэков теряется при огромном размере атласа).
• (программистам) Сжатие текстур: PVRTC для ios, ETC/DXT(1/5) для android.
• (программистам) Атласы имеют размеры 2^N
• (программистам) Все используемые картинки - квадратные.

Может быть, что-то забыл. Что забыл, напишу позже.

Разговаривать на общем языке

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

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

Теперь у меня новая проблема: мне надо объяснить моим коллегам, что когда нужна какая-либо функциональность, не нужно страдать синдромом not invented here, нужно взять готовую либу и, если нужно, добавить недостающую функциональность. И, блин, не унаследовав от базового класа, а используя композицию!

Когда я вижу простыню из 900 строк, у меня возникает желание сделать вот так:

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

 и обязательно ищу в нем баг, чтобы получилось вот так:

Вы не поверите, в 90% я его нахожу :)

Честно, не надо придумывать заново колесо, не надо проявлять фантазию в именах переменных, пользуемся готовыми паттернами, реюзаем код. Проще говоря, для себя вывел следующие правила:

• Используем единый стиль форматирования, желательно тот же самый, что используется внутри общества, в котором вы живете. Потому что если вы пишете иначе, то вам сложно понять код других программеров, а другие будут плеваться на ваш код. Это все равно как русскому туристу в Китае на рынке договориться о скидке.
• Самое сложное - придумывать названия (переменным, классам). Это правда. Вот не ленимся переименовать кнопку c ButtonX на MessageButtonBehaviour, anotherTemp на что-либо более подходящее. Я уж молчу о переменных типа ttt, secondVar, var5 (я не шучу - сегодня видел в боевом проекте).
•  Юзаем паттерны, а не изобретаем их! И не надо делегат называть адаптером(привет андроид!), не надо хвалиться, что придумал новое супер решение, не прочитав шестую страницу банды четырех. 
• Не забываем, что паттерны паттернами, но принципы KISS и YAGNI игнорировать нельзя. Вообще, сначала применяем здравый смысл, а потом бегите за стереотипным решением.
•  Изучаем алгоритмы и структуры данных не для того, чтоб победить на топкодере и получить новую футболку, а чтоб знать внутренности структуры данных и алгоритмов, уметь применять на практике и если нужно, написать самому. 
• И да, если знаем алгоритм или структуру, то применяем готовое решение, а не пишем собственный мегабыстрый класс! Сегодня рыдал от строчки типа такого: public List<string> itemsStack = new List<string>();. Угадайте, что это за структура данных? Угадайте, как автор этого шедевра делал push, pop, top? И это было в файле объемом 900 строк!!!!!1111 Я рискнул рефакторить, но позже понял, что это было плохой идеей, потому что этот гребанный стек применялся еще где-то и передавался ref-ом в какой-то левый класс, который зачем-то использовал его по-своему как список(linkedList)!
• И да, не боимся пользоваться плагинами, не ходим грудью колесом аля "я все умею!", все самое лучшее уже давно написано за нас. Мы жмотимся на плагин стоимостью 100 баксов, но сами в течение пяти дней готовы допиливать собственный говнокод, почти выполняющий функции того плагина.
• Не забываем развиваться, изучать новые фичи своего инструмента. Поверьте, вопреки распространенному мнению, обновление - это фикс багов и добавление новых фичей, а не наоборот! И если в языке X появилась штука, которая позволяет в одну строчку написать то, что вы писали в сорок - то даже дурачок Боб, не сумеющий написать свое имя наоборот(с), поймет, что надо юзать эту штуку!

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

P.S. На проекте у нас два программиста: коллега и я. Сегодня произошел священный спор по поводу египетских скобок. Я сторонник египетских скобок, аргументировал так:

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

Он аргументировал это так:

• египетские кнопки это плохо
• я привык писать по bsd стилю, по-другому не умею.
• весь мир неправ.

В общем, это был священный спор и каждый остался при своем мнении. Вдруг кто считает иначе, велкам :)

to-do or not to-do

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

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

Вот тут-то мы и встали. Дизайнер оказался очень гордым. Самым гордым из всех дизайнеров, с кем мне приходилось сталкиваться. Даже мем "упоротый" покажется уменьшительно-ласкательным. С другими дизайнерами, с которыми мне приходилось иметь дело, мы всегда находили общий язык. ВСЕГДА. И это происходило, в первую очередь, потому что мы оба понимали, что делаем ОБЩУЮ работу и стремимся к ОДНОЙ цели, находимся на ОДНОЙ стороне баррикад и не пытаемся вставить палки друг друг другу в колеса.

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

Договор подписать не успели. Если бы успели, это расценивалось как  мой отказ выполнять договор и я должен был вернуть средства, которые бы мне обязаны были заплатить за мою работу. Сейчас он лежит у меня на столе. Никакого пункта с намеком о том, что работа не может быть закончена по вине заказчика (ведь именно он должен отдавать арт и другие информационные средства) нет.

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

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

Всем PM-ам посвящается

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