Чёрные треугольники

Автор оригинала: Rampant Coyote
  • Перевод

В октябре 1994 года я только начал свою карьеру добросовестного программиста видеоигр в небольшом стартапе SingleTrac, который позже получил славу и почёт (но, к сожалению, не очень много удачи) благодаря таким сериям игр, как Warhawk, Twisted Metal и Jet Moto. Но в то время в компании было меньше 20 сотрудников, и официально она работала всего около месяца. Это случилось в мою первую рабочую неделю, возможно, в первый или второй день. Из кабинета разработчиков слышались восторженные крики.

Финансовый контролёр и действующая HR-леди нашей компании Джен вышла посмотреть, что за невероятный успех празднуют инженеры и художники. Все смотрели в экран телевизора, подключённого к комплекту разработки Sony Playstation. На экране на фоне одноцветного фона отображался чёрный треугольник.

«Это чёрный треугольник», — сказала она удивлённым, но саркастическим голосом. Один из программистов движка попытался ей объяснить, но она покачала головой и вернулась в свой офис. Я почти мог слышать её мысли: «У нас осталось десять месяцев, чтобы выпустить две игры для Sony, а они радуются чёрному треугольнику? На ЭТО понадобился почти месяц разработки?»

Позже она осознала (и объяснила другим), что чёрный треугольник был первым шагом. Он не значил, что нам просто удалось вывести треугольник на экран, с этим мы бы справились и за день. Всё дело было в путешествии, которое совершил треугольник, чтобы попасть на экран. Он прошёл сквозь наши новые инструменты моделирования, через два промежуточных программы-конвертера, был загружен как полная база данных, а потом отрендерен через довольно сложную иерархию сцены, полностью затекстурен и освещён (хоть освещение и отсутствовало, поэтому он выглядел чёрным). Чёрный треугольник продемонстрировал, что фундамент наконец готов, ядро довольно сложной системы завершено, и мы готовы начать работать над интересной игрой. К концу дня мы завершили экранные модели и уже управляли ими с помощью контроллеров. Через неделю у нас была среда, внутри которой могла двигаться модель.

После этого мы начали называть достижения определённого типа «чёрными треугольниками». Так называли важные достижения, требовавшие кучи работы, но после выполнения которых почти ничего нельзя было продемонстрировать, оставалась только работа, которую можно было делать дальше. Чтобы оценить чёрный треугольник, человек должен по-настоящему знать внутренние подробности того, над чем ты работаешь.

Годы спустя я чатился с ещё одним коллегой из SingleTrac и с восторгом рассказывал о моей работе над кодом многопользовательской части. Я потратил почти неделю на внутреннюю архитектуру, стремясь сделать её понятной, надёжной и простой в использовании. В ней использовался UDP вместо TCP/IP (ради скорости), поэтому я создал собственный протокол «гарантированной доставки» для тех редких пакетов, передача которых должна быть обязательной. Я редко работал над низкоуровневым кодом до этого, поэтому для меня это был новый опыт. Когда я закончил всё, то подключил другой компьютер к игре — и бум! Всё получилось, он соединился к хост-машине. Круто. Ни каких обновлений, я почти больше не добавлял, ядро архитектуры было готово. Остальное ДОЛЖНО было добавиться быстро. Объясняя это моему другу по мессенджеру, я сказал: «Это чёрный треугольник». Он сразу понял, что я имею в виду. Это была удобная и краткая метафора.

Можете украсть этот термин. И когда прогресс будет казаться немного медленным, потому что приходится выполнять серьёзную работу над архитектурой, то просто помните — это «чёрный треугольник».
Поддержать автора
Поделиться публикацией

Комментарии 17

    +7
    Мне кажется есть два типа разработчиков: первые хотят побыстрее собрать готовый прототип, в вторые готовы за месяц выводить черные треугольники.
      +7

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


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

        +3
        Как говорил мой бывший начальник, «нам пофиг, что ничего не работает, главное — чтобы были кнопочки, цвета и надписи правильные!»
        +1
        Я бы сказал есть два этапа разработки игр, когда непонятно что делать, или нужно просто проверить идею или геймплей — тогда пишешь прототипы, абы как, но главное быстро. А когда понятно что делать, или разрабатываешь какие-то общие системы, то тогда лучше потратить месяц и сделать нормально, но так, чтобы система была устойчива к изменениям.
        +5
        А twisted metal отличная игра, насыщенная деталями и хорошим геймплеем.
          +2

          Очень знакомое состояние. Бывает возьмешься за проект, и приходится месяц-два полировать "core" иногда даже без видимых результатов для заказчика. Заказчик нервничает, думает что развод какой-то. А потом раз… И за неделю получается движок который превосходит все ожидания заказчика. 90% адекватные и терпеливые. 10% — психуют, требуют возврата денег, уходят к "индусам" и гробят проект.

            +13
            Мне почему-то вспомнилась поговорка, что дуракам недоделаную работу не показывают…
              0
              в стародавние времена графические библиотеки оценивались, как правило, по архитектуре вывода точки. очень уж критичный участок был. всякие линии и прочее — это лишь вопрос математики и там ничего нового непридумаешь. да и вобщем то немного там этого остального было.
              ну ещё спрайт, видел, помнится, удивительно хитрые оптимизации.
                +2
                Линии никто вызовами putpixel() не рисовал, это было бы сверхнакладно. Да и математику нужно ещё грамотно реализовать, а то разница в скорости может на порядки отличаться.
                У Абраша про это в своё время хорошо было расписано.
                • НЛО прилетело и опубликовало эту надпись здесь
                    0
                    А при чём тут шутаны, речь шла о графических библиотеках, работающих с примитивами.
                    Естественно, в софтовом текстурированном 3D всё рисовалось попиксельно, но там скорость вывода точки имела уже отнюдь не решающен значение.
                +1
                По-моему, полная фигня.
                Если б они сразу же сделали вывод этого несчастного треугольника, то после этого им было бы на порядок легче делать и проверять все элементы конвеера, так как любая ошибка сразу же была бы видна.
                  +1

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

                    0
                    Не совсем понял, о чём вы.
                    Вы о том, что при достаточной длине конвейера они могли бы и несколько лет потратить на «чёрный треугольник», причём так и не достигнув результата (потому что изменения «в хвосте» потянут за собой цепочку изменений — и багов — от самого начала, а половина фич окажется несовместимой друг с другом)?
                    Потому что если плясать «от результата», то он как раз всегда будет — просто не будет включать в себя все фичи (часть из которых вполне может оказаться и не такой нужной, как им казалось на этапе планирования. Так ли там нужны были ДВЕ промежуточных программы-конвертера?).
                      0

                      Если линейно, то вы принципиально не сможете получить не линейное решение. Мост на опорах да, подвесной нет.

                  0
                  Даже здесь комментарии намекают на то, что сегодня этот метод не в фаворе. Сейчас модна методология «херак-херак и в продакшен», когда за красивым анимированным GUI скрывается неподдерживаемый лютый песец.
                    0
                    Когда клепаешь бэкэнд на java это — черный треугольник.

                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                    Самое читаемое