Как придумать подземелье

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

Чтобы никто не ушёл обиженным, вот небольшой набор рекомендаций на тему. Рекомендации подойдут не только для подземелий, но и для разработки любой локации.

Дополнительно советую почитать:

• О создании названий
• О проектировании миров
• Следующий фронтир геймдизайна

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

Далее

Типы в Python не радуют

Сделал ещё один заход на контроль типов в Python. На этот раз со стороны собственной библиотеки для контроля изменений типов переменных в runtime.

Общие выводы ясны из названия поста, хотя полученная библиотека более-менее работает и я попытаюсь её со временем довести до ума. Если разработчики Python наведут порядок у себя в проекте.

Задумка

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

Краткое обоснование:

1. Важная часть семантики программы на динамическом языке программирования конструируется во время выполнения программы.
2. Поэтому закодировать её статически не получится — сложно и дорого.
3. Поэтому статический анализ типов для динамических языков не пригоден — он игнорирует критические части логики и провоцирует разработчиков на создание костылей для обхода этого игнорирования.
4. Поэтому анализировать типы имеет смысл только время выполнения программы.

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

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

Библиотеку для такой функциональности я и попытался реализовать, но столкнулся с суровой реальностью.

Далее

Больше новостей о процедурной генерации

На этот раз Open AI рассказали о новой нейронке (на русском) а-ля GPT-3, но для изображений. Пример её работы можно видеть на заглавной картинке. Изображения сформированы для фразы «A capybara made of voxels sitting in a field» (капибара из вокселей, которая сидит в поле).

На странице с анонсом можно посмотреть другие примеры работ, включая разные способы изображения (3D рендер, изометрию, низкополигональные модели, etc).

Результаты, конечно, кривоваты. Но, надо учесть два нюанса:

• Это первый подход к подобной архитектуре с подобными деньгами.
• Это сеть общего назначения, не натасканная на геймдев.

А вот если бы её допилить, специализировать на фэнтези, да подключить к Сказке… Но у меня столько денег нет :-) А у кого-нибудь обязательно найдутся.

Постепенно вырисовывается новый пайплайн для арта:

• нейронка для постановки задания;
• нейронка для генерации контента;
• нейронка для устранения неточностей на картинке;
• нейронка для стилизации;
• нейронка для вылизывания;
• нейронка для выделения 3D меша;
• нейронка для оптимизации меша;
• нейронка для анимации;

Интеграция контента, позиционирование камер, цвет, свет, звук и прочее — тоже нейронки. Ну вы поняли :-D

Товарищи, которые научатся делать эти лопаты, сорвут большой куш.

Поругайте (или похвалите) меня

Но лучше всё-таки поругайте. Похвалить я и сам могу ;-)

Бложику нужна обратная связь от читателей.

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

А, и самое главное — блог читают о_О Привет читатели!

Чтобы и мне и бложику развиваться дальше, необходимо исправлять слабые места и находить новые возможности. Некоторые вещи я вижу, но определённо не все и не в том свете, в котором видите вы.

Поэтому я буду очень благодарен за пару слов с критикой или советами от вас мне:

• как сделать бложик лучше;
• как не сделать хуже;
• о чём писать, о чём не писать;
• и так далее…

Пишите где вам удобно: в комментариях к посту, в телеграмме, в facebook, на почту, etc.

Заодно, принимаю заказы на посты. Пишите интересующие вас темы, постараюсь их раскрыть, если получится :-)

Пространство механик ММО

Давно крутил в голове формальный подход к выбору механик для ММО, но чего-то не хватало. Спасибо дискуссии на mmozg.net — нашёл недостающую размерность.

Идея в следующем.

Чтобы игра была долго интересна целевой аудитории, её механики должны закрывать некоторый набор потребностей игроков.

Самый простой пример — психотипы Бартла. Планируя механики для игры, необходимо позаботиться, чтобы они закрывали потребности каждого психотипа. В идеале. То есть нужны механики для achievers, killers, socializers и explorers. Не обязательно по одной на каждый тип. Можно по несколько, а можно и так, чтобы одна механика закрывала несколько типов.

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

Мне же интересно посмотреть на сами механики, динамику игры и именно в контексте ММО. Безотносительно свойств самих игроков.

Поэтому я попробовал представить игровые механики как объекты в многомерном пространстве (механик) и выделить в этом пространстве ортогональные оси.

Далее