© 2016 Redwood Games
11.04.2017
Боремся с багами и совершенством, или настоящая цена разработки
Привет, друзья!
С интересом отвечу на частый вопрос, который мне задают по ходу проекта Plutocracy:
Все ли у нас всегда идет гладко и сталкиваемся ли мы с какими либо трудностями в разработке?
К разработке любого ПО, не только игры, «гладко» — малоприменимый термин).
Если же говорить про разработку игр — то это самый сложный уровень программ, в которых задействуется не только ресурс программистов, но и творческое начало, со всеми вытекающими.
Поэтому разработка компьютерной игры — это квинтэссенция, близкая по духу к созданию современного кино. Нужен свой сценарий, режиссер, продюсер, техники и художники, спец. эффекты и пр. пр.
Это для игрока все выглядит как кнопка или картинка — за пользовательской оболочкой скрывается сложная архитектура приложения, состоящая из десятков или сотен тысяч строк кода.
Одна не там поставленная запятая — и весь код может просто не запуститься!
И все же, очень трудно понять, почему даже крутые издатели видеоигр с мировым именем, тысячами сотрудников, и капитализацией в миллиарды долларов, позволяют себе задерживать выход в свет своих проектов на месяцы, а бывает, и годы от запланированных сроков?!
Например, игру «Hearts of Iron 4» от знаменитой студии Paradox, выпустили с задержкой около 1,5 лет от предполагаемой в начале даты. А релиз «Guild 3» уже затягивают который год, и до сих пор неизвестна точная дата выхода.
Неужели нельзя планировать лучше? Что может идти «не так» и какие «болезни» случаются с командой разработчиков на этапе создания игры?
Пройдя 2/3 пути создания своего первого игрового проекта — «Plutocracy», я готов дать ответ на эти вопросы, исходя из полученного нами опыта.
Несмотря на то, что какие то нюансы ждут нас еще впереди, уже сейчас мы регулярно боремся с 2 главными трудностями гейм-девелоперов:
1. Разрастание концепта игры
Вот представьте, Вы — режиссер и сценарист. Перед Вами стоит задача сделать крутой фильм. Вы придумываете сценарий, нанимаете актеров, съемочную бригаду и начинаете съемки. И уже в процессе, Вам кажется, что в каком то моменте будет лучше сделать по другому, нежели в сценарии? Либо Вам предлагают это сами актеры, либо талантливый оператор, чьему слову Вы доверяете. Ну как тут не поддаться соблазну улучшить игровой эпизод, отойдя от первоначального сценария?
В конечно счете — Вы правы, ведь Вы улучшаете фильм, тем самым.
С интересом отвечу на частый вопрос, который мне задают по ходу проекта Plutocracy:
Все ли у нас всегда идет гладко и сталкиваемся ли мы с какими либо трудностями в разработке?
К разработке любого ПО, не только игры, «гладко» — малоприменимый термин).
Если же говорить про разработку игр — то это самый сложный уровень программ, в которых задействуется не только ресурс программистов, но и творческое начало, со всеми вытекающими.
Поэтому разработка компьютерной игры — это квинтэссенция, близкая по духу к созданию современного кино. Нужен свой сценарий, режиссер, продюсер, техники и художники, спец. эффекты и пр. пр.
Это для игрока все выглядит как кнопка или картинка — за пользовательской оболочкой скрывается сложная архитектура приложения, состоящая из десятков или сотен тысяч строк кода.
Одна не там поставленная запятая — и весь код может просто не запуститься!
И все же, очень трудно понять, почему даже крутые издатели видеоигр с мировым именем, тысячами сотрудников, и капитализацией в миллиарды долларов, позволяют себе задерживать выход в свет своих проектов на месяцы, а бывает, и годы от запланированных сроков?!
Например, игру «Hearts of Iron 4» от знаменитой студии Paradox, выпустили с задержкой около 1,5 лет от предполагаемой в начале даты. А релиз «Guild 3» уже затягивают который год, и до сих пор неизвестна точная дата выхода.
Неужели нельзя планировать лучше? Что может идти «не так» и какие «болезни» случаются с командой разработчиков на этапе создания игры?
Пройдя 2/3 пути создания своего первого игрового проекта — «Plutocracy», я готов дать ответ на эти вопросы, исходя из полученного нами опыта.
Несмотря на то, что какие то нюансы ждут нас еще впереди, уже сейчас мы регулярно боремся с 2 главными трудностями гейм-девелоперов:
1. Разрастание концепта игры
Вот представьте, Вы — режиссер и сценарист. Перед Вами стоит задача сделать крутой фильм. Вы придумываете сценарий, нанимаете актеров, съемочную бригаду и начинаете съемки. И уже в процессе, Вам кажется, что в каком то моменте будет лучше сделать по другому, нежели в сценарии? Либо Вам предлагают это сами актеры, либо талантливый оператор, чьему слову Вы доверяете. Ну как тут не поддаться соблазну улучшить игровой эпизод, отойдя от первоначального сценария?
В конечно счете — Вы правы, ведь Вы улучшаете фильм, тем самым.
Но в геймдеве, любое отхождение от концепта игры — это прежде всего сложность для программистов-инженеров. Приходится менять архитектуру приложения. Это как начать перестраивать дом, когда уже построен первый этаж. Если бы был только фундамент — то проблем почти никаких. Но первый этаж приходится либо полностью сносить, либо «импровизировать», встраивая в него новые конструкции.
Еще сложнее — когда построен второй этаж… А Вам нужно что то поменять в архитектуре первого!
По опыту нашей собственной разработки, изменения в концепте — один из краеугольных камней для большинства разработчиков, который пожирает временной ресурс.
К тому же, это плодит количество ошибок и не состыковок в коде, что еще больше удлиняет процесс разработки.
Придерживаться первоначального концепта, ничего в нем не изменив — значит заранее сковать себя и свой продукт оковами, и как следствие — выпуск игры, которая может просто не «зайти». Т.к. концепт на бумаге и готовое приложение — это небо и земля. Игра должна развиваться вместе с работой над ней.
Если же без конца менять концепт в процессе разработки, совершенствуя игру — срок разработки может превысить все разумные рамки. И компромисс, кажется, совсем невозможен.
Какие решения выработали мы в процессе работы над Plutocracy:
2. Баги (ошибки в коде)
Как и все разработчики, мы регулярно сталкиваемся с багами (ошибками), на которые приходится убивать время порой больше, чем на сам процесс разработки нового функционала. Например, вот как видит свои ошибки в коде старший программист — Андрей, в нашей системе контроля задач — Redmine:
Еще сложнее — когда построен второй этаж… А Вам нужно что то поменять в архитектуре первого!
По опыту нашей собственной разработки, изменения в концепте — один из краеугольных камней для большинства разработчиков, который пожирает временной ресурс.
К тому же, это плодит количество ошибок и не состыковок в коде, что еще больше удлиняет процесс разработки.
Придерживаться первоначального концепта, ничего в нем не изменив — значит заранее сковать себя и свой продукт оковами, и как следствие — выпуск игры, которая может просто не «зайти». Т.к. концепт на бумаге и готовое приложение — это небо и земля. Игра должна развиваться вместе с работой над ней.
Если же без конца менять концепт в процессе разработки, совершенствуя игру — срок разработки может превысить все разумные рамки. И компромисс, кажется, совсем невозможен.
Какие решения выработали мы в процессе работы над Plutocracy:
- Двигаться небольшими итерациями (версиями), применяя принципы Agile-разработки (гугл в помощь, кому интересно)
- Не перестраивать «первый этаж», когда уже есть «второй».
- Не всегда новое — лучше чем старое. Иногда можно и промахнуться с новым решением. Поэтому собираем небольшую фокус группу и критически оцениваем каждое изменение.
- Даем устояться новой идее 1-2 недели, оставив ее в покое. Если после этого срока она не утратит актуальности — вперед!
2. Баги (ошибки в коде)
Как и все разработчики, мы регулярно сталкиваемся с багами (ошибками), на которые приходится убивать время порой больше, чем на сам процесс разработки нового функционала. Например, вот как видит свои ошибки в коде старший программист — Андрей, в нашей системе контроля задач — Redmine:
Чем больше функционала — тем больше потенциальных ошибок может возникать у игры. Это малоприятная, но обязательная часть работ.
Иногда ошибки возникают совершенно не линейно — например, когда добавляем один модуль, а сыпаться начинают другие модули, но связанные с новым.
Наше решение здесь больше классическое — мы не беремся за новый функционал, не исправив ошибки предыдущего.
И, конечно же — тестирование. Сначала внутри студии своими силами — потом силами союзников (добровольцев — тестировщиков).
Подводя итог, скажу, что благодаря вовремя выявленным причинам застоев, и найдя правильные решения, нам удается не впадать «в кому» по ходу разработки, увеличивая сроки или бюджет проекта в разы, как это часто случается с начинающими, и не только, студиями.
И хотя люфт в датах релиза альфа и бета-версий у нашей студии всегда имеет место быть (мы не совершенны) — наше текущее маленькое достижение заключается в том, что он измеряется не в годах или месяцах, а в более коротких и не критических для нас сроках.
И это при том, что функционал игры разросся в 2,7 раза по сравнению с заложенным по бумаге в игру на старте разработок!
Вообще, любой трудовой коллектив — это отдельная «машина», со своими устоями и правилами работы. А тем более, если это коллектив творческий — побудить его работать как часики, это отдельная тема, которую я обязательно буду затрагивать в нашей рубрике — «Геймдев».
Как говорил Уоррен Баффет — «если Вы заставите забеременеть 9 женщин, это не значит что Вы получите ребенка через 1 месяц…»
Так что, всему свое время, друзья.
Благодарим Вас за терпение и поддержку!
Из самой гущи разработок —
СЕО «Redwood» Владимир Иванов.
P.s. Тем, кто занят своим проектом или только планирует, рекомендую книгу от создателей Basecamp — Дэвида Хайнемайера, и Хенссон Джейсон Фрайда — «Rework: бизнес без предрассудков». Мне лично она помогла переосмыслить в свое время некоторые позиции в управлении компанией и даже менталитете.
Иногда ошибки возникают совершенно не линейно — например, когда добавляем один модуль, а сыпаться начинают другие модули, но связанные с новым.
Наше решение здесь больше классическое — мы не беремся за новый функционал, не исправив ошибки предыдущего.
И, конечно же — тестирование. Сначала внутри студии своими силами — потом силами союзников (добровольцев — тестировщиков).
Подводя итог, скажу, что благодаря вовремя выявленным причинам застоев, и найдя правильные решения, нам удается не впадать «в кому» по ходу разработки, увеличивая сроки или бюджет проекта в разы, как это часто случается с начинающими, и не только, студиями.
И хотя люфт в датах релиза альфа и бета-версий у нашей студии всегда имеет место быть (мы не совершенны) — наше текущее маленькое достижение заключается в том, что он измеряется не в годах или месяцах, а в более коротких и не критических для нас сроках.
И это при том, что функционал игры разросся в 2,7 раза по сравнению с заложенным по бумаге в игру на старте разработок!
Вообще, любой трудовой коллектив — это отдельная «машина», со своими устоями и правилами работы. А тем более, если это коллектив творческий — побудить его работать как часики, это отдельная тема, которую я обязательно буду затрагивать в нашей рубрике — «Геймдев».
Как говорил Уоррен Баффет — «если Вы заставите забеременеть 9 женщин, это не значит что Вы получите ребенка через 1 месяц…»
Так что, всему свое время, друзья.
Благодарим Вас за терпение и поддержку!
Из самой гущи разработок —
СЕО «Redwood» Владимир Иванов.
P.s. Тем, кто занят своим проектом или только планирует, рекомендую книгу от создателей Basecamp — Дэвида Хайнемайера, и Хенссон Джейсон Фрайда — «Rework: бизнес без предрассудков». Мне лично она помогла переосмыслить в свое время некоторые позиции в управлении компанией и даже менталитете.
