Лето в разгаре, и если вы не на пляже – самое время почитать, что интересного и значимого произошло в игровой индустрии в июле.

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

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

Перевод статьи «JavaScript Modules» с сайта jsmodules.io.

В новой версии JavaScript появится модульная система, главным образом вдохновленная идеей модулей Node.js.
В этой статье я расскажу, как это будет работать.

Создание модуля

В качестве упражнения, мы построим простой asap модуль, который позволит назначать выполнение действий «как только так сразу» асинхронным образом. В Node.js, вы можете сделать это при помощи process.nextTick, есть и разные подходы, которые работают во многих браузерах. Мы создадим модуль, который будет работать в любом окружении.¹

Перевод статьи «JavaScript CustomEvent», David Walsh

С самого появления JavaScript, события были шлюзом ко взаимодействию пользователя в браузере. События сообщают нам не только о том, что происходит взаимодействие, но также вид взаимодействия, задействованные элементы и предоставляют методы для работы с событием. Создание и инициирование(triggering) кастомных событий всегда являлось более сложной задачей. С использованием JavaScript CustomEvent API, эта сложность может быть устранена. CustomEvent API позволяет разработчикам не только создавать кастомные события, но также инициировать их на элементах DOM, передавая данные по цепочке. Самое главное, что API максимально прост!

Статья будет о создании второй по счету моей игры под Android, на кроссплатформенном движке Cocos2D-x (v3.1). Код преимущественно на С++, местами Java и Lua. Попытаюсь вкратце рассказать про основные моменты разработки.

Текст предназначается в первую очередь для тех, кто, как и автор, с Unity практически не знаком. Но слышал – и хотел бы познакомиться.
А также для тех, кого создатель Unity интересует как личность.

Unity — один из самых популярных игровых движков. На нем сделаны, например, Hitman GO, Rust, Oddworld: New ’n’ Tasty, Monument Valley, Lumo, Warhammer 40,000: Space Wolf и еще тысячи других игр. В основном это мобильные проекты и игры от инди-студий. Почему? Потому что Unity — очень простая в изучении штука, которую могут освоить одиночки и небольшие студии. На конференции DevGamm, посвященной разработке игр, автор встретились с создателем этого движка и CEO компании Unity Technologies – Дэвидом Хельгасоном (David Helgason), и решили, что шанс упускать нельзя. Перед нами человек, который знает об индустрии игр едва ли не больше, чем любой их разработчик!

Дэвид и сам когда-то был разработчиком игр – Unity появилась на свет именно как инструмент для создания тех проектов, которые молодой и неопытный исландец вместе друзьями хотел выпустить в свет. Они верили, что смогут создать отличную игру. Но когда они наконец доделали ее, то поняли, что игра вышла хорошей, но не отличной. А вот инструмент для ее разработки получился очень даже привлекательным — так Unity из движка для личных целей превратилась в инструмент для разработчиков игр по всему миру. От остальных движков Unity отличается в первую очередь простотой и кросс-платформенностью – с помощью этого программного пакета можно делать игры хоть для PC, Mac или консолей, хоть для iOS или Android. Да почти для чего угодно. В общем, мы решили задать Дэвиду несколько вопросов о том, как делаются игры и куда движется игровая индустрия.


Знакомьтесь: Дэвид Хельгасон

Извиняюсь за заголовок в стиле «for Dummies», но это именно то, о чем я хочу сегодня поговорить — о монетизации. В двух словах о себе: занимаюсь инди-геймдевом с 2010 года, на данный момент у меня около десятка изданных игр на Play Store с общим количеством загрузок чуть-чуть не дотягивающим до 20 млн. Я не люблю распространяться о финансовой стороне, но понимаю что в теме о деньгах, без этого никак. На КДПВ вы можете видеть мою статистику за несколько последних дней (на момент написания статьи). В общем, бывало хуже, но бывало и лучше! Цифры не из тех, что поражают воображение, но, согласитесь, довольно неплохие. Особенно, учитывая что я всего лишь любитель, клепающий игры по вечерам.



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

