Введение

Данная статья подводит итоги проекта по созданию спутника “Маяк”, первого российского спутника, созданного руками любителей космонавтики и запущенного на орбиту 14 июля 2017 года с космодрома “Байконур”. Дана хронология развития проекта, перечень основных технических и организационных задач, список участников проекта на разных стадиях.

Так же в статье вот так отмечены решенные вопросы, а вот так — отмеченные ошибки, допущенные в ходе работ.

В тексте встречает местоимения “я” и “мы”. Я — это автор этого текста и руководитель проекта “Маяк”, Александр Шаенко, мы — это команда проекта “Маяк”.

Итак, начнем.

Предисловие

В данной статье рассмотрим как сделать руку-клавиатуру, а также самодельный датчик изгиба (сгибания). На одной руке, как правило, 5 пальцев — это дает сделать 32 (2^5) комбинации. Но на русский язык не потянет (33-32 символа), а вот на английский язык как раз, ещё и останется место для space/backspace/enter и т.д.

Немного идей: если подумать, то это интересный джойстик; если присоединить вторую руку, то это 1024 комбинации, а это возможно музыкальный инструмент; внедрить гироскоп/акселерометр и улучшить до мышки.

Майнеры криптовалют на веб-сайтах стали реальной проблемой. Недавно даже The Pirate Bay начал тестировать такую опцию монетизации. Появились первые сервисы вроде Coinhive, которые агитируют владельцев сайтов устанавливать майнеры и зарабатывать деньги без баннеров и рекламы. По их расчётам, обычный посетитель сайта на среднем ноутбуке генерирует 30 хешей в секунду. Для The Pirate Bay со средним временем сессии 5 минут и месячной аудиторией 315 млн человек это даёт 30×300×315000000 = 2 835 000 мегахешей в месяц.

Если гуманно обращаться с людьми и загружать процессор только на 30%, то остаётся 850 000 мегахешей. Coinhive выплачивает владельцам веб-сайтам 0,00015 XMR за миллион хешей, так что The Pirate Bay мог бы заработать 127,5 XMR ($12 000) в месяц и полностью убить свою репутацию в глазах пользователей.

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

Класс 3D-модели

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

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

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

Около месяца назад в сети появилась информация о весьма примечательном одноплатнике Orange Pi 2G-IOT, предназначенном для реализации различных проектов в области Интернета вещей.

Под катом — перевод первой части статьи What every programmer needs to know about game networking, об истории становления и принципах устройства мультиплеерных сетевых игр. Автор Glenn Fiedler.

Введение

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

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

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

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

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

Если вы используете в своей игре спрайты с прозрачностью (а обычно так и бывает, как минимум для UI), то вам, вероятно, стоит уделить внимание к полностью прозрачным пикселям текстур (или «текселам»).

Даже если значение альфа-канала равно 0, с пикселем всё равно связано значение цвета. Этот цвет ни на что не влияет, так ведь? В конце концов, пиксель полностью прозрачен, кому есть дело до его цвета…

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

Созданию простого 2D платформера посвящено немало публикаций на ресурсах для разработчиков игр. В качестве движка часто используют Unity, а для создания карт — Tiled Map Editor. Взаимодействие этих двух сред осуществляется с помощью бесплатной утилиты Tiled2Unity, которая создает из TME файлов префабы в Unity.

Как это работает, расскажем на примере разработки нашего платформера “X-Drums”.

Двигаться будем по следующей схеме:

1. Настройка экспорта Tiled2Unity
2. Настройка столкновений в Tiled Map Editor
3. Настройка параметров, которые поддерживает Tiled2Unity
4. Настройка пользовательских параметров в Tiled Map Editor

• Пользовательские параметры для слоев (объектов)
• Пользовательские параметры для объектов

1. Настройка экспорта

Итак, у нас есть проект в Unity и есть карта, созданная в Tiled Map Editor. Запускаем Unity и импортируем Tiled2Unity.unitypackage.

Корутины (Coroutines, сопрограммы) в Unity — простой и удобный способ запускать функции, которые должны работать параллельно в течение некоторого времени. В работе с корутинами ничего принципиально сложного нет и интернет полон статей с поверхностным описанием их работы. Тем не менее, мне так и не удалось найти ни одной статьи, где описывалась бы возможность запуска группы корутинов с продолжением работы после их завершения.
Хочу предложить вам небольшой паттерн, реализующий такую возможность, а также подбор информации о корутинах.

