Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Курсовая работа пример.docx
Скачиваний:
3
Добавлен:
26.09.2019
Размер:
674.4 Кб
Скачать

Министерство образования Российской Федерации    Государственное образовательное учреждение высшего профессионального образования     Волгоградский государственный университет   кафедра Математики и информационных технологий  Курсовая работа  Создание стратегической игры на DirectX

Выполнил: Вашуркин Антон Владимирович  Проверил: Григорьева Елена Геннадиевна        

Волгоград 2011

Содержание

I. Введение

II.Планирование игрового процесса.

1. Фаза идей.

2.фаза определения требований.

3.фаза технической документации.

4.фаза разработки.

5.фаза тестирования.

6.фаза распространения.

III.Блочная графика.

1. Хранение блоков в двухмерном массиве

2.Свойства блоков

IV. Воспроизведение WAV файлов.

1.Класс для чтения файлов формата WAV

2.Воспроизведение WAV файла.

V.Отрисовка спрайтов.

1.Процедура нарезки фрэймов и создания спрайтов

2.Процедура создания анимации персонажей

3.Вывод растра c клипированием и с учетом прозрачного цвета

VI.Волновой алгоритм поиска пути.

VII.Список источников.

Введение.

Создание игры в реальном времени сложная и кропотливая работа. Многие программисты сразу мчатся к написанию кода, не размышляя об имеющемся в руках проекте. Такой подход приводит к пропуску ключевых моментов, хаотическому развитию, уходу членов команды и даже закрытию проекта. Даже если группа состоит из одного или двух человек, не надо поддаваться искушению быстрого и беспорядочного развития проекта. Нужно выделить время, чтобы должным образом спланировать проект который включает в себя: фазу идей, фазу определения требований, фазу технической документации (только в больших проектах), фазу разработки, фазу тестирования и фазу выпуска программы.

Планирование Игрового процесса

Фаза идей

В фазе идей мы придумываем идею программы. Так как мы имеем дело со стратегическими играми, стоит задать несколько вопросов, таких как:

  • К какому типу относится стратегическая игра — реального времени или пошаговая?

  • Игра основана на реальных или на вымышленных событиях?

  • В какой период времени разворачивается действие игры — средневековье, Гражданская война, Вторая Мировая война или будущее?

  • Игра будет однопользовательской, многопользовательской или поддерживать оба режима?

  • Графика будет двухмерной, трехмерной или и той и другой?

  • Как долго длится средний раунд игры до завершения?

  • Какова цель игры?

  • Игра в основном стратегическая или тактическая?

  • Игра простая или сложная?

  • Как выиграть в игре?

  • Как проиграть в игре?

  • Как долго продолжается игра до победы?

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

Создание наброска

На основе идей мы можем создать набросок игры:

Исходные данные

Фэнтезийный мир.

Сражения

Уровень бригад

Реализм

Отсутствует вид со спутника (отсутствие мини-карты)

Возможные маршруты

Игроки

Один игрок

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

Используя в качестве примера набросок с многопользовательской игрой, вот как бы я перечислил требования для раздела многопользовательской игры:

Требования для многопользовательской игры.

  1. Поддержка от 2 до 16 игроков.

  2. Игра может быть сохранена и заново загружена.

  3. Необязательный выделенный сервер.

  4. Администратор игры может отключать и блокировать игроков.

Здесь хорошо следовать правилу гласящему, что больше информации — лучше.

Фаза технической документации

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

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

Требования к многопользовательской игре

Необязательный выделенный сервер

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

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

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

Фаза разработки

В течение фазы разработки мы разрабатываем игру. Ключевые моменты этой фазы:

  • Контроль исходного кода.

  • Управление метками.

  • Отслеживание ошибок.

  • Тестирование отдельных частей.

Контроль исходного кода

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

Управление метками

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

Отслеживание ошибок

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

Тестирование отдельных частей

Тестирование частей — это испытание разработчиком его собственного изделия. Перед тем, как отправить игру команде тестировщиков, разработчики, как предполагается, проверяют ее самостоятельно. В моём случае команда тестировщиков отсутствовала.

Фаза тестирования

В фазе тестирования команда тестировщиков подвергает вашу программу различным испытаниям. Обычно у команды тестировщиков есть документ, называемый план возвратного тестирования (regression plan), содержащий список испытаний, которым следует подвергнуть вашу программу. Если все пункты плана возвратного тестирования выполняются без ошибок, ваш код значительно продвигается к стадии бета-версии.

Системные тестировщики также выполняют для вашего кода то, что называется стрессовым тестированием (negative testing). Предположим, у вас есть поле ввода в котором игрок указывает количество отрядов, которые будут отправлены в боевую группу. Системный тестировщик может ввести буквы вместо цифр, чтобы увидеть что случится. Также тестировщик может ввести отрицательное или слишком большое положительное число, чтобы посмотреть не приведет ли это к аварийному завершению вашего кода.

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