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

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

Оригинальное описание алгоритма

1. Сначала я задаю нужное количество комнат – к примеру, 150. Естественно, цифра произвольная, и чем она больше, тем сложнее будет подземелье.

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

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

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

3. И вот у нас есть 150 случайных комнат, расположенных на небольшом пространстве. Большинство из них наезжают друг на друга. Теперь мы осуществляем их разделение по технологии separation steering, чтобы разделить прямоугольники так, чтоб они не пересекались. В результате они не пересекаются, но находятся достаточно близко друг от друга.

4. Заполняем промежутки клетками размером 1х1. В результате у нас получается квадратная решётка из комнат различного размера.

5. И тут начинается основное веселье. Определяем, какие из клеток решётки являются комнатами – это будут любые клетки с шириной и высотой, превышающими заданные. Из-за распределения Парка-Миллера мы получим сравнительно небольшое количество комнат, между которыми есть довольно много свободного пространства. Но оставшиеся клетки нам также пригодятся.

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

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

8. Дерево получается аккуратным, но скучным – никаких вам замкнутых ходов. Поэтому мы случайным образом добавляем обратно примерно 15% ранее исключённых рёбер графа. В результате получится граф, где все комнаты гарантированно достижимы, с несколькими замкнутыми ходами.

9. Чтобы превратить его в коридоры, для каждого ребра строится серия прямых линий (в форме Г), идущих по рёбрам графа, соединяющим комнаты. Тут нам пригождаются те клетки, которые остались неиспользованными (те, что не превратились в комнаты). Все клетки, накладывающиеся на Г-образные линии, становятся коридорами. А из-за разнообразия размеров клеток стены коридоров будут неровными, что как раз хорошо для подземелья.

И вот пример результата!

Осторожно — под катом много монстров анимированных гифок!

Примечание: данный пост является переводом статьи cmcenroe.me/2014/12/05/days-in-month-formula.html (Часть I), а также авторским к нему дополнением (Часть II). Не следует относиться к материалу серьёзно, а скорее как к разминке для ума, требующей не более чем школьных знаний арифметики и не имеющей практического применения. Всем приятного чтения!

Часть I

Вступление

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

ФормализуяДругими словами, необходимо найти функцию f, такую, что значение f(x) для каждого месяца x, представленного числом от 1 до 12, равняется количеству дней в этом месяце. Таблица значений аргумента и функции¹:

x	1	2	3	4	5	6	7	8	9	10	11	12
f(x)	31	28	31	30	31	30	31	31	30	31	30	31

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

Ниже следуют мои шаги по нахождению решения.

Принципы Metro-дизайна

Обычно мы употребляем слово «Metro» как название стиля дизайна пользовательского интерфейса, который компания Microsoft использует в своей собственной платформе и также предлагает использовать разработчикам и дизайнерам при создании приложений для Windows Phone (в этой серии статей я фокусируюсь на Windows Phone). Но давайте немного углубимся в суть термина «Metro» и выясним, что же в действительности он означает. Начнем с того, что Metro определяется двумя вещами: принципами Metro-дизайна и языком Metro-дизайна.

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

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

В предыдущей статье "Процесс проектирования приложений для Windows Phone" мы обсуждали важность определения темы вашего приложения для Windows Phone. Этап идей поможет вам усовершенствовать вашу тему и генерировать идеи, которые помогут улучшить пользовательское взаимодействие для этой темы. Мы говорили о выборе в качестве темы пользовательского опыта, такого как обед, бег или плавание, вместо мыслей о приложениях с точки зрения API или RSS-каналов, доступных извне.
Формирование идей и концепции — это весёлый этап и в него лучше всего играть с другими людьми!

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

На практике часто встречается следующая задача: связать вью-модель, которая хранится в unity-контейнере, с одним или несколькими её представлениями (экранами). Обычно такое связывание происходит в бехаинд-коде, в результате чего у представления устанавливается нужное значение в свойство DataContext.

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

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

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

Одним из ключевых моментов в разработке xaml-ориентированных приложений является использование привязок (Bindings). Привязка — это медиатор (посредник), с помощью которого синхронизируются значения свойств между связанными объектами.

Стоит отметить не очевидный, но важный нюанс: хотя привязка так или иначе ссылается на взаимодействующие объекты, она не удерживает их от сборки мусора!

