Разработка программного модуля для компьютерной игры - Дипломная работа

По объему задействованных технологий, привлеченных средств и уровню профессиональной подготовки разработчиков игровая индустрия давно заняла отнюдь не последнее место в мире IT. Развитие многих программных технологий, в частности, всех мыслимых способов отрисовки трехмерных изображений, идет именно благодаря играм. Имеет место проблема организации ресурсов, в частности, информации на диске. Ситуация в индустрии диктует еще одно требование: необходима возможность работы с несколькими параллельными версиями ресурсов - это нужно для корректной установки патчей (пакетов исправлений и дополнений) и пользовательских модификаций. Используя этот подход, был разработан модуль, задачей которого является прозрачная работа с файловыми ресурсами вне зависимости от хранилища, из которого они получены - дисковый каталог, сеть, архив, зашифрованное хранилище, exe-файл или dll-файл.В специальном разделе пояснительной записки к дипломному проекту я опишу основные стадии разработки программного модуля «VFS»: постановка задачи, предварительные НИР и техническое задание.Большинство модулей, так или иначе нуждающихся в файловом вводе, принимают информацию в виде потока, реализованного силами CRT или STL. В силу широкого использования в индустрии средств STL, решения на базе CRT используются все реже, поэтому закладываться на их использование я не стал - таким образом, стандартным форматом ввода-вывода де-факто в модуле стали std::basic_istream и std::basic_ostream. Модуль должен обеспечивать единое пространство имен, связывающее все разрозненные хранилища, и изолирующее от пользовательского кода реальное размещение данных. Естественно, структура имен файлов в модуле должна соответствовать общепринятой (директория/файл), чтобы не усложнять логику работы с ним. Второй задачей модуля является представление в стандартном виде (как потока STL) файловых данных, полученных из различных по внутренней структуре файловых хранилищ.В силу специфики задачи подобные системы как отдельные программные модули, как правило, реализуются только в стенах софтверных компаний, имеющих в таких модулях необходимость - потенциальный рынок таких систем невелик. Библиотека boost::filesystem является свободно распространяемой в рамках пакета BOOST, продвигаемого комитетом по стандартизации C . Эта библиотека призвана облегчить «сборку» пути до файла и некоторые операции с путем. Эта библиотека реализует часть требуемого в ТЗ функционала, конкретно - единообразное представление клиентскому коду данных файлов и возможность итерирования файлов. Задача абстракции от конкретного типа хранилища наиболее полно решена на данный момент в системе Linux (и в большинстве используемых ныне *nix-систем) комплексом под названием VFS (Virtual File System).Основные требования, которые предъявлялись к модулю: 1) Открытие файлов на чтение и запись. 3) Возможность подключать хранилища из сети, зип-архивов с шифрацией и без, из исполняемых файлов Win32. Создаваемый модуль должен обеспечивать «прозрачное» выполнение файловых операций, проводимых клиентским кодом, в том числе: 1) Открытие файла на чтение и предоставление входного потока на него стандартной библиотеки С , согласно относительной системе именования, принятой в структуре данных проекта. Для эффективного управление списком файловых хранилищ (в дальнейшем - «подсистем») модуль должен обеспечивать следующие операции: 1) Наличие системы виртуальных директорий для организации разветвленных виртуальных пространств именования файлов. Для обеспечения гибкости работы модуля необходимо наличие следующих особенностей: 1) Система должна позволять сосуществовать нескольким файлам, доступным по одинаковому имени (в разных подсистемах).На рисунке 1.1. поясняется, что является входными и выходными данными модуля. Для начальной инициализации VFS клиентский код монтирует подсистемы. Происходит это так: создается объект подсистемы, например, дисковой, инициализируется каталогом на диске, который должен быть представлен этой подсистемой, а также указанием необходимых атрибутов доступа (пароли, права), а потом передается ядру VFS вместе с желаемым расположением в дереве виртуальных директорий. Ядро VFS запустит алгоритм поиска файла с таким именем в виртуальном дереве. Ядро VFS идентифицирует все файлы, чье имя соответствует маске поиска (считается, что все такие файлы лежат в одной виртуальной директории) и выдаст наружу объект, позволяющий вести перебор аналогично контейнеру STL.Общая схема работы модуля выглядит следующим образом: 1) В случае работы со списком подсистем клиентский код должен создать подсистему, определиться с ее виртуальным путем и передать ее ядру. 2) В случае запросов к общему интерфейсу - собственно, основному интерфейсу VFS - во всех случаях запускается универсальный механизм создания итератора, он формирует специфической структуры список дескрипторов, подходящих под маску поиска и путь (маской поиска может выступать конкретное имя файла), с которым далее может происходить следующее: а) В случае запроса на итери

