Разработка программного модуля для компьютерной игры
Дипломная работа - Компьютеры, программирование
Другие дипломы по предмету Компьютеры, программирование
?граммно сформированные данные в памяти.
Этот подход был заложен в операционных системах UNIX. Он отличается высокой гибкостью и прозрачностью в использовании. Его реализация позволяет полностью инкапсулировать код, отвечающий за непосредственную работу с разнородными хранилищами, и предоставить единый интерфейс на все файловые операции.
Используя этот подход, был разработан модуль, задачей которого является прозрачная работа с файловыми ресурсами вне зависимости от хранилища, из которого они получены - дисковый каталог, сеть, архив, зашифрованное хранилище, exe-файл или dll-файл. Архитектура модуля предусматривает максимально простое подключение к существующим проектам, а так же простое расширение функционала:
) Увеличение количества типов поддерживаемых файловых подсистем (хранилищ). Предусмотрен специальный интерфейс, реализуя который можно реализовать и подключить новую подсистему.
) Наращивание механизмов эвристики по выбору вариантов файлов в случае использования параллельных веток. Предусмотрен механизм передачи внешнего функтора для сравнения файлов.
Модуль реализует работу с алгоритмами архивации zip, шифрованием по алгоритму CRC32, с сетью и с ресурсами исполняемых файлов Win32.
Выбор средств разработки определялся удобством интеграции в существующие проекты, а также быстродействием результирующего модуля. В силу того, что программирование в MiSTland ведется на языке С++, модуль также был реализован на C++ и с использованием идеологии STL. Из инструментальных средств, выбор пал на Microsoft Visual Studio 7.1, STLport, BOOST и zlib. Проектирование велось в Rational Rose, для не-UML схем использовался Microsoft Visio.
Предлагаемый модуль является dll-библиотекой, подключаемой к любому проекту через интерфейс на языке С++, и обеспечивающий требуемый функционал, используя стандартные потоки языка C++.
В технологической части и программной документации освещены этапы решения задачи, принципы тестирования и отладка. Отдельная глава посвящена вопросу надежности.
В организационно-экономическом разделе рассчитаны себестоимость разработки модуля и его цена.
В производственно-экологическом разделе рассмотрены вредные факторы, присутствующие на рабочем месте программиста, психофизиологические факторы, требования к освещенности помещения, шуму, электро- и пожаробезопасности, спланировано само рабочее место и организация работы программиста с компьютером.
Раздел 1. Специальный раздел
.1 Исследовательская часть
В специальном разделе пояснительной записки к дипломному проекту я опишу основные стадии разработки программного модуля VFS: постановка задачи, предварительные НИР и техническое задание. На этапе эскизного проектирования будут определены требования к входным и выходным данным, составлен общий алгоритм работы модуля. При техническом проектировании будет определена архитектура модуля, детализированы функциональные требования, разработаны основные алгоритмы работы, описана конфигурация технических средств.
1.1.1 Постановка задачи
Общая проблематика файловых хранилищ была освещена во введении. Поясню основные принципы работы с файловыми ресурсами в игровых проектах, так сказать, изнутри.
Большинство модулей, так или иначе нуждающихся в файловом вводе, принимают информацию в виде потока, реализованного силами CRT или STL. В силу широкого использования в индустрии средств STL, решения на базе CRT используются всё реже, поэтому закладываться на их использование я не стал - таким образом, стандартным форматом ввода-вывода де-факто в модуле стали std::basic_istream и std::basic_ostream.
Первой задачей модуля является прозрачность в предоставлении файлового потока по имени. Проблемой является физически разделенное размещение данных - в разных каталогах, на разных носителях, в разных форматах. Модуль должен обеспечивать единое пространство имен, связывающее все разрозненные хранилища, и изолирующее от пользовательского кода реальное размещение данных. Подобное поведение модуля обычно называют прозрачностью в отношении пользовательского кода. Естественно, структура имен файлов в модуле должна соответствовать общепринятой (директория/файл), чтобы не усложнять логику работы с ним.
Второй задачей модуля является представление в стандартном виде (как потока STL) файловых данных, полученных из различных по внутренней структуре файловых хранилищ. Как правило, приходится сталкиваться с заархивированными, зашифрованными данными, сетевыми устройствами, платформенно-зависимыми хранилищами (например, данные, зашитые в исполняемые файлы Win32 как ресурсы). В данном контексте сложность составляют ограничения, налагаемые структурой хранилищ.
Третьей задачей модуля является поддержка наличия нескольких файлов, доступных по одному и тому же имени. Выбор между ними должен осуществляться при помощи эвристики системы незаметно для пользовательского кода, а так же при помощи явного указания программистом критерия сравнения файлов. Такой функционал необходим для поддержки нескольких параллельных версий ресурсов - например, в случае исправлений или пользовательских модификаций.
1.1.2 Предварительные НИР
Из постановки задачи следует, что требуемый модуль является самостоятельной подключаемой библиотекой, поэтому в предварительных НИР следует изучить имеющиеся примеры ПО аналогичного назначения. В силу специфики задачи подобные системы как отдельные програ