В этой статье я хочу рассказать о нашем боте для релизов. У нас много очень разных проектов, начиная от микросервисов backend(a), заканчивая приложением для win 10.

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

Все началось вот с такого крика души:

"Количество разработчиков растет, компания развивается и процесс выгрузки становится все сложнее и запутаннее. Очереди на «добро» скапливаются. Разработчик должен следить нет ли у кого вмерженной и невыгруженной задачи, хотя б на одном из сервисов перед ним и ждать когда, блокировка снимется. Если он еще не получил «добро», то периодически пинать добродавателей, т.к. сообщения с просьбой добра теряются в чатике. А выгрузиться хочется быстрее, потому, что если ты не выгрузишься сегодня, например, то завтра уже кто-то другой может вмержиться и не посмотреть, что предыдущий тег не выгружен => выгрузить незаметно для себя два — и все сломается. Это все превращается в маленький кошмар."

Дóжили. Недавно была обнаружена проблема синхронизации игрового процесса с реальным временем не где-нибудь, а в игре "Quake Champions". Название игры "Quake" раньше было синонимом чего-то крутого, высокотехнологичного и идеального. И в голову не могло придти, что через какую-то пару десятков лет и камня на камне не останется от былого превосходства, а в новой игре с именем "Quake" появятся грубые ошибки, приводящие к тому, что один из игроков может получить преимущество только потому, что у него лучше "железо". Дело в том, что скорость стрельбы в новом шутере зависит от fps, то есть, количество пуль, выпущенных игроками с разным значением fps за один и тот же промежуток времени будет разным, а значит один из них может получить преимущество.

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

Показ приватных переменных в инспекторе

Когда время заканчивается, разработчики выдохлись, а загадочные проблемы продолжают появляться, иногда требуются нестандартные решения. Когда вам любой ценой нужно завершить проект, то на кону стоит всё… В паре классических статей, изначально опубликованных в дружественном журнале Game Developer magazine, мы изучили несколько потрясающих примеров таких решений из реальной жизни. Эти нестареющие шедевры можно прочитать здесь (перевод на Хабре) и здесь.

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

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

Введение

«В моё время игры были лучше. Они были интереснее, потому что геймплей считался более важным, чем графика».

— Геймеры, рождённые в любом десятилетии

Каким бы ни было «ваше время», думаю, вы в какой-то степени согласны с этим мнением. Для меня это был период с середины 80-х до середины 90-х, когда я проводил бесчисленные часы за Sir Fred, Atic Atac, Airborne Ranger, Monkey Island, Twilight: 2000, Stunts, Gunship 2000, Twinsen’s Adventure, Dark Sun, Challenge for Ancient Empires, серией the X-Wing и очень многими другими играми.

Иногда мы испытываем приступы ностальгии и нам хочется сыграть в одну из тех игр снова. В этом случае у нас есть на выбор несколько вариантов.

Сыграть в remastered-версию. Некоторые игры настолько потрясающи и собрали настолько преданную базу фанатов, что выпускается официальное «новое издание». Это точно такая же игра, но с современной графикой. Отличным примером таких игр может быть замечательная Monkey Island Special Edition.

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

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

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

Реактивное программирование — это всё то же самое, только на стероидах, то есть мы можем создавать потоки данных всего. И также наблюдать за ними и реагировать. Update, OnCollisionEnter, Coroutine, Event, Mouse input, Keyboard input, Joystick input — все это потоки.
Все что нас окружает это потоки.

Оглавление

Часть 2: ядро движка

• Интегрирование
• Метки времени
• Модульная архитектура
  • Тела
  • Формы
  • Силы
  • Материалы
• Широкая фаза
  • Отсечение дубликатов контактных пар
  • Система слоёв
• Проверка пересечения полупространств

Часть 3: трение, сцена и таблица переходов

• Трение
• Сцена
• Таблица переходов коллизий

Часть 4: ориентированные твёрдые тела

• Математика вращения
• Ориентированные формы
• Распознавание коллизий
• Разрешение коллизий

Мне всегда нравились классические шутеры от первого лица 90-х. Я часами просиживал за моим 386-м, играя Doom, потрясённый тем, как кому-то удалось написать код, отрисовывающий на моём экране 3D-графику в реальном времени с отличным разрешением 320x200. Я немного знал программирование (только что начал изучать BASIC), поэтому осознавал, что глубоко внутри это всего лишь куча математики и байтов, записываемых в видеопамять. Но в то время даже массивы для меня были довольно сложным понятием, поэтому я не мог даже начать постигать всю сложность 3D-рендеринга.

В то время все писали 3D-движки с нуля, потому что другого способа не было. Но сегодня написание логики 3D-рендеринга с нуля скорее всего окажется плохой идеей. Очень плохой. Почти как изобретение колеса! При наличии огромного количества 3D-движков и библиотек, намного более хорошо протестированных и оптимизированных, чем то, что вы можете сделать сами, нет никаких причин для разумного разработчика начинать писать собственный движок.

Если только…

Представьте, что вы можете вернуться в машине времени назад в 90-е, когда ещё не было OpenGL и DirectX, не было видеопроцессоров. Всё что у вас есть — ЦП и экран, заполненный пикселями. Вам всё придётся писать самому.

Если эта идея кажется вам интересной, то вы не одиноки: это именно то, что можно сделать на такой выдуманной консоли, как TIC-80.

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

