Как сделать свой майнкрафт на c

Обновлено: 24.01.2025

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

И так, поехали:

Разберём код:
Строка "string appData = Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData);":
указывает к строке(string) appData следующий путь до папки AppData
Строка ProcessStartInfo mcStartInfo = new ProcessStartInfo("javaw", ". ":
ProcessStartInfo mcStartInfo = new ProcessStartInfo задаёт параметры на запуск minecraft.jar.
. + textBox1.Text) - программное имя textBox (смотреть в окне свойств)
Строка this.Close();
this. указывает на форму, Close() - действие с формой(закрытие)

В итоге после вставки кода мы видим следующий шедевр:

OMG! Все словосочетания с Process подчёркнуты красным(ошибки). Исправляем! ПКМ по подчёркнутому тексту и выбираем "Разрешить" -> 1 пункт

После этого всё стало нормально, без ошибок

Тестируем:
Запускаем отладку:

Появляется окошко, как в визуальном редакторе (я его сделал таким):

Вводим в текстовое поле ваш ник и тапаем на кнопку(текст вы можете настроить в "Окне свойств")
В сингле проверим, с каким ником у нас запустилась игра:

Надеюсь вам понравился гайд

Часто задаваемые вопросы:

Q: Как открыть окно свойств?
A: "Вид"-"Другие окна"-"Окно свойств"

Q: Как поменять текст окна/кнопки?
A: Выделите в визуальном редакторе элемент, текст которого вы хотите заменить, в Окне свойств в строке "Text" меняете текст

Q: Почему на других компьютерах не работает программа?
A: Возможно у них не установлена версия Framework, на которой вы писали приложение(по умолчанию используется самая последняя установленная)

Q: Как собрать/скомпилировать?
A: "Проект" -> "Построить проект". Потом в "Мои документы"Visual Studio 2010\Projects\Имя_проекта\Имя_проекта\bin\Debug\Приложение.exe

Я поставил перед собой задачу воссоздания с нуля Minecraft за одну неделю с помощью собственного движка на C++ и Vulkan. Меня вдохновил на это Hopson, который сделал то же самое при помощи C++ и OpenGL. В свою очередь, его вдохновил Шейн Бек, которого вдохновила Minecraft, источником вдохновения для которой была Infiniminer, при создании которой, предположительно, вдохновлялись реальными горными промыслами.

Репозиторий GitHub этого проекта находится здесь. У каждого дня есть своя git-метка.

День 3

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

Граф рендеринга позволяет мне задавать узлы и рёбра. Узлы представляют собой выполняемую GPU работу. Рёбра — это зависимости данных между узлами. Каждый узел получает собственный буфер команд, в который выполняет запись. Граф занимается двойной буферизацией буферов команд и синхронизацией их с предыдущими кадрами. Рёбра используются для автоматической вставки барьеров конвейера перед и после того, как узел выполняет запись в каждый буфер команд. Барьеры конвейера синхронизируют использование всех ресурсов и переносят принадлежность между очередями. Кроме того, рёбра вставляют семафоры между узлами.

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

Движок имеет три типа узлов. AcquireNode получает образ из цепочки буферов (swapchain), TransferNode передаёт данные от CPU к GPU, а PresentNode предоставляет изображение цепочки буферов, которое нужно отобразить.

Каждый узел может реализовать preRender , render и postRender , которые выполняются в каждом кадре. AcquireNode получает изображение цепочки буферов во время preRender . PresentNode предоставляет это изображение во время postRender .

Я отрефакторил рендерер треугольников, чтобы он использовал систему графов рендеринга, а не обрабатывал всё самостоятельно. Существует ребро между AcquireNode и TriangleRenderer , а также между TriangleRenderer и PresentNode . Это гарантирует, что изображение цепочки буферов правильно синхронизировано в процессе его использования во время кадра.

Клянусь, внутри движок поменялся

Задачи

Разработка на Vulkan намного медленнее, чем на OpenGL, поэтому я не смог включить в игру многие функции настоящей Minecraft. Нет ни мобов, ни крафта, ни красного камня, ни физики блоков, и т.п. С самого начала цели проекта были следующими:

Создание системы рендеринга рельефа
- Мешинг
- Освещение
- Рельеф
- Деревья
- Биомы
Malmo: вывод

Авторы фреймворка подарили нам потрясающую возможность погрузиться в любимый мир с другой стороны. Malmo пока что находится в бете, во многих ситуациях он… заставляет совершенствовать свои навыки в troubleshooting. Тем не менее, его плюсы перевешивают все его минусы, а тот факт того, что исходники лежат в открытом доступе на github, позволяет нам самостоятельно доделать нужное место или создать issue для исправления критических багов.

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

День 2

Я интегрировал библиотеку Vulkan Memory Allocator. Эта библиотека берёт на себя большую часть бойлерплейта, связанного с распределением памяти Vulkan: типы памяти, кучи памяти устройств и вторичное распределение.

Теперь, когда у меня было распределение памяти, я создал классы для мешей и буферов вершин. Я изменил рендерер треугольников так, чтобы он использовал класс мешей, а не встроенные в шейдер массивы. На данный момент передача данных мешей в GPU выполняется рендерером треугольников вручную.

Изменилось немногое

День 1

Движок достаточно прост, чтобы поддерживать рендерер треугольников. Он имеет одно окно и игровой цикл, к которому можно подключать системы. GUI ограничен частотой кадров, выводимой в заголовок окна.

Проект разделён на две части: VoxelEngine и VoxelGame .

Программируем в мире Minecraft

Хабр, привет! Пока все обсуждают ИИ в мире Pacman, мы начнем делать свой ИИ в Minecraft с фреймворком Malmo от Microsoft Research. Pacman у нас тоже появится. Если вы любите кубический мир, или вам хотелось бы начать изучать искусственный интеллект, или у вас есть дети, с которыми вы не можете найти общие увлечения, или же вас просто заинтересовала тема – прошу под кат.

В этой статье я постараюсь затронуть несколько тем:
- Выскажу свое мнение о помешательстве детей на кубической игрушке
- Расскажу об основной идее Malmo
- Покажу несколько примеров с кодом и дам понимание, куда можно идти дальше
- Расскажу об идее и результатах Malmo Challenge
День 5

Я добавил ввод пользователя и возможность перемещения камеры при помощи мыши. Система ввода слишком переусложнена, но она устраняет странности ввода GLFW. В частности, у меня возникала проблема изменения позиции мыши при её блокировании.

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

Просто для сравнения — примерно то же самое Hopson сделал в день 1 своего проекта.

День 6

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

Одной из абстракций был шаблонный класс ChunkData<T, chunkSize> , определяющий куб типа T размером chunkSize по каждой из сторон. Этот класс хранит данные в 1D-массиве и обрабатывает индексирование данных с 3D-координатой. Размер каждого блока составляет 16 x 16 x 16, поэтому внутренние данные представляют собой простой массив длиной 4096.

Ещё одна абстракция заключается в создании итератора позиций, генерирующего координаты от (0, 0, 0) до (15, 15, 15) . Эти два класса гарантируют, что итерации с данными блоков выполняются в линейном порядке для повышения локальности кэша. 3D-координата по-прежнему доступна для других операций, которым она нужна. Например:

У меня есть несколько статических массивов, задающих смещения, которые обычно используются в игре. Например, Neighbors6 задаёт 6 соседей, с которыми куб имеет общие грани.

Neighbors26 — это все соседи, с которыми у куба общая грань, ребро или вершина. То есть это сетка 3x3x3 без центрального куба. Также есть подобные массивы для других наборов соседей и для 2D-наборов соседей.

Существует массив, определяющий данные, необходимые для создания одной грани куба. Направления каждой грани в этом массиве соответствуют направлениям в массиве Neighbors6 .

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

Я заменил TriangleRenderer на ChunkRenderer . Также я добавил буфер глубин, чтобы меш блока мог рендериться правильно. Нужно было добавить ещё одно ребро в граф рендеринга между TransferNode и ChunkRenderer . Это ребро передаёт владение ресурсами семейства очередей между очередью передачи и очередью графики.

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

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

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