Наследование от класса Binding разрешено, но в целях безопасности кода переопределение метода ProvideValue, который связан с основной логикой работы, не допускается. Это так или иначе провоцирует разработчиков на применение паттерна Converter, который тесно переплетается с темой привязок.

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

Признак плохого дизайна №1:
Наличие объекта-«бога» с именем, содержащим «Manager», «Processor» или «API»

Ведущий iOS-разработчик Redmadrobot Егор BepTep Тафланиди — о том, как добиться стройного архитектурного дизайна мобильного приложения, используя классические шаблоны проектирования и логическое разделение исходного кода на модули.

Чтобы направить всю энергию системы в необходимом направлении, нужно эту систему ограничить правилами.

Привет, Хабр! Продолжаем серию статей об архитектурном дизайне мобильных приложений. Под катом поговорим о проектировании слоёв UI. Добро пожаловать!

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

итак…

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

Привет, Хабр!

Все мы здесь любим качественные пошаговые руководства для начинающих, чего уж греха таить. По платформерам на Unity руководств много, а вот качественных не то что бы и очень. Сегодня мы попробуем добавить в копилку хороших уроков еще один. А создавать мы будем персонажа для 2D-платформера, ни больше, ни меньше.

Присоединяйтесь, учитесь, но помните: под катом очень много гифок.

Привет, Хабр!

Я, как и обещал, продолжаю делиться с вами знаниями, приобретенными в процессе освоения 2D-режима Unity. От начинающего, так сказать, начинающим. Систематизирую, улучшаю и прогрессирую вместе с вами. Сегодня мы добавим к содержимому первой статьи управление камерой, сбор бонусов и первый способ умереть в игре. Если вам, как и мне, не терпится приступить, то добро пожаловать под кат.

И да, гифок там еще больше, чем в прошлый раз.

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

Разрабатывать игры хотят все, и это неудивительно: они популярны и хорошо продаются. Кто не мечтает прославиться и разбогатеть, сделав очередные Angry Birds или Halo? В реальности, однако, разработка игр – одна из самых сложных задач в программировании, ведь в игре нужно подобрать такое сочетание графики, звука и геймплея, чтобы она захватила пользователя.
Чтобы облегчить жизнь разработчикам игр, создаются разнообразные фреймоворки, не только для С и С++, но и для С# и даже JavaScript. Одним из таких фреймворков является Microsoft XNA, использующий технологию Microsoft DirectX и позволяющий создавать игры для Xbox 360, Windows, and Windows Phone. Microsoft XNA сейчас уже более не развивается, однако в то же время сообщество Open Source предложило другой вариант – MonoGame. Познакомимся с этим фреймворком поближе на примере простой футбольной (к чему бы это?) игры.

Я технический евангелист компании Unity Technologies, и моя работа — путешествовать. За пару часов до Нового Года я насчитал в своем календаре 23 командировки по разным конференциям и мероприятиям в 2013-ом. В 2012-ом ситуация была похожа, но фокус был больше на Западную Европу. А теперь пришло время делиться опытом.

Для тех, кому одного курса на праздники мало и кто хочет больше, продолжаем нашу серию курсов от Школы анализа данных Яндекса. Сегодня подошла очередь курса «Дискретный анализ и теория вероятностей» – даже более фундаментального, чем предыдущий. Но без него нельзя представить ещё большую часть современной обработки данных.

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



Читает курс Андрей Райгородский. Доктор физико-математических наук. Профессор кафедры математической статистики и случайных процессов механико-математического факультета МГУ им. М. В. Ломоносова. Заведующий кафедрой Дискретной математики ФИВТ МФТИ. Профессор и научный руководитель бакалавриата кафедры «Анализ данных» факультета инноваций и высоких технологий МФТИ. Руководитель отдела теоретических и прикладных исследований компании «Яндекс». (Ещё больше можно узнать в статье о нём на Википедии).

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

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



Читает курс лекций Константин Вячеславович Воронцов, старший научный сотрудник Вычислительного центра РАН. Заместитель директора по науке ЗАО «Форексис». Заместитель заведующего кафедрой «Интеллектуальные системы» ФУПМ МФТИ. Доцент кафедры «Математические методы прогнозирования» ВМиК МГУ. Эксперт компании «Яндекс». Доктор физико-математических наук.