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

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

Что вообще нужно, чтобы на какой-либо планете возникли полярные сияния?

По определению, полярные сияния — это свечение (люминесценция) верхних слоёв атмосфер планет, обладающих магнитосферой, вследствие их взаимодействия с заряженными частицами солнечного ветра.

Итак, нам требуется:

1. Солнечный ветер, представляющий из себя поток заряженных частиц — протонов, электронов, ядер гелия и др. — Имеется всегда во всей Солнечной системе.
У планет или их спутников:
2. Атмосфера, с атомами которой будет взаимодействовать солнечный ветер.
3. Магнитное поле, направляющее заряженные частицы в определенную область планеты (не обязательно в полярную, — угол между магнитной осью и осью вращения планеты, может быть значительным.)

Посмотрим, как это работает на Земле.

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

Самое забавное в такой ситуации это то,

Любому программисту будет полезно понимание различных структур данных и способов анализа их производительности. Но на практике мне ни разу не пригождались АВЛ-деревья, красно-чёрные деревья, префиксные деревья, списки с пропусками, и т.д. Некоторые структуры данных я использую только для одного конкретного алгоритма и ни для чего больше (например, кучи для реализации очереди с приоритетом в алгоритме поиска пути A*).

В повседневной работе я обычно обхожусь на удивление малым количеством структур данных. Чаще всего мне пригождаются:

• Общие массивы данных (Bulk data) — способ эффективного хранения большого количества объектов.
• Слабые ссылки (Weak reference) (или дескрипторы (handle)) — способ обращения к объектам в bulk data без сбоев программы в случае, если объект удалён.
• Индексы — способ быстрого доступа к отдельным подмножествам в bulk data.
• Массивы массивов — способ хранения объектов bulk data с динамическими размерами.

Я посвящу несколько статей тому, как я обычно реализую все эти структуры. Давайте начнём с простейшей и самой полезной — bulk data.

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

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

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

Обратное собеседование

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

Если вы задавали вопросы, которых нет в этом списке, отправьте пожалуйста пулл-реквест!

Задача

Допустим, нам захотелось логгировать каждый метод некого Java-класса по разному:

• Для каждого метода свой лог-файл,
• … свой формат лога,
• … свой минимальный уровень логгирования,
• формат лога расширяем собственными %переменными,
• возможность обновлять эту конфигурацию на лету.

Оглавление

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

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

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

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

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

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

Я пишу сайты на asp.net mvc. В этих 16 главах я хочу рассказать, как я это делаю. Это некий учебник-справочник всех тех знаний, которые я накопил в течение трех лет.

Почему именно asp.net mvc

ASP.NET MVC я люблю потому что:

• Это .net. Я знаю .net и С#.
• Это компилируемый код.
• Это не ASP.NET WebForms, я работаю с html-кодом.
• Используется MVC-паттерн.
• Visual Studio – самое популярное средство разработки, в котором есть IntelliSense.
• Отличные инструменты отладки.

Связанные проекты сообщества Open Data (проект Linked Open Data Cloud). Многие датасеты на этой диаграмме могут включать в себя данные, защищенные авторским правом, и они не упоминаются в данной статье

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

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

Мы разобрались в этом вопросе и собрали данные по датасетам, удовлетворяющим критериям открытости, востребованности, скорости работы и близости к реальным задачам.

Здравствуйте, уважаемые читатели.

Предлагаю всем, кто заинтересуется, обсудить некоторые основные идеи классического и параллельного программирования в расширении C++, основанном на процедурах/функциях с планированием повторного входа (ПППВ/ФППВ). В минимальном варианте — это процедура или функция, у которой есть статический или динамический план исполнения.

Трудно поспорить, что ландшафт — неотъемлемая часть большинства компьютерных игр на открытых пространствах. Традиционный метод реализации изменения рельефа окружающей игрока поверхности следующий — берем сетку (Mesh), представляющую из себя плоскость и для каждого примитива в этой сетке производим смещение по нормали к этой плоскости на значение, конкретное для данного примитива. Говоря простыми словами, у нас есть одноканальная текстура размером 256 на 256 пикселей и сетка плоскости. Для каждого примитива по его координатам на плоскости берем значение из текстуры. Теперь просто смещаем по нормали к плоскости координаты примитива на полученное значение(рис.1)


