… или как захоронить свои ядерные отходы навсегда.



Многие уверены, что век монументального строительства прошёл. Пирамиды, мегалиты и загадочные гробницы лежат старыми игрушками в песочнице человечества. Мы выросли из них и живём сегодняшним днём, ярким и мимолётным. Когда нас не станет — от нас останутся только колоссы древности… и ONKALO.

Когда я начинал свою карьеру разработчика, моей первой работой стала DBA (администратор базы данных, АБД). В те годы, ещё до AWS RDS, Azure, Google Cloud и других облачных сервисов, существовало два типа АБД:

• АБД инфраструктуры отвечали за настройку базы данных, конфигурирование хранилища и заботу о резервных копиях и репликации. После настройки БД инфраструктурный администратор время от времени «настраивал экземпляры», например, уточнял размеры кэшей.
• АБД приложения получал от АБД инфраструктуры чистую базу и отвечал за её архитектуру: создание таблиц, индексов, ограничений и настройку SQL. АБД приложения также реализовывал ETL-процессы и миграцию данных. Если команды использовали хранимые процедуры, то АБД приложения поддерживал и их.

АБД приложений обычно были частью команд разработки. Они обладали глубокими познаниями по конкретной теме, поэтому обычно работали только над одним-двумя проектами. Инфраструктурные администраторы баз данных обычно входили в ИТ-команду и могли одновременно работать над несколькими проектами.

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

И не надо…

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

Введение

Алгоритм был написан как часть работы на получение степени бакалавра и основан на статье Ma et al (2014). Целью работы было ускорение алгоритма и дополнение его новыми функциями. Я вполне доволен результатом, потому что мы сделали алгоритм достаточно быстрым, чтобы использовать его во время выполнения игры. После завершения бакалаврской работы мы решили превратить её в статью и отправить на конференцию Game-ON 2018.

Алгоритм

Для создания уровня игры алгоритм получает в качестве входных данных набор полигональных строительных блоков и граф связности уровня (топологию уровня). Узлы графа обозначают комнаты, а рёбра определяют связи между ними. Цель алгоритма — назначить каждому узлу графа форму и расположение комнаты таким образом, чтобы никакие две формы комнат не пересекались, и каждая пара соседних комнат могла соединяться дверьми.

«Он снова это сделал!», — вот, что первое пришло мне в голову, когда я посмотрел на оборотную сторону флаера Pixar ^[1], полностью заполненную кодом. Скопление конструкций и выражений была подписана в правом нижнем углу не кем иным, как Эндрю Кенслером. Для тех, кто его не знает, скажу: Эндрю — это программист, придумавший в 2009 году 1337-байтный трассировщик лучей размером с визитку.

На этот раз Эндрю придумал нечто более объёмное, но с гораздо более интересным визуальным результатом. Так как я закончил писать свои Game Engine Black Books про Wolf3D и DOOM, у меня появилось время на изучение внутренностей его загадочного кода. И почти сразу меня буквально очаровали обнаруженные в нём техники. Они сильно отличались от предыдущей работы Эндрю, основанной на «стандартном» трассировщике лучей. Мне было интересно узнать о ray marching, функциях конструктивной объемной геометрии, рендеринге Монте-Карло/трассировкой пути, а также множестве других трюков, которые он использовал, чтобы ужать код в такой небольшой кусок бумаги.

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

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

Внимание! Под катом много текста и "жирных" гифок.

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

В декабре на конференции HolyJS Александр Коротаев (Tinkoff.ru) рассказал, как он сделал браузерную версию «Героев». Ранее уже появилась видеозапись доклада, а теперь для Хабра мы сделали ещё и текстовую версию. Кому удобнее видео — запускайте ролик, а кому текст — читайте его под катом:

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

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

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

Часть 2. Больше про сетевые протоколы и перемещение пакетов

У этого перевода не совсем обычная история. Системы контроля версий далеки от моих профессиональных интересов. Для рабочих проектов они мне требовались нечасто, причем, разные, так что, каждый раз, когда возникала такая необходимость, я заново вспоминала, как в них делается та или иная операция. А для личных проектов мне хватало возможностей Dropbox, хранящей историю версий файлов.


