Статья: Dirty Coding Tricks (по наводке thesz). Это сборник небольших рассказов разработчиков игр о том, как они “решали” проблемы в своем коде, когда до дедлайна оставалось всего ничего. Например, в одном случае версия игры для PlayStation падала, если в начале первого уровня игрок слишком долго ничего не делал. Ошибку не нашли, но обнаружили, что если в этом месте развернуть виртуальную камеру на 90 градусов вправо, то крах программы не происходит. Именно в таком варианте игру и отправили в печать.
Но на двух эпизодах я хотел бы остановиться подробнее.
Meet My Dog, Patches
История о том, как при переносе игры с PC на PlayStation-I пришлось заменить все операции с float-ами на операции с числами фиксированной точности. Из-за этого возникали погрешности вычислений в системе определения коллизий. И персонаж, например, проваливался в дырки в полу (которые так же возникали из-за погрешностей вычислений). Сначала проблему попытались решить переделкой уровней игры. Но это не помогало, т.к. сразу же после латания дыр на одном уровне, сотни новых дыр обнаруживали на других уровнях. Тогда разработчик решил пропатчить игровой движок условиями вида:
IF (Damp will fall through a hole()) THEN
Don't do it
Поначалу патчи работали. Потом их становилось все больше и больше:
But it did not go well. Hundreds of patches were needed, and then the patches themselves started causing problems, so more patches were added to turn off the patches in hyper-specific circumstances. The bugs kept coming, and I kept beating them back with patches. Eventually I won, but at a cost of shipping several months behind schedule, and working 14 hour days for all of those several months.
После такого опыта разработчик пришел к выводу:
That experience soured me against "the patch." Now I always try to dig right down to the root cause of a bug, even if a simple, and seemingly safe, patch is available. I want my code to be healthy.
К похожему выводу я пришел благодаря олимпиадам по программированию. Причем мне потребовалось две олимпиады. В 1992-м на республиканской олимпиаде в Гродно, в задаче для языка ассемблер я поленился написать общую функцию для вычленения ключевых слов из файла. В результате я запорол свое решение. На следующий год, на такой же олимпиаде и опять на ассемблере я попытался учесть опыт прошлого – самую сложную часть задачи я сначала расписал на бумаге (операции сложения, вычитания, умножения и деления для больших чисел в символьном представлении). И когда этот код быстро заработал без ошибок, я решил “сэкономить” время и оставшуюся часть (перебор чисел с их взаимным перемножением) сделать прямо за компьютером. Естественно, вторая часть не заработала и я опять провалился.
Мораль этих двух басен: если у вас возникает впечатление, что вы делаете не то, что следует, что лучше остановиться, подумать и сделать правильно, то нужно так и поступить. Особенно в условиях прессинга и ограниченного времени. Поскольку именно в таких условиях нет времени для быстрых, но неправильных решений.
Мне повезло прочувствовать это на собственном горбу в раннем возрасте и на ничего не значащих проектах.
The Programming Antihero
Это история о том, как разработчики игры титаническими усилиями пытались уменьшить потребление памяти. После всех потуг оставалось где-то 1.5Mb перерасхода. И тут один матерый программирище показывает классный фокус. Открывает свой код и удаляет оттуда статический массив размером 2Mb. Который был объявлен, но никогда не использовался. Офигевшему от такого трюка коллеге он объяснил: мол, давно заметил, что память придется экономить, а делать это очень и очень трудно. Мол, практически невозможно уместить готовую игру в жестки лимит. Поэтому я всегда занимаю пару мегабайт памяти. И когда становится совсем уж невмоготу, я эту память отдаю и мы вписываемся во все лимиты.
Вот это я понимаю, вот это опыт! Респект и уважуха. Нужно будет перенять. Не с памятью, так с быстродействием. Навесить на программу сразу некоторый гандикап, а затем пытаться ужать ее до нужных пределов. И если уж совсем чуть-чуть останется, выбросить этот гандикап нафиг!
Кстати, эта история напомнила мне давным-давно прочитанную книгу Роберта Хайнлайна “Туннель в небе”. Там студентов для экзамена на выживания выбросили на неисследованную планету. И предупредили, мол опасайтесь стобора. Кто такой стобор, естественно, никому не объяснили. А в самом конце, когда выжившему главному герою довелось поговорить с организатором эксперимента, выяснилось следующее:
- Но вначале это было серьезной помехой. Эти стоборы
особенно - я покажу вам одного из них в поле, когда... но
послушайте, - Род задумчиво посмотрел на Мэтсона.
- Это ведь стоборы, не так ли? Маленькие хищники, более
высокие спереди, чем сзади, несколько похожие на диких котов,
но в десятки раз более свирепые?
- Почему ты спрашиваешь меня?
- Но ведь вы предупреждали нас о стоборе. Все группы
были предупреждены.
- Вероятно, это и должен быть стобор, - заметил Мэтсон,
- но я не знал, что он так выглядит.
- Что?
- Род, на каждой планете есть свой СТОБОР... и все они
различны. Иногда их несколько. - Он остановился, чтобы
выбить свою трубку. - Ты помнишь, я говорил, что на каждой
планете есть своя особая опасность, отличная от опасностей на
всех остальных планетах Галактики?
- Да...
- Конечно, но это ничего не означает, кроме чисто
умозрительной конструкции. А вы должны опасаться реальной
опасности, если хотите остаться в живых... И мы
персонифицировали эту опасность, не говоря вам, в чем она
заключается. Ежегодно мы делаем это разными способами. Цель
заключается в том, чтобы предупредить вас: смертельная
опасность может выглядеть как угодно... Мы старались поселить
страх перед этой опасностью в ваших внутренностях, а не в
головах.
- Ну, и дурак же я ... здесь нет никакого стобора! И
никогда не было.
- Конечно, он был. Для кого же вы соорудили эти ловушки?
Вот и напомнил мне 2Mb массив-гандикап в программе того самого стобора :)
отличные истории
ОтветитьУдалить