Уровень подготовки веб-мастера: любой

У вас есть не только сайт, но и приложение Android? Теперь вы можете подключить одно к другому, чтобы пользователи смартфонов и планшетов могли легко находить контент приложения прямо в результатах поиска Google.

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



Сотни разработчиков приложений уже пользуются индексированием приложений. Среди них уже и первые разработчики из России, как, например, Афиша. На конференции Google I/O мы представили множество новых функций, упрощающих размещение ссылок на сайт в приложении, связь страниц сайта с приложением настройки, отслеживание эффективности и возможных ошибок.

Привет, Хабрасообщество!

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

Рынок мобильных игр: 28,9 млрд долларов в 2016 году

Juniper Research подготовил доклад с прогнозами развития мобильного рынка, выжимку самого интересного предлагает нам venturebeat.com.

Согласно докладу, мобильный рынок игр дорастет до 28,9 млрд USD в 2016 году, что на 38% больше, чем индустрия должна принести в текущем году (20,9 млрд USD). Таким образом гигантский рынок мобильных игр не собирается сбрасывать обороты, и к 2019 году докладчики обещают рост до 39,6 млрд USD. Основными драйверами роста станут страны Дальнего Востока и Китай, достигнув общей доли в 57%.

Крупные игроки на мобильном рынке, такие как King и Supercell, делают ставку на привлечение игроков в свои продукты для поддержания своих доходов. Данная стратегия очень расточительна, и Juniper предполагает, что наметился общий тренд в стратегии, где анализ показателей продукта стоит во главе угла, что в свою очередь позволяет поднять LTV и тем самым значительно повысить ROI.

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

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

1. Глобальные общефилософские рассуждения из разряда «10 причин, почему тебе не надо становиться инди-разработчиком игр»;
2. Узко специализированные туториалы, решающие конкретную задачу: «Поворачиваем изображение в %framework_name% на произвольный угол при помощи %tool_name%»

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

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

Привет, Хабра!
При разработке игр на JavaScript часто возникает необходимость создавать множество объектов. О том, как правильно это сделать и не утонуть в коде, я рассказывал, примерно — месяц назад на Frontend Dev Conf в Минске. Возможно, доклад будет интересен тем, кто не был на конференции и сталкивался с проблемой создания множества объектов, либо является разработчиком HTML5 игр.



Под катом текст с картинками.

Это, пожалуй, финальная статья, которая дополнит в какой-то мере предыдущие рассказы про релизы зомбодавилки на Google Play, Web Player и Windows Phone 8.

Речь пойдет про старт на AppStore. Кроме того, часть статьи будет о сотрудничестве с издателем, а в качестве дополнения – пару слов о недавних запусках на новых платформах и итоги по проекту, в целом.

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

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

Итак, ни для кого не секрет, что пиариться — трудно. И самое главное — не забывайте о том, что думать о раскрутке вашей игры нужно заранее, а не после релиза. Вообще, первое, что следует сделать — это прочитать книгу Галенкина. Там много всего полезного.

По поводу “когда начинать пиариться” там же есть цифра “за пару месяцев до релиза” для мобильного проекта и до полугода для ПК. Это связано с тем, что на всем протяжении вам надо поддерживать интерес потенциального покупателя к вашей игре. И продолжительность этой заинтересованности разная для разных платформ.

Яблочный рынок приложений, или Apple App Store, потребляет и порождает деньги. Чем больше Вы вкладываете денег, тем выше отдача. Однако, заработанное не всегда больше потраченного. С недавних пор в моей голове вдруг сформировался типичный график потраченных/полученных средств.



Зеленая прямая — график потраченных денег. На что потраченных? На покупку траффика. В результате Ваше приложение выходит в ТОП100, ТОП25 или (ого!!) ТОП10 США и начинает приносить деньги. Красная линия — это заработанное. Если заработанное больше потраченного, то красная линия на графике выше зеленой и Вы отдыхаете на Гавайях, пересыпая между ладоней белый песок Вайкики.

