Игра Oil Rush

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

// <какой-то код>
 
int main ()
{
        constexpr int a = f ();
        constexpr int b = f ();
 
        static_assert (a != b, "fail");
}

Можно ли в приведенном выше фрагменте вместо комментария вставить такое определение f (), чтобы a получила значение, отличное от b?

“Разумеется, нет!” — скажете вы, немного подумав. Действительно, обе переменные объявлены со спецификатором constexpr, а значит, f () тоже должна быть constexpr-функцией. Всем известно, что constexpr-функции могут выполняться во время компиляции, и, как следствие, не должны зависеть от глобального состояния программы или изменять его (иными словами, должны быть чистыми). Чистота означает, что функция при каждом вызове с одними и теми же аргументами должна возвращать одно и то же значение. f () оба раза вызывается без аргументов, поэтому должна оба раза вернуть одно и то же значение, которое и будет присвоено переменным a и b… правильно?

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

Я ошибался.

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

Как правило, язык C++ используют там, где требуется высокая скорость работы. Но на C++ без особых усилий можно получить код, работающий медленнее какого-нибудь Python/Ruby. Именно подобным кодом оперируют многочисленные сравнения Any-Lang vs C++.

Вообще, оптимизация бывает трех типов:

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

Специально заниматься оптимизацией готового кода следует только после того, как проект закончен и используется. Как правило, оптимизация потребуется только в небольшой части проекта. Поэтому сначала нужно найти места в коде, которые съедают большую часть процессорного времени. Ведь какой смысл ускорять код, пусть даже на 500%, если он отнимает только 1% машинного времени? И следует помнить, что, как правило, гораздо больший выигрыш в скорости дает оптимизация самих алгоритмов, а не кода. Именно про данный ее вид говорят: «преждевременная оптимизация — зло» (с).

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

Третий тип даже не совсем оптимизация. Скорее это избегание неоптимальных языковых конструкций. Язык C++ довольно сложный, при его использовании частенько нужно знать, как реализован используемый код. Он достаточно низкоуровневый, чтобы программисту пришлось учитывать особенности работы процессоров и операционных систем.

Привет, хабрапользователь! После небольшого перерыва можно опять браться за трехмерную графику. В этот раз мы поговорим о таком алгоритме глобального затенения, как Normal-oriented Hemisphere SSAO. Интересно? Под кат!

Привет всем. Я хочу рассказать вот о чём… Недели две назад впервые понадобилось работать с GUI под С++ и, погуглив малость, я решил использовать Qt. Его все жутко хвалили, да и вообще на первый взгляд выглядел он весьма достойно.

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

Добавлено: На основе комментариев добрых людей была сделана правка, повествующая о том, как можно обойтись без MOC и без костыликов вообще.

Qt хорошо известен своим механизмом сигналов и слотов. Но как это работает? В этом посте мы исследуем внутренности QObject и QMetaObject и раскроем их работу за кадром. Я буду давать примеры Qt5 кода, иногда отредактированные для краткости и добавления форматирования.

Глава 1. В поисках сокровищ

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

Но, что будет, если вы делаете игру о поиске тех самых сокровищ? На это у нас пока еще нет ответа, но мы, хотябы попытались. Мы кое-что нашли. А сокровище это или нет, вопрос к тебе, дорогой читатель.



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

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

Далее описаны детали реализации и демо проект. Кому интересно — добро пожаловать под кат.

Мне постоянно приходится слышать от студентов и начинающих гейм-дизайнеров – да, честно говоря, и от бывалых программистов тоже – один и тот же вопрос, который звучит примерно так: “Какую архитектуру AI мне выбрать для своего проекта?”. Этим вопросом пестрят форумы, его можно услышать на конференции разработчиков игр GDC, и, конечно же, его не один раз вспоминают во время пре-продакшна создатели любой игры – от AAA-класса до инди. Я работаю консультантом по игровому AI, поэтому я постоянно слышу ее от своих клиентов.

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

В этой статье мы поговорим о различных механизмах, посредством которых взаимодействуют части Android-приложений. Условимся называть все эти механизмы «уровнем взаимодействия» (насколько мне известно, в документации Android нет специального термина для этого).

Введение

Кнопки «Undo» и «Redo», позволяющие отменить и вернуть обратно любые пользовательские действия, а также посмотреть в списке перечень всех выполненных действий, являются стандартом де-факто для таких приложений, как текстовые процессоры и среды разработки, редакторы графики и САПР, системы редактирования и монтажа звука и видео. Они настолько привычны для пользователя, что последний воспринимает их наличие как данность, всего лишь одну функциональную возможность наряду с десятками других. Но с точки зрения разработчика требование к наличию undo является одним из факторов, влияющих на всю архитектуру проекта, определяемую на самых ранних стадиях проекта разработки.



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

Это последняя статья из цикла о процедурно генерируемых с помощью Unity и C# картах мира. Осторожно, под катом 7 МБ картинок.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ершов Андрей Петрович программист — пионер, его влияние на развитие советской школы программирования и вычислительной техники нельзя переоценить. Он ввел в научный оборот термин информатика для обозначения науки, связанной со способами обработки, хранения и передачи информации с помощью ЭВМ. Стал первым программистом, избранным в Академию наук по Отделению информатики, вычислительной техники и автоматизации.



Жизненный путь Андрея Петровича начался 9 апреля 1931 года. Ершов родился в Москве, в семье потомственных интеллигентов. Двоюродный прадед Ершова по материнской линии – Федор Иванович Успенский, ординарный академик Российской академии наук, основатель и директор Русского археологического института в Константинополе. Прадед, Алексей Иванович Успенский служил военным врачом на Кавказе и в Закаспийской области и был женат на дворянке Евдокии Васильевне Скрыльник. Дед Андрея Петровича, Константин Николаевич Малинин — выпускник Московского университета, был членом партии большевиков с 1904 год, позже заведовал отделом в Агитпропе ЦК ВКП (б). Мать, Татьяна Константиновна Малинина, окончила Академию коммунистического воспитания им. Н.К. Крупской в Москве. Отец, Петр Николаевич Ершов закончил аспирантуру в Научно-исследовательском институте полупродуктов и красителей (НИОПИК), работал в Москве, Донбассе, затем заведовал отделом Центральной лаборатории на Кемеровском анилинокрасочном заводе.

Михаила Романовича Шура-Бура — прекрасный ученый, который внес огромный вклад в создание и разработку первых отечественных ЭВМ. Известен также как создатель первой ПП (программирующей программы), интерпретирующей системы ИС-2 для машины М-20. Вспоминая о космическом корабле Буран, нельзя не упомянуть фамилию Михаила Шура-Буры, который был одним из разработчиков программного обеспечения для корабля.

Родился Михаил Романович 21 октября 1918 года в селе Парафиевка (Украина, Черниговская область), куда его родители переехали из Киева, так как началась гражданская война и нужно было как-то прокормить семью. Дед был простым деревенским кузнецом, отец окончил университет и практиковал адвокатскую деятельность.