Разработка игры «Морской бой» с АИ
Министерство образования и науки
Российской Федерации Федеральное агентство по образованию
Государственное образовательное учреждение высшего профессионального образования
«»
Курсовая работа
на тему «Разработка игры «Морской бой» с АИ»
По дисциплине «Технология Разработки Программных Продуктов»
Специальность
«Программное обеспечение вычислительной
техники и автоматизированных систем»
()
| Преподаватель:
________________________ «___»_________20__г. |
Выполнил:
дневного отделения |
Санкт-Петербург
2010/2011
Аннотация
Во введении находится общая информация о курсовом проекте. Раздел «Определение требований» содержит информацию, с разных сторон охватывающую требования к создаваемой системе. Раздел «Проектирование» описывает всю механику создания конечного программного продукта. В разделе «Верификация и аттестация» описано предстоящее тестирование программы, раздел «Программная документация» содержит пользовательские инструкции по установке и эксплуатации.
Оглавление
Введение
Цель курсовой работы – создание кассовой системы для магазина. Поскольку, конечный программный продукт очень трудоемкий в аспекте написания исходного кода, было принято решение первоначального создания упрощенной альфа-версии игры, то есть с возможностью оплаты только наличным расчетом, а так же без учета карты на скидку.
1 Определение требований
1.1 Описание бизнес процесса
На данный момент существует множество кассовых систем различных компаний, однако не многие из них имеют возможность учитывать количество товара находящегося на полках и на складе и при необходимости сообщать о необходимости выставить недостающий товар на полки. Область распространения создаваемого программного продукта концентрируется на торговой точке заказчика, и в последствии на других торговых точках. Для реализации продукта необходимо грамотно размещать рекламу в СМИ и на специализированных сайтах (этот вопрос требует дополнительного исследования, не входящего в рамки данного документа).
Для
того чтобы продукт стал основной
системой магазина-заказчика необходимо
сделать его максимально
Главная идея системы, это связь между торговым залом и складом, за счет которой упрощается работа сотрудников.
1.2 Обзор аналогов
Продукт компании ЦТО ООО «ФАРАОН»
АТОЛ: Рабочее место кассира
Плюсы: приятный интерфейс, позволяющий долгое время находиться за монитором, возможность удаления товара из списка нажатие клавиши, полностью самостоятельное Win32-приложение для Windows 98 / ME / NT / 2000 / XP / 2003 / Vista
Минус:
Обилие кнопок и функций может
«навредить» при работе с этой
системой при ошибке сотрудника.
Продукт компании "Центр КТ"
"ШТРИХ-М: РМК 6.0"
Плюсы: легкий в плане восприятия пользователями программный продукт, не требующий специальных навыков и знаний для работы с ним, что касается операционной системы, кассовая программа "ШТРИХ-М: РМК 6.0" оптимизирована как для работы в среде Win32, так и в среде Linux.
Минусы:
недостаток функции, таких как например
оплата по безналичному расчету, делает
программу не конкурентно способной.
Таблица 1 - Сравнение аналогов
| Критерии/игры/оценка (0-10) | 1 | 2 | 3 |
| Функционал | 10 | 8 | 10 |
| Оплата по безналу | + | - | 8 |
| Совместимость с ОС | 9 | 6 | 9 |
| Удобство интерфейса | 5 | 7 | 5 |
1.3 Моделирование требований
Описание диаграмм IDEF0 и UML Use Case: в один момент времени с системой может взаимодействовать только один человек, сетевого режима не предусмотрено. На верхнем уровне диаграммы IDEF0 (А-0) изображена вся система в целом с входными и выходными данными и используемыми ресурсами. На нижнем уровне А0 раскрываются последовательно процессы системы.
1.4 Выбор модели жизненного цикла
Таблица 2 - Выбор модели ЖЦ
| Модель ЖЦ | Процент «подходимости» |
| Модель ЖЦ | Процент «подходимости» |
| Каскадная модель | 30-40% |
| Модель прототипирования | 15-20% |
| Инкрементная модель | 20-30% |
| V-образная модель | 50-60% |
| Спиральная модель | 80-90% Оптимальной для данного программного продукта является спиральная модель, так как взаимосвязь с заказчика с развитием системы идет с самого раннего этапа, а так же снижается риск неудачи и изменения требований. |
1.5 Описание технического задания
Так как, заказчик ПП является новым «участником» этой отрасли, то все решения и действия, а так же логика и внешний вид программы, в ходе разработки и при создании ТЗ определяются одним единственным человеком, отражая его позицию насчет того, «как должна выглядеть кассовая система» без каких-то дополнительных объяснений или оговорок.
2 Проектирование
2.1 Выбор модели системы
Выделяют три модели архитектуры системы: Модель репозитария, модель «Клиент-Сервер» и Абстрактная машина. Первая модель подразумевает использование отдельного хранилища информации, к которому будут иметь доступ разные компоненты системы, которые, в свою очередь, никакой информации не хранят. Такая модель архитектуры хорошо подходит для систем с большим объемом данных. Так как в «Морском бое с АИ» хранимых данных крайне мало, и обращающихся к памяти модулей тоже – данная система для проекта не подходит. Модель «Клиент-Сервер» так же не подходит по следующим причинам: нет необходимости в дополнительном разбиении системы на клиентскую и серверные части; нежелательна зависимость работы программы от наличия доступа к сети; игра абсолютно локальна, поэтому потенциал такой модели (использование одних и тех же ресурсов разными пользователями) использован не будет. Оставшаяся модель абстрактной машины и подходит для данной игры.
Помимо различных архитектур системы, задачу можно решать разными способами:
Локальная/сетевая система
Здесь выбор останавливается на локальной версии; обоснования приведены выше.
Плагин/компонент/
Плагин и компонент в нашем случае не подходят, т.к. программа самостоятельна и автономна. Комплекс программ – попросту не нужен: система довольно проста.
Компилируемое/скриптовое приложение
Реализовывать можно обоими способами, но т.к. написание на скриптовом языке влечет за собой требование к наличию у пользователя специального обработчика, что не есть хорошо, и сложнее относительно компилируемого языка при разработке ПП для автора этого документа, выбор остается за компилируемым вариантом.
Распределенная/локальная система
Т.к.
на каждую машину будет ставиться
полная автономная копия ПП, надобности
в распределенной системе нет.
Component
Diagram
На диаграмме изображены компоненты создаваемой системы: интерфейс пользователя, через который в игру поступают все команды, модуль AI, отвечающий за действия схожие с пользовательскими (расстановка кораблей, выстрелы), но производимые «за» сторону компьютера, и само игровое пространство, где хранится информация о текущем состоянии игрового поля. Все это будет располагаться на одном компьютере.
2.2 Проектирование структуры системы
Class Diagram
На диаграмме представлены классы, использующиеся при создании игры: класс, отвечающий за каждый конкретный корабль с соответствующими атрибутами, класс, формирующий игровые поля и, собственно, связующее звено – «игра» (содержит информацию о последовательности ходов и состоянии полей).
2.3 Проектирование логики работы
Логика работы программы описана в следующих диаграммах:
Communication
Diagram
На данной диаграмме отображаются последовательности возникновения «связей» (команд, операций); раскрывается механизм игры. После выбора в главном меню игроком пункта «Новая игра» происходит создание полей игрока и компьютера с расстановкой на них кораблей и дальнейшими действиями (выстрелы, определение победителя) по всем существующим (внесенных в механизм разработчиком) правилам игры «Морской Бой».
State Machine Diagram
Диаграмма
показывает изменения, которые могут
происходить с объектом игры «Поле»
в результате расстановки кораблей
или наступления события «
Activity Diagram
На диаграмме иллюстрируется ход игры: расстановка кораблей одним из 2х способов, серии выстрела игрока и компьютера.
2.4 Проектирование интерфейса
На рисунке показано основное окно приложения, в которое попадает пользователь после процедуры расстановки кораблей.
3 Разработка программного кода
В
основе программного продукта лежит
скрытие соответствующих
GetDlgItem(IDC_BUTTON_ID)
А так же, не менее важно изменение надписи на кнопке при нажатии на неё. Это реализуется следующим образом:
CString SW;
SW="X";
ka1.SetWindowTextW(
Игра продолжается до тех пор, пока у каждой из сторон есть хотя бы одно «поле» одного корабля. Проверка осуществляется следующим образом: создается по одной переменной для каждого корабля, которые (переменные) наращиваются в случае попадания. После каждого хода происходит проверка, все ли эти переменные достигли своего максимума (т.е. «все ли корабли потоплены?»), и, если «да» - выдается соответствующее сообщение.
if((k1==1)&&(k2==2)
unshow(); // функция блокирования
оставшихся кнопок игрового
result="
UpdateData(
};
4 Верификация и аттестация
4.1 Выбор методов верификации и аттестации
Тестирование подразумевает под собой ответ на вопрос: все ли поставленные требования к программному продукту были выполнены, насколько верно и корректно.
Тестирование включает в себя
- Тестовые данные
- Карта ошибок (какие проблемы в работе были выявлены)
- Тестирование проектной документации
- Тестирование готового программного кода
Стоит отметить, что тестирование не показывает наличие ошибок, а лишь определяет их отсутствие (наличие) на определенных входных данных.
- Тестирование белого (прозрачного) ящика – это доступ к исходному коду; определяется процент его покрытия (сколько кода проверено за один тест).
- Функциональное тестирование – проверка, все ли функции, определенные в ТЗ, есть в программе.
- Ручное тестирование заключается в ручном переборе всевозможных входных данных и в задействовании всех элементов управления программы тестером, а так же в документировании выполненных действий.
- Модульное тестирование – процесс в программировании, позволяющий проверить на корректность отдельные модули исходного кода программы.
- Альфа-тестирование подразумевает под собой тестирование «альфа-версии» программного продукта самими разработчиками.
Создаваемый
программный продукт будет
4.2 Инспектирование
- Расстановка кораблей АИ: Communication Diagram – 5:расстановка кораблей
- Расстановка кораблей АИ: Activity Diagram - расстановка кораблей
- «Выстрел» АИ: Communication Diagram – 9:выстрел
- «Выстрел» АИ: Activity Diagram – ход AI
- «Предоставление» игрового пространства (2 квадратных поля): Communication Diagram- 2:создание пустого поля игрока
- «Предоставление» игрового пространства (2 квадратных поля): Communication Diagram- 3:создание пустого поля компьютера
- Возможность завершения игры в любой момент путем нажатия кнопки «Выход»: Activity Diagram - автопоражение
- Ведение статистики игрового процесса: количество сыгранных «за раз» игр, кол-во побед, поражений: Communication Diagram – 11:результат партии
В ходе выполнения работы были проверены требования поставленные техническим заданием, требования были выполнены качественно и полно, так как на диаграммах отображена достаточно полная информация.
4.3 Тестирование
Поскольку в игре Морской бой («SeaWar») входных данных всего два (нажатие на клавиши-поля компьютера и нажатие кнопки «Выход») – был сделан упор в тестирование «игровых комбинаций». В результате перебора более двадцати «тактик обстрела», сбоев в работе программы выявлено не было. Созданная игра удовлетворяет основным требованиям; остальные будут доработаны в следующих версиях программного продукта.
Как уже было написано выше, игра исключительно верно реагирует на нажатия кнопок-полей «врага». Выйти из игры возможно путем нажатия клавиши «Выход». Выйти иными программными способами (помимо «убийства» соответствующего процесса в диспетчере задач) невозможно; у игры отсутствует контекстное меню на панели задач (эта функция была отключена при создании программы).
5 Программная документация
5.1 Инструкция по установке
Для корректной работы программы необходимо установить Microsoft Visual Studio 2008 года или старше со всеми соответствующими библиотеками. Запуск игры осуществляется с помощью .ехе файла. Для удобства, его можно переместить на рабочий стол или создать ярлык. Рекомендованная конфигурация компьютера: процессор 1Ггц и выше, ОЗУ 512Мб, ОС Windows XP/Vista/7.
5.2 Инструкция пользователя
Запуск программы происходит при двойном щелчке на файле «Kassa.exe». В открывшемся окне в левой части расположено поле игрока, в правой – поле компьютерного оппонента. Так же, внизу окна находится поле для вывода результата партии «Победа/Поражение» и кнопка выхода.
После нажатия на поле компьютера – оно «вскрывается» и блокируется от повторных нажатий. Вскрытое поле может оказаться пустым (будет изображен знак «*»), может содержать одну палубу корабля (будет изображен знак «х»). В случае уничтожения всех палуб какого-либо корабля – по его периметру вскрываются и блокируются пустые поля, таким образом игрок понимает, что корабль уничтожен.
Игра проходит по классическим правилам, то есть после каждого неудачного выстрела одной стороны – в бой вступает другая.
Для начала новой игры необходимо перезапустить программу.
Заключение
Была
создана кассовая система. Она полностью
функционирует согласно поставленному
заданию, однако, нуждается в доработке:
для того, что бы считать данный ПП законченным,
необходимо дописать модули возможности
оплаты по безналичному расчетом, а так
же модуль учета карты на скидку
Приложение 1 Техническое задание
1 Назначение разработки
Программный продукт разрабатывается для продажи в торговые точки.
2 Цель и задачи
Целью разработки кассовой системы является получение прибыли в результате ее продажи.
3 Требования к разработке
3.1 Требования к функциональным характеристикам
Расстановка кораблей АИ: в начале игры компьютер должен произвести расстановку «своих» кораблей на игровом поле – корабли расставляются от большего к меньшему (один 4х-палубный, два 3х-палубных, три 2х-палубных и четыре одно-палубных). Генерацией случайных чисел определяются координаты корабля и его расположение (горизонтальное/вертикальное). Если последним кораблям «не хватает» места – игровое поле генерируется заново. Данный механизм обеспечит уникальность и совершенность каждой игровой партии.
«Выстрел» АИ: «чистый» выстрел (когда ранее не было попаданий) происходит на основе случайно-сгенерированных координат из числа «свободных». В случае промаха – последующий выстрел осуществляется таким же способом. Если же было попадание (в этом или предыдущем ходе), происходит оценка потенциально-оставшихся на поле кораблей с учетом «рельефа» карты (что позволит заведомо отсечь «неправильное» направление следующих выстрелов), после чего направление последующих выстрелов выбирается из оставшихся случайно и сохраняется в случае попадания либо до «затопления», либо до промаха.
«Предоставление» игрового пространства (2 квадратных поля)
Возможность завершения игры в любой момент путем нажатия кнопки «Выход»
Ведение статистики игрового процесса: количество сыгранных «за раз» игр, кол-во побед, поражений.
3.2 Описание входных и выходных данных
Таблица 3 - Входные и выходные данные
Функция Входные параметры Выходные параметры Расстановка кораблей АИ - Координаты и положение корабля; вызов функции пересоздания поля в случае «нехватки» места. «Выстрел» АИ Информация о предыдущем успешно выстреле АИ Координаты нового выстрела Статистика Сыгранные партии (последовательно) Формальная статистика (кол-во игр, % побед, % поражений)
3.3 Модель работы продукта разработки
3.4 Требования к надежности
Система защищена паролем.
3.5 Эргономические и техникоэстетические требования
ПП представляет собой одно перемещаемое окно размером 900*600px. Так же должны быть всплывающие окна, информирующее о победе/поражении, а так же требующие подтверждения в случае нажатия кнопки «выход».
3.6 Требования к защите информации
К системе имеет доступ ограниченное число людей, с индивидуальным паролем.
3.7 Другие требования к разработке
Данные требования к системе не предъявляются.
3.8 Требования к аппаратно-программному комплексу
Windows XP, Vista, 7.
3.9 Требования к технологиям разработки
При разработке программного продукта будут использованы следующие программные комплексы:
Microsoft Office 2003
Microsoft Visual Studio 2010
Visual Paradigm
Ramus
3.10 Требования к составу технических средств при эксплуатации
-
4 Методы тестирования соответствия разработки предъявленным требованиям
Тестирование будет произведено методами, описанными в п. 4.1 в течении двух недель с момента выхода рабочей версии программы.
Приложение 2 Программный код
// SeaWarDlg.cpp : файл реализации
void CSeaWarDlg::kshot() { // функция выстрела АИ
CString SW;
switch (step) {
case 0:
SW="X";
pd1.
SW="*";
pg1.
pg2.
pd2.
SW="*";
pv3.
break;
case 1:
SW="*";
pb3.
break;
case 2:
SW="X";
pg4.
pg5.
SW="*";
pg3.
pd3.
pd4.
pd5.
pv4.
pv5.
break;
case 3:
SW="*";
pb5.
break;
case 4:
SW="*";
pb4.
break;
case 5:
SW="X";
pa2.
SW="*";
pa3.
break;
case 6:
SW="X";
pb2.
pv2.
SW="*";
pa1.
pb1.
pv1.
