Разработка игры «Морской бой» с АИ

Министерство  образования и  науки

Российской  Федерации Федеральное  агентство по образованию

Государственное образовательное  учреждение высшего  профессионального  образования

«» 
 

Курсовая  работа

   на  тему «Разработка игры «Морской бой» с АИ»

По дисциплине «Технология Разработки Программных Продуктов»

Специальность «Программное обеспечение вычислительной техники и автоматизированных систем» () 
 
 

 
 
 
 
 
 
 
 
 

Санкт-Петербург

2010/2011

Аннотация

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

 

Оглавление 
Введение

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

 

1 Определение  требований

     1.1 Описание бизнес процесса

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

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

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

 

     1.2 Обзор аналогов

     Продукт компании ЦТО ООО «ФАРАОН»

     АТОЛ: Рабочее место  кассира

       
 

     Плюсы: приятный интерфейс, позволяющий долгое время находиться за монитором, возможность удаления товара из списка нажатие клавиши, полностью самостоятельное Win32-приложение для Windows 98 / ME / NT / 2000 / XP / 2003 / Vista

     Минус: Обилие кнопок и функций может  «навредить» при работе с этой системой при ошибке сотрудника. 

     Продукт компании "Центр КТ"

     "ШТРИХ-М:  РМК 6.0"

     

        

     Плюсы: легкий в плане восприятия пользователями программный продукт, не требующий специальных навыков и знаний для работы с ним, что касается операционной системы, кассовая программа "ШТРИХ-М: РМК 6.0" оптимизирована как для работы в среде Win32, так и в среде Linux.

     Минусы: недостаток функции, таких как например оплата по безналичному расчету, делает программу не конкурентно способной.  
 
 

Таблица 1 -  Сравнение аналогов

 
 
 
 
 

     1.3 Моделирование требований

     Описание диаграмм IDEF0 и UML Use Case: в один момент времени с системой может взаимодействовать только один человек, сетевого режима не предусмотрено. На верхнем уровне диаграммы IDEF0  (А-0) изображена вся система в целом с входными и выходными данными и используемыми ресурсами. На нижнем уровне А0 раскрываются последовательно процессы системы.

     1.4 Выбор модели жизненного цикла

Таблица 2 -  Выбор модели ЖЦ

     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)->EnableWindow(FALSE);

     А так же, не менее важно изменение  надписи на кнопке при нажатии на неё. Это реализуется следующим образом:

           CString SW;

           SW="X";

           ka1.SetWindowTextW((LPCTSTR)SW);

     Игра  продолжается до тех пор, пока у каждой из сторон есть хотя бы одно «поле» одного корабля. Проверка осуществляется следующим  образом: создается по одной переменной для каждого корабля, которые (переменные) наращиваются в случае попадания. После каждого хода происходит проверка, все ли эти переменные достигли своего максимума (т.е. «все ли корабли потоплены?»), и, если «да» - выдается соответствующее сообщение.