План разработки игры
Для первой игры про шарик нам нужны:
- Игровой дизайнер (ГД - это вы)
- Level Designer (Вы сами будете расставлять объекты и думать как левел дизайнер)
- 3D Artist (тот кто моделирует. Я для всех игр сделаю модели.)
- 2D Designer (будет рисовать ГУИ - в этой роли вы сами)
- Sound Designer (подбирает звуки и музыкальное оформление - я всё подберу, но вы можете и сами)
План разработки - это понятный для каждого человека из команды список действий. Если один человек из команды что-то не понимает, он тормозит всю команду!
ГД пишет план в диз-доке.
Для каждой игры и для каждого состава разработчиков - план свой. Лучше не копировать, а заново писать. В плане должны быть минимум 3 этапа: прототип, наполнение контентом и релиз.
1 этап - Прототип игры
2 этап - Наполнение контентом / Детализация
...
3 (последний) этап - Тестирование / Релиз
До того, как делать прототип игры, должны быть готовы все механики и протестированы на комфортность. Всё это делается на Игровой Площадке (PlayGround). Игровая площадка - это не игра, это тестовая локация с повторяющимися элементами. Для нашей первой игры про шарик, нужно протестировать размер шарика и отдаленность от него камеры, скорость перемещения шарика, как шарик двигается по супер-узким участкам, как двигается на широким участкам. Как врезается в стены, как может протиснуться сквозь узкие стенки, может ли отскакивать от каких-то стенок? Может ли подпрыгивать, если разгонится, чтобы что-то перелететь? Это всё тестируется на Игровой Площадке БЕЗ МОДЕЛЕЙ, только средствами движка. Одноцветные кубы и шарики.
1 этап - Прототип игры
1. ГД пишет концепт и начинает писать диз-док
1.1. Программист делает шаблон приложения
1.2. Программист проверяет экспорт приложения
(1.2.1 Если работает команда, программист настраивает гит-хаб)
1.3. Программист и ГД решают как будет выглядеть Игровая Площадка (выше написано как она выглядит)
- комфортная камера
- комфортное перемещение и скорость по открытой местности
- комфортное перемещение и скорость по узким площадкам
- комфортное перемещение и скорость по широким площадкам
- нужны стенки или нет?
- варианты разных стенок по высоте
- варианты узких и широких проходов
- варианты наклонных поверхностей, тест слишком отвесных наклонных
- тест максимально длинной прямой
- тест максимально короткой прямой
1.4. Программист реализует все основные механики
1.5. Вся команда тестирует механики на Игровой Площадке (в нашем случае - это один человек =) )
1.6. Программист исправляет ошибки, доделывает абсолютно все игровые механики (переключение экранов, кнопки)
Не нужно сразу делать игру, иначе на большой игре забуксуешь и не будешь знать что делать дальше!!! Мы ещё даже не начали делать Прототип игры. Ни в коем случае не добавлять механик больше, чем придумали до начала разработки! Если придумана крутая механика - она записывается в "урну идей" или в "мусорку идей". И возможно будет реализована в следующей игре.
Кубики - это НЕ НАСТОЯЩИЕ и не детализированные модели. Это временные разноцветные модельки с надписями. Для схематической сборки прототипа уровня. После этапа прототипирования эти кубики заменяются на настоящие модели. Теоретически не нужно менять расстановку объектов, т.к. они уже были расставлены.
Прототип уровня собирается ТОЛЬКО из кубиков, а не из стандартных ассетов игры. Прототип уровня - это не Игровая площадка.
1 этап - Прототип игры
...
2.1. ГД работает с диз-доком и ставит задачи всей команде по плану.
2.2. 3D Artist готовит большие игровые кубики (Construction Blocks)
2.3. Level Designer собирает из больших игровых кубиков прототип уровня
2.4. Программист переносит механики из Игровой Площадки в прототип игры
2.5. Программист делает дополнительные механики
2.6. Вся команда тестирует дополнительные механики на Игровой площадке
2.7. 3D Artist готовит маленькие игровые кубики (Props)
2.8. Level Designer расставляет маленькие кубики на прототипе уровня. И дорабатывает прототип
2.9. 2D Designer придумывает 2д оформление игры по концепт-документу и делает наброски всей графики для игры.
2.10. Программист добавляет всю 2д графику в игру
2.11. Вся команда тестирует прототип уровня
2.12. Sound Designer ищет звуки и музыку. Какая музыка и звуки должно быть написано в диз-доке.
Прототип игры до детализации лучше никому не показывать.
До того, как начинать делать детализацию, в диз-доке должны быть описаны ВСЕ предметы и весь контент для игры. Если его сразу не описать, то потом во время разработки начнутся простои из-за ненужного обсуждения "а что ещё добавить?" или "что делать дальше?". С хорошим диз-доком таких вопросов никогда не должно появляться. Диз-док пишете вы - ГД =)
В результате получим вот такой прототип: