Проектирование
Из приведенного выше описания мы можем выделить несколько сущностей, которые будут играть ключевую роль в проектировании игры. Это шарик, доска и блоки. Причем все эти сущности имеют общие свойства: положение, размер, графическое представление, а также обработчик столкновений с другими объектами (сущностями). Все это свойственно спрайтам (sprite). Поскольку в MIDP 1.0 нет поддержки работы со спрайтами (в MIDP 2.0 она уже есть), нам придется делать все самим. Это не страшно, так как необходимая функциональность наших спрайтов сравнительно мала.
Если немного подумать, то можно прийти к выводу, что блоки и доска имеют много общего. Поэтому в плане функциональности они схожи, и мы можем реализовать эти две сущности в одном классе.
Чтобы реализовать модель определения столкновений объектов, воспользуемся упрощенческим методом прямоугольников. В этом случае каждый из объектов на игровом поле будет определяться следующими параметрами: координатой X, координатой Y, а также высотой и шириной. Для доски и блоков эти параметры полностью определяют их фактический размер. Однако для шарика такое представление — достаточно грубое приближение его натуральной формы. Чтобы достичь более натурального поведения шарика при таком представлении, нужно немного уменьшить его размеры (например, 75% диаметра шарика в качестве одной стороны его прямоугольника). По определению два объекта считаются столкнувшимися, если их прямоугольники перекрываются, т.е. накладываются друг на друга.
Для того чтобы придать нашей игре более привлекательный вид, мы нарисовали объекты в псевдотрехмерной форме. Каждый объект отбрасывает тень, которая передвигается вместе со своим объектом. Кроме того, объекты подвержены эффекту освещения. Верхние края, откуда предположительно светит источник света, более светлые, тогда как нижние немного затемнены.

Теперь на стадии проектирования введем в нашу игру еще три сущности (это очень упростит реализацию игры). Первая сущность будет группировать блоки на всех уровнях. Назовем ее "списком блоков" (brick list). Этот список представляет собой контейнер объектов, но помимо этого он будет выполнять и функции видимости объектов. Например, вместо того, чтобы перерисовывать каждый блок, мы просто даем команду списку перерисовать все блоки данного уровня. Так же и в случае с обработкой столкновений. Чтобы не определять индивидуально, не столкнулся ли шарик с каким-то из блоков, мы возлагаем эту задачу на список, который и осуществит эту проверку за нас. Второй вводимой сущностью будет "экран" (screen). Эта сущность будет координировать любые действия, происходящие на игровом поле (т.е. что нужно рисовать, и в каком порядке). Стратегию перерисовки мы обсудим далее в секциях Реализация и Оптимизация. Наконец, нам нужна сущность, которая связала бы все это вместе — что-то, что могло бы привести в действие нашу игру. По вполне понятным причинам назовем эту сущность движком (engine).
Игра на данный момент спроектирована так, что имеет всего четыре уровня. Однако их количество можно очень легко увеличить в будущем. Для того чтобы сделать функцию по расширению уровней максимально простой, мы выносим представление уровней в виде данных вне исходного кода. Если сделать так, то новые уровни могут быть прочитаны из базы данных устройства или даже загружены из сети без проблем с безопасностью. Это означает также, что уровни может разрабатывать любой желающий, а не только программист. Но для этого, естественно, нужно будет написать немного лишнего кода, который будет осуществлять чтение/загрузку уровней из внешних источников.
Другим объектом, на который нужно обязательно обратить внимание на этапе проектирования, — это размер экрана. Спецификация MIDP не устанавливает какой-то определенный размер экрана и даже не задает возможный минимальный его размер. Здесь все зависит от разработчиков устройств. Именно они устанавливают разрешение для своих устройств. Общее решение данной проблемы — допускать очень малый размер экрана. Таким образом, у большинства устройств размер экрана совпадет либо почти совпадет с выбранным вами. В случае, если разрешения совпадут, игра будет занимать все пространство экрана устройства. Если же разрешение устройства окажется больше, то игра будет центрирована внутри физической области экрана. Наша игра — типичный пример простой игры, когда можно выбрать более искушенный подход для решения этой проблемы. Поскольку размеры всех объектов кодировать не так уж сложно, мы можем вычислять их при старте игры, первоначально определив фактический размер и разрешение экрана устройства. Это значит, что наша игра всегда будет использовать максимум доступного ей экранного пространства.

