Пару дней назад на закрытом форуме oper.ru разгорелась очень интересная дискуссия о gamedev'е. К сожалению, привести ее целиком нет возможности, но основной "докладчик", Борис Баткин, разрешил мне опубликовать у нас на сайте кое-что из его высказываний. Сейчас Борис живет в Сан-Диего (Калифорния) и работает lead programmer'ом в Midway. Не скажу, что я полностью согласен со всеми его мыслями. Но интересующимся и сочувствующим очень рекомендую ознакомиться. Борис сегодня один из самых опытных людей в индустрии, свободно пишуших по-русски. И его практика не ограничивается только программированием. Он плотно занимается управлением.

Итак, Борис Баткин (9-10 марта 2005):

вы спросите - почему они постоянно опаздывают. я расскажу вам про то, что видел сам. проблемы production, проблемы технологий, проблемы маркетинга, и наконец отсутствие здравого смысла - решают.

начнём по-маленьку с production.

скажите, а на вашем проекте есть продюсер? а он вам реально нужен?

приятнее всего делать игры без расписания, сроков выхода, ограничений по scope, документации, итд итп миядзаки говорил, что он почти так делает мультики. верю. вернее очень хочу верить. и потому буду. верить. и делать - пока денег дают. хочу шедевра.

вот так вот - собрались, как-то определили что будет на экране. и стали тупо кодить. где-то ближе к "концу" (а на самом деле едва-ли середине), стали уже дизайнить. итерировать. до посинения. игра всех времён и народов. убийза "дум-3", а лучше "дьябло-2".

такому проекту продюсер не нужен. он ему вредит. ему вообще вредит процесс и солнечный свет. тот самый солнечный свет такой проект скорее всего не увидит. у него есть только одно достоинство. качество. если его доделать, то получится HL-2. иногда doom-3. хуже - дум-3 и hl-2 пока получился только так. да и дьябла-2 - точно так-же.

т.е. хочется верить, что делать надо так. потому, что так делать "приятно". так делаются игры. деньги делают не так. продюсер, кстати, нужен тогда, и только тогда, когда начинают делать деньги. тогда и появляется "срок выхода". который вовсе и не "примерный срок выхода".

"быстро", "дешево", "качественно" - выбери 2. ага. сейчас. это если у вас нормальный процесс, то 2. а процесс у вас скорее всего обычный. выбери 1. в срок. ужасайся результатам, не успевай, трать деньги. опять не успевай. реж контент. и опять не успевай. если делаешь игру "к фильму" - совсем не успевай. и пусть из шутера получится стрелялка.

можно выбрать дешево и качественно. в итоге получится либо дешево, либо качественно. в геймдеве можно выбирать 1, и только 1. т.е. либо дешево, либо качественно. и никогда - к сроку. исключения, подтверждающие правила - отвратительный школьный вульгаризм. LOTR вышел к сроку. за страшные деньги. дрянь-игра. 1. даже у EA - один. кучу денег заработал, кстати. и к лучшему.

не нравится треугольник - сделаем призму. т.е. scope. можно уменьшать расходы, уменьшая scope. если делать один уровень (читай аркадная машина, игровой автомат) - то можно делать качественно и дешево. потому как этот один уровень всё время полировали. гладили. и приручали глюка. аркадные машины можно делать "по старинке". в 4 рыла. за 6 месяцев. говорят. и делали.

посему спросите себя ещё раз - зачем вам нужен продюсер. если у вас нет внятного процесса - он тратит ваши деньги. говорят, продюсер нужен паблишеру. чтобы вести "расписание" для зарубежных коллег. говорят, продюсер может решать насущные production проблемы. если повезёт. условно-досрочно. ваш продюсер - личность творческая? он придумывает фишки. он project lead? бывает и такое. говорят. а пока - сперва надо исправлять процесс. и только потом будут делаться деньги.

пока процесс такой, как есть - они будут опаздывать. долго. мучительно. и пусть.

* * *

чуть-чуть про технологии. на "индустрия молодая" пинать буду. потому как иначе - только на себя и пинать.

не все ветераны одинаково полезны. наши в большинстве своём больны NIH [от автора: NIH == not invented here; мы не будем пользоваться стл, потому что ..... её сделали не мы. в той или иной форме. аналогично мы не будем пользоваться D3DX. итд итп.], местами аллергией на С++, и часто - работой не на своей должности.

ветеран в менеджменте - это тоска. вечнозелёная. делать там ему - чаще всего нечего. типичный ветеран программер - умел кодать. один, не в комманде. не знал математики. не понимает CS. покорение крыма разглядывал в бинокль. мыслит категориями коммандной строки. в те дни - когда мыслит.

те, какие бездеятельные - от них меньше вреда. т.е. они просто не делают свою работу. другим - не мешаеют. деятельные-же - куда как страшнее. здесь совсем не та индустрия, где можно делать "проверенными методами". рулит технологическая иннициатива.

реюзать код, и прочие мифы индустрии - подкрепляются успешными контр-примерами. см. unreal. см. jack&daxter. см. baldur's gate..... впрочем последний уже не см. snowblind - это конечно весело. с песнями. но помрёт вместе с ПС2 в теперешнем виде. и поделом.

