
- •Перелік умовних скорочень
- •Аналіз предметної області. Вибір компонентної технології
- •1.1 Основні концепції компонентної розробки прикладних задач
- •1.2 Модель com/dcom
- •1.3 Модель Java Beans
- •1.4 Технологія розподіленого програмування corba
- •1.5 Технологія .Net
- •2 Розробка технічного завдання
- •3 Розробка стратегії гри для кожної категорії учасників
- •4 Створення об'єктної моделі системи
- •5 Розробка власного компоненту
- •6 Програмна реалізація спроектованої системи
- •6.1 Опис взаємодії гри з користувачем
- •6.2 Загальні відомості про програму
- •Висновки
- •Список літератури
- •Додаток а
- •Додаток б
- •Затверджую
- •Додаток в
- •Додаток г
- •Додаток д
6 Програмна реалізація спроектованої системи
В ході курсової роботи перед нами постає завдання у реалізації комп’ютерної гри «Дуель». В розробці було вжито деякі особливості, на яких я би хотів зупинити увагу.
Реалізації взаємодії між гравцем та системою був розроблений за допомогою Microsoft Visual Studio.
На етапі основного виробництва виконується величезний обсяг робіт. Спочатку пишеться вихідний код, малюється графіка, такі як спрайт. Величезний обсяг роботи також припадає на створення та розробку моделей відображення об’єктів на формі.
Весь цей час доповнюється та змінюється ігровий дизайн, щоб відобразити поточне бачення гри. Деякі особливості або аспекти гри можуть бути видалені, деякі додані. Художня трактування може еволюціонувати, а процес гри - змінитися. Може з'явитися нова цільова платформа, а також нова цільова аудиторія.
З точки зору часу перший рівень гри розробляється довше за всіх інших. Оскільки при створенні самої концепції і графіки використовуються інструменти для створення та відображення об’єктів, потрібні можливості і зміни внутрішніх інструментів. З появою нових можливостей деякі рівні можуть застаріти, тому в перший рівень гри можуть вноситися різні виправлення. Крім того, в силу динамічної природи розробки ігор, дизайнерське бачення першого етапу з часом може змінюватися. Наступні етапи розроблюються значно швидше, так як список можливостей стає більш повним, а бачення гри - більш ясним.
Тести підключаються до гри, коли з'являється щось іграбельне. Це може бути один рівень або підмножина ігор, що може використовуватися в будь-яких розумних межах. На ранньому етапі тестування гри віднімає відносно малу частку часу. У міру наближення розробки до кінця, гра може почати відбирати для тестів весь час - і навіть понаднормово - оскільки тести намагаються охопити і протестувати нові можливості, для яких існують тести регресії. Сьогодні тестування є життєво важливим для ігор, оскільки, в силу складності більшості з них, одна єдина зміна може призвести до катастрофічних наслідків.
6.1 Опис взаємодії гри з користувачем
Дана програма на самому початку розробки носила характер гри, яка моделює саму фізику дуелі з її невизначеністю та випадковістю результатів. Тому при розробці велику увагу було приділено розробці самої логіки програми, а не інтерфейсу взаємодії з користувачем.
Дана гра передбачає те, що користувач мусить задіяти свою інтуїцію у виборі на якого дуелянта йому потрібно поставити, щоб перемогти, цей аспект і передає весь азарт даної гри .
Зважаючи на це був розроблений інтерфейс гри який представлений на рисунку 6.1
Рисунок 6.1 – Інтерфейс гри «Дуель»
Як видно на Рисунок 4.1 інтерфейс представлений у вигляді об’єкта відображення динаміки подій на якому при запуску промальовуються моделі 5 дуелянтів, та зони взаємодії з користувачем.
Згідно поставленої задачі було розроблено менню яке складається з пунктів таких як , «Гра» рисунок 6.2
Рисунок 6.2 – Пункт меню «Гра»
До даного пункту входять події з допомогою яких користувач може закінчити гру, або почати її з початку.
Наступною необхідною умовою була розробка інструкції рисунок 6.3 з допомогою, якої користувач може дізнатися про дану гру та її запропоновані правила. Дана модель може передбачати формування гравцем власних правил, які не відповідають запропонованим.
Рисунок 6.3 – Пункт меню «Інструкція»
Поле взаємодії із гравцем представлене у вигляді кнопок рисунок 6.4:
«Нова гра»
«Постріл»
«Стоп»
«Автоматична гра»
«Звіт гри»
Рисунок 6.4 – Поле взаємодії із гравцем
Кнопка «Нова гра» виконує перезапуск гри в любий момент часу виконання програми. Також при її натисненні відбувається запуск класів та методів, що відповідають за створення моделей поведінки гравців та їх стратегій, дані стратегії були описані вище. Також вона відповідає за проведення жеребкування та визначення порядку у якому будуть відбуватися постріли дуелянтів.
Моделі гравців представлені на формі круглими областями різних кольорів рисунок рисунок 6.5
Рисунок 6.5 – Відображення дуелянтів на формі
Слідуючим етапом взаємодії користувача з грою є кнопка «Постріл» вона відповідає за реалізацію методу відображення руху кулі та отримання результатів роботи створеної моделі даної гри. При її натисненні відбувається відтворення на екрані першого пострілу гравця згідно із жеребом, якщо він попав в опонента той зафарбовується у червоний колір і втрачає можливість виконання власного пострілу рисунок 6.6
Рисунок 6.6 – Відображення мертвих дуелянтів
Гра буде тривати до того часу поки не залишиться лише один живий гравець тоді зявиться напис із інформацією про переможця рисунок 6.7
Рисунок 6.7 – Відображення мертвих дуелянтів
При розробці програми розглядалась можливість, що користувач даної програми може сам вигадувати правила тому для більшої наглядності того, що відбулося на формі була створена додаткова кнопка «Звіт гри»
При натисненні на неї користувачі можуть отримати детальний звіт даної гри, що усуне будь які конфлікти при зясуванні переможця рисунок 6.8
Рисунок 6.8 – Звіт гри
Також у нас розробленні кнопка «Автоматична гра» дана функція розроблена для того, щоб користувач не затруднявся постійним нажиманням кнопки «Постріл» . Дана кнопка виконує всі кроки автоматично, до моменту закінчення гри це є досить зручно коли гравців стає більше.
Кнопка «Стоп» зупиняє автоматичне виконання гри.