Идея игры

Разговор об игровой концепции для такой игры, как Pong, может показаться немного смешным, но я попытаюсь оставить вещи как можно более общими. Очень важно, чтобы вы перед началом кодирования подумали о том, как игра будет выглядеть и ощущаться. Чем больше игровой проект, тем важнее для него фаза проектирования. Я не говорю, что вы не сможете написать игру или приложение вообще без концепции. Фактически, большинство новичков сразу начинают что-то писать, а затем улучшают это снова и снова, пока результат не удовлетворит их. Проблема такого подхода в том, что вы вряд ли найдете лучшее решение с первой попытки.

Логика игры Pong проста и не требует много текста или графики (рис. 2.1). Это делает простым написание как кода, так и концепции игры. Просто подумайте обо всех компонентах, необходимых для игры (мяч, ракетки и границы экрана) и запишите ваши первые идеи.

Рис. 2.1

Записывайте ваши идеи!

Написание концепции не означает, что вы должны записать все ваши идеи, как сумасшедший рисовать UML-диаграммы и начинать работать только тогда, когда все будет полностью распланировано. Я полностью против такого подхода, поскольку невозможно заранее знать, как все сложится. Кроме того, новички, вероятно, не знают, что лучшим путем является проектирование всей игры. Вместо этого вы можете создать ясную картину игры в вашем разуме, и, после того, как решите, что потратили достаточно времени на проектирование в уме, приступить к работе.

Если над игровым проектом работают и другие люди, становится трудно объяснять идеи и поддерживать синхронизацию. Только по одной этой причине вы должны сделать привычкой записывать все свои идеи, относящиеся к игре, в одном месте. Вы не только сможете показать записи другим людям и получить больше отдачи, но и сами, записывая некоторые части игровой идеи и думая об относящихся к ним вещах, можете заметить, что на бумаге они выглядят сложнее, чем в уме, и вам надо подумать о дополнительных зависимостях.

Например, вы знаете, что для игры Pong необходимы две ракетки и мяч, перемещающийся между ракетками. Но, возможно только после записи начальной идеи игры и размышлений о текстурах спрайтов, вы задумаетесь о большей детализации процесса игры — сколько жизней должно быть у каждого игрока, как узнать попал ли мяч по краю ракетки и что делать в этом случае? Влияет ли скорость ракетки на скорость и направление полета мяча? Будет ли со временем увеличиваться скорость мяча, чтобы игра не наскучила? Несомненно, многие из этих вещей могут быть улучшены после того, как вы завершите первую версию игры. Но намного легче рассмотреть эти вещи заранее, чтобы, написав сложный код, вы вдруг не обнаружили, что вовсе не нуждаетесь в нем.

В качестве примера я напишу дизайн-концепцию для игры Pong, которую мы будем разрабатывать в этой главе. Для более сложных игр концепция может занимать 5 – 10 страниц, но не следует писать 100 страниц концепции вообще ничего не программируя. Это займет слишком много времени, а потом концепцией будет сложно управлять. В гибкой методологии вы будете часто обновлять концепцию и менять детали. Я обычно не начинаю с диаграмм UML, пока не будет написано по крайней мере 50% кода, и обзорные диаграммы и документация обновляются позднее, когда проект подходит к финалу.

Идея игры Pong

Игра является простым клоном Pong для одного или двух игроков. В однопользовательском режиме второй ракеткой управляет компьютер. В многопользовательском режиме два игрока могут управлять каждый своей ракеткой с помощью различных клавиш на клавиатуре одного PC, или с помощью двух пультов Xbox 360.

Особенностями игры являются несколько двухмерных спрайтов для мяча и ракеток и пара звуковых файлов для столкновения мяча с ракеткой и потери жизни. Есть очень простое меню, позволяющее выбрать следующие варианты:

• Одиночная игра

• Многопользовательская игра

• Выход

Меню реализовано с помощью простых текстур, фон представляет собой открытый космос и почти вся графика сделана максимально яркой. Мы попробуем сделать игру максимально интересной.

Возможности и игровой процесс

