A-tit indd

Паттерны программирования игр
— Введение
25
Райт, не способен продумать сбалансированный игровой 
дизайн на бумаге. Это требует итераций и экспериментов.
Чем быстрее вы сможете опробовать идеи на практике 
и посмотреть на поведение программы в реальности, тем 
больше вероятность найти что-то действительно стоящее. 
Даже после того, как вы нашли правильные (игровые) ме-
ханики, нужно потратить время на настройку. Крошечный 
дисбаланс способен разрушить удовольствие от игры.
Здесь нет простого ответа. Повышение гибкости ва-
шей программы приводит к повышению скорости разра-
ботки, но влияет на производительность. Точно так же 
оптимизация кода делает его менее гибким.
Хотя, по моему опыту, намного легче сделать весе-
лую игру быстрой (с точки зрения производительности), 
чем быструю игру — веселой. Один из компромиссов за-
ключается в том, чтобы сохранять код гибким до тех пор, 
пока не установится четкая архитектура, а затем по-
жертвовать частью абстракции в целях повышения про-
изводительности.
Хорошее в плохом коде
Все сказанное подводит меня к следующему выводу: 
вы всегда вправе сами выбирать стиль написания кода. 
Большая часть книги посвящена созданию удобного 
и понятного кода, я, конечно же, сторонник «правиль-
ного» кода, но иногда имеет смысл позволить себе лег-
кую небрежность.
Если вы хотите получить хорошо структурированный 
код, вам придется потратить время на обдумывание де-
талей. Более того, поддерживать хорошую архитектуру 
в течение полного жизненного цикла проекта не всегда 
просто. Вам следует отнестись к своему коду трепетно, 
как порядочный турист относится к месту своей стоян-
ки: уходя, он всегда старается оставить стоянку в луч-
шем состоянии, чем то, в котором она была.
Такая ситуация хороша, если вы собираетесь жить 
этим кодом и работать над ним в течение длительного 

---