Содержание

Введение

Раздел 1. Специальный раздел

1.1. Исследовательская часть

1.1.1. Постановка задачи

1.1.2. Предварительные НИР

1.1.3. Информационные потребности пользователей

1.1.4. Требования, предъявляемые к системе

1.2. Конструкторская часть

1.2.1. Структура входных и выходных данных

1.2.2. Общая схема работы модуля

1.2.3. Выбор платформы проектирования и его обоснование

1.2.4. Проектирование архитектуры модуля

1.2.5. Конфигурация технических средств

1.2.6. Алгоритмы работы модуля

1.2.7. Методика тестирования

1.2.8. Результаты экспериментальной проверки

Раздел 2. Технологический раздел

2.1. Проектирование на языке UML

2.1.1. Концепция Unified Modeling Language

2.1.2. Виды диаграмм UML

2.1.3. Связь с объектно-ориентированными языками

2.2. Идеология STL в применении к архитектуре модуля8

2.2.1. Шаблоны в C

2.2.2. Контейнеры

2.2.3. Алгоритмы

2.2.4. Потоки

Современные компьютерные игры - крупные и сложные программные комплексы. Затраты только на программную разработку часто измеряются сотнями человеко-месяцев. По объему задействованных технологий, привлеченных средств и уровню профессиональной подготовки разработчиков игровая индустрия давно заняла отнюдь не последнее место в мире IT.

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

Одной из отличительных черт игры как компьютерного приложения является работа с огромным количеством ресурсов. Текстуры, музыка, видео, скрипты часто исчисляются гигабайтами, особенно в последнее время. Имеет место проблема организации ресурсов, в частности, информации на диске. Применение СУБД в данном случае сопряжено с техническими и экономическими сложностями: 1) Для представления данных в табличном или объектном виде чаще всего нужна их обработка. Сама по себе СУБД - отдельное приложение, с которым нужно устанавливать связь, разделять ресурсы и т.д. Редактирование данных на этапе разработки вызовет сложности. Также тяжело решить некоторые специфичные проблемы, речь о которых пойдет ниже.

2) Современные быстродействующие СУБД стоят довольно больших денег, и в случае с распространением игры как товара, как правило, требуется отдельное лицензирование.

Чаще всего разработчики реализуют иерархические структуры на диске. В силу внешних причин отдельные части ресурсов могут быть заархивированы и/или зашифрованы. Часть ресурсов может быть оставлена на ключевом носителе (сейчас в этой роли часто выступает оптический диск), который тоже может быть защищен по какой-либо технологии (оптический диск - STARFORCE, LASERLOCK и другие). Также ресурсы могут быть размещены на сетевом сервере, что накладывает свои требования к доступу, верификации и иногда к защите. Ситуация в индустрии диктует еще одно требование: необходима возможность работы с несколькими параллельными версиями ресурсов - это нужно для корректной установки патчей (пакетов исправлений и дополнений) и пользовательских модификаций. В результате разработчики часто оказываются перед распределенным комплексом весьма сложных по структуре хранилищ. Кроме того, необходимость знать о типах хранилищ и особенностях работы с ними, вызывает резкое усложнение кода и затрудняет его повторное использование.

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

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

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

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

Используя этот подход, был разработан модуль, задачей которого является прозрачная работа с файловыми ресурсами вне зависимости от хранилища, из которого они получены - дисковый каталог, сеть, архив, зашифрованное хранилище, exe-файл или dll-файл. Архитектура модуля предусматривает максимально простое подключение к существующим проектам, а так же простое расширение функционала: 1) Увеличение количества типов поддерживаемых файловых подсистем (хранилищ). Предусмотрен специальный интерфейс, реализуя который можно реализовать и подключить новую подсистему.

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

Модуль реализует работу с алгоритмами архивации zip, шифрованием по алгоритму CRC32, с сетью и с ресурсами исполняемых файлов Win32.

Выбор средств разработки определялся удобством интеграции в существующие проекты, а также быстродействием результирующего модуля. В силу того, что программирование в MISTLAND ведется на языке С , модуль также был реализован на C и с использованием идеологии STL. Из инструментальных средств, выбор пал на Microsoft Visual Studio 7.1, STLPORT, BOOST и zlib. Проектирование велось в Rational Rose, для не-UML схем использовался Microsoft Visio.

Предлагаемый модуль является dll-библиотекой, подключаемой к любому проекту через интерфейс на языке С , и обеспечивающий требуемый функционал, используя стандартные потоки языка C .

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

В организационно-экономическом разделе рассчитаны себестоимость разработки модуля и его цена.

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