Кранчи в игровой индустрии и не только
Наткнулся на хороший видос про кранчи в видеоигровых студиях, инфу из которого можно и отнести к другим сферам разработки:Ссылка на пост с видосом: http://joyreactor.cc/post/4616767
На эту тему еще есть хорошая книга "Кровь, пот и пиксели", от известного сливальщика инфы Джейсона Шрейера.
И книга и видос рассказывают о том, что не все так радужно в королестве геймдева, да и вообще в разработке. Люди, которые горят идеей о разработке игор должны задуматься не только о том, а как они вообще будут их делать, но и о том, хотят ли они их делать вообще. Потому что эта культура переработок, к сожалению, часто встречается в геймдеве и часто на ней паразитирует кто-то из начальства. Да, страсть к разработке это хорошо, но от нее не будет толку, если человек банально перегорит и просто перестанет хотеть этим заниматься.
Недавняя ситуация с киберпанком показывает, что от кранчей нет пользы, ибо мы все равно получили довольно сырой продукт, но страшно подумать "а что было бы тогда без кранчей?". И вот это уже спорный вопрос. Я слышал в "Душевном подкасте" от выходцев со СтопГейма, что "Asassin's Creed мы получаем тогда, когда люди не кранчат". И это абсолютно неправильное утверждение и, что самое главное, довольно опасное. Во-первых: кранч означает, что человек будет работать больше нормы и уставать сильнее + стресс. А что делает человек, когда он устает и у него постепенно снижается продуктивность? Он начинает делать ошибки. Да, с помощью кранча можно "забрутфорсить" некоторую работу, через "не могу" сделать некоторые вещи. Но эти вещи либо должны быть просты (условное заполнение документации или банальный копипаст кода), иначе качество сильно пострадает. Ибо человек устал, у него перестает работать голова, у него замыливается глаз и он уже не видит простых ошибок. В том же киберпанке есть банальный баг с нерабочим переназначением клавиш (назначить "нажатие" приседа, а не "зажатие" на ту же кнопку, через некоторое время кнопку приходится все равно "зажимать"), откуда он пришел, если от банального недосмотра (ну а затем не стали фиксить, ибо не приоритетно) от переутомления? Во-вторых: это опасная фраза из-за того, что люди думают, что кранчи = хорошие игры. Но это не так, отчасти из-за причин выше, отчасти из-за того, что некоторые компании и без этого работаю и у них выходят хорошие игры, о чем тоже говорится в видосе.
Сам я работаю разработчиком в интерпрайзе (Java developer) и видел и кранчевые разработки, которые ничего хорошего не давали + команда больше мчалась вперед и не оглядывалась на баги, ибо не было особо времени, что приводило к их накоплению. Но сейчас, к счастью, работаю без кранчей (ну разве что иногда чуть чуть) и доволен. В результате количество багов довольно небольшое + стресса меньше.
Так же не стоит забывать, что само руководство компании заинтересовано в кранчах, ибо таким образом они получают т.к. сказать "больше контента" за ту же сумму (не везде есть доплата за переработки). И конечно же, HR может вам начать вешать лапшу в духе "ой, нам нужны прям работяги, стресоустойчивые и все дела", но нужно понимать, что это не он будет кранчить вечерами в офисе, а вы.
Так что, если вы думали окунуться в геймдев, то советую сперва прочитать "Кровь, пот и пиксели" и решить, хотите ли вы перерабатывать на постоянной основе, или работать на "о**уеть перспективном стартапе, денег пока нет, но обязательно выстрелит, ага", прежде чем идти дальше. Ну а игрокам в очередной раз хочется напомнить, что в последнее время слишком много желчи льеться в адрес разработчиков и их игор. В этом плане хорошо сказал Булджать в своем недавнем видео про культовые забагованные игры.
P.S. для тех, кто говорит "а че они анонсировали игру, если она еще не готова была, шо это они показывали фишки, которые вырезали потом" в видосе так же есть простая истина - нельзя все предусмотреть. Тут как в мемах про "я сделаю это на изи = буду делать неделю", ибо разработка это очень динамический процесс, и даже если на этапе планирования все збс, на этапе самой разработки можно действительно понять, что что-то не работает, а что-то не реализовать за то время, которое было заложено в разработку.
