Разобравшись, чем же мы будем заниматься в пункте Постановка задачи, пойдем дальше. Этап Выбор инструментов пропустим, поскольку подробные пояснения здесь пока не требуются. Перейдем сразу к Проектированию, и попутно затронем Создание кода.
Сразу же оговорюсь, что все нижеизложенное - это лишь обзор того, с чем нам придется иметь дело. Проектирование - слишком сложная тема, чтобы целиком охватить даже то, что я уже знаю, в одном посте. А того, чего я не знаю - гораздо больше.
Так что многое здесь может быть непонятно, и это нормально, если вы новичок в какой-то из затронутых здесь областей. В свое время я обязательно вернусь ко всем моментам, которые вскользь затронул в этом посте и подробнее расскажу о них. А пока я могу посоветовать не терять времени даром и, прежде чем появится следующий мой пост, попробовать самостоятельно поискать дополнительную информацию по затронутым ниже темам.
Предмет беседы
Прежде всего уточним, что вообще мы подразумеваем под термином "проектирование"? Очевидно, что это некая деятельность по составлению проекта программы (в нашем случае - игры), то есть описания того, как она будет устроена и как должна работать. Но как конкретно должен выглядеть готовый (о том, насколько вообще применимо здесь это слово - ниже) проект и каким образом мы его получим?
Прежде всего мы разбиваем всю программу на отдельные самодостаточные части и определяем, как они взаимодействуют друг с другом. Выделив и описав каждую такую часть, мы затем берем их все по очереди и проделываем то же самое с каждой из них - разбиваем на составляющие, и затем описываем как каждую из этих составляющих, так и взаимодействие между ними.
По аналогии с тем, как конечным продуктом Постановки задачи был документ, являющийся исчерпывающим руководством к действию для команды разработчиков, можно с некоторой долей условности сказать, что готовый проект - это исчерпывающее руководство к действию для программиста. Хотя на самом деле программист подключится к работе гораздо раньше, чем мы составим уже готовый проект. И вообще, программирование и проектирование к тому моменту у нас будут давно идти вместе и будут сильно зависеть друг от друга.
Но вообще - да, программист потом будет просто воплощать то, что написано в проекте. Даром что сам проект составлялся на основе того, что до этого писал тот же самый программист.
Разделяй и властвуй
Почему мы вообще разбиваем общую систему на отдельные подсистемы? Просто потому, что описать в мельчайших подробностях всю систему разом не представляется возможным - она слишком сложная.
В качестве примера рассмотрим отвлеченную сверхзадачу - описать вашего соседа на субатомном уровне. Понятно, что в лоб с этим вопросом не справиться (решить волновые уравнения для 10^28 атомов в принципе невозможно за время существования Вселенной), но мало-мальски приемлемое решение все же существует.
Достаточно представить человека как иерархическую структуру - совокупность биологического организма и психологии. Организм сводится к сумме систем органов, те - к отдельным органам, затем к тканям, клеткам, наконец переходим к молекулярным структурам. Психологию можно описать через работу мозга и его отдельных структур, затем перейти к нейрофизиологии и биохимии, к физическим процессам передачи электрических импульсов... Задача все еще непосильная для одного человека, но для всего человечества за разумное по геологическим масштабам время - более чем!
Однако, довольно лирики, вернемся к проектированию программ, и игр в частности. Осознав сложность системы в целом, мы разбиваем ее на независимые подсистемы, каждая из которых будет проще исходной системы. Затем их также разбиваем на части - и так до тех пор, пока не получим фрагменты, которые уже легко сможем реализовать без необходимости дальнейшего упрощения. Это, кстати, и есть канонический принцип "Разделяй и властвуй".
Но чтобы этот принцип работал, части, на которые мы разбиваем ту или иную систему, должны быть, во-первых, действительно независимыми друг от друга, и во-вторых, выполнять какую-то четко определенную задачу. Они должны работать по принципу черного ящика - никто извне не знает, как все устроено внутри, но все знают, для чего они используются, и что будет, если нажать вот на эту кнопку. Применительно к программам это означает, что другим системам мы предоставляем только внешний интерфейс, который они и используют, а к деталям реализации доступа они не имеют.
Благодаря этому мы и можем потом рассматривать каждую подсистему как самостоятельную систему, которую тоже можно эффективно разбирать на более мелкие части.
Когда мы разбили какой-то элемент программы на отдельные фрагменты, самой важной частью работы становится установление взаимосвязей между ними. Если каждый фрагмент работает как надо, это вовсе не означает, что свалив их все в беспорядке в одну кучу, мы получим работающую программу. Готовые элементы еще нужно правильно собрать в одну систему.
Связи и зависимости подсистем друг от друга определяют их внешний интерфейс, а также то, как именно они взаимодействуют друг с другом.
Создавая интерфейс (то есть набор доступных пользователю функций, классов и т.п.), важно не добавлять какие-то возможности "чтобы было" в надежде, что когда-нибудь они кому-то понадобятся (подобная идея лежит в основе принципа YAGNI - You Ain't Gonna Need It, "Вам это не понадобится"). Некоторые возможности могут оказаться совершенно невостребованными в реальности, но при этом не только отнимут время на их реализацию, но и могут наложить неприятные ограничения на систему, что приведет к никому не нужному усложнению и снижению полезности системы. Гораздо легче добавить вновь понадобившуюся функциональность, чем выкинуть не пригодившиеся возможности и затем "починить" систему, избавив ее от старых ограничений.
То, как именно будут взаимодействовать подсистемы, поможет лучше описать каждую из них. Описание, для чего та или иная часть используется, является хорошим дополнением к описанию того, что она из себя представляет.
User story и Epic story
Хорошим подспорьем в описании того, как система будет использоваться, представляют так называемые user story (пользовательские истории, они же - примеры использования). Они представляют из себя конкретные сценарии применения системы, выраженные либо с помощью бытовой лексики, либо в терминах конкретной прикладной области, в которой она и будет работать. То есть user story пишется на языке, наиболее понятном и характерном для конечного пользователя (человека, если мы говорим о программе, либо другой системы, если мы говорим о библиотеке).
К примеру, user story для игры обычно являются частью ее диздока (зачастую в неявном виде).
Использование этих историй помогает лучше понять, для чего и как именно будет использоваться та или иная часть программного продукта. На их основе можно составить список необходимой функциональности, ввести ограничения на некоторые параметры (например, характеризующие быстродействие или удобность), выделить отдельные подзадачи, которые затем можно реализовать в отдельных подсистемах.
Существует разновидность пользовательских историй, называемая epic story. Если user story может описывать отдельные аспекты использования системы или ее части, то эпик характеризует в общих чертах главную цель, преследуемую при использовании системы целиком.
Например, для моего проекта эпик можно сформулировать так: "Ведя проект, я буду писать игру и описывать процесс ее создания, что повысит мои навыки игростроения, поможет мне создать себе некоторую репутацию и сформирует своеобразный учебник геймдева для начинающих". При этом можно выделить отдельные user story, такие как "По мере работы над проектом я буду публиковать посты на своем сайте, в которых буду описывать свои наработки, проблемы и методы их решения, что поможет мне собрать фидбек, сделать себе репутацию и представит наглядное учебное пособие для посетителей сайта". При этом такая отдельная user story проекта может служить epic story для сайта проекта.
Во второй части мы продолжим разбор проектирования, и рассмотрим наконец архитектуру именно игровых приложений. Также мы добавим долю реализма в идеальный план "составить проект и по нему написать код" и обсудим, как можно подготовить свое приложение к возможным изменениям (которые неизбежно приходится вносить на всех этапах разработки).