Игра уже почти в состоянии альфа-версии. Месяцами вы упорно работали над ней, до цели остался последний рывок, а финишная линия уже видна. Вы планируете потратить несколько следующих месяцев на полировку, настройку и балансировку своего шедевра, прежде чем показать его миру и заработать состояние. Но это не совсем верно. Ещё многое предстоит сделать. Фактически, перед вами скоро откроется совершенно новый мир, пока вы будете гуглить информацию о маркетинге, PR, создании сообщества и издании игры. Вы читали постмортемы, слышали страшные истории и смотрели видео с GDC об играх, разваливавшихся за пару последних месяцев разработки или пропавших в пучине после выпуска из-за недостаточной огласки или апатии. Теперь вас беспокоит судьба вашего замечательного творения, в которое вы вложили месяцы творческой работы и энергии. Страх постепенно овладевает вами. Ужас от того, что ваша игра может просто кануть в небытие.

Предстоит ещё многое сделать! Если вы похожи на меня, то у вас в чём-то не хватает опыта. Все мы обладаем разными навыками и хорошо справляемся со своей работой, но никто не может быть специалистом во всех областях. Например, я в первую очередь программист, и я могу заниматься заниматься массой других вещей (кроме графики, в ней я не силён), но создание бизнеса, маркетинг, PR и создание сообщества… Нет, для меня это всегда было загадкой, и я всегда игнорировал эти аспекты до последнего момента, после чего, наконец, заставлял себя сделать кое-как эту часть работы. Просто для меня это не очень интересная часть процесса разработки игры, и я думаю, что большинство с этим согласится. Кроме фанатов маркетинга, естественно.

Предисловие

Вводим «AdMob» в Google и первым сайтом уже будет не AdMob-ский, а Google-ский сайт. После перехода на оный Вас начнут по немногу переманивать на темную сторону Firebase (недавно купленный Google).

Firebase дает довольно обширные возможности по аналитике (по крайней мере для меня, как программиста, а не маркетолога) рекламы в вашем приложениее (рост, вес, страна, кол-во просмотров, версии Android куда установливалось и тд. и тп.).

Первым делом был найден пост, но он для Eclipse, а после первых попыток сделать по примеру — начались предупреждения о depricated да и вообще ошибки.

Прочитав больше информации стало понятно, что переход AdMob на firebase произошел недавно и разбиратся придется самому.

В первой и второй частях статьи мы создали приложение для работы с Github, внедрили Dagger 2 и покрыли код unit тестами. В заключительной части мы напишем интеграционные и функциональные тесты, рассмотрим технику TDD и напишем с ее применением новую функциональность, а также подскажем, что читать дальше.

В этом цикле статей мы научимся создавать процедурно генерируемые карты мира с помощью Unity и C#. Цикл будет состоять из четырех статей.

Прошло немного больше недели с момента выхода моего первого «настоящего» приложения в Play market. И как это ни странно, оно сумело закрепится в топ-10 новых бесплатных своей (пусть и не самой конкурентной) категории сразу в 2 странах(Россия и Украина). И даже там потихоньку обходит конкурентов. Странно это сразу по двум причинам — во-первых, единственной реальной инвестицией в приложение было мое время и время моей девушки. А во-вторых неопытность нашего стартапа как в продвижении продуктов, так и в разработке качественных приложений. Но все же мы сумели добиться, хоть локального и маленького, успеха.
Всех желающих узнать о продвижении приложения «малой кровью» — добро пожаловать под кат.

Подводим итоги первой в этом году рабочей недели — в Google Play наконец-то появились промо-коды, определили ситуацию с разработкой корпоративных приложений, снова разобрали Cordova и разработали фреймворк для iOS. Интересных вам проектов в новом году!

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

Управление зависимостями – одна из наиболее важных функций в арсенале систем сборки. С приходом Gradle в качестве основной системы сборки Android-проектов в части управления зависимостями произошёл существенный сдвиг, закончилась эпоха ручного копирования JAR-файлов и долгих танцев с бубном вокруг сбоящих конфигураций проекта.



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

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