Реализация
Как сказал Дональд Кнут: "Предварительная оптимизация — это источник всех зол". Всецело доверяя этому высказыванию, мы начнем с обычной реализации, чтобы не усложнять себе жизнь. Как только игра начнет работать, мы определим части программы, которые необходимо будет оптимизировать. Далее будут приведены довольно интересные элементы кода, иллюстрирующие подробности идей реализации. Эти элементы представлены по принципу "снизу-вверх". Это означает, что части более низкоуровневого кода будут рассматриваться раньше, чем высокоуровневый код.

Класс ThreeDColor
Этот класс реализует безопасный шаблон перечислений, который был ранее представлен в знаменитой книге "Эффективное программирование на Java" ("Effective Java Programming"). Все цвета, которые можно использовать, представлены в виде экземпляров переменных с модификатором public.
Private-конструктор данного класса предотвращает установку других значений этих переменных. Методы brighter() и darker() используются для выбора подходящего цвета для освещения и затемнения соответственно. Метод getRGB() возвращает целое RGB-значение цвета, который был установлен с помощью метода Graphics.setColor(int).  

Класс Sprite
Этот класс является суперклассом для классов Ball и Brick. Каждый объект класса Sprite имеет координаты X и Y, ширину, высоту, определяющие прямоугольник, а также смещение тени. Смещение тени задает, насколько далеко от объекта будет рисоваться его тень. Оно также показывает, насколько высоко над экраном будет "парить" объект. Прямоугольник, который определяется в этом классе, как мы уже говорили выше, используется для "отлова" столкновений объектов. Он создается в конструкторе, в котором также определяется значение смещения тени согласно фактическому размеру экрана. Данный класс также определяет абстрактные методы для рисования объектов и теней у спрайтов. Реализация этих методов предполагается уже в классах Ball и Brick.
Код класса Sprite: http://java.sun.com/blueprints/code/bricks10/com/sun/j2me/blueprints/jbricks/Sprite.j ava.html. 

Класс Ball
Этот класс занимается движением и прорисовкой шарика. Радиус шарика (или его размер) определяется на основе текущих размеров экрана.
Каждый экземпляр шарика имеет ряд переменных, которые задают его скорость (dx, dy), случайные скоростные помехи (xo, yo), а также его цветовую схему (цвет, яркость и затемнение). Конструктор создает экземпляры переменных класса Sprite width (ширина) и height (высота) на основе значения радиуса шарика и, помимо этого, устанавливает цвет.
Этот класс содержит четкие инструкции по поводу того, как нужно прорисовывать шарик. Метод move() устанавливает новое положение шарика на игровом поле с учетом текущей скорости и помех. bounceHorizon-tal() и bounceVertical() подбирают и вычисляют подходящий коэффициент скорости после столкновения шарика с другим объектом или стенкой. Чтобы предотвратить тупиковую ситуацию, когда шарику некуда больше двигаться либо когда он начинает циклично двигаться по одной и той же траектории (замкнутому пути), методы bounce Horizontal() и bounceVertical() каждый раз в цикле привносят немного помех при вычислении пути. Это позволяет избежать зацикливания игры. Методы paint() и paintShadow() используются для прорисовки шарика.
Код класса Ball: http://java.sun.com/blueprints/code/bricks10/com/sun/j2me/blueprints/jbricks/Ball.java.ht ml. 

Класс Brick
Класс Brick определяет ряд основных атрибутов блоков: width (ширина), height (высота), step (шаг), gap (разрыв). Атрибуты width и height представляют собой ширину и высоту блоков по умолчанию, step — это количество движений блока при анимации, а gap — это расстояние до смежных с ним блоков. Все эти значения тоже вычисляются согласно текущему размеру экрана. Кроме того, в этом классе присутствуют определения для символических имен для каждого типа блоков: zombie (для несуществующих блоков), standart (обычные блоки), fixed (неразрушимые блоки) и slide (блоки, которые могут перемещаться на место своих соседей, если такое место еще не занято). Наконец, каждый блок имеет ряд атрибутов, касающихся его позиционирования на игровом поле, типа, цветовой схемы, количества очков, которое дается за разрушение этого блока и ссылки на список блоков, к которому он принадлежит.
Большинство атрибутов блока инициализируется конструктором. Метод clear() удаляет блок с игрового поля, hit() знает, как текущий блок должен отреагировать на следующее столкновение с шариком. IsFixed() возвращает true, если этот блок нельзя разрушить (тип fixed). Как и в предыдущем классе, методы paint() и paintShadow() предназначены для прорисовки объекта.
Код класса Brick: http://java.sun.com/blueprints/code/bricks10/com/sun/j2me/blueprints/jbricks/Brick.java .html. 