^{Изображение из твиттера @girlie_mac}

Но вот однажды я на три незабываемых дня попала в роддом — это иногда случается с женщинами. Из развлечений у меня были новорожденная дочь и телефон с большим экраном. Дочь поначалу развлекала плохо (дома она быстро исправилась), а на телефоне помимо книг и фильмов обнаружился текст «Git from the bottom up», который оказался более чем годным… С тех пор прошло почти 3 года, подросшей дочке уже пора самой начинать использовать Git Git стал мейнстримом, если не сказать стандартом в современной разработке, а я с удивлением обнаружила, что перевода на русский этого чуда, полезного не только начинающим, но и продвинутым пользователям Git, до сих пор нет. Исправляю эту ситуацию.

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

Сегодня мы поговорим об Stream API и попробуем приоткрыть завесу тайны в до сих пор до конца неизведанном мире. Несмотря на то, что Java 8 вышла достаточно давно, далеко не все используют полный набор ее возможностей в своих проектах. Открыть этот ящик Пандоры и узнать, что собственно скрывается внутри столь загадочного явления, нам поможет разработчик из JetBrains – Тагир lany Валеев, который давно изучил этого фантастического зверя и места его обитания вдоль и поперек (и совсем недавно написал очередной гайд о том, как правильно, и как неправильно писать стримы), да еще и написал свою библиотеку StreamEx, улучшающую работу с джавовыми стримами. Кому стало интересно, просим под кат!

Отсебятина

Наткнулся год назад на ряд очень интересных статьей господина Simon. Саймон очень любит разбирать то, как создаются игры, а именно графические решения того или иного элемента в игре. Начиная от сколов на гранях плит, заканчивая тем, как реализовано отрезание кусков от объектов. Но особенно интересным представляется его ряд статей под общим названием «Ад рендера» (Render Hell), в котором он подробно разбирает, как на уровне железа (да и программно тоже) происходит рендер 3D-объектов.

Перевод вольный. Его я делал для себя, чтобы в какой-то момент я мог вернуться и прочитать то, что мог не уловить с первого раза или просто забыть.

Ну что, начнем?

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

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

23 ноября 2011 года id Software поддержала собственную традицию и опубликовала исходный код своего предыдущего движка.

На сей раз настало время idTech4, который использовался в Prey, в Quake 4 и, разумеется, в Doom 3. Всего за несколько часов было создано больше 400 форков репозитория на GitHub, люди начали исследовать внутренние механизмы игры или портировать её на другие платформы. Я тоже решил поучаствовать и создал Intel-версию для Mac OS X, которую Джон Кармак любезно прорекламировал.

С точки зрения чистоты и комментариев это самый лучший релиз кода id Software со времени кодовой базы Doom iPhone (которая была выпущена позже, а потому откомментирована лучше). Крайне рекомендую каждому изучить этот движок, собрать его и поэкспериментировать.

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

– Наша Лена уходит в декрет, – сообщил начальник, – поэтому нам надо искать замену на время ее отсутствия. Часть задач мы распределим, а вот как быть с задачей перенаправления обращений пользователей?

Лена – это наш сотрудник технической поддержки. Одна из ее обязанностей – распределение поступающих на электронную почту обращений между специалистами. Она анализирует обращение и определяет ряд характеристик. Например, «Тип обращения»: ошибка системы, пользователю просто нужна консультация, пользователь хочет какую-то новую функциональность. Определяет «Функциональный модуль системы»: модуль бухгалтерии, модуль паспортизации оборудования и т.д. Проставив все эти характеристики, она перенаправляет обращение соответствующему специалисту.

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

На этом увлекательный роман заканчиваем и переходим к технической части.

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

В статье рассмотрены базовые особенности QR кодов и методика дешифрирования информации без использования вычислительных машин.

Иллюстраций: 14, символов: 8 510.

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

Оглавление:

1) Local TCP forwarding
2) Remote TCP forwarding
3) TCP forwarding chain через несколько узлов
4) TCP forwarding ssh-соединения
5) SSH VPN Tunnel
6) Коротко о беспарольном доступе
7) Спасибо (ссылки)

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

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

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

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

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