3.2.1.1. Case-діаграма героя
3.2.1.2. Case-діаграма монстра
3.2.2. Діаграма класів
3.2. 3. Зовнішні персонажі.
Зовнішні персонажі – це монстри.
3.2.3.1. Функції зовнішніх персонажів.
3.2.3.1.1. Переміщення зовнішніх персонажів.
Вони можуть хаотично переміщатись по зоні і при зіткненні с головним персонажем вони його знищують.
3.2. 4
Гіпер посилань не має так, як у нас лише одна зона.
3.2. 5
Зона це видима область, яка зображена на моніторі. Всі дії будуть виконуватись в зоні.
3.2.5.1. Атрибути Зони.
В зоні мають бути такі атрибути: артефакти, житті і монстри.
3.2.5.1.1. Найменування зони.
Його не буде, так як у нас буде лише одна зона.
3.2.5.1.2. Рисунок зони.
Для зображення зони повинен бути рисунок, який повинен бути на весь екран.
3.2.5.1.3. Кнопкі.
В лівому кутку екрана є 2 поля, які показують скільки у нас життів осталось і скільки ми зібрали артефактів.
3.2 .6 Гра Final Fantasy
3.2.6.1. Атрибути гри.
3.2.6.1.1. Довготривалість гри.
Повинна зберігатись запис про тривалість кожної гри.
3.2 .7 Персонаж Final Fantasy.
3.2.7.1. Атрибути персонажу.
3.2.7.1.1. Ім’я персонажу.
Кожен персонаж повинен мати унікальне ім’я, яке в майбутньому можна буде задавати
3.2.7.1.2. Характеристики.
Кількість життів, початкові координати, кількість знайдених артефактів, розмір кроку.
3.2.7.1.3. Зображення персонажу.
Кожен персонаж буде зображений своєю картинкою розмірами 25рх по горизонталі і 30рх. По вертикалі.
3.2. 8 Персонаж гравця.
В грі буде персонаж яким буде управлять гравець
3.2.8.1. Атрибути персонажу гравця.
Персонаж противника (монстра).
Персонаж який управляється комп’ютером і служить противником персонажу гравця.
Атрибути персонажу противника
3.3. Вимоги до ПК
Процесор з частотою не менше 1.2 Ггц, ОЗП 512 Мб,ОС Windows XP чи пізніша, клавіатура, мишка.
3.4. Обмеження проектування.
Програма повинна розроблятись з використанням методу об’єктно-орієнтованого програмування.
Запускатись програма буде без яких-небуть перед установок.
3.5. Атрибути програмной системи.
3.5.1. Надійність.
Гра буде абсолютно надійною.
3.5.2. Доступність.
Гра повинна буде запускатись на комп’ютері з операційною системою Windows 7.
3.5.3. Захист.
В майбутніх версіях гри буде можливість доступу до збережених ігр лише за наявності пароля.
3.5.4. Підтримка.
3.5.4.1. Змінення персонажів і зон.
В майбутніх версіях гри буде можливість зміни персонажів а також локацій.
5. Проектна документація
Каркас архітектури рольової гри
Історія версій даного документа,
15/01/2013 Тичина В.Е.: первісний чорновий ескіз.
18/01/2013 Тичина В.Е: вдосконалена і сильно змінена схема пакета,
19/01/2013 Горецький О..: критичний огляд, зауваження.
20/01/2013 Сташкевич Б.С.: переглянута робота з компонентами, включеними в неї
Присяжнюк Д.
21/01/2013 Буковчик Ю.: деталі класів переміщені в розділ 3.
1. Введення
1.1. Мета
У даному документі наведено опис пакетів і класів каркаса рольової відеогри.
1.2. Опис проекту
Каркас відображає сутність та основи класів рольової гри. Він створюється з навчальною метою, щоб продемонструвати приклад каркаса. Він не призначений для створення каркасу для комерційних ігор. Він невеликий за розмірами, що сприяє навчанню.
1.3. Визначення, скорочення і терміни
Каркас - збори взаємопов'язаних класів, які використовують для створення сімейств додатків за допомогою спадкування або агрегації.
РГ (рольова гра) - відеогра, в якій персонажі взаємодіють. Характер взаємодії залежить від характеристик персонажів і від середовища, в якому вони знаходяться.
2. Посилання
Software Engineering: an Objected-Oriented Perspective. E. Braude, Wiley, 2000.
UML: The Unified Modeling Language User Guide. G. Booch, J. Rumbaugh, I.Jacobson, Addison-Wesley, 1998 [15].
Стандарт IEEE 1016-1987 (затверджений заново у 1993 році) встановлює основні напрямки розробки SDD.
3. Опис декомпозиції
3.1. Модульна декомпозиція
Каркас складається з пакетів РольоваГра, Персонажі, Артефакти та Схема.
Всі класи є відкритими, якщо не вказано інше.
3.1.1. Пакет РольоваГра
Даний пакет спроектований як машина переходів по станам. Основна ідея полягає в тому, що рольова гра завжди знаходиться в одному з декількох станів. Даний пакет дозволяє описати можливі стану гри і ті дії, які можуть відбуватися у відповідь на події. У пакеті реалізується зразок проектування State [Ga]. Стан гри інкапсульовані в певний об'єкт СтанГри, а він, у свою чергу, агрегується одиночним об'єктом РольоваГра. Цей агрегований об'єкт називається стан. Іншими словами, стан - це атрибут об'єкта РольоваГра, що відноситься до типу СтанГри.
3.1.2. Пакет Персонажі
Цей пакет містить клас ПерсонажГри, в якому дається опис персонажів гри.
3.1.3. Пакет ІгроваСередовище
У даному пакеті дається опис фізичного середовища, в якій проходить гра. Клас СхемаГри агрегує об'єкти з'єднань. Кожен об'єкт з'єднання агрегує пару об'єктів ІгроваЗона, які він пов'язує. Дана архітектура дозволяє здійснювати численні з'єднання між двома зонами.
Кожен об'єкт ІгроваЗона агрегує персонажі гри, які він містить (якщо містить), і може фіксувати зустріч персонажів.
3.1.4. Пакет Артефакти
Даний пакет призначений для зберігання елементів, які слід розташувати в зонах, таких як дерева або столи, а також предметів, якими володіють персонажі, наприклад щитів і ранців.
3.2. Декомпозиція на паралельні процеси
Каркас не включає в себе і не зачіпає паралельні процеси.
4. Опис залежностей
Єдина залежність між модулями каркаса полягає в агрегації класу ПерсонажГри класом ІгроваЗона.
5. Опис інтерфейсу
Всі класи в даних пакетах є відкритими, таким чином, інтерфейси складаються з усіх методів їх класів.
Архітектура рольової гри FinalFantasy. SDD, частина 1
Історія версій цього документа.
15/01/2013 Тичина В.Е.: первісний ескіз.
18/01/2013 Присяжнюк Д. складена загальна схема.
19/01/2013 Горецький О. виявлення дефектів.
20/01/2013 Тичина В.Е.: додаткові компоненти, запропоновані Горецьким О.
21 /01/2013 Тичина В.Е.: додаткова розбивка на компоненти відповідно варіантам використання і моделі переходів станів.