Рис.1 карта высот + плоскость = ландшафт

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

Для вычисления урона от атаки в таких настольных ролевых играх, как Dungeons & Dragons, используются броски урона. Это логично для игры, чей процесс основан на бросках кубиков. Во многих компьютерных RPG урон и другие атрибуты (сила, очки магии, ловкость и т.д.) вычисляются по похожей системе.

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

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

Многие начинающие художники горят желанием рисовать персонажей для игр. Но зачастую энтузиазм быстро гаснет, потому что создание персонажа — это ответственное дело, которым нельзя заниматься в отрыве от работы всей команды. Поэтому мы написали для вас руководство, как создавать игровых персонажей, на примере «Аллодов Онлайн».

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

Когда компьютеры обрабатывают лица, они иногда полагаются на объемные морфируемые модели (3D Morphable Model,3DMM). Модель представляет собой среднее лицо и содержит информацию об общих закономерностях отклонения от этого среднего. Например, если у вас длинный нос, у вас также может быть и широкий подбородок. Учитывая такие корреляции, компьютер может затем охарактеризовать ваше уникальное лицо, не сохраняя каждую точку в 3D-скане, а перечислив только пару сотен чисел, описывающих ваше отклонение от среднего лица, включая параметры, которые примерно соответствуют возрасту, полу и длине лица.

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

Компьютерный исследователь из Имперского колледжа Лондона Джеймс Бут (James Booth) и его коллеги разработали новый метод, который автоматизирует создание 3DMM и позволяет им использовать более широкий спектр человеческих лиц. Метод состоит из трех основных шагов. Сначала алгоритм автоматически ориентирует сканирование лица на кончик носа и другие точки. Затем другой алгоритм выравнивает все сканы в соответствии с ориентирами и объединяет их в модель. Далее алгоритм ищет и удаляет плохие сканы.

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

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

В этой статье я буду говорить о разработке многопользовательской карты для Call of Duty: Modern Warfare. Давайте назовём её «Tugurios». Она будет создаваться в антураже трущоб. Теперь мы немного поговорим об истории и сеттинге карты.

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

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

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

Друг наших образовательных программ Михаил Пименов,  CEO компании Wonder Games и Team Lead инди-проекта "Guard of Wonderland" сам не раз задававший себе эти вопросы, создал для себя выборку всевозможных материалов по индустрии геймдева. От полезных ресурсов, до сообществ, подкастов, книг и фильмов, которые призваны помочь понять, с чего начинается и чем заканчивается разработка игрового проекта. Объединив наши силы, мы с Мишей сделали эту статью с подборкой полезных материалов по игровой индустрии. Вы найдете подборку под катом.

Написать этот пост меня вдохновила замечательная статья в блоге Gaffer on Games «Reading and Writing Packets» и неуёмная тяга автоматизировать всё и вся (особенно написание кода на C++!).

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

• Выбор формата. Если бы мы писали простенькую игру на JavaScript, нас бы устроил JSON или любой его самописный родственник. Но мы пишем серьёзную многопользовательскую игру, требовательную к трафику; мы не можем позволить себе отправлять ~16 байт на float вместо четырёх. Значит, нам нужен «сырой» двоичный формат. Однако, двоичные данные усложняют отладку; было бы здорово, если бы мы могли менять формат в любой момент, не переписывая целиком все наши функции чтения/записи.
• Проблемы безопасности. Первое правило сетевой игры: не доверяй данным, присланным клиентом! Функция чтения должна уметь оборваться в любой момент и вернуть false, если что-то пошло не так. При этом использовать исключения считается неважной идеей, поскольку они слишком медленные. Мамкин хакер пусть и не сломает ваш сервер, но вполне может ощутимо замедлить его беспрерывными эксепшнами. Но вручную писать код, состоящий из if'ов и return'ов, неприятно и неэстетично.
• Повторяющийся код. Функции чтения и записи похожи, да не совсем. Необходимость изменить структуру пакета приводит к необходимости поменять две функции, что рано или поздно приведёт к тому, что вы забудете поменять одну из них или поменяете их по-разному, что приведёт к трудно отлавливаемым багам. Как справедливо замечает Gaffer on Games, it is really bloody annoying to maintain separate read and write functions.

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