В данной статье хочу рассказать вам об опыте разработки одной простенькой игры под Android, которая многократно окупилась еще на стадии разработки!

Привет! Меня зовут Алексей, я тимлид в крупной IT-компании. Сейчас мне 43, только в 40 лет я стал разработчиком, а до этого 15 лет был практикующим врачом-хирургом. Делюсь с вами, как в середине жизни я поменял профессию, о страхах, рисках и планах с этим связанных.

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

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

Что такое инкрементная игра?

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

В сущности, такова общая структура «инкрементной» игры. Она кажется простой, даже примитивной, но в игровом процессе есть неожиданная глубина и привлекательность. Стили игры могут быть разными — от коммерчески успешных и казуальных Clicker Heroes и AdVenture Capitalist до более экспериментальных или хардкорных примеров, таких как Candy Box, Cookie Clicker и Sandcastle Builder.


Cookie Clicker, самое начало.

Что же самое важное в инкрементной игре? Хотя в этом жанре есть множество вариаций и экспериментов, фундаментальными аспектами дизайна являются:

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

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

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

В этой статье мы поговорим о «магической» константе 0x5f3759df, лежащей в основе элегантного алгоритмического трюка для быстрого вычисления обратного квадратного корня.

Вот полная реализация этого алгоритма:

float FastInvSqrt(float x) {
  float xhalf = 0.5f * x;
  int i = *(int*)&x;  // представим биты float в виде целого числа
  i = 0x5f3759df - (i >> 1);  // какого черта здесь происходит ?
  x = *(float*)&i;
  x = x*(1.5f-(xhalf*x*x));
  return x;
}

Этот код вычисляет некоторое (достаточно неплохое) приближение для формулы



Сегодня данная реализация уже хорошо известна, и стала она такой после появления в коде игры Quake III Arena в 2005 году. Её создание когда-то приписывали Джону Кармаку, но выяснилось, что корни уходят намного дальше – к Ardent Computer, где в середине 80-ых её написал Грег Уолш. Конкретно та версия кода, которая показана выше (с забавными комментариями), действительно из кода Quake.
В этой статье мы попробуем разобраться с данным хаком, математически вывести эту самую константу и попробовать обобщить данный метод для вычисления произвольных степеней от -1 до 1.

Да, понадобится немного математики, но школьного курса будет более, чем достаточно.

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

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

Всем привет!

«Если можешь что-то посчитать на GPU, делай это»
// Конечно в рамках разумного



VS


Обращаем внимание на разницу в фпс

Начну, пожалуй, с предыстории. Один из наших программистов, решил проверить UI на предмет падения фпс. И мы нашли интересную зависимость, при отключении миникарты фпс поднимался в процентном соотношении. Интересно. Нужно решать проблему. Сразу напишу что про атласы и различные пулы, мы пробовали. И тогда я решил заняться этим вопросом более детально. И тут первая мысль, которая меня посетила, UI использует материал, значит можно все перенести на ГПУ, начнем.

Диабет является одним из самых распространенных заболеваний во всем мире. В одной только России число диабетиков составляет 9,5 миллионов человек, в мире же это число достигает 422 миллиона, а это каждый 18-й человек.

Я, разработчик приложения для диабетиков, являюсь этим самым 18-м человеком, в 8 лет мне поставили диагноз «Диабет 1 типа».



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

Из-за этого диабетикам первого типа приходится постоянно делать инъекции инсулина – в среднем 5 раз в день, и измерять уровень сахара в крови, прокалывая палец в среднем 7 раз в день. Диабетики второго типа чаще всего обходятся просто соблюдением диеты и приемом таблеток, но все равно иногда им приходится подключать и инсулинотерапию.

Как же мобильное приложение может помочь всем этим людям?

Всё началось, когда автор Ruby on Rails признался миру:

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

Всем привет. Я с моими коллегами работали(ем) в небольшой аутсорсинговой компании. Таких мелких компаний, предоставляющих услуги по обслуживанию инфраструктуры достаточно много, да и почти каждый Системный администратор или ИТ менеджер задумывался, а не начать ли мне подобный бизнес? Одному ли, или с партнером? Вопросов на этом этапе возникает много и я со своей позиции могу поделиться опытом по созданию подобной «конторы».
Начать хотелось бы с конца, ну или почти с конца — с написания SLA. На самом деле SLA просто необходима, даже если вы начинаете работать один и берете себе клиентов на фриланс. SLA сможет помочь вам мотивированно отказывать симпатичной секретарше в просьбе починить очередной чайник. Я конечно же утрирую, но истина не так далека от примера с чайником. Если вы хотите предоставлять конвеерные услуги, т.е. такие, которые бы были идентичны от клиента к клиенту, то SLA вам в руки. Его можно называть как угодно: доп. соглашением, соглашением уровня сервиса или просто приложением к договору.
Собственно мы столкнулись с задачей по написанию SLA, когда поняли, что клиенты недовольны тем, что мы не являемся по щелчку пальца и не решаем задачи по мановению волшебной палочки. Твердо решив узаконить отношения с клиентами был составлен юридически «правильный» договор и некое подобие SLA. Конечно многие ИТ менеджеры начнут кидать в меня помидоры, но все же, то что мы создали имеет право называться SLA, т.к. несет аналогичную смысловую нагрузку.