-Чему равна точка Ж?,- спросит сообразительный читатель.

В 2011 году она равнялась 5000 долларов, этого хватало войти в ТОП10. Приложение приносило не менее 1000 долларов в день. Те времена ушли. Теперь в 2014 году надо потратить 50000 долларов, приложения из ТОП10 зарабатывают в день не менее 10000 долларов в день.

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

Как же определить показатель степени для Вашего приложения? Для этого не надо тратить 50000 долларов.
Ловко я Вас заманил под кат?

Коллеги, у нас сегодня важное событие! Мы рады представить вашему вниманию автоматизированный сервис продвижения мобильных приложений — www.appintop.com

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

Не всё так просто

На первый взгляд, JavaScript может показаться достаточно простым языком. Возможно, это из-за достаточно гибкого синтаксиса. Или из-за схожести с другими известными языками, например, с Java. Ну или из-за достаточно малого количества типов данных, по сравнению с Java, Ruby, или .NET.

Но в действительности, синтаксис JavaScript гораздо менее прост и очевиден чем может поначалу показаться. Некоторые наиболее характерные черты JavaScript до сих пор неправильно воспринимаются и до конца не поняты, особенно среди опытных разработчиков. Одна из таких черт — производительность при получении данных (свойств и переменных) и возникающие при этом проблемы с производительностью.

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

Перевод статьи Ричарда Корнфорда Javascript Closures.

• Введение
• Разрешение имен свойств объектов
  
  • Присваивание значений
  • Чтение значений
  
  
• Разрешение имен идентификаторов, контексты исполнения и цепь областей видимости
  
  • Контекст исполнения
  • Цепь областей видимости и свойство [[scope]]
  • Разрешение имен идентификаторов
  
  
• ...

Введение

Замыкание

Замыкание — это выражение (обычно функция), которое может иметь свободные переменные, вместе со средой, которая привязывает эти переменные (т.е. “замыкает” это выражение).

Замыкания относятся к наиболее мощным особенностям ECMAScript (javascript), но они не могут быть применены должным образом без понимания. Несмотря на то, что их легко создать, даже случайно, их создание может иметь пагубные последствия, в частности, в некоторых относительно распространенных окружениях браузеров. Чтобы избежать случайных столкновений с недостатками и использовать преимущества замыканий, необходимо понимать их механизм. Это сильно зависит от роли цепи областей видимости в разрешении имен идентификаторов (identifier resolution) и от разрешения имен свойств в объектах.

Самое простое объяснение замыкания в том, что ECMAScript допускает вложенные функции, определения функций и функции-выражения (function expressions) внутри тел других функций. И эти вложенные функции имеют доступ ко всем локальным переменным, параметрам и функциям, находящихся внутри их внешней функции (внешних функций). Замыкание образуется, когда одна из этих вложенных функций становится доступной вне той функции, в которую она была включена, таким образом, она может быть выполнена после завершения внешней функции. В этот момент она все еще имеет доступ к локальным переменным, параметрам и внутренним декларациям функций (function declarations) своей внешней функции. Эти локальные переменные, параметры и декларации функций (изначально) имеют те же значения, которые были во время завершения внешней функции и могут взаимодействовать с внутренней функцией.

К сожалению, правильное понимание замыканий требует понимания механизмов, которые стоят за ними, и немало технических подробностей. Хотя некоторые из алгоритмов, определенных в ECMA 262, затронуты в начале последующего объяснения, большинство не могут быть опущены или просто приведены к упрощенному виду. Если вы знакомы с разрешением имен свойств объектов, то можете пропустить этот раздел, но только люди, уже знакомые с замыканиями, могут позволить себе пропустить последующие разделы и прямо сейчас перестать читать и вернуться к их использованию.