Тарантога: мемплексы
Про метаинформацию поговорили, теперь можно поговорить и про тексты. Затронем в том числе и поднятый в предыдущем эссе вопрос: является ли текст отдельной сущностью или утверждением метаинформации.
По названию поста уже можно сделать вывод, что говорить мы будем не совсем про тексты, но давайте не забегать вперёд.
Сначала определимся с тем что такое текст.
Я немного схитрил в предыдущих постах, когда говорил, что экзокортекс управляет текстами. Важны не только тексты, но и картинки, видеоролики, звукозаписи, чертежи и так далее.
Поэтому под текстами я имел в виду не «последовательность символов», а скорее «текстовый документ», который может содержать разнородную информацию, включающую и сам текст и какие-то медиа-объекты.
Далее под текстом я буду понимать именно «текстовый документ», если явно не будет указано обратное.
Экзокортекс: метаинформация
Прежде чем собирать что-то работающее, следует разобраться с центральным элементом всей системы — информацией, которой она управляет. В этом посте я поговорю про метаинформацию текстов, а в следующем про них самих.
Но сначала внесём некоторую ясность в терминологию. Я тут пишу «экзокортекс то», «экзокортекс сё», но ведь софт, о котором я говорю, является только частью экзокортекса. Говорить про него как про целый экзокортекс в корне неправильно. Это, в конце-концов, путает.
Поэтому софту нужно отдельное название: Тарантога. В честь известного профессора. Сначала я думал назвать его Ийоном, но пришёл к выводу, что оригинальный Ийон имеет довольно посредственное отношение к управлению информацией, в отличии от его известного друга. При этом контекст этих персонажей хорошо соответствует уровню бреда, который может породить подобная система.
Напомню примерный перечень метаинформации из описания минимальной функциональности Тарантоги:
- Уникальные сущности, которые упоминаются в тексте: компании, продукты, персоны, географические объекты, события.
- Источник текста: полный url, идентификатор источника (например, «Хабр»).
- Тип текста: комментарий, пост, etc.
- Характер текста. На Хабре это может быть «урок», «перевод».
- Темы текста. Можно определить по хабу на Хабре, разделу форума или упоминаемым сущностям.
- Время создания, обновления.
Процедурная генерация и прочая математика
Открыл для себя доклады, которые Squirrel Eiserloh делал для математической секции GDC. Очень наглядно и доступно рассказывает о процедурной генерации, случайности и прочей математике.
Доклады:
- Процедурная генерация (смотреть по порядку): 1, 2, 3, 4, 5, 6
- Случайность основанная на шуме (например, Перлина)
- Работа с камерой
- Нелинейные преобразования
- Математика RGB(A)
- Матричные операции
- Генерация случайных чисел и шумов
Доклады о процедурной генерации особенно интересны.
О книге «Геймдизайн»
«Если вы хотите сделать игру, которая завоюет сердца миллионов и принесёт вам доход, эта книга для вас» — надпись на обложке. Нет. Всё-таки нет. Если вы хотите вот всё это и вообще не понимаете что вокруг происходит, то начать с этой книги будет хорошей идеей, но никаких прорывных идей вы в ней не найдёте.
Джесси Шелл проделал хорошую работу по сбору и переработке информации из множества источников, собрав хорошее «введение в профессию геймдизайнера» и, одновременно, справочник по этой профессии.
Для новичков книга полезна освещением геймдизайна с разных сторон. Но далеко не со всех, например, практике расчёта баланса она не учит.
Для профессионалов — это отличный справочник по узкоспециализированной литературе. Каждая глава заканчивается небольшим списком источников, которые позволят глубже проникнуть в тему. В списке бывают как книги, так и статьи. Если судить по названиям, то многие тексты выглядят стоящими.
Уникальные идентификаторы для связи исходников. Как?
Хочу странного, может подскажете способ сделать.
Итак, хочу вести список фичей (в репозитории, рядом с исходниками) и когда пишу логику (тесты, документацию, вёрстку) иметь возможность поставить какой-то идентификатор рядом с реализацией (тестом, документацией, вёрсткой). Дескать вот тут реализуется (тестируется, документируется, отображается) именно эта фича. И потом по этим кроссылками генерировать всякую полезную аналитику.
Фичей не в смысле больших user-story, а в смысле конкретных пунктов, реализацию которых надо контролировать. Например «имя гильдии должно быть уникально», «Это поле должно отображаться только залогиненому пользователю».
Фактически я уже так работаю, записывая каждую мелкую фичу в туду-листе и удаляя их по факту реализации. Не хочется, чтобы знания терялись. Логичный следующий шаг — хранить историю фичей и их реализации.
Вопрос вот в чём: как делать идентификаторы, которые будут связывать фичи с кодом?
Варианты, которые вижу:
- Писать руками. Проблемы: геморрой и простор для ошибок/опечаток.
- Плагин для emacs (любого другого редактора), который в файле с фичами генерирует уникальные идентификаторы, после чего копировать их куда надо. Проблемы: его надо сделать, нужно поддерживать уникальность между файлами, хочу фичи не только в отдельном файле, но и в коде, если это будет удобно.
- Литературное программирование: писать фичу сразу там, где реализуется. Проблемы: фича реализуется в нескольких местах (код, тесты, вёрстка, документация), поэтому идентификаторы всё равно нужны.
- Идентификатором делать сам текст фичи. Проблемы: занимает много места, текст может меняться и будет геморойно менять его везде.