В игре есть два режима: меню и игра. Меню просто отображает элементы, перечисленные в предыдущем разделе, а в игре присутствуют мяч, две ракетки и простейшая система подсчета очков. Взгляните на набросок того, что мы постараемся реализовать (рис. 2.2):

Рис. 2.2

Технологии

Конечно же мы будем использовать XNA Game Studio Express; нам не надо будет использовать никаких дополнительных библиотек потому что мы будем визуализировать только несколько простых спрайтов, и в этот процесс не будут вовлечены никакие трехмерные модели или шейдеры. Игра должна работать как в Windows, так и на консоли Xbox —360.

Как видите, я все разместил на одной странице, и это одно из моих правил, используемых при написании концепции игры. Сперва разместите все на одной странице, потом посвятите немного времени кодированию и, если это потребуется для вашей команды или внешних партнеров (например, если вы захотите показать концепцию издателю), напишите чистовую версию на 5 – 10 страниц, основанную на первоначальной идее с добавлением нескольких набросков.

Я никогда не говорю в концепции собственно о программировании; достаточно убедиться, что вы знаете, какую технологию использовать. Теперь настало время подумать о реализации. Не думайте о ваших возможностях, когда пишете концепцию игры, это может сильно ограничить вас. Держите это в вашем уме.

Примером более сложной игровой концепции может служить игра Rocket Commander (рис. 2.3). Вы можете ознакомиться с этой концепцией, находящейся в PDF-файле в каталоге с файлами для данной главы. Она состоит из четырех страниц и обложки и описывает все идеи для игры Rocket Commander. Взглянув на обложку можно заметить, что игра выглядит не так, как концепция, но основные игровые идеи находятся здесь.

Рис. 2.3

Гибкая методология

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

Вместо того чтобы планировать абсолютно все до мельчайших деталей, вы делаете только грубый набросок концепции. Затем каждая часть концепции сама проходит через процесс планирования с большей детализацией особенностей, разработку кода, помогающего в тестировании модулей, создание самой реализации кода и заключительное тестирование и документирование части. Такие итерации должны занимать не больше нескольких недель и повторяться для всех частей большого проекта.

Также гибкие методы включают ряд идей об улучшении совместной работы, объединении разработчиков в команду с заказчиками, тестировщиками, менеджерами, проектировщиками и т.д. Есть несколько правил, помогающих отчасти структурировать этот гибкий процесс, чтобы избежать всеобщего хаоса. Из-за сокращенной фазы планирования может показаться, что детализированный план проекта отсутствует, также как и в хаотическом подходе немедленного кодирования. Но в реальности процесс планирования продолжается на протяжении всего проекта и это более полезно, чем всеохватывающее планирование в начале и необходимость жить со всеми ошибками, сделанными на этой стадии в течение всего проекта.

В этой книге я не буду много говорить о гибкой методологии, но во всех проектах этой книги я буду использовать тестовые модули, начинать с создания краткой концепции, разрабатывать тесты и затем выполнять итерации кодирования. Если вы хотите больше узнать о тестировании модулей, я рекомендую обратиться к сайту Мартина Фаулера http://martinfowler.com.

Мартин также написал несколько книг и я рекомендую вам его книгу «Рефакторинг. Улучшение существующего кода», которую вы также найдете на сайте. Кроме того на сайте есть множество ссылок и информации по теме гибких процессов разработки программного обеспечения.

Решение начальных проблем

Ладно, теперь у вас есть идея игры, но вы еще не задумывались о том, откуда брать графику, что делать со звуковыми файлами и как все это реализовать. Что насчет проблемы столкновения мяча со сторонами ракетки? Может даже потребуется простой физический движок для мяча?

