Процедурная генерация и прочая математика

Открыл для себя доклады, которые Squirrel Eiserloh делал для математической секции GDC. Очень наглядно и доступно рассказывает о процедурной генерации, случайности и прочей математике.

Доклады:

• Процедурная генерация (смотреть по порядку): 1, 2, 3, 4, 5, 6
• Случайность основанная на шуме (например, Перлина)
• Работа с камерой
• Нелинейные преобразования
• Математика RGB(A)
• Матричные операции
• Генерация случайных чисел и шумов

Доклады о процедурной генерации особенно интересны.

Софт для «поддержки принятия решений»

Обновлено: исходники проекта открыты — https://github.com/Tiendil/morphologic

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

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

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

Софт может пригодиться, если вам необходимо найти решение / выбрать архитектуру / определить лучшее сочетание параметров в сложной и / или слабо формализированной области.Например, вы знаете, что решение может обладать свойствами A, B, C, D, … Z, но не знаете какое сочетание свойств будет оптимальным. При том, что A и D несовместимы, а сочетание свойств B+X+Y выглядит лучше, чем P+Q.

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

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

На странице софта есть более подробноее описание и инструкция.

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

Прототип:: https://tiendil.github.io/morphologic/

Группа в телеграм для обсуждения: https://t.me/morphologic_soft

Видео с изменениями карты мира «Сказки» с 2013 года

Смотреть лучше в максимальном качестве.

Карта изменяется динамически, исходя из действий игроков и своей внутренней логики.

По сути реализована небольшая модель формирования ландшафта с учётом климата и «точек влияния», контролируемых игроками.

Просчитываются и меняются: высота, температура почвы/воздуха, направление ветра, влажность, плодородность земли, типы растительности.

Поверх этого отображаются обобщённые биомы (пустыня, джунгли, горы, etc). Для каждой клетки выбирается биом, который лучше всего ей подходит.

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

Первый взгляд на LaTeX

Для личных нужд решил изучить эту штуку. Пока просмотрел только документацию, но определённое мнение сформировалось. Сейчас поделюсь.

Для затравки вот цитата из исследования эффективности MS Word & LaTeX.

We show that LaTeX users were slower than Word users, wrote less text in the same amount of time, and produced more typesetting, orthographical, grammatical, and formatting errors. On most measures, expert LaTeX users performed even worse than novice Word users. LaTeX users, however, more often report enjoying using their respective software.

An Efficiency Comparison of Document Preparation Systems Used in Academic Research and Development Markus Knauff*, Jelica Nejasmic.

Далее

Уникальные идентификаторы для связи исходников. Как?

Хочу странного, может подскажете способ сделать.

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

Фичей не в смысле больших user-story, а в смысле конкретных пунктов, реализацию которых надо контролировать. Например «имя гильдии должно быть уникально», «Это поле должно отображаться только залогиненому пользователю».

Фактически я уже так работаю, записывая каждую мелкую фичу в туду-листе и удаляя их по факту реализации. Не хочется, чтобы знания терялись. Логичный следующий шаг — хранить историю фичей и их реализации.

Вопрос вот в чём: как делать идентификаторы, которые будут связывать фичи с кодом?

Варианты, которые вижу:

1. Писать руками. Проблемы: геморрой и простор для ошибок/опечаток.
2. Плагин для emacs (любого другого редактора), который в файле с фичами генерирует уникальные идентификаторы, после чего копировать их куда надо. Проблемы: его надо сделать, нужно поддерживать уникальность между файлами, хочу фичи не только в отдельном файле, но и в коде, если это будет удобно.
3. Литературное программирование: писать фичу сразу там, где реализуется. Проблемы: фича реализуется в нескольких местах (код, тесты, вёрстка, документация), поэтому идентификаторы всё равно нужны.
4. Идентификатором делать сам текст фичи. Проблемы: занимает много места, текст может меняться и будет геморойно менять его везде.