Доброго времени суток. Данная статья, хотя лучше обозвать её ToDo, может быть полезна людям со способностями к рисованию, которые знают основы моделирования и обработки изображений, ну или умеют включать нужные программы. Если это про Вас, или Вам интересно как сделать такой замок — прошу под кат.
Задумывались ли вы когда-нибудь о то, почему птицы летая большими стаями никогда не сталкиваются и не коллапсируют в огромный галдящий перьевой ком? Хм, если подумать, это было бы круто. В любом случае, однажды в 1986 нашёлся человек по имени Крейг Рейнольдс, который решил создать простую модель поведения птиц в стаях и назвал её Boids. В модели у каждого боида есть три базовых правила: Separation, Alignment и Cohesion. Первое заключается в избегании столкновения с соседями, второе заставляет лететь примерно в ту же сторону что и соседи, а третье говорит не летать в одиночку и держаться группы. Эти простые правила позволяют создать правдоподобные стаи птиц, рыб и другой живности, чем и пользуются в кино и игровой индустрии.
В статье я расскажу как можно реализовать эту модель на практике. Для разработки я использую Unity и C#, но большинство вещей верны для других движков и языков. В этом туториале я не разжёвываю основы работы с Unity, подразумевается, что вы знаете эффект комбинации Ctrl+Shift+N на сцене, умеете работать с инспектором, дублировать и двигать объекты. Если нет, то советую начать с этой статьи. Или можете просто посмотреть на картинки.
Не секрет, что объектов в играх на порядок больше чем их возможных поведений. При прототипировании описания объектов можно составлять прямо в коде на Java, С++ или C#, но там всё довольно быстро запутается. Потом объекты выносят в базу данных, либо в XML или JSON конфиг. Это сильно помогает, ведь после редактирования конфигурации пересобирать код не требуется, и этим могут заниматься не только программисты, но и спецы по предмету (для игр это гейм-дизайнеры и контентщики). Когда разрастается команда либо количество объектов переходит какую-то черту, программисты пишут удобный редактор, который позволяет визуально править этот JSON-конфиг. В результате на выходе получается какой-то трудно поддерживаемый монстр.
Если вы не собираетесь нанимать множество людей которые вообще не умеют кодить, то можно попробовать пойти другим путём: описывать метаданные с помощью Domain Specific Language.
Здравствуйте! Весьма надолго у меня растянулась подготовка материала (жизнь давала изрядных пинков под зад), но вот я справился и готов поделиться продолжением первой статьи с вами.
В этой части мы:
— оптимизируем код из предыдущей статьи;
— создадим объект «база» и научим её чиниться время от времени;
— добавим пушкам патроны и перезарядку;
— избавимся от «неудобной» переменной gv;
А в конце статьи вас ожидает маленький бонус :)
Всем заинтересовавшимся — добро пожаловать под долгожданный кат!
Знаете ли вы, что кузнечики, будучи брошенными в ведёрко, начинают маршировать по кругу как на картинке выше? Правда сверху не кузнечики, а Boids — модель коллективного поведения птичек, пчёлок, рыбок и другой живности. Несмотря на простоту модели, она демонстрирует эмерджентные свойства: боиды собираются в кучу, летают стаями по кругу, нападают на людей.
Это вторая часть статьи, посвящённая различным хитростям оптимизации Unity и C#, которые увеличивают производительность алгоритма из первой части в пару десятков раз.
В процессе поиска алгоритмов расчета коллизий на сайте GameDev, я наткнулся на маленькую статью про движок idTech 6 и заинтересовался воксельной графикой, которую противопоставляют полигональной графике, на которой сейчас основана почти вся компьютерная графика.
Вообще, воксел расшифровывается как "объемный пиксель", однако сейчас под вокселом в основном понимается некий примитив, чаще всего куб или прямоугольный параллелепипед, который имеет определенный размер и цвет. В idTech 6 и в движке Кена Сильвермана Voxlap они хранятся в разреженном октодереве (SVO — sparse voxel octree), что позволяет экономить память и делает возможным простую реализацию "уровня детализации".
Снеговик из вокселей
Иными словами, вокселы — это такой конструктор LEGO, где из одинаковых деталек разного размера (а также, соеденяя маленькие детальки в большие) можно реализовать самые разнообразные модели, фигуры и т.д.
Одно из самых больших преимуществ вокселей относительно полигонов, то, что их можно разрушать — программа точно знает, что если воксел частично разрушен, то его можно поделить на более мелкие вокселы, которые будут из того же материала, что и их родитель.
Не то чтобы я был диким фанатом консолей, но есть вещи, которые действительно впечатляют. Понятное дело, что консолям нового поколения без впечатляющих пилотов на рынке делать нечего. Речь идет не о Watch Dogs, который тоже заслуживает внимания, как любая песочница с открытым миром, а о Tom Clancy’s The Division анонсированная для PS4 и Xbox One. Картинка (я оцениваю лишь ее) выглядит действительно хорошо. Игры уже давно стремятся быть не играми. Это уже почти кино. Меня мало волнует сейчас вопрос гейм-плея данной игры. Сейчас я просто потребитель, который готов клюнуть на вкусную обертку.
Параллельно с этим во мне просыпается девелопер-скептик, который ничего и никогда не принимает на веру, который до того как возопить о пришествии чего-либо сперва хочет убедиться в том, что пришествие произошло. Не потому, что боится выглядеть глупо, но потому что, обжегшись тысячи раз — не хочет повторить это в тысяче первый.
Мне уже давно не удается играть в игры как игроку. Иметь стопроцентное погружение. Это побочный эффект призмы через которую я смотрю на любую игру. Глаз в первую очередь цепляется за знакомые графические артефакты, ищет пути, которыми шли разработчики в создании графического контента. Одобрительно хлопает плюсам, и огорченно хмурит брови там, где все осталось как есть, без изменений. Все это помножено на «взгляд художника», который также аплодирует умелым действиям, и негодующе рычит в тех местах, где неизвестный художник допустил ошибку. Все это множится на еще не добитого геймера, который превыше всего ставит гейм-плей.
Сложный коктейль мешающий, в полной мере, наслаждаться компьютерными играми. Борьба противоположностей. Внутренний конфликт потребителя и разработчика.
Что я вижу здесь? Для начала посмотрите трейлер и решите, что видите для себя вы. А потом… лопата?
Spatial hashing это простая техника, которая используется в базах данных, физических и графических движках, симуляциях частиц и вообще везде, где нужно быстро что-то найти. Если в кратце, то суть в том, что мы разбиваем пространство с объектами на ячейки и складываем в них объекты. Затем вместо поиска по значению очень быстро ищем по хэшу.
Предположим, что у вас есть несколько объектов и вам нужно узнать нет ли между ними столкновений. Простейшим решением будет посчитать расстояние от каждого объекта до всех остальных объектов. Однако, при таком подходе количество необходимых вычислений растёт слишком быстро. Если на десятке объектов приходится делать сотню проверок, то на сотне объектов выходит уже десяток тысяч проверок. Это и есть печально известная квадратичная сложность алгоритма.
Как-то раз я решил написать игру. Для себя и в своё удовольствие. Передо мной стоял выбор – использовать всё готовенькое ака Box2D или написать для неё физику самому. Второй вариант показался мне более интересным, и я принялся выискивать в просторах сети информацию, которая помогла бы мне написать всё необходимое. Выискал. Как результат получился очень гибкий(как для игры) и простой физический движок. Основой движка стал метод численного интегрирования Верле.
Хотите услышать рассказ о том, как классика ролевых игр на PC смогла возродиться как мультиплатформенный проект, да еще и в виде «расширенного издания»? Один из основателей Bioware Трент Остер (сегодня — президент компании Beamdog / Overhaul Games, занимавшейся разработкой переиздания) готов провести нас за кулисы и рассказать, как же все происходило.
Это вторая и заключительная часть статьи, посвященной процедурным методам производства контента для 3D приложений. Первую часть Вы можете найти здесь.
В этой части, так же как и в предыдущей, приводятся ссылки на скачивание созданных нами исходных материалов, которые можно свободно использовать (с изменениями или без) в своих проектах, но только не продавать/распространять в чистом виде и/или в составе каких-либо библиотек.
Напоминаем, что все эти исходные файлы не подвергались никакой специальной подготовке, обработке или оптимизации, чтобы не приукрашивать реальную ситуацию (довольно часто в процессе работы приходится жертвовать универсальностью/удобством создаваемых решений в пользу сэкономленного времени).
В этот раз речь пойдёт о том, какими средствами и приёмами мы пользовались при создании бенчмарка Valley, чтобы в максимально сжатые сроки произвести большое количество фотореалистичного контента.
На что вы сейчас смотрите? Если вы не из параллельной вселенной, где все сидят за векторными мониторами, то перед вами растровое изображение. Поглядите на эту полоску: /. Если придвинуться поближе к монитору, то можно увидеть пиксельные ступеньки, которые пытаются притвориться векторной линией. Для этой цели существует целая куча всевозможных алгоритмов растеризации, но я бы хотел рассказать об алгоритме Брезенхема и алгоритме У, которые находят приближение векторного отрезка в растровых координатах.
С проблемой растеризации мне довелось столкнуться во время работы над процедурным генератором планов зданий. Мне нужно было представить стены помещения в виде ячеек двумерного массива. Похожие задачи могут встретиться в физических расчётах, алгоритмах поиска пути или расчёте освещения, если используется разбиение пространства. Кто бы мог подумать, что знакомство с алгоритмами растеризации однажды может пригодиться?
Недавно на хабре проскочил пост, который напомнил мне о такой забавной и довольно интересной вещи, как BoxCar2D (Оригинал, Версия из поста), которую в первый раз я увидел пару лет назад, и которая меня порядком впечатлила. И уже тогда я подметил в ней один фатальный недостаток (вкратце — ее сделал не я), но в тот раз руки так и не дошли до его исправления. И вот теперь я решил это исправить.
Итак, я расчехлил Visual Studio и принялся за дело.
Первым делом я просто повторил функционал BoxCar2D, а именно: фиксированный размер популяции, которая проживает свою жизнь и порождает следующее поколение. Можно было поиграться с тем, как усложняется трасса со временем, что содержит в себе геном и как машинки скрещиваются и мутируют.
С текстурами вечно какие-то проблемы! То оказывается, что нельзя взять любую фотку и налепить на модельку. То на стыке текстур появляются швы, которые замучаешься заглаживать. То вроде уже и загладил всё, но глаз, этакий проказник, всё равно замечает повторяющиеся узоры и рушит иллюзию.
Можно сделать текстуру побольше, чтобы повторяющиеся куски дальше отстояли друг от друга и были не так заметны. Можно даже сделать её совсем огромной, на пару сотен тысяч пикселей, чтобы она накрывала всю сцену целиком без швов и повторений. Подобную технику называют мегатекстурой. Но мегатекстуры и близкие к ним виртуальные текстуры усложняют работу с памятью, для работы с ними требуются особые инструменты, да и в целом это ещё молодая технология.
Как же быть? Есть один трюк — непериодические мозаики. Они лишены проблемы повторяемости и достаточно просты в реализации. Одну из таких мозаик придумал китайский математик Ван Хао в 1961 году. Элементы этой мозаики можно представить в виде прямоугольников с разноцветными гранями. Но чтобы понять принцип её работы, надо сначала разобраться в классическом методе заполнения площадей текстурами.
Всем привет!
Сразу попрошу извинения за стилистику моей писанины и незнание русского языка – к сожалению я ни разу не блогописатель, но желание оставлять комменты на хабре — сильный мотиватор. Кроме того, что я не писатель, я еще и не программист, а инженер-строитель, который иногда балуется написанием пары строк кода – такое вот хобби среди прочих. Но про строительство я вдоволь написался во времена подготовки и защиты диссера, и больше к этому возвращаться желания нет.
А в этой статье я хочу описать личный опыт создания одной игрушки с реализацией многопользовательской игры, позволяющей поддерживать различные платформы (пишу я на .NET, поэтому в первую очередь мой опыт касается Windows/WP, но этот же метод прекрасно подойдет для других платформ, у меня есть рабочие прототипы описываемой игры для Android/iOS, но пока нет желания платить по 1к юсд за коммерческие пакеты Xamarin). И да — в этой вводной статье (которая изначально планировалась исключительно в песочницу) я не буду раскрывать технических деталей, так как в этом случае я рискую еще долго ее не закончить. Кто знает, возможно у меня еще появится время и возможность написать более подробное продолжение.
Хотелось ли вам когда нибудь сделать свою игру или 3D презентацию, или просто узнать как работают другие игры? Мне всегда хотелось сделать свою игру, и было интересно узнать как работают уже существующие. Не буду скрывать что одной из моих любимых игр является Unreal, работающая на движке UnrealEngine от Epic Games. Первая версия движка появилась 1998 году. На данный момент актуальная версия движка четвёртая. Кроме самой серии Unreal на движке было сделано очень много игр.
Выпустив первую версию движка Epic Games приложила к движку UnrealEditor — редактор позволяющий делать свои уровни и моды для игры. В 2009 году Epic Games выпустила UDK который позволил делать свои игры. На мой взгляд этот движок достоин того, чтобы разобраться как с ним работать и что он может.
Я попытаюсь описать основы работы с UnrealEngine, но в силу некоторых причин я буду описывать его в основном по второй его версии. Большинство из описанного будет работать и в UDK и в UnrealEngine4. Итак, если вас это заинтересовало, добро пожаловать под кат.
Уже два года как я не работаю в геймдеве. Соответственно, появилось время и желание обобщить мысли об этом бизнесе безобразии. От откровенно хулиганских, до претендующих на исследование.
Тем не менее, с хулиганского начну лишь отчасти: классификации игроков по тому, что они хотят в игре и от игры. Она не полна и спорна, но снабжена занимательными комментариями и завершается грандиозным мысленным экспериментом на примере известного анекдота.
Да, и я буду писать о монетизации довольно цинично. Я бы сказал, предельно цинично, хотя и с большой долей иронии и чёрного профессионального юмора. На самом деле всё возможно и не так страшно.
При выборе темы диплома учитывалось желание накодить что-то практическое, что и повлияло на выбор темы. Было принято решение разработать платформу для проведения соревнований по программированию ИИ танка. В целом идея не нова и такие вещи уже делались (http://robocode.sourceforge.net, например). Но существует несколько причин, по которым были выбраны именно танчики:
Итак, обещанное продолжение моей первой статьи из песочницы, в котором будет немного технических деталей по реализации простой многопользовательской игры с возможностью играть с клиентов на разных платформах.
Предыдущую часть я закончил тем, что в последней версии моей игры «Магический Yatzy» в качестве инструмента клиент-серверного взаимодействия я использую WebSocket’ы. Теперь немного технических подробностей.