Все эти вопросы обычно возникают после фазы проектирования и в более сложных проектах вы можете потратить недели, если не месяцы, чтобы только определить некоторые из основных проблем. Например, первой игрой, сделанной мной для .NET 2.0 была Rocket Commander, и у меня была замечательная идея иметь на экране тысячи астероидов и миллионы астероидов на уровне в целом. У меня были некоторые замечательные идеи относительно того, чтобы позволить им сталкиваться и отскакивать друг от друга; вот только было непонятно, как реализовать это в оптимизированном виде. После ряда начальных тестов я обнаружил, что не могу визуализировать даже 100 астероидов без значительного понижения быстродействия.Вместо того, чтобы переписать концепцию игры и получить в результате унылую игру без многочисленных астероидов (которые являются базовой концепцией Rocket Commander — без множества астероидов у вас вообще не будет игры), я попробовал решить эту проблему, визуализируя наборы астероидов отсортированные по шейдерам и материалам, выполняя раннее отбрасывание невидимых астероидов и применяя физику только к ближайшим астероидам.

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

В большинстве сделанных мной игровых проектов я тратил больше половины времени на решение начальных проблем и их деление на меньшие задачи, которые в свою очередь также должны быть решены. Сама игра позже собирается путем объединения этих частей вместе, и, как по волшебству, вся игра оказывается готова за несколько дней. Закончить создание игры так быстро, как только возможно, это хороший подход, чтобы не разочароваться не видя долгое время никаких результатов, и в прошлом я всегда несколько раз повторял сборку игры, пока не был полностью удовлетворен результатом. Это занимало очень много времени. Благодаря гибкому процессу разработки я могу работать над проблемами и не попадать в почит бесконечный цикл внесения улучшений.

Что это означает для вашей игры Pong? Ладно, игра очень проста, и вы не будете тратить много времени, чтобы улучшить ее в 100 раз. Скажем, вы реализуете только базовую версию Pong с жестко запрограммированной ракеткой компьютера слева, перемещающейся вверх и вниз в зависимости от позиции мяча, и управляемой игроком ракеткой справа. Затем, после усовершенствований и тестирования однопользовательской игры вы, возможно, захотите добавить поддержку двух игроков и столкнетесь с трудностями, поскольку жестко запрограммировали код для компьютера. Вам может понадобиться закомментировать части кода или даже удалить их и реструктурировать код игрового процесса. Через некоторое время после тестирования режима для двух игроков вы можете захотеть добавить меню и снова вам придется перемещать код в другое место, повторно реализовывать код для компьютера и т.д.

Хотя это хорошая практика, побуждающая к рефакторингу (рефакторинг означает изменение зтруктуры вашего кода без изменения функциональности для упрощения поддержки; смотрите книгу Мартина Фаулера «Рефакторинг»), значительно проще сосредотачиваться на одной части игры за раз и иметь несколько версий игры, запуская тесты параллельно. Именно это мы сделаем в следующей части главы и, надеюсь, вы уловите, что я имел в виду. Рефакторинг проходит более естественно, делает ваш код более удобным и позволяет вам видеть результаты значительно быстрее, благодаря тестированию модулей.

Одна из проблем, которую вы решите в следующей части, — как обрабатывать физику мяча и как определить с какой частью ракетки он столкнулся.

Создание текстур

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

И снова, для игры Pong все очень просто, но более сложные игры могут потребовать арт-концепции, набора эскизов и кого-то с хорошей идеей о том, как управлять всеми этими художественными работами и как совместить все это воедино и вовремя для реализующего все программиста игр. В начале истории компьютерных игр почти все игры создавались одним человеком, и хотя это самый простой путь, сегодня ни одна серьезная игра не может быть создана всего одним разработчиком. Большинство хороших художников не являются программистами, а большинство программистов не слишком хороши в качестве художников. Если вы делаете простую игру, это не имеет большого значения, но чем крупнее становится проект, тем больше времени вы будете посвящать подбору членов команды, умелых художников, создателей моделей и объединению их вместе.

Взгляните на графику для вашей игры (рис. 2.4.). Вы будете использовать три текстуры: PongBackground.dds (1) для фона, PongMenu.png (2) которая содержит логотип, элементы меню и все остальные тексты для вашей игры и PongGame.png (3) с изображениями ракеток и мяча.

Рис. 2.4

Дополнительно вы импортируете в ваш проект два звуковых файла (PongBallHit.wav и PongBallLost.wav) и добавляете простой проект XACT для воспроизведения звука. Чтобы больше узнать о звуке и XACT, прочитайте главу 9.