Начались занятия в Product Vision Masters и оказалось что сходу сложно разделять понятия из заголовка. А без этого возникает путаница: не ясно о чём говорим, какое утверждение к чему относится и на что влияет.
Давайте разберёмся.
Продолжение жизни и работы с ошибками — обсудим штуки на уровень выше.
Эссе получилось большим, но точно найдутся упущенные моменты. Если я что-то забыл — пишите. Буду благодарен и за более интересные примеры.
Итак. Давайте подумаем, как мы предсказываем будущее всякое.
Предсказаниями мы занимаемся постоянно — это буквально суть нашего существования:
Это примеры «гарантированных» предсказаний, но даже они могут не исполнится:
Фактически, мы никогда не знаем актуальное состояние мира вокруг нас:
Мы даже не обладаем всей информацией о прошедших событиях.
Поэтому.
Каждое наше решение и действие основывается на предположениях о прошлом, настоящем и будущем.
Штуки, которыми мы создаём предсказания, называются моделями.
Расскажу об одной боли при разработке и проектировании ПО — преобразованиях данных между их схемами. Буду говорить о серверах, как наиболее наглядном и знакомом мне примере, но соображения можно распространить на весь софт.
Для демонстрационных целей местами может случиться некоторое преувеличение.
Рассмотрим простейший проект, этакий минимальный набор:
Данные, соответственно, ходят в обе стороны:
Сколько схем данных вы тут видите?
В пост о генерации подземелий часто приходят люди, которые ищут урок по придумыванию подземелья, а не по программированию. Для партии в D&D, например.
Чтобы никто не ушёл обиженным, вот небольшой набор рекомендаций на тему. Рекомендации подойдут не только для подземелий, но и для разработки любой локации.
Дополнительно советую почитать:
Последнее эссе больше о дизайне компьютерных игр, но содержит несколько важных соображений, которые я в дальнейшем буду использовать.
Давно крутил в голове формальный подход к выбору механик для ММО, но чего-то не хватало. Спасибо дискуссии на mmozg.net — нашёл недостающую размерность.
Идея в следующем.
Чтобы игра была долго интересна целевой аудитории, её механики должны закрывать некоторый набор потребностей игроков.
Самый простой пример — психотипы Бартла. Планируя механики для игры, необходимо позаботиться, чтобы они закрывали потребности каждого психотипа. В идеале. То есть нужны механики для achievers, killers, socializers и explorers. Не обязательно по одной на каждый тип. Можно по несколько, а можно и так, чтобы одна механика закрывала несколько типов.
Но психотипы относятся в первую очередь к игрокам, а не к самим механикам. В конце концов возможна игра только для исследователей, почему бы ей не быть?
Мне же интересно посмотреть на сами механики, динамику игры и именно в контексте ММО. Безотносительно свойств самих игроков.
Поэтому я попробовал представить игровые механики как объекты в многомерном пространстве (механик) и выделить в этом пространстве ортогональные оси.