Недавно я начал работу в Unity над битбоксовой музыкальной игрой Boots-Cut. В процессе прототипирования базовых механик игры я обнаружил, что довольно сложно правильно синхронизировать ноты с музыкой. В Интернете по этой теме нашлось довольно мало статей. Поэтому в своей статье я постараюсь дать наиболее важные подсказки по разработке музыкальной игры (особенно в Unity).

Введение

Итак, вы хотите или пытались создать ритм-игру, но игровые элементы и музыка быстро рассинхронизировались, и теперь вы не знаете, что делать. Эта статья вам в этом поможет. Я играл в ритм-игры со старшей школы и часто зависал на DDR в местном зале аркадных автоматов. Сегодня я всегда ищу новые игры этого жанра, и такие проекты, как Crypt of the Necrodancer или Bit.Trip.Runner, показывают, что в этом жанре можно сделать ещё многое. Я немного работал над прототипами ритм-игр в Unity, и в результате потратил месяц на создание короткой ритм-игры/головоломки Atomic Beats. В этой статье я расскажу о самых полезных техниках создания кода, которым я научился при создании этих игр. Информацию о них я не смог нигде больше найти, или она была изложена не так подробно.

Во-первых, я должен выразить огромную признательность Ю Чао за пост Music Syncing in Rhythm Games [перевод на Хабре]. Ю рассмотрел основы синхронизации таймингов аудио с игровым движком в Unity и выложил исходный код своей игры Boots-Cut, что очень помогло мне в создании своего проекта. Вы можете изучить его пост, если хотите узнать краткое введение в синхронизацию музыки в Unity, но я рассмотрю эту тему подробнее и обширнее. В моём коде активно используется и информация из статьи, и код Boots-Cut.

Аннотация

Всем привет. Относительно недавно я написал статью Генерация окружения на основе звука и музыки в Unity3D, в которой привел несколько примеров игр, задействующих механику генерации контента на основе музыки, а так же рассказал про базовые аспекты подобных игр. В статье практически не было кода и я пообещал, что будет продолжение. И вот оно, перед вами. На этот раз мы попытаемся создать трассу для 2D гонки, в стиле Hill Climb, из вашей музыки. Посмотрим, что у нас получится..

Аннотация

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

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

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

Я решил написать эту статью, т.к. заметил, что многие разработчики допускают ошибки при использовании RecyclerView, даже несмотря на то, что Google уже довольно давно его выпустила.

Описанные здесь пункты упоминались в различных докладах и материалах на Google Devs.

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

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


— Все вы как минимум пару месяцев программируете под Android. Возможно, кто-то программирует пару лет и уже от корки до корки прочитал developer.android.com. А возможно, нет. Но вы все наверняка знаете, как можно сделать многие вещи как минимум одним из способов. Но не секрет, что этих способов может быть много, у каждой команды они могут быть свои, и часто тот или иной способ выбран исключительно по историческим причинам.

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

При работе с платформой Android я столкнулся со множеством проблем, потому что проектировал свои Модели неправильно. Мои приложения были недостаточно реактивными. Теперь используя RxJava и Model-View-Intent (MVI) я, наконец, добился нужного уровня реактивности. Об этом я пишу цикл статей. В первой части расскажу о модели и объясню, чем она важна.

За последние два года Android-разработчики в Badoo прошли длинный тернистый путь от MVP к совершенно иному подходу к архитектуре приложений. Мы с ANublo хотим поделиться переводом статьи нашего коллеги Zsolt Kocsi, описывающую проблемы, с которыми мы столкнулись, и их решение.

Это первая из нескольких статей, посвящённых разработке современной MVI-архитектуры на Kotlin.

1. Retrofit

1.1. Что такое Retrofit

Retrofit — это REST клиент для Java и Android. Он позволяет легко получить и загрузить JSON (или другие структурированные данные) через веб-сервис на основе REST. В Retrofit вы настраиваете, какой конвертер используется для сериализации данных. Обычно для JSON используется GSon, но вы можете добавлять собственные конвертеры для обработки XML или других протоколов. В Retrofit используется библиотека OkHttp для HTTP-запросов.

Как я себя чувствовал во время испытаний.

Исходные условия: засыпаю перед рассветом, просыпаюсь в обед.
Желаемый результат: просыпаться в 7-9 утра без будильника.
Способ: 1 месяц тестировать очки «для просыпания».

И вот что из этого вышло.

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

Чем отличается Telegram от других популярных мессенджеров? Он — открытый!
Другие мессенджеры тоже имеют API, но почему-то именно телеграм известен как наиболее открытый из самых популярных?

Начнем с того, что у Telegram действительно полностью открытый клиентский
код. К сожалению, мы не видим комиты каждый день прямо на GitHub, но у нас есть код под открытой лицензией. Архитектура Telegram подразумевает, что и Bot и API имеет практически такие же методы — https://core.telegram.org/methods.

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

RxJava используется в большом количестве android-приложений, но при этом многие не знают других источников событий, кроме Observable и, может быть, Flowable. Они забывают о специализированных классах Single, Maybe и Completable, которые зачастую способны добавить больше ясности в код.

Под катом вас ждёт шпаргалка по источникам событий, которые существуют в RxJava.

Привет, «Хабр»! Прошло почти 9 месяцев с тех пор, как на Google I/O 2017 компания Google анонсировала Kotlin в качестве официального языка разработки под Android. Кто-то использует его как основной инструмент намного дольше, учитывая, что на нём можно было писать уже с середины 2014 года. В документации Google стали появляться примеры реализации на Kotlin. За это время разработчики смогли «потрогать» и оценить все преимущества этого языка. И многие, включая меня, думали: какой же шаг будет следующим? Support Library на Kotlin? Или что-то новое? И вот, встречайте: Android KTX! А мы представляем вашему вниманию перевод статьи, посвящённой его разбору.

Привет, Хабр. Не так давно я с большим интересом прочла здесь несколько статей со здравыми рекомендациями заботиться о сотрудниках до того, как они «сгорят», перестанут выдавать ожидаемый результат и в конечном итоге приносить пользу компании. И ни одной — с «другой стороны баррикад», то есть от тех, кто действительно выгорел и главное, справился с этим. Я — справилась, получила рекомендации от бывшего работодателя и нашла работу ещё лучше.

Собственно, что делать руководителю и команде, достаточно хорошо написано в «Сгоревшие сотрудники: есть ли выход» (uyga) и «Гори, гори ясно, пока не погасло» (Lisichkina). Краткий спойлер от меня: достаточно быть внимательным руководителем и заботиться о сотрудниках, остальное — разные по степени эффективности инструменты.

Но я убеждена, что ≈80% причин выгорания лежат в личностных особенностях сотрудника. Вывод основан на моём опыте, но думаю, это справедливо и для других выгоревших. Более того, мне кажется, что более ответственные, переживающие за своё дело и внешне перспективные, покладистые работники выгорают чаще, чем остальные.


Аллегория с хомячком может показаться кому-то обидной, но она наиболее точно отражает всё произошедшее. Сначала хомячок радостно прыгает в колесо, потом от скорости и адреналина кружится голова, а потом в его жизни остаётся только колесо… Собственно, как я слезла с этой карусели, а также честная рефлексия и непрошеные советы, как пережить выгорание — под катом.

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

Под катом список тем, которые покажут проблемные места там, где о них не любят упоминать.