Класс BrickList
BrickList — это первый класс, относящийся к высокоуровневым классам нашей игры. Этот класс занимается размещением блоков на игровом поле. Он знает, как нужно расположить блоки с учетом всех их параметров, а также с расстановкой цветов. Конструктор BrickList использует вариант расположения по умолчанию. Метод moveBrick() перемещает блок с одной позиции на другую, checkForCollision() возвращает значение — число больше нуля, если произошло столкновение шарика с одним из блоков из текущего списка блоков. Возвращаемое значение — это количество очков, которое получает игрок за сбитый блок. Это значение берется из свойства соответствующего сбитого блока. После этого количество заработанных игроком очков увеличивается на это значение. Обратите внимание, каким образом метод checkCollision() заново использует тот же прямоугольник для проверки на столкновение, тем самым исключив из процесса проверки на столкновения любой ненужный мусор (да, это есть оптимизация).
Метод isClean() возвращает true, если на игровом поле (и, соответственно, в списке) не осталось больше стандартных блоков. Таким образом, это означает, что уровень успешно пройден; в противном случае этот метод возвращает false. getNeighbor() возвращает соседствующий блок для блока, передаваемого в качестве аргумента и в соответствующем направлении. Если для этого блока по указанному направлению нет больше соседей, то этот метод возвращает null. Методы paint() и paintShadow() отображают все блоки текущего листа, поочередно вызывая методы paint() и paintShadow() для каждого из своих элементов-блоков.
Код класса BrickList: http://java.sun.com/blueprints/code/bricks10/com/sun/j2me/blueprints/jbricks/BrickL ist.java.html. 

Класс Screen
Этот класс заправляет всеми высокоуровневыми операциями по рисованию, которые необходимы нашей игре. Он знает, как рисовать различные экраны, которые мы обсуждали в секции Описание этой статьи, а также может запрашивать состояние у класса Engine, чтобы знать, какой экран прорисовывать. В заглавном экране на имя автора наложена простенькая анимация, так что имя автора поднимается из нижней границы экрана. Для анимации этот класс использует переменную wildcard_y. Кроме того, методы keyPressed() и keyReleased() пересылают события, поступающие от клавиатуры, в класс Engine.
Код класса Screen: http://java.sun.com/blueprints/code/bricks10/com/sun/j2me/blueprints/jbricks/BrickL ist.java.html. 

Класс Engine
Этот класс можно смело именовать сердцем нашей игры. Он хранит все шаблоны уровней в переменной pattern_list (представленные таким образом, что, посмотрев на исходные данные, можно без особого труда представить себе, что собой будет представлять тот или иной уровень) и определяет ряд различных состояний, в которых может пребывать игра. Это состояния title, play, over и demo. Игра стартует, начиная с состояния title, когда отображается заставочный экран. Если в течение определенного промежутка времени была нажата какая-нибудь клавиша, игра переходит в нормальное игровое состояние play. Иначе она стартует демонстрационный режим (состояние demo). В этом состоянии игра играет сама в себя. Выйти в обычный режим play можно, нажав любую клавишу. В случае, когда игрок теряет все выделенные ему жизни, игра переходит в состояние over. Если в течение определенного времени игрок нажимает какую-либо клавишу, игра переходит в режим play, иначе стартует режим demo. Основной цикл программы определен в методе run(). Здесь движок игры "засыпает" на некоторое время, после чего анимирует все объекты и, наконец, перерисовывает экран. Такой подход используется в огромном количестве аркадных игр и обычно называется игровым циклом.
В этом цикле игра прежде всего обновляет свое состояние. Среди элементов, которые игре нужно обновить, — пользовательский ввод, таймеры, генераторы случайных чисел и вражеский AI (Artificial Intelligence — искусственный интеллект). После того, как состояние игры было обновлено, экран перерисовывается. После перерисовки движок "спит" некоторое время и потом начинает весь этот процесс заново. Чтобы дать игре возможность работать независимо от него, модуль движка запускается в своем собственном потоке. Это реализовано посредством использования в классе Engine реализованных методов интерфейса Runnable. После чего создается новый объект класса Thread, и его конструктору передается объект нашего движка. При этом объект thread первым делом запускает сам движок посредством вызова метода run() класса Engine.
Обратите также внимание на то, как происходит обработка нажатий игроком клавиш. Код клавиши, нажатой пользователем, записывается в переменную при первом ее нажатии. Как только пользователь отпускает эту клавишу, значение этой переменной с кодом клавиши сбрасывается. Основной цикл программы передвигает доску, управляемую пользователем, в запрошенном направлении, пока клавиша не будет отпущена.
Это означает, что для того, чтобы переместить доску в другой край экрана, игроку не потребуется несколько раз нажимать на клавишу. Он ее просто удерживает до тех пор, пока доска не переместится в нужное ему место.
Код класса Engine: http://java.sun.com/blueprints/code/bricks10/com/sun/j2me/blueprints/jbricks/Engine .java.html. 