Цепочку буферов невозможно создать, если размер окна равен 0 по оси X или Y. В том числе, когда окно свёрнуто. То есть когда такое происходит, вся игра ставится на паузу и продолжается, только когда окно разворачивается.

Сейчас меш является простой трёхмерной шахматной доской. Цвета RGB меша устанавливаются в соответствии с его позицией по XYZ, умноженной на 16.

День 7

Я сделал так, чтобы игра обрабатывала за раз не один, а несколько блоков. Множественные блоки и их меши управляются ECS библиотеки entt . Затем я отрефакторил ренедрер блоков так, чтобы он рендерил все блоки, находящиеся в ECS. У меня по-прежнему только один блок, но я мог бы при необходимости добавить новые.

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

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

Предыдущий буфер вершин невозможно удалить сразу же. Могут существовать буферы команд, выполняемые из предыдущих кадров, которые зависят от конкретного объекта VkBuffer . Движок должен хранить буфер, пока эти буферы команд не завершатся. То есть, если мы рисуем меш в кадре i , GPU может использовать этот буфер до начала кадра i + 2 . Буфер нельзя удалять из ЦП, пока GPU не завершил его использовать. Поэтому я изменил граф рендеринга так, чтобы он отслеживал срок жизни ресурсов.

Если узел графа рендеринга хочет использовать ресурс (буфер или изображение), то он должен вызвать метод sync внутри метода preRender . Этот метод получает указатель shared_ptr на ресурс. Этот shared_ptr гарантирует, что ресурс не будет удалён, пока выполняются буферы команд. (С точки зрения производительности, такое решение не очень хорошее. Подробнее об этом позже.)

Minecraft: моя предыстория

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

Для меня Minecraft стал продолжением любимой игрушки детства – Lego, исправив ее главный недостаток: постоянную нехватку деталей. Аналог Lego с безлимитными деталями, что может быть лучше.

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

У Minecraft очень размытое понятие финальной цели. Конечно, вы можете прокачаться и убить дракона, с гордостью сказав, что вы прошли игру. Но так никто не делает. Основной кайф мира Minecraft в том, что каждый раз в нем можно придумать свою личную цель: исследовать мир и найти пещеру с тайниками, построить дом своей мечты, изучить основы электричества или зайти на сервер вместе с другом и делать друг другу всевозможные ловушки. Отсутствие цели в игре – на мой взгляд, главное ее преимущество. Minecraft дает огромный простор для творчества, при этом почти не ставит ограничений.

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

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

Создание качественных сборок на маинкрафт [Guide]

Начнём пожалуй с того, что такое сборка в принципе. Изначально, когда сборки только зарождались, они были все однотипны. Так продолжалось вплоть до 1.4.7, когда был первый всплеск качественных сборок. Именно тогда моды начали интегрировать друг с другом. Не умело, пробуя перо, но интегрировать. Затем началась эпоха FTB , которая длится и по сей день, однако неумолиомо идёт на спад (фантан иссяк). Уже тогда сваливать моды в кучу стало дурным тоном. Не так давно, как вы наверняка знаете, вышла сборка Sevtech Ages от Darkosto . Она вывела сборки майнкрафт на совершенно другой уровень. Теперь, как вы понимаете, свалки модов не в почёте и если вы хотите создать достойную сборку, то вам придётся немало попотеть.

Итак. Какой же должна быть современная сборка? Попробуем разобраться в этом.

1) Нужно чётко определиться с жанром сборки. Будет ли это industrial, magic, magitech, AFN(all from nothing или всё из ничего), а может RPG.

Вы спросите. А как же SevTech? Ведь там есть и магия и технологии и приключения. Я вам отвечу. Это межжанровая сборка, но на её создание было убито огромное количество сил и времени! Да и делал её профессионал! Поэтому это исключение из правил и вам не стоит ровняться на этот стиль!

2) Вы должны… Нет… Вы ОБЯЗАНЫ идеально знать все моды, которые вы хотите включить в вашу сборку! Причём очень желательно хотя бы приблизительно понимать, как они работают (потом поможет избежать проблем в стиле «Я хотел сделать так, а оно работает не так, что делать?») Если вы ну совсем не можете читать исходный код, то рекомендую вам пройти майнкрафт с каждым из модов, которые вы хотите воткнуть в сборку по отдельности или сгрупировав их по 2-3 штуки (не считая JEI, WAILA, Minimap и т. д.)