Оригинал изображения

Полгода назад я рассказывал про свой опыт работы фрилансером на oDesk. После этого я решил оставить разработку Android приложений на заказ и заняться своей давней мечтой — созданием игр. Мы с друзьями объединились, и работа закипела…

Для начала хочу рассказать о текущем состоянии проекта:
Время от разработки до публикации: 2 месяца
Время нахождения в магазинах приложений: 3 месяца
Загрузки iOS: > 15000 (93 % русскоязычные пользователи)
Загрузки Android: > 35000 (63 % русскоязычные пользователи)

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

Всем привет. DisaDisa начал хорошее дело по переводу уроков по Unity 3D от сайта www.unity3dstudent.com. Я решил продолжить начатое, чтобы уж на хабре был законченный курс.

Ссылки на предыдущие уроки:

• Уроки B00-B03
• Уроки B04-B08
• Уроки B09-B12
• Уроки B13-B16

Содержание:

1. Оптимизация размера игры
2. Бандлы и загружаемые ресурсы. Что требуется от системы?
3. Дифы манифеста
4. Экономия на кодогенерации

Мы прошли экватор цикла о создании MMO RTS. Сегодняшняя статья посвящена оптимизации.

Привет, Гиктаймс! Как часто доводится слушать от друзей и знакомых мольбы на тему ускорения старой системы. Действительно старой. Апгрейдить компьютер с первым Phenom или (в лучшем случае) «корой дуба» в 2017 году не так-то просто. Память DDR2 — все еще продается, но подобный апгрейд далеко не всегда уместен. Толку от новой видеокарты тоже мало, процессор не вытянет. Остается лишь один вариант, а именно установить SSD в качестве основного накопителя. Доказываем, почему такой апгрейд является единственным и наиболее рациональным вариантом.

Это продолжение предыдущей статьи. Мы шаг за шагом создаем движок, на котором будет работать игровая логика нашей экономической стратегии. Если вы видите это впервые — настоятельно рекомендую начать с Части 1, так как это зависимое продолжение и требует ее контекста.

Как и раньше — внизу статьи вы можете найти полный код на ГитХаб и ссылку на бесплатное скачивание.

---

Этим летом на даче, в конце августа, добившись наконец нормального обмена устройства, которое будет описано ниже, с электросчетчиком, я сидел на крылечке и слушал разговор двух белок, одна сидела на большой туе, а вторая – на яблоне. Тут позвонил мой друг, только что вернувшийся из автопохода на Белое море. На его вопрос «как дела?» я ответил, пребывая все еще погруженным в проект: «поговорил со счетчиком, сижу вот, слушаю разговор двух белок». Друг помолчал и сказал: «Ну про белочек после литра выпитой я конечно знаю, но после разговора со счетчиком???» :)

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

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

Работу с объектом можно условно разделить на 3 этапа:

1. Общение с заказчиком, получение информации об ожидаемых функциях системы и их приоритетах
2. Установка и настройка
3. Общение с заказчиком, получении отзыва о системе, недостающих функциях, функциях, оставшихся невостребованными.

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

Я понимал, что этот процесс можно как-то упростить, однако всерьез этим не занимался. Но недавно на рынок вышли два интересных обновления, которые подтолкнули нас с @RagimovRV попробовать добавить моему и клиентским "Удобным домам" немного сообразительности.

Приветствую. Есть такая штука — гидролок\нептун\авквасторож — системы перекрытия подачи воды, если происходит не контролируемая утечка. Принцип простой — датчик воды + автоматика + пара кранов с электроприводами. Но дьявол как обычно в деталях: как устроены краны, как устроены датчики протечки и почему один стоит 50 рублей, а другой 500р. На все это дело навернут килограм макетингового булшита, упаковка вырви глаз и т.д.

В рассказе пройдусь по кирпичикам системы, чем руководствовался в выборе. Вся система строится на заводских датчиках и самодельном контроллере на базе Particle (ex.Spark) Photon (такая esp8266 у которой облачная IDE на wiring из коробки), база девайса stm контроллер + wifi модуль от броадкома. Все это завязано на openhab сервер на Orange Pi One.