На следующий день этих китайцев уже не было. Как я узнал позже, они нажаловались на меня коменде. А та перевела их в VIP-общежитие с отремонтированными блоками, куда я безуспешно пытался попасть за деньги. Не было мест.
Я опять был виноват? Да и насрать. Китайцы так меня испугались, видимо, я и вправду производил грозное впечатление.
Как я узнал позже, вместе со мной в «Адаманте» работало несколько студентов, но более старших курсов и магистратуры. Один из них, Артём, мой будущий начальник, был с моего факультета того же СПбГУ. Правильно, кому еще реализовывать компьютерную физику?
«Адамант» при мне выпустил две завершенные игры — Liquidator 2 и Exodus from Earth. К первой я практически не имел отношения, может быть, за исключением пары баг-фиксов. Но моя фамилия вписана в число разработчиков обеих игр.
Итак, «Адамант» делился на два больших подразделения: разработки и дизайна. В подразделении дизайна работали аниматоры, художники по текстурам, художники по моделям и даже один композитор. Я же относился к подразделению разработки, которое, в свою очередь, делилось на отдел искусственного интеллекта, состоящий из одного человека, отдел физики, отдел графики и отдел редакторов.
Изначально я попал в отдел искуственного интеллекта. Это отдел, который заставляет компьютерных персонажей бегать, стрелять, думать. Начальником у меня стал Рома. Рома — прикольный человек, полностью погруженный в процесс программирования. Он, недолго думая, мог реализовать практически любой алгоритм. Правда, читабельность, а иногда и эффективность, от этого страдали. До «Адаманта» он успел поработать во многих местах, и даже побыть сантехником. «Сидишь так зимой на горячей трубе в раскопанной трассе, и куришь сигаретку…» — мечтательно рассказывал Рома.
Через две недели ко мне подошел Андрей, руководитель отдела физики, и сказал, что забирает меня к себе. Новость меня шокировала. Во мне заговорила неуверенность, что я справлюсь. Опять будут эти сложные производные и интегралы.
— Дима, а что не так? — спросил Андрей.
— Я только из университета ушел, потому что мне надоела эта физика, а тут опять…
— Рома — слабый руководитель, лучше тебе поработать здесь.
И Андрей оказался прав. За два года работы в «Адаманте» я сильно поднял свой уровень программирования. Например, я научился писать эффективный код, пользоваться профайлером. В компании было правило, что в самых нагруженных местах игра должна давать не менее 30 FPS (Frames Per Second — количество кадров в секунду). Точнее, этого требовал издатель. В игровой движок был встроен внутренний профайлер, показывающий количество миллисекунд на выполнение определенных блоков кода: AI (Artificial Intelligence — искусственный интеллект), Render (отрисовка графики), Physics (физика) и менее важные. Каждый блок можно было развернуть и посмотреть, на каком конкретно коде CPU «сидит» слишком долго. После чего начиналась оптимизация.
Кроме меня в отделе физики был Артём. Интересная закономерность: и Артём и Андрей оканчивали мой физфак СПбГУ. Именно они реализовали игровой физический движок.
Цель любого физического движка — рассчитать взаимодействие объектов, с учетом приложенных сил вычислить скорости и соответственно сдвинуть объекты на время кадра. Во время одного кадра скорость принимается постоянной. Для этого сначала нужно найти точки контакта объектов (их называют Joint’ы), составить большую матрицу с кучей цифр и решить уравнение с этой матрицей. Вот эта часть для меня и была пугающая. Мне очень сильно не хотелось разбираться в подобном. Но ядро функционировало без ошибок. И создание нового объекта в физическом мире, например той же пружины, сводилось просто к описанию параметров Joint’а, а все остальное безошибочно считал уже написанный код.
Существует два подхода к расчету игровой физики: коллизионный и выталкивающий. Коллизионный предполагает рассчитывать точки контакта одного объекта с другим. Если время до контакта меньше времени кадра, то кадр дробится, объекты расталкиваются, и пересчет повторяется снова. Такая физика обладает реалистичной точностью. Но минусов у нее также много: кадр иногда может дробиться на слишком много частей, что приводит к снижению производительности, и даже к откровенным тормозам. Выглядит это так, будто все замирает и начинает подергиваться. Так же, из-за ограниченной точности вычислений, возникают ситуации застревания объектов.