Наверняка многие господа младше 14 лет начнут кричать «НО ВЕДЬ ЛОЛОЛОШКА ВСЕГДА ИГРАЕТ С МОДАМИ КОТОРЫЕ ОН ВООБЩЕ НЕ ЗНАЕТ И ЭТО КЛАССНО!». Забудьте о Роминых сборках. Этому есть несколько причин. Первая: он уже несколько лет на ютубе и может себе позволить халтуру, бо всё равно ведь схавают. Вторая: он развлекает аудиторию стримов и видосов, а не привлекает игроков. На его сборках играет меньше 5% его зрителей! Третья: вы даже не представляете, сколько работы он проводит, чтобы собирать такие гигантские сборки с НИКОМУ не знакомыми модами, чтобы было интересно!

3) Моды должны быть настроены и интегрированы. Не бойтесь отключать половину контента модов. Главное чтобы всё было гармонично и вписывалось в общую концепцию!

4) Если моды всем хорошо знакомы, то придумывайте игроку цели, которых трудно будет достичь!

5) Сборка должна быть оптимизирована. Желательно под максимум 4 ГБ ОЗУ

Что нам потребуется для создания качественной сборки:
1. Forge.
2. Exel (как бы это странно не звучало, но он вам очень пригодится для балансировки)
3. CraftTweaker с аддонами (менять рецепты, удалять предметы)
4. BetterFPS
5. FoamFix (желательно)
6. Если есть лицензия маинкрафт, то TwitchApp (ускорит процесс создания сборки в 1.5 раз)
7. JEI или аналог. Просто must have если открытие крафтов не является частью игрового опыта
8. 7-10 основных модов, которые игрок будет развивать в течении игры
9. Любой мод для добавления кастомных ачивок/квестов
Что не стоит добавлять в вашу сборку:
1. Optifine. Если вы будете выкладывать сборку с установленным оптифайном на Curseforge, Minecraft forrum и другие комьюнити сервисы, то вас могут забанить за нарушение авторских прав.
2. Better Foliage. Очень сильно нагружает видео карту и совместим не со всеми модами. Если добавляете, то отключайте в настройках по умолчанию всё, что только можно.
3. Greg Tech. Если вы не умеете читать код, то даже не пробуйте ставить этот лагодром в вашу сборку. Вы огребёте с ним огромное количество проблем!
4. Драконик. Я уже слышу, как рвёт пуканы у школьников. Драконик — ужасный и совершенно не сбалансированный мод! Если вы его ставите в сборку и он вам ну оооочень нужен, то усложните его до предела и вырежте из него все источники энергии (или сделайте их крафт настолько сложным, чтобы пролучить их можно было только в самом конце). Хороший пример интеграции этого мода — FTB Infinity Evolved
5. Моды аналоги. Например AE2 и RefindStorage.
Пожалуй на этом с вводной статьёй всё. Если она вам понравилась, но напишите в комментариях, о чём вы хотели бы прочитать. Я учту это при написании статьи — гайда.

День 4

Я создал камеру и систему 3D-рендеринга. Пока камера получает собственный постоянный буфер и пул дескрипторов.

В этот день я замедлился, потому что пытался найти подходящую конфигурацию для рендеринга 3D с помощью Vulkan. Большинство материалов онлайн посвящено рендерингу в помощью OpenGL, в котором используются немного отличающиеся от Vulkan системы координат. В OpenGL ось Z пространства усечения (clip space) задаётся как [-1, 1] , а верхний край экрана находится в Y = 1 . В Vulkan ось Z задаётся как [0, 1] , а верхний край экрана находится в Y = -1 . Из-за этих небольших отличий стандартные матрицы проецирования GLM не работают правильно, потому что они предназначены для OpenGL.

В GLM есть опция GLM_FORCE_DEPTH_ZERO_TO_ONE , устраняющая проблему с осью Z. После чего проблему с осью Y можно устранить простой сменой знака элемента (1, 1) матрицы проецирования (в GLM используется индексация от 0).

Если мы переворачиваем ось Y, то нужно перевернуть и данные вершин, потому что до этого отрицательное направление оси Y указывало вверх.

Теперь в 3D!

Malmo Challenge: история и результаты

Кроме самого фреймворка, Microsoft также проводил соревнование на базе платформы, названной Malmo Challenge. Оно было призвано побудить ученых и исследователей к работе над коллаборативными алгоритмами. Конкурс стартовал примерно полгода назад, а результаты появились 5 июня.

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

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

Эта задача в общем виде называется Охота на оленя. Она была сформулирована еще в 18 веке Жан Жаком Руссо. Несмотря на внушительный возраст проблемы, до сих пор неясно, какой алгоритм наиболее эффективно решает поставленную задачу.

Я рада поделиться с вами результатами соревнования. Меня очень удивило распределение мест в турнирной таблице.

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

Участники, занявшие второе место, решили взять самые сложные из существующих решений, они использовали DNN, Reinforcement learning, DQN, A3C model… И это все не помогло им обойти Байеса и Марковские цепи.

Подытожим статью мыслью о том, что нужно быть проще.

Видео с моим рассказом о Malmo на встрече Петербургского Python митапа уже появилось на моем канале на Youtube. Там также есть записи других моих лекций и прочая болтовня про IT.

Библиотеки

Разумеется, я не собирался писать Vulkan-приложение с нуля. Для ускорения процесса разработки я по возможности буду использовать готовые библиотеки. А именно:
Как ~~играть~~ программировать в Malmo

Основной процесс выглядит следующим образом: в одном окошке вам необходимо поднять сервер и клиента. Для этого есть скрипт ./Minecraft/launchClient.* . После того, как сервер поднялся, в другом окне вы можете запустить код с основной логикой для управления персонажем. Как узнать, что сервер поднялся? Все крайне логично: вы увидите запущенный экземпляр Minecraft с начальным меню внутри, а в терминале будет гордо красоваться надпись Building 95% .

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

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

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

Авторы позаботились о нас и сделали внушительное число примеров, добавив к ним описание.

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

И насладитесь первыми шагами своего героя. Учтите, что по умолчанию используется т.н. ContinuousMovementCommands. Воспринимайте отдаваемые персонажу команды как изменение положения рычага. Говоря "move 1" , вы сделаете не один шаг. Вы будете бежать, пока не дадите команду "move 0" . Такой код на практике не сдвинет человечка с места:

Команды выполнятся за считанные доли секунды. Не забывайте вставлять периодические строчки "time.sleep(X)" . Я уверена, что вы знаете, где брать информацию об остальных командах (хотя, по моему опыту, проще по диагонали просмотреть туториал и затем искать нужное в исходниках).

В xml файле вы можете задать режим игры:

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

Вот этот код нарисует вам Пакмана, который поедает шарики и уходит в радужный кратер:

Наконец, в xml можно добавить необходимые координаты для добавления обзора персонажу:

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

Мы получим массив со строками. Каждая строка – это текстовое представление типа одного из кубиков.

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

Фичи для ИИ

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

К сожалению, этого будет недостаточно. Чтобы двигаться дискретно, ваше начальное положение должно быть строго в центре кубика:

Целые координаты поставят вас в пересечение кубов, персонаж откажется двигаться с места, никаких предупреждений и ошибок вы не увидите. В туториале об этом также не предупреждают. Я потратила около 4 часов, чтобы осознать суть проблемы и сделать координаты x и z половинчатыми. (y отвечает за высоту и не играет роли в данной истории).

Кроме этого, исследователи добавили несколько приятных фич для решения задачи обучения с подкреплением (Reinforcement Learning). Алгоритмы этого типа подразумевают постоянное награждение или наказание искусственного интеллекта за те или иные действия. Разработчики продумали этот момент и добавили возможность прописать эти действия/события в xml, избавив код от постоянных одинаковых проверок. Вы также можете задать окончание игры по наступлению некоторого события:

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

Malmo: основная идея

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

Технические моменты

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

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

Читайте также: