Всем привет! Данная статья — об игровых интерфейсах и порядку работы с ними. Она предназначена в первую очередь для тех, кто работает в игровой индустрии и в том или ином виде влияет на разработку интерфейса, но при этом сам не является UI/UX специалистом. Проект-менеджеры, продюсеры, геймдизайнеры, программисты, работающие с GUI, художники — я писал этот текст, думая о вас, ребята.

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

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

Это звучит достаточно просто, и в каком-то смысле так и есть. Первый источник проблем заключается в том, что эта операция будет активно использовать кодеки — и да, она будет ограничена вычислениями, а не памятью и вводом-выводом. Поэтому нам нужна не просто рабочая, но и эффективная реализация. И по дороге мы столкнёмся со множеством других сложностей: взаимодействия с буферизацией ввода-вывода, обработка конца буфера, тупиковые ситуации в битовых сдвигах, определённых в C/C++ и в разных архитектурах процессоров, а также другие особенности битовых сдвигов.

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

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


Так о чём же надо помнить, чтобы делать работу качественно, и SEO-специалисты были довольны вашей работой?

Разработка тестов приложения — не самое приятное занятие. Этот процесс занимает долгое время, требует большой концентрации и при этом крайне востребован. Язык Kotlin дает набор инструментов, который позволяет довольно легко построить собственный проблемно-ориентированный язык (DSL). Есть опыт, когда Kotlin DSL заменил билдеры и статические методы для тестирования модуля планирования ресурсов, что превратило добавление новых тестов и поддержку старых из рутины в увлекательный процесс.

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

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



Статья основана на докладе Ивана Осипова (i_osipov) на конференции JPoint. Дальнейшее повествование ведется от его лица. Иван работает программистом в компании Haulmont. Основной продукт компании – CUBA, платформа для разработки энтерпрайза и различных веб-приложений. В том числе на этой платформе делаются и аутсорсинговые проекты, среди которых недавно был проект в области образования, в котором Иван занимался построением расписания для образовательного учреждения. Так сложилось, что последние три года Иван так или иначе работает с планировщиками, и конкретно в Haulmont в течение года они этот самый планировщик тестируют.

При разработке современных веб-сайтов интенсивно используются возможности JavaScript по работе с DOM. Скрипты позволяют отображать и скрывать элементы, из которых строятся страницы, настраивать свойства этих элементов. У объектов DOM, с которыми взаимодействуют из программ, имеются свойства и методы. О некоторых из них, по мнению автора материала, перевод которого мы сегодня публикуем, знают практически все веб-программисты. А вот некоторые, о которых он и хочет здесь рассказать, пользуются куда меньшей известностью.

В прошлых двух статьях мы рассказывали об IIoT — индустриальном интернете вещей — строили архитектуру, чтобы принимать данные от сенсоров, паяли сами сенсоры. Краеугольным камнем архитектур IIoT да и вообще любых архитектур работающих с BigData является потоковая обработка данных. В ее основе лежит концепция передачи сообщений и очередей. Стандартом работы с рассылкой сообщений сейчас стала Apache Kafka. Однако, для того, чтобы разобраться в ее преимуществах (и понять ее недостатки) было бы хорошо разобраться в основах работы систем очередей в целом, механизмах их работы, шаблонах использования и основной функциональности.

Мы нашли отличную серию статей, которая сравнивает функциональность Apache Kafka и другого (незаслуженно игнорируемого) гиганта среди систем очередей — RabbitMQ. Эту серию статей мы перевели, снабдили своими комментариями и дополнили. Хотя серия и написана в декабре 2017 года, мир систем обмена сообщениями (и особенно Apache Kafka) меняется так быстро, что уже к лету 2018-го года некоторые вещи изменились.

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

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

Можно сделать так, чтобы модель и расчёты стали универсально полезными не для какого-то конкретного шара, а для широкого круга задач. Можно обеспечить оптимальную точность вычислений при численном интегрировании дифференциального уравнения. Можно избавиться от необходимости вручную задавать пределы интегрирования и шаг при расчёте в широком диапазоне параметров. Наконец, можно многое рассказать о динамике полёта нашего шара и без численного решения. И для всего этого служит один давний приём, верный и надёжный, когда-то обязательный при любых расчётах на ЭВМ и до их появления, а сейчас факультативный и часто относимый к магии и искусству – приведение уравнений к безразмерному виду и собственным масштабам. Воспользуюсь задачей о воздухоплавании, как примером и покажу, насколько более осмысленным и изящным становится анализ задачи, при использовании этой техники. А потом объясню почему это может быть важным для программистов, и отчего эта статья попала в хаб «Функциональное программирование».

В одной из предыдущих статей мы провели обзор технологий, которые используются на нашем новом проекте — fast paced шутере для мобильных устройств. Теперь хочу поделиться, как устроена клиентская часть сетевого кода будущей игры, с какими трудностями мы столкнулись и как их решали.

В июне 2018 г. в России был опубликован перевод последнего издания книги Рэфа Костера “Разработка игр и теория развлечений” (A Theory of Fun for Game Design).

Рэф Костер — один из наиболее известных и авторитетных теоретиков геймдизайна, обладатель титула “Легенда онлайн-игр” (2012). Хотя первое издание книги Костера о разработке игр было выпущено более 10 лет назад, его работа об этиологии любви человека к играм и о том, зачем нам нужны игры и какими они должны быть в современных условиях, до сих пор актуальна.
Под катом — тезисный пересказ русскоязычного издания книги.

Привет.

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

Под катом вы увидите: подробную историю создания RTS своими руками (концепция, код, интерфейс, баланс, карта, модели) и эксперимент по привязыванию к ней айтрекера как средства ввода.

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