Данная статья является продолжением поста Генераторы непрерывно распределенных случайных величин. В этой главе учитывается, что все теоремы из предыдущей статьи уже доказаны и генераторы, указанные в ней, уже реализованы. Как и ранее, у нас имеется некий базовый генератор натуральных чисел от 0 до RAND_MAX:

unsigned long long BasicRandGenerator() {
    unsigned long long randomVariable;
    // some magic here
    ...
    return randomVariable;
}

С дискретными величинами все интуитивно понятнее. Функция распределения дискретной случайной величины:


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

Распределение Бернулли

Здравствуйте, меня зовут Дмитрий. Я занимаюсь созданием компьютерных игр на Unreal Engine в качестве хобби. Сегодня я расскажу, как создать свой модуль, а потом, как создать плагин в Unreal Engine 4.

Эта статья — вторая часть перевода выступления Джона Нески (John Nesky) с GDC14.

Первая часть тут.

#26 Оставлять угол съёмки постоянным в то время, как персонаж бежит по склону

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

Предисловие

В настоящее время я работаю над собственным игровым движком. С использованием минимального количества сторонних библиотек, после реализации игрового цикла (game loop), отрисовки кадра, функции «update», загрузки текстур и пр., основная «начинка» движка была готова. Пришло время реализации еще одной важной составляющей — сцены (scene).

Введение

В статье я предполагаю, что движок уже оснащен игровым циклом с «callback»-функциями. Весь код будет написан на Java, но может быть легко перенесен на любой другой язык, поддерживающий garbage collection. Что-ж, приступим.

В этой статье я расскажу о том, как своими руками, имея только блокнот и любой веб-сервер, сделать шейдерные 2D-тени на WebGL. Все шаги лежат на гитхабе как ветки и переключаются git checkout stepN, так что добро пожаловать даже тем, кто не настроен кодить.

КДПВ:

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



Мимо меня этот момент не прошел, а объял всей своей сущностью и велел что-то делать. Работу менять не хотелось, а вот создать что-то вне этой самой работы можно было. Так как на работе приходится заниматься созданием исключительно полезных приложений – захотелось сделать что-то совершенно бесполезное иное. В моем понимании это должно было быть развлекательное приложение, а значит игра. В худшем случае игра должна пойти в копилку портфолио, которое не запрещают договора о неразглашении коммерческой тайны (да-да, работаешь много, а показать ничего не можешь, так как нельзя). В лучшем же случае, чтобы игра радовала – она должна приносить хоть какие-то деньги.

Статья будет полезна начинающим разработчикам игр. В ней мы рассмотрим преимущества и способы создания и рендеринга трёхмерных объектов для изометрических 2D-игр на примере Blender. В статье не будет каких-то сложных операций, достаточно начальных знаний 3D-редактора. Для примера рендеринга и анимации я взял башню из Dune2, и, чтобы ей было не так скучно одной, дополнил двумя постройками из Desert Strike.

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

В этой статье я, Артур, основатель и гейм-дизайнер инди команды ArmNomads Games (состоящей из трех человек), хочу поделиться пройденным нами путем в опасные дебри мобильного гейминга. От идеи до конечного релиза.



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

Главный враг раздолбайства — план.

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

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

Подобный подход рождает несколько довольно странных выводов. Например, если речь идёт о новом сайте – явно, что все тексты должны быть готовы до начала работ по дизайну. При работе с игрой виртуальные прототипы (в симуляциях) работают только на последних этапах балансировки, вначале же куда важнее быстро собрать на бумаге. Если уж говорить шире, то мы знаем, что новый XCOM (и XCOM2) тестировали и тестируются как настолки, а потом уже гонятся на компьютер.

Может показаться, что прототипировать — это вроде как не очень нужно. Херак-херак — и в продакшн. На самом деле, это чертовски важно в любом процессе; например, по заветам юзабелистов — это 70% работы. Вопрос только в том, как это можно делать.

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

На презентации Google I/O 15, компания Google представила новую версию библиотеки поддержки которая реализует несколько компонентов, сильно связанных со спецификациями Material Design, среди этих компонентов вы можете найти новые типы ViewGroup такие как AppbarLayout, CollapsingToolbarLayout и CoordinatorLayout.

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