реюзать можно тулсы. хорошие тулсы долго живут. везде, кроме gamedev. у нас о них "забывают". потому как NIH. каждый новый техдиректор норовит всё переписать. у нас не крик души - у нас крик "душить".

реюзать рантайм - это тоже очень и очень приятно. сколько версий библиотеки векторов и матриц вы видели? а сколькими пользовались? страшное спрошу - сколько версий написали сами?

опять-же, идея забороть проблему "миллионом леммингов" порочна в своей основе. здесь совсем не конвеер. участников процесса может стать только меньше. доктор учится много-много лет. программист тоже будет учиться много лет. или учиться более эффективно. потому как иначе разрежет живот игре не в том месте. и будет when it's done...

проблема - научить больше программистов - плохая проблема. интенсивный путь развития подразумевает автоматизацию.

что такое автоматизация для gamedev? проще всего "на примере". пока мы продолжаем руками скриптить state-machine-ы - игры будут опаздывать. пока изменение скриптов будет требовать перезапуска игры - игры будут опаздывать. пока у нас нет nightly build и batch process - игры будут опаздывать.

есть масса тулсов для организации build-ов. ими никто не пользуется. потому как NIH видимо таки.

видел batch-файлы. видел один раз make-file. видел custom-тулсы. почему не юзается что-то внятное - для меня загадка.

почему gamedev тулсы пишутся так, что внятное юзать очень тяжело - загадка ещё большая. думаю NIH. думаю fun factor. приятнее и веселее написать свой make :)

скажу страшное - пока вы не начнём делать сиквелы - наши игры будут опаздывать. сиквел - не обязательно сиквел игры. сиквел технологий.

во всякой другой внятной индустрии есть стандарты. может доживём. а пока - when it's done... и то только для тех, кто может доделать.

* * *

буду пинать "наём кадров". осталось понять - это кадры такие, или такой наём. куда делись те гении от программизма - неясно.

даю на интервью систему двух линейных уравнений. даю решить квадратное уравнение. даю инвертировать матрицу. даю решить уравнение A * B * C = D относительно B, для матриц. даю посчитать, сколько раз каждое слово в тексте встречается. даю поделить A на B - в целых числах без деления.

после чего нанимаю одного из 100. хочу платить много денег. некому.

* * *

проектирование. вообще отдельная тема. ложные иллюзии понимания происходящего.

специализированный "архитектор", человек настолько-же неизбежный, насколько и редкий. сейчас классический lead programmer - это архитектор, менеджер и мегакодер в одном лице. замечу, что "мегакодера" в нём перестал видеть прогрессивный gamedev уже.

осталось разделить менеджера и архитектора, и.... сделать так чтобы первый слушался второго. и будет легче. хорошо не будет - но легче навсегда.

опять-же понять, что архитектору придётся платить ну очень много денег - грустно. как окупать игры - при таком раскладе - ещё более интересный момент.

ну т.е. скажите сегодня lead-programmer-у - что архитектуру на его игру будет делать вот тот дядя... он засмеётся и уйдёт к конкурентам. потому как fun ему важнее, чем проект. может разве что когда будет некуда уйти....

* * *

деградация начинается, когда наступает beyond debugging. когда начинаются workarounds. есть у меня баг где-то. засирается счётчик. отладить по каким-то причинам не могу - например дебаггер падает, breakpoint на данные не работает (например через DMA засирается), или как угодно ещё. например руки кривые мешают.

когда вместо того, чтобы поймать - где засирается - я начинаю делать ещё один счётчик и синхронизацию - наступает workaround.

а beyond debugging - это когда не получается отлаживать. чаще всего из за проблем с кодобазой.

* * *

XP - оно здорово помогает душить в себе "великого архитектора". потому как вася пупкин - он не великий, и даже не архитектор. только тому самому великому архитектору XP ни разу не помогает.

вам хорошо, если у вас работает миямота. он всё знает зарание. он надизайнит сразу, и будет хоть как-то понятно, что писать. вообще, когда у вас работает миямото - голова болит о создании ему комфортных условий, а не о процессе проектирования, и как покороче сделать летучки.

беда в том, что миямота у вас не работает... и вместо великого дизайнера и великого архитектора, за неимением гербовой, приходится плясать на простой.

а невеликому архитектору надо много-много итераций. нужны методы коммуникации. расписание - оно не только для того, чтобы понять "что" и "когда". оно ещё и для того, чтобы все могли прочитать - что и когда.

в идеале - каждый сам кузнец своего расписания. глядить. проверяет. зорким глазом - а всё ли расписали. потому как если не всё - в субботу работать ему. ему. да и всем остальным. из за него, заразы. потому как не углядел. воспитывать. хоть-бы и методом субботников.

может дорастёт в таком раскладе пупкин до миямоты. может и не доростёт. так и эдак - итерировать будет качественнее. быстрее. меньше итерировать будет, при необходимости. человек склонен научаться.

а миямота - ему проще. он своё XP под себя организует. неспешно. как ему проще итерировать - так и будет. без миямоты - сильно меньше шансов. плохо XP работает без миямоты.