Как клиент, пытающийся заставить программиста / программиста развить мои идеи в работающую программу, что я должен предоставить своим разработчикам?

Я директор группы по разработке игр для начинающих (я говорю «группа», потому что она еще не является официальной компанией). Недавно я получил готовность нескольких программистов, которые готовы помочь мне с проектом, но они запрашивают документацию.

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

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

Я знаю, что у меня здесь много вопросов. Я надеюсь, что это не проблема. Заранее спасибо за любые рекомендации!

Разработка игр обычно работает немного иначе, чем разработка приложений. Причина в том, что игры обычно предъявляют гораздо меньшие и гораздо менее строгие требования. У вас нет четко определенной бизнес-проблемы, которую должно решать ваше программное обеспечение. Единственные настоящие требования к игре - «правильно работает на целевой платформе», «апеллирует к целевой демографии» и «интересно играть» (и, возможно, «продает много микротранзакций», если вы находитесь в этом разделе индустрии ). Все остальное может быть изменено в процессе разработки.

Однако, чтобы убедиться, что все разработчики игры работают в одном направлении и не заканчивают борьбой до смерти из-за творческих различий, у вас должно быть некоторое кодифицированное «видение» того, как вы хотите, чтобы финальная игра выглядела и играла , Это видение обычно кодифицировано в Документе по дизайну игры . Такой документ обычно описывает:

• Основная предпосылка игры:
  • Шаг лифта : Основная идея игры, описанная как кратко , насколько это возможно.
  • Какой жанр игры?
  • Кто является вашей целевой аудиторией?
  • На какую платформу (ы) вы нацеливаетесь?
• Механика игры:
  • Какие действия может выполнять игрок в этой игре и как они влияют на игру?
  • Какие неигровые объекты присутствуют в игре, как они ведут себя и как они взаимодействуют друг с другом и с игроком?
• Область применения:
  • Сколько контента вы хотите иметь в игре?
  • Какой уровень качества вы хотите, чтобы этот контент был?
• Эстетическое направление игры:
  • Какую общую атмосферу вы хотите, чтобы игра была?
  • Как вы хотите, чтобы игра выглядела?
  • Как вы хотите, чтобы игра звучала?
• Когда дело доходит до истории, это во многом зависит от жанра. Некоторые игры вообще не нуждаются в истории. Многим играм нужно всего несколько предложений. Но если вы создаете игру, основанную на сюжете, например, RPG или приключение, то это может быть самой длинной частью проектного документа и может включать:
  • Описание мира, в котором происходит игра, и ее ключевых мест
  • Описание важных персонажей, их внешности, их личности и их предыстории
  • Основная схема сюжета, который рассказывается во время игры

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

Тем не менее, будьте открыты для изменений в процессе разработки. Когда документы по дизайну популярных игр становятся достоянием общественности, преднамеренно или непреднамеренно, вы обычно можете заметить что-то интересное. Если вы сравните эти ранние заметки о дизайне с готовой игрой, то, как правило, будет много существенных отличий. Обычно это результат процесса разработки игры, называемого Fail Faster :

1. Придумать грубый дизайн
2. Создать простой прототип
3. Проиграйте его с критическим мышлением и выясните, что с ним не работает
4. Пересмотрите свой дизайн
5. Вернуться к этапу 2

Так что не бойтесь менять или сокращать функции, когда вы понимаете во время игрового тестирования, что они на самом деле не такие забавные, как в вашей голове. Также будьте открыты для предложений от команды. Большинство людей в индустрии разработки игр решили присоединиться к этой отрасли, потому что они хотят реализовать свои идеи на практике. Поэтому предоставление вашей команде творческого влияния может стать для них отличным мотиватором. Но, как хороший продюсер, вы также обязаны сказать "Нет!" если вы думаете, что идея не будет работать или превысит бюджет.

Я с нетерпением жду возможности сыграть в вашу игру.