Итак, решено создать игру. Игра - програмнное обеспечение, а потому, как и для любого другого ПО, для успешного завершения проекта необходимо обозначить цели его создания, желаемый конечный результат, обозначить план разработки и круг обязанностей участников.
Очень важно понимать - без чётко обозначенных целей проект не может существовать. Причин тому несколько:
- Feature creep - цели должны ограничивать вашу команду от желания добавлять то, что в общем-то не очень нужно, но было бы неплохо. Надо понимать, что сложность добавления чего-либо нового возрастает с увеличением количества строк кода (по какой функции, зависит от архитектуры - может и по экспоненте, может и по сублинейной), следовательно, добавляя что-то "не из спецификации" вы не просто задерживаете добавление запланированных вещей, но делаете это сложнее. Это абсолютно не значит что вы должны сесть и написать свою "ECMA 333" а потом методично её реализовывать. Это просто значит что в команде должен быть один центр принятия решений (в нашем случае просто человек), который определяет, что должно оказаться в конечном продукте, а что - нет.
- Code churn - программисты известны своей любовью к чистому, понятному, производительному коду. К сожалению, любой код имеет срок годности - от нескольких часов до нескольких недель - после которого он уже перестаёт быть таким уж и простым, проседает по эффективности, страдает от недостатка комментариев, переусложнённой структуры. Иными словами, он становится "legacy" - старым, пыльным закоулком вашего репозитория который по-хорошему надо бы почистить и заменить новыми, чистыми, понятными, оптимизированными строками... Если у ваших программистов нет конкретной задачи но есть много мотивации (вы написали в спецификации "сделайте мне хорошую программу!"), они скорее всего будут "полировать" одни и те же файлы пока мотивация не иссякнет (это просто человеческая природа - мы любим чтобы было хорошо и не любим чтобы было плохо). Ваш покорный слуга особенно сильно страдает этим недугом, так что - watch out!
- Альтенативно, если вашей команде непонятно, что делать, она не будет делать ничего. Может показаться, что в нашем случае это не актуально, но мы люди занятые, времени у нас от силы два часа в день, а потому и приниматься за "создание игры" намного сложнее чем за "реализацию градиента для этой анимации".
Что ж, соглашаетесь вы, конечно, надо писать спецификацию. Но как? Вот несколько guidelines (советов):
- Может показаться, что спецификация - это обязательно такой большой документ. Это не так, часто вполне можно обойтись отдельными, маленькими документиками (мы, скорее всего, будем использовать issues на GitHub, но об этом далее). К примеру:
| Плохо | Хорошо |
|---|---|
| В нашей игре должна быть анимация столкновения столкновения снарядов с целью | В нашей игре должна быть анимация столкновения столкновения (снежинок, карандашей) с (нерадивыми студентами, гранитом знаний) с (эффектом застревания снега в одежде, эффектом и звуком слома карандаша) |
- Очень часто, в процессе реализации оказывается что "что-то идёт не так". Чтобы избегать этого следует разделять дизайны на "в разработке" и "основополагающие". По первым, ответственный за их реализацию человек должен иметь как можно больше возможностей для эксперимента и доработки идеи до рабочего состояния (или отказа от неё). Вторые же являются обязательными для выполнения "как есть" - в нашем случае это сама концепция игры, технологическая платформа (движок), её основные механики и стиль анимации. Наличие "окончательных" дизайнов также позволяет избегать "analysis paralysis" - ситуации, в которой команда не может решить, что она хочет. Это делает такие документы обязательно более высокоуровневыми, опирающимися на опыт конечного пользователя а не на детали реализации (это - та часть спецификации, где можно писать "будет синее небо с летающими книгами-пеликанами") а также обязательными с самого начала.
- Как часть этой выскоуровневой спецификации обязательно должна быть обозначена конечная стадия продукта, то есть критерии, по которым можно будет однозначно определить, завершён ли проект или нет.
- Есть такой репозиторий - dotnet/designs, в котором создатели .NET хранят спецификации для различных новых возможностей платформы (к примеру, Serializer Goals). Мы не организация из 100 человек - нам не нужен будет такой уровень качества или детализации, но этот репозитрий - хорошая коллекция хороших примеров.
Продолжение следует.