На рынке есть куча инструментов для ревью кода с готовыми сценариями использования, рекомендациями и правилами. GitHub, Phabricator, FishEye/ Crucible, GitLab, Bitbucket, Upsource — список можно долго продолжать. Мы в Badoo тоже в своё время с ними работали: в своей предыдущей статье  я рассказывал нашу историю ревью кода и о том, как мы пришли к изобретению собственного «велосипеда» — решения Codeisok.

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

Именно поэтому другую часть айсберга можно и не заметить.

TL;DR: это C&C для мобилок.
/thread

Если вы счастливый человек с личной жизнью и не заходили в сеть на выходных, то, вероятнее всего, вы пропустили коллективный крик тысяч фанатов C&C в частности и жанра RTS в целом, который прокатился по всему земному шару после презентации компании EA на игровой выставке E3. Казалось бы, EA из года в год достигает дна: селфи в Sims, лутбоксы в StarWars, новый политкорректный трейлер BF V. Каждый раз, наблюдая за тем, как компания, которая подарила мне детство, фразу «EA Games, challenge everything» и «Эрон-дон-дон» в NFS Underground, методично, с неистовством копает себе репутационную могилу, мне становится дурно.

То, что EA в очередной раз выстрелили себе в ногу подтверждает и реакция публики на трейлер игры на YouTube. На момент написания этого поста соотношение лайков/дизлайков составляет 1,1 тыс. против 21 тыс. Ниже, собственно, сам трейлер. Уберите от экранов беременных женщин, лиц с неустойчивой психикой, детей и собак:


Условно, мой локальный «бабах» можно разделить на две части: «Как обосновывают это сторонники компании» и «почему они не правы».

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

Что можно защитить

В законодательстве Российской Федерации нет указания на компьютерную игру как на отдельный объект интеллектуальных прав. На практике компьютерные игры относят к программам для ЭВМ и/или к составным произведениям (которые включают в себя несколько объектов интеллектуальных прав). И в том, и в другом случае речь идет об авторских правах. Части игры могут быть запатентованы как промышленные образцы или зарегистрированы в качестве товарных знаков.

По порядку:

1. Авторские права

Авторскими правами могут быть защищены:

— Исходный и объектный код программы;
— Графические элементы;
— Тексты внутри игры (правила, указания героям, диалоги);
— Саундтреки;
— Видеозаставки;
— Шрифты;
— и другое (перечень не исчерпывающий).

Если бы я пару лет назад сказал руководству, что на хабре сидят пользователи домашней версии КОМПАС-3D — любители инженерного 3D-моделирования, надо мной бы посмеялись. Но с каждым годом сферы конструирования и IT всё больше срастаются, да и интерес к 3D-печати заставляет IT-шников плотнее изучать САПРы. Наверное поэтому одними из первых комментариев к нашим статьям были вопросы про КОМПАС-3D Home. Это и сподвигло меня на написание этой статьи, постараюсь ответить в ней на основные вопросы пользователей. Тем более КОМПАС-3D v17 Home наконец-то полностью выпущен. Хотя в этом году из-за переговоров с торговыми сетями издание коробочной версии несколько затянулось. В статье постараюсь ответить на основные вопросы пользователей.

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


Транспорт для передвижения в космосе — автор Кекова Анастасия

ОСТОРОЖНО, ТРАФИК!

На прошлой неделе были опубликованы два новых стандарта для беспарольной аутентификации на сайтах, в мобильных и веб-приложениях: WebAuthn API и CTAP. Оба были одобрены Microsoft, Mozilla и Google.

Подробнее об них расскажем ниже.

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


На изображении ниже показан набор тайлов (тайлсет), на основании которого сгенерирован мир из видео. Мир снабжён примечаниями, которые помогут представить его в настоящей среде.

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

До моей работы в Uber у меня не было опыта работы с распределёнными системами. Я получил традиционное образование в Computer Science, после чего с десяток лет занимался full-stack разработкой. Поэтому, пусть я и мог рисовать различные диаграммы и рассуждать о компромиссах (tradeoffs) в системах, к тому моменту я недостаточно хорошо понимал и воспринимал концепции распределённости — такие, например, как согласованность (consistency), доступность (availability) или идемпотентность (idempotency).

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

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

Итак, давайте приступим к нашему погружению в SLA, согласованность, долговечность данных, сохранность сообщений, идемпотентность и некоторые другие вещи, которые мне потребовалось выучить на своей новой работе.

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

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

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

(С)

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

• кэширование страниц сайта для офлайн доступа;
• ведение учета страниц, доступных офлайн, проброс необходимых данных;
• мониторинг статуса сети, онлайн или офлайн;
• общение сервис-воркера со страницами и вкладками, которые он обслуживает;
• перехват сервис-воркером запроса на открытие адреса /offline/ и генерирование новой страницы прямо на устройстве, без запроса к серверу.

Если тема сервис-воркеров и Progressive Web Apps (PWA) для вас новая, то перед чтением этой статьи необходимо познакомиться с ними поближе.

Меня зовут Рыбин Павел, я работаю во фронтенд-разработке Медиапроектов Mail.Ru Group. Это руководство мне помогали писать грабли, набитые шишки и подводные камни, попавшиеся мне при реализации PWA для мобильной версии Авто Mail.Ru.

В тексте будут встречаться небольшие примеры кода, иллюстрирующие рассказ. Расширенную же демо-версию можно посмотреть на GitHub.

И снова здравствуйте, друзья!

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

А я перейду к рассказу о следующем этапе работы!