Считаем бизнес-план для игры в Steam

Когда выкладывал отчётную презентацию (слайды) по World Builders 2023 (мои посты, сайт), обещал рассказать как делал roadmap и финансовую модель для игры. Выполняю обещание.

К концу поста у нас на руках будут:

• Краткая стратегия нашей компании: что мы делаем, как, зачем и почему.
• Табличка наших маяков — успешных игр, которые примерно похожи на то, что мы хотим сделать. Похожи как по геймплею, так и по размеру команды, бюджету, etc.
• Состав команды, которую нам надо собрать.
• Roadmap — план разработки нашей игры.
• Зачатки маркетинговой стратегии.
• Финансовая модель — сколько мы будем тратить, сколько зарабатывать.
• Огромное количество моих оговорок по всему посту.
• Шутки и прибаутки.

Все итоговые документы вы можете найти тут.

Далее

Вымышленная вселенная, сеттинг, произведение — в чём разница?

Начались занятия в Product Vision Masters и оказалось что сходу сложно разделять понятия из заголовка. А без этого возникает путаница: не ясно о чём говорим, какое утверждение к чему относится и на что влияет.

Давайте разберёмся.

Далее

Feature Programming

Эссе по итогам нырка в Deep Learning, но не о DL и даже не совсем о Machine Learning, а о новой парадигме программирования, которая рождается из него.

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

В следствие выбранной темы, эссе получилось футурологическим и абстрактным. Например, я не буду перечислять области применения DL и достигнутые в них результаты — этим итак всё инфопространство забито.

Оговорка раз: я определённо не эксперт в машинном обучении. Эссе в большей степени отражает мой опыт и картину мира, нежели знания и понимание ML и DL.

Оговорка два: термины «признак», «feature» будут использоваться достаточно вольно.

Далее

Бесконечность схем данных

Расскажу об одной боли при разработке и проектировании ПО — преобразованиях данных между их схемами. Буду говорить о серверах, как наиболее наглядном и знакомом мне примере, но соображения можно распространить на весь софт.

Для демонстрационных целей местами может случиться некоторое преувеличение.

Рассмотрим простейший проект, этакий минимальный набор:

• один тип клиентов;
• один сервис;
• одно хранилище.

Данные, соответственно, ходят в обе стороны:

• между клиентом и сервисом;
• между сервисом и хранилищем.

Сколько схем данных вы тут видите?

Далее

Боты и твинки в играх

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

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

Поскольку область большая и непроработанная, описывать направления буду разными способами: часть — высокоуровневыми соображениями, часть — декомпозицией на частные случаи. Где смогу, буду приводить примеры, но будут и места с вопросами и догадками. Сосредотачиваться на конкретном жанре также не буду — поговорим о многопользовательских играх во всём их разнообразии.

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

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

И будьте осторожны, очень много букв.

Далее