Python & OpenAPI

Покопался в OpenAPI и его интеграции с Python. Глубоко не лез — только чтобы закрыть собственные вопросы.

OpenAPI — спецификация API web-сервисов, выросшая из Swagger — описывает свойства API, чтобы по описанию генерировать документацию, клиентские и серверные библиотеки.

Swagger — проприетарная штука, OpenAPI — открытая. Поэтому сам Swagger я не смотрел — в наше время не стоит завязываться на такое, если у вас нет мешка с деньгами и вагона с юристами.

Также не смотрел интеграцию OpenAPI с другими языками. Где-то всё будет лучше, где-то — хуже. Думаю, лучше всего поддерживаться OpenAPI должно для JavaScript, так как фронтендерам оно больше всех пользы несёт.

Далее, тезисно, моё мнение.

Далее

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

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

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

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

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

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

Далее

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

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

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

Задумка

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

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

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

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

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

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

Далее

Франшиза кружков черчения

Дарю идею для стартапа. Практически голубой океан, как минимум на пост СССР.

Надо делать франшизу кружков черчения.

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

Смотрите:

• Предмет черчения теряет свою направленность на выработку прямых инженерных навыков — уже никто не чертит на бумаге.
• Поэтому его убирают из школ и универов.
• В то же время огромное количество людей имеет положительное мнение о черчении, как занятии, и считает, что полезные навыки оно развивает.
• Фактически, у черчения на пост СССР сейчас репутация примерно как у каллиграфии среди японских ниндзя. Только черчение — более современная дисциплина.
• Продукты черчения выглядят круто, элитно, это практически картины. Их можно в рамках на стены вешать.
• Совершенствоваться в черчении можно очень долго. Это позволяет как делать разноуровневые кружки, так и проводить соревнования.
• Черчение имеет за собой сложную традицию: стандарты, подходы, «школы».
• Черчение требует дорогих и пафосных инструментов: циркули, фигурные линейки, кульманы, лампы. Уголок для черчения в доме однозначно добавит понтов хозяину.
• Черчение требует расходников: грифели, стёрки, различная бумага.
• Преподаватели черчения остаются не удел — это готовые мотивированные сотрудники.

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

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

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

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

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

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

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

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

Далее