Оптимизация
Как только мы запускаем игру в среде WTK или на самом устройстве, сразу бросается в глаза тот факт, что наш подход к прорисовке экрана слишком медленный. Анимация слишком резкая и рывковая. В игру совершенно невозможно играть.
Надо что-то срочно менять. В нашем случае мы просто перерисовывали весь экран для каждого фрейма. Согласно природе нашей игры понятно, что это просто абсолютно нелогичный подход, поскольку в игре у нас от фрейма к фрейму происходит изменение только двух вещей: текущей позиции шарика и доски (если пользователь активно ее перемещает). Изредка наш мячик соударяется со стандартным блоком, который после этого исчезает, либо со скользящим (slide) блоком, который может переместиться на место своего соседа, а может и не переместиться. В этом случаем нам придется перерисовывать еще и весь список блоков. Однако после более близкого изучения мы замечаем, что можно, собственно говоря, весь список и не перерисовывать. Можно просто стереть сбитый стандартный блок из списка или, если это slide-блок, удалить его в старой позиции и нарисовать в новой. Таким образом, имеет смысл рисовать список блоков в отдельном буфере изображения и только потом копировать этот буфер на экран во время перерисовки. Так, во время изменения списка (из-за сбитого или перемещенного блока) мы перерисовываем изменившуюся часть списка в отдельном буфере изображения.
В общем, оптимизация имеет смысл в нескольких областях. Графическая производительность — это одна из наиболее важных областей, и мы должны иметь это в виду. Однако перегруженность в вычислениях также очень критична для вашей игры. Если ваша игра тратит слишком много времени на прохождение игрового цикла, нужно обратить внимание на такие вещи, как проверка на столкновения и другие вычислительные расчеты игры. Для начала попробуйте отключить все кажущиеся вам полезными внутренние особенности реализации и проследите, насколько это уменьшит или увеличит нагрузку на процессор. WTK 2.0 имеет встроенный инструмент для мониторинга загруженности процессора эмулятором. Но будьте внимательны: его цифры не всегда отражают реальную картину происходящего на настоящих устройствах. Как только вы найдете что-то, что нужно исправить, сначала убедитесь, действительно ли ваша реализация обновленного кода оптимизирует работу приложения. Если нет, то вам следует поискать другой, более быстрый подход к решению этой проблемы. Также обязательно обратите внимание на элементы управления. Нет ничего более отталкивающего, а в играх особенно, чем медленное и инертное управление, которое не дает пользователям игры проявить свои игровые способности.

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

Вывод
Самый главный урок, который вы должны были извлечь из этой статьи: рисование — занятие очень ресурсоемкое. Если вы посмотрите на код изначальной реализации, а потом на оптимизированный код, то не увидите между ними большого различия. Между тем, различия в производительности игры очень велики. Если вы собираетесь действительно использовать, а тем более продавать, свою игру, вам обязательно нужно опробовать ее в действии на реальном устройстве. Хоть WTK — это и великолепный инструмент для разработки, но в игре существуют моменты, которые можно обнаружить, лишь запустив ее на реальном мобильном устройстве.
В следующий раз мы рассмотрим сетевой вариант игры для мобильных устройств и еще раз поговорим про проектирование, реализацию и оптимизирование игр на Java.