Подякувати Студентському архіву довільною сумою
Admin
26.02.2023 12:38
Дякуємо, що користуєтесь нашим архівом!
Інформація про навчальний заклад
ВУЗ:
Інші
Інститут:
О
Факультет:
ЗІ
Кафедра:
Не вказано
Інформація про роботу
Рік:
2010
Тип роботи:
Інші
Предмет:
Моделювання
Частина тексту файла (без зображень, графіків і формул):
Перелік умовних скорочень
Microsoft .NET -- програмна технологія, платформа для створення програмного забезпечення
Microsoft Visual Studio 2010 - середовище розробки програмного забезпечення
Microsoft XNA - набір інструментів, що полегшує розробку і управління комп'ютерними іграми
XNA Game Studio - середовище розробки комп'ютерних ігор за допомогою Microsoft XNA
UML - уніфікована мова об'єктно-орієнтованого моделювання
DCOM (ActiveX) (Distributed Component Object Model)
CORBA (Common Object Request Brocer Architecture)
OMG (Object Management Goup)
IDL (Interface Definition Language),
Вступ
Компонентне програмування – наступний еволюційний крок на шляху розвитку передових технологій. Воно являє собою логічне продовження структурного і об’єктно-орієнтованого програмування. Компонентне програмування зі своєю появою принесло дуже важливі технологічні елементи: єдину оболонку для функціонування об’єктів, уніфікацію способів взаємодії і доступу до можливостей об’єктів. Воно дозволяє будувати програмне забезпечення по принципу конструктора – із незалежних готових компонентів, що набагато ефективніше, ніж створювати з нуля. Для розробки кожного такого «будівельного блоку» програміст може використовувати будь-яку мову програмування. Але найголовніше, що забезпечується прозорий доступ до віддалених об’єктів.
Концепція компонентного програмування має на увазі повне відокремлення внутрішніх функцій компонента від функцій доступу до нього із зовні. Тобто звертаючись до компоненту зовсім не обов’язково знати його внутрішню будову, для цього досить знати лише те, як викликати цю функцію. Іншими словами, необхідно знати, як взаємодіяти з компонентом, який його інтерфейс.
Таким чином значення слова інтерфейс в мовах програмування має таке ж саме значення, як і в звичайній мові: інтерфейс – це те, що розміщено між двома об’єктами і забезпечує взаємозв’язок між ними. Звідси слідує, що інтерфейс-орієнтоване програмування являє собою технологію розробки програмного забезпечення, жорстко орієнтовану на використання інтерфейсів. Тут, починаючи розробку програми, потрібно в першу чергу розробити інтерфейс, а потім жорстко дотримуватись їх на кожному етапі проектування.
Отже можна сказати, що компонентні об’єктні середовища є найбільш сучасним та природнім фундаментом для накопичення та використання знань з програмування. Подібне середовище базується на компонентній об’єктній моделі. Вона включає в себе готові компоненти, а також інструментальні засоби які дозволяють вибрати компоненти, настроїти їх і зв’язати між собою та об’єднувати.
Компонентні середовища володіють всіма перевагами притаманними об’єктно-орієнтованому підходу.
Інкапсуляція об’єктних компонентів ховає складність реалізації роблячи доступним тільки представлений зовні інтерфейс.
Наслідування дозволяє розвивати створені раніше компоненти, при цьому не порушуючи цілісність об’єктної оболонки.
Поліморфізм дає можливість групувати об’єкти характеристики яких з деякої точки зору схожі.
Частіше всього розподілені об’єкти (компоненти) працюють в конфігурації клієнт-сервер. Самі об’єкти являються серверами - вони реагують на запити і надають клієнту сервіси або ресурси.
З точки зору компонентної моделі, компоненти описується набором інтерфейсів, які вона реалізує. Кожний такий інтерфейс – це свого роду «розетка» до якої повинні під’єднуватися інші компоненти або прикладні задачі.
В даній курсової роботі буде розроблена програма, що моделює багатосторонню гру «Дуель». Дана програма буде створена з використанням компонентних технологій.
В ході роботи буде сформований власний компонент, який буде реалізувати моделювання діагонального руху об’єкта, що в подальшому зможе використовуватися поза межами даної програми.
Аналіз предметної області.
Основні концепції компонентної розробки прикладних задач
Під компонентами програмного забезпечення розуміють прості структурні елементи, які можна повторно використовувати при побудові програмних систем. Вони реалізують прикладні функції інформаційної системи, надають семантичні послуги прикладного або технічного характеру та можуть бути модифіковані в процесі розробки на рівні двійкових кодів.
Від стандартів компонент залежать методи побудови та організація взаємодії між компонентами. Ці стандарти визначають представлення компонента перед зовнішніми для нього об’єктами незалежно від внутрішньої його реалізації. Таким представленням є інтерфейси та протоколи взаємодії. Якщо застосовувати в процесі розробки стандартні інтерфейси і дотримуватися протоколів компонент то є гарантія, що компоненти з схожими специфікаціями виявляться взаємозамінні і дадуть змогу їх незалежної модифікації. Зовнішній вигляд та поведінка компонент може бути адаптована до визначених прикладних функцій інформаційної системи. Компоненти можна об’єднувати, формуючи з них або більші компоненти або закінчені прикладні задачі.
Під інтерфейсом компонента, через який інші компоненти можуть під’єднуватися до компонента та підтримувати взаємодію, зазвичай розуміють дескриптор інтерфейсу. Дескриптор інтерфейсу це набір властивостей компонента, набір методів компонента, набір подій, які визначають реакцію компонента на зовнішній вплив або внутрішні умови.
Властивості та методи компонента представляються інтерфейсом, через який зовнішні об’єкти мають доступ до сервізів, що надає даний компонент. Цей інтерфейс називається інтерфейсом прикладного програмування API. При цьому властивості компонента описують значення його загально доступних атрибутів, а методами визначається його поведінка. Події визначають реакцію компонента на зовнішні впливи або на внутрішні умови (наприклад на зміну значення тієї чи іншої властивості). Від інтерфейсу залежить яка подія буде активізована при виникненні деякої умови.
Зовнішні дані в яких виникає потреба в сервісах даного компонента, повинні самі зареєструватися в середовищі розробки та виконання для отримання події та показати свій методи для обробки цієї події.
Така модель взаємодії об’єктів, заснована на механізмі публікації та підписки, дозволяє динамічно встановлювати зв’язки між компонентами в розподіленому середовищі.
Компоненти існують та функціонують всередині контейнерів. Контейнери створюють загальний контекст взаємодії між компонентами прикладних задач. Контейнери також надаються компонентам вкладеним в інші компоненти, стандартний доступ до послуг середовища виконання.
Контейнери самі часто реалізуються в вигляді компонентів і можуть бути вкладені в інші контейнери. Для організації зв’язків між компонентом та контейнером, що знаходиться в ньому зазвичай використовують протоколи засновані на механізмі подій.
Стандарти компонентів визначають мета дані (тобто дані про дані), які кожен компонент друкує для того щоб мати можливість взаємодії з іншими компонентами. Мета-дані про властивості даного компонента можуть повідомлятися або статично на етапі проектування, або динамічно на етапі виконання.
Основні концепції компонентного програмування дадуть змогу краще зрозуміти існуючі технології з цього напряму програмування. Розглянемо основні платформи які на даний момент вважаються найефективнішими в програмуванні і фактично формують нову епоху в програмуванні.
Модель COM/DCOM
COM і DCOM – технології, які забезпечують взаємодію між компонентами прикладної задачі. Вони дозволяють розгортати розподілену прикладну задачу на платформі Windows. COM - є моделлю програмування на основі об’єктів. Вона спрощує взаємодію компонентів та прикладних задач. DCOM це, свого роду, «клей» який зв’язує різні технології. DCOM дає змогу двом або декільком компонентам легко взаємодіяти одне з одним, незалежно від того, коли і на якій мові вони були написані, а також де саме вони знаходяться і в якій операційній системі працюють. Розглянемо більш детально DCOM.
Модель DCOM, запропонована компанією Microsoft. Вона задає тип та структуру інтерфейсів, які забезпечують взаємодію компонентів в розподіленому середовищі. Кожний компонент в моделі DCOM повинен мати принаймні один інтерфейс, що підтримує основні механізми інтерфейсних посилань. В DCOM реалізовано механізм повідомлення про події. Передбачені інтерфейси для доступу до мета-даних. Інтерфейс доступу до бібліотеки типів дозволяє динамічно знаходити та забезпечувати взаємодію компонентів в процесі виконання.
Середовище компонентної розробки підтримує на даний момент розробку компонент на трьох мовах програмування: Visual Basic, Visual C++ та J++ . Візуальна розробка компонент підтримується за допомогою property sheet. Середовище розробки і виконання компонентів також розроблене а основі моделі DCOM. Саме завдяки цьому його можна розширювати та настроювати за допомогою стандартних механізмів.
Так як в мовах C++ і Visual Basic немає вбудованої підтримки рефлексій, на відміну від Java, тому в DCOM всі метадані (крім тих що відносяться до Java) виражаються в термінах компонентної моделі, а не на мові програмування.
Модель Java Beans
Платформа розподілених компонентів основана на специфікації Java Beans була розроблена компанією Sun Microsystems. Специфікація Java Beans являє собою сукупність спеціальних інтерфейсів мови програмування Java. Вона наслідує поняття та характеристики Java, такі як об’єктна орієнтованість, багато потоковість, використання віртуальної машини, незалежність від апаратно-програмної платформи, інформаційна безпека та багато інших. На відміну від моделі DCOM, яка є нейтральною до мови програмування, але залежить від платформ, Java Beans нейтральна до платформ, але залежить від мови програмування (орієнтована на Java). Мобільність компонентів які створюються відносно платформ забезпечує технологія віртуальної Java-машини.
Середовище компонентної розробки, засноване на технології Java Beans, має API-інтерфейс. Він явно підтримує візуальну розробку компонентів за допомогою сторінки властивостей DCOM. Цими якостями володіють інтегровані середовища розробки: Visual Cafe компанії Symantec, Visual Age for Java корпорації IBM, JBuilder (Borland), Java Workshop (Sun Microsystems).
По функціональним можливостям вони можуть порівнюватися з середовищем Visual Studio від Microsoft. Вони забезпечують візуальну розробку компонентів за допомогою застосування сторінки властивостей, палітр и попереднім визначенням правил буксирування готових компонентів за допомогою мишки.
Для формування мета даних в моделі Java Beans використовується API-інтерфейс Core Reflection. Який був успадкований від Java. Він являє собою спеціальний набір класів Java.
Платформа розподілених компонентів заснована на моделі Java Beans описана специфікацією EJB (Enterprise Java Beans) компанії Sun Microsistem. Вона являє собою розподілене серверне середовище для Java аналогічну по функціональним можливостям для середовища DCOM.
Кожний компонент EJB повинен функціонувати всередині контейнера, який ізолює його від робочої ОС сервера. Контейнер автоматично виділяє компоненту потік процесів і управляє від його імені службами підтримки паралелізму, захисту, довгочасного збереження, транзакційної обробки та іншими службами, котрі надаються зі сторони серверного середовища.
Технологія розподіленого програмування CORBA
CORBA – це одна з популярних на сьогоднішній день технологій розподіленого програмування. Вона розроблялася та підтримується консорціумом OMG і є багато різних реалізацій стандарту для різних платформ та мов програмування.
CORBA дозволяє створювати розподілені в просторі мережі компоненти, при чому ці компоненти можуть бути написані на різних мовах програмування (наприклад С та Java), працювати на різних операційних системах (наприклад Linux і Windows NT), просто визначаючи інтерфейси одне одного и віддалено викликаючи відкривання нових методів, з яких складаються компоненти.
CORBA включає в себе просту мову програмування опису інтерфейсів об’єктів – IDL, вона дозволяє відділяти описання інтерфейсів від їх реалізації в перетворювати в CORBA існуючі прикладні задачі. Важливо також відзначити що будь-який компонент може бути як клієнтом так і сервером одночасно. Для підвищення надійності, захисту даних і досягнення кращої роботи CORBA може бути реалізований як частина операційної системи. При цьому посилання на об’єкти можуть бути зроблені постійними, таким чином зменшуючи час, необхідний для обробки кожного запиту.
Можна викликати методи об’єктів, розташований в цій же програмі, на цьому ж хості в мережі, на будь-якому хості або пристрої в мережі. Для того щоб викликати методи віддаленого об’єкту потрібно мати як мінімум його опис на IDL і об’єктне посилання на нього.
Технологія .NET
Платформа MS.NET включає в себе як готові компоненти для побудови програмного забезпечення, так і інтегроване середовище розробки, що забезпечує можливість багатомовної розробки програмних систем з використанням різних мов програмування (наприклад С#, C++, VBasic.NET, Java#).
Платформа MS.NET розвинула існуючі підходи до зниження складності програмного забезпечення – компонентному представленню програмних систем і пропонує більш надійний та простий метод формування програмних компонент.
Платформа використовує розподілені обчислення, які в значній мірі знижують складність сучасної форми розробки програмного забезпечення в вигляді розподілених програмних систем або клієнт-серверних прикладних задач.
Платформа MS.NET містить більшість існуючих на даний момент Інтернет технологій, забезпечує можливість швидкої розробки як звичайних Web-додатків так і Web-сервісів.
Платформа .NET складається з основних компонентів:
Visual Studio.Net
Сервери.Net
.Net Framework
Сервіс .Net
Операційні системи
Операційні системи Microsoft представляють базовий рівень платформи.
Сервери.Net є програмними продуктами Microsoft, використання яких дозволяє знизить складність розробки складних програмних систем. (наприклад використовуються сервери Application Center 2000, Exchange Server 2000,SQL).Сервіс.Net (Net Building Bloc Services) представляє собою готові «будівельні блоки» складних програмних систем, які можуть бути використані через Інтернет як сервісні послуги (наприклад Microsoft Passport, що дозволяє встановити єдине ім’я користувача і пароль на всіх сайтах, які підтримують аутентифікацію через Passport).
Visual Studio.Net – верхній рівень MS.NET. Забезпечує можливість створення складного програмного забезпечення на основі платформи.
Центральною частиною MS.NET є .NET Framework.
.NET Framework складається із двох головних компонентів: бібліотеки базових класів та CLR (Common Language Runtime). Які відповідно призначені для вирішення наступних завдань:
Уніфікації бібліотек функцій для всіх застосувань, незалежно від мови програмування яка використовується.
Підвищення керованості застосувань з погляду безпеки та ефективного використання ресурсів.
.Net Framework Class Library – бібліотека базових функцій. Принципова новизна полягає в тому, що якщо раніше подібний набір створювався окремо для кожної мови програмування, то тепер він один для всіх засобів.
CLR (Common Language Runtime) – складний програмний апарат, призначений для стирання границь між різними мовами програмування. Він виконує програми, частини яких написані на різних мовах програмування.
Вище було розглянемо основні концепції та технології компонентного програмування, що набули особливого розвитку в останні роки. Хочеться звернути увагу, що технології які застосовуються та інструментальні засоби аналізу та проектування підтримують як структурний так і об’єктний підходи, застосовуючись до компонентної розробки прикладних задач. Від програмних модулів інших типів, з точки зору реалізації, компоненти відрізняються тим що їх можна модифікувати в процесі розробки на рівні двійкових кодів що виконуються. В той час як бібліотеки, підпрограми та інші модулі необхідно змінювати на рівні вихідних кодів з відповідною перекомпіляцією.
Якщо порівнювати яка платформа краща то однозначно нічого сказати не можна кожний програміст вибирає те що для нього найбільш потрібно на даний момент. Вважається що через кілька років .NET повністю монополізує ринок, але якщо порівнювати його з Java то єдиний її недолік те що вона більш повільна (більш ніж в три рази). Однак це пояснюється тим що сама віртуальна Java-машина є більш універсальною і тим самим вповільнює виконання. Якщо порівнювати CORBA і COM то вони також як багато в чому відмінні так і багато в чому схожі. Це клієнт-серверні технології, в яких функціональність об’єкту надається клієнту через звернення до абстрактних інтерфейсів.
Отже виходячи з вище представленої інформації чітко зваживши всі плюси та мінуси розглянутих компонентних технологій даний проект буде розроблятися з використанням технології .Net.
Основним критерієм на основі якого було обрано дану технологію є її універсальність та більша розповсюдженість в сфері розробки програмних продуктів.
2 Проектування програмного блоку
2.1 Розробка технічного завдання
У даному програмному проекті необхідно реалізувати модель багатосторонньої дуелі. Дана програма повина відповідати наступним критеріям:
Кількість дуелянтів повина бути не менше трьох;
В ході програми з допомогою жеребу повинен бути сформований порядок стрільби дуелянтів.
Дуелянти повині розташовуються на однаковій відстані один від одного.
Вони обмінюються пострілами почерзі, визначеній жеребом, поки не залишиться лише один дуелянт.
Черговий стріляючий може стріляти в будь якого із інших.
Потрібно сформувати моделы трьох категорій дуелянтів:
С – снайпер і ніколи не промахується з даної дистанції;
Б – влучає лише в 80%;
Д – приблизно в 50% випадків.
Потрібно розробити найкращу стратегію гри для кожного із учасників.
Програма повинна мати меню, мінімальний склад якого такий:
Робота програми;
Відомості про програму (інструкція);
Відомості про автора;
Вихід.
Всі надписи на екрані повинні бути державною мовою.
У роботі передбачено створення власних класів та бібліотек.
Потрібно забезпечити високу швидкість і надійність роботи програми.
Для роботи програмної моделі необхідна наявність Visual Studio 2010 Express. Програмної модель не потребує до дат кових модулів та драйверів.
2.2 Розробка стратегії гри для кожної категорії учасників
В для забезпечення роботи даної програми необхідною умовою є розробка загальної моделі поведінки кожного з гравців для забезпечення найбільшої імовірності їх перемоги у дуелі.
В ході аналізу даної ситуації був розроблений алгоритм який передбачає усі можливі варіанти розвитку ситуації та вибір найкращого на даний момент часу.
private void completion_shooting()
{
bullet[A, 0] = 0;
if (type_shot == "killed")
people[B, 0] = 0;
if (type_shot == "live")
people[B, 0] = 1;
if (type_shot == "killed")
DlReport.GridReport.Rows.Add(nameColor[list_people[0]] + " знищив " + nameColor[strongest_man]);
if (type_shot == "live")
DlReport.GridReport.Rows.Add(nameColor[list_people[0]] + " не попав в " + nameColor[strongest_man]);
timerShot.Enabled = false;
upgrade_current_point();
List<int> All_people = new List<int>();
for (int i = 0; i < people.GetLength(0); i++)
if (people[i, 0] == 1) All_people.Add(i);
if (All_people.Count == 1)
{
CptInfo.Visible = true;
DlReport.GridReport.Rows.Add("Гра завершена, переможець - \"" + nameColor[list_people[0]] + "\"");
CptInfo.Text = "Гра завершена, переможець - \"" + nameColor[list_people[0]] + "\"";
}
}
Даний фрагмент коду описує дії гравців в залежності від тої ситуації, яка склалася в ході жеребкування. Стратегі кожного з гравців, полягає у тому, що в будь якому випадку постріл потрібно виконувати по гравцю який має менший шанс на промах. Тобто у випадку коли жереб випав так, що першим стріляє гравець із імовірністю на враження 50% він буде виконувати постріл по опоненту з шансов у 100% враховуючи, що гравець із шансом 80% може схибити при свому пострілі.
2.3 Створення об'єктної моделі системи
UML - моделювання – досить важливий етап в проектуванні програми, що зображає сучасні тенденції в тій предметній галузі, яка досліджується в даному курсовому проекті, а саме в сфері IT- технологій, що з ним пов’язаний.
Нище приведена діаграма послідовностей для прецеденту «Запуск гри» (див рис. 3.1). Діаграма послідовностей дозволяє досить детально описати внутрішні процеси , які виникають під час виконання прецеденту. Діаграма містить ось часу, що спрямована зверху вниз; всіх виконавців; повідомлення або запити між виконавцями; посилання на інші прецеденти.
/
Рисунок 2.1 – Діаграма послідовностей для прецеденту «Запуск гри»
Діаграма в UML - це графічне представлення набору елементів, що замальовується найчастіше у вигляді зв'язаного графа з вершинами і ребрами. Діаграми малюють для візуалізації. Основна мета діаграм - візуалізація системи, що розробляється, з різних точок зору. Діаграма - в найзагальнішому сенсі деякий зріз системи. Зазвичай, за винятком найпростіших моделей, діаграми дають згорнуте представлення елементів, з яких складається система, що розробляється.
Використання UML не обмежується моделюванням програмного забезпечення. Його також використовують для моделювання бізнес-процесів, системного проектування і відображення організаційних структур.
UML дозволяє також розробникам програмного забезпечення досягти угоди в графічних позначення для представлення загальних понять (таких як клас, компонент, узагальнення, об'єднання і більше сконцентруватися на проектуванні та архітектурі.
Далі наведена UML - діаграма класів, яка зображує об'єктну моделі комп'ютерної гри, яка реалізована в даному курсовому проекті. Вона описує структуру системи, показуючи її класи, їх атрибути і оператори, а також взаємозв'язки між цими класами.
Взаємозв'язок - це особливий тип логічних відносин між сутностями, показаних на діаграмах класів та об'єктів. В UML є декілька типів взаємозв'язків між класами, наприклад: асоціація, агрегація, композиція, узагальнення та залежність
Далі розглянемо об'єктну модель (рис. 4.1). На якій відображені класи гри та їх атрибути, методи і зв'язки між ними.
/
Рисунок 2.2 - UML діаграми гри «Дуель»
Система складається з таких класів:
1 Form - абстрактний клас-предок для всіх об'єктів, які відображаються на екрані, які є основними об'єктами у грі;
Методи класу:
Home_Load - початкове розташування об’єктів даний метод відображає початкове розташування об’єктів на екрані.
timer1_Tick – забезпечує відтворення руху кулі на формі та покрокову зміну її положення відповідно до ситуації.
random_real_people – забезпечує ефект жеребкування гравців в хаотичному порядку та їх шанси на перемогу.
completion_shooting – визначає результат пострілу та стан гравця в якого виконувався постріл. В залежності від шансу на влучання в ціль.
upgrade_current_state – виводить на екран статистичні параметри після виконання основного блоку прогами.
btnAutomatic_Click – забезпечення автоматичної роботи програми.
MenuItem2_Click – метод відповідає за роботу меню.
Width - ширина об'єкта;
Height - висота об'єкта;
Position - позиція об'єкта на ігровому полі;
Bounds - границі об'єкту;
IsAlive - прапорець перевірки чи існує зараз об'єкт, якщо об'єкт не існує, то в подальшому не потрібно його відображати у вікні.
Клас Ball має атрибут Velocity, він відповідає за прискорення кульки, вектор напрямку його руху.
Та має методи:
Collide() метод, який перевіряє зіткнення блоків із кулькою.
ReflectHorizontal() - метод, змінює рух кулі після зіткнення із горизонтальною стороною.
ReflectVertical() - метод, змінює рух кулі.
Move() - переміщує кулю, змінюючи її координати додаючи поточне прискорення.
Draw() - метод, виконує відображення кулі для нових позицій.
Initialize() - ініціалізація.
UnloadContent() - метод визволення пам'яті від об'єктів, які завантажувалися при виконанні методу LoadContent().
Draw() - метод, який виконує відображення усіх об'єктів у вікні, які необхідно відобразити у вікні.
Update() - метод оновлення інформації об об'єктах, при зміні їх координат або властивостей.
3. Реалізація спроектованої системи на мові C# з використанням .NET
3.1 Створення компонента технології .NET
Підчас створення даног проекту виникла потреба у реалізації моделювання руху кулі в просторі відповідно до отримуємих параметрів програми. В результаті вирішення даної під задачі був отриманий клас, який в подальшому був винесений у відповідну бібліотеку, в подальшому він може бути використаний, як компонент інших програмних додатків. Уся ця логіка системи, її математична модель була розміщена в відповідних класах цієї бібліотеки.
Tick .dll
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace Tick
{
private void Tick(object sender, EventArgs e)
{
//поточне положення кулі
float AX = 0, AY = 0, BX = 0, BY = 0;
AX = bullet[A, 1];
AY = bullet[A, 2];
BX = bullet[B, 1];
BY = bullet[B, 2];
bullet[A, 0] = 1;
//постріл кулі
if ((AX > BX + beside_people) && ((bullet_move_x == "XLeft") || (bullet_move_x == "")))
{
AX -= (float)Math.Abs((SAX - SBX - beside_people) / speed);
bullet[A, 1] = AX;
if (point_step == 0) bullet_move += "XLeft";
if (point_step == 0) bullet_move_x = "XLeft";
}
if ((AX + beside_people < BX) && ((bullet_move_x == "XRight") || (bullet_move_x == "")))
{
AX += (float)Math.Abs((SBX - SAX - beside_people) / speed);
bullet[A, 1] = AX;
if (point_step == 0) bullet_move += "XRight";
if (point_step == 0) bullet_move_x = "XRight";
}
if ((AY < BY + beside_people) && ((bullet_move_y == "YDown") || (bullet_move_y == "")))
{
AY += (float)Math.Abs((SBY - SAY + beside_people) / speed);
bullet[A, 2] = AY;
if (point_step == 0) bullet_move += "YDown";
if (point_step == 0) bullet_move_y = "YDown";
}
if ((AY + beside_people > BY) && ((bullet_move_y == "YUP") || (bullet_move_y == "")))
{
AY -= (float)Math.Abs((SAY - SBY + beside_people) / speed);
bullet[A, 2] = AY;
if (point_step == 0) bullet_move += "YUP";
if (point_step == 0) bullet_move_y = "YUP";
}
if (bullet_move == "XLeftYDown")
if ((AX <= BX + beside_people) && (AY >= BY + beside_people))
completion_shooting();
if (bullet_move == "XLeftYUP")
if ((AX <= BX + beside_people) && (AY + beside_people <= BY))
completion_shooting();
if (bullet_move == "XRightYDown")
if ((AX + beside_people >= BX) && (AY >= BY + beside_people))
completion_shooting();
if (bullet_move == "XRightYUP")
if ((AX + beside_people >= BX) && (AY + beside_people <= BY))
completion_shooting();
if (bullet_move == "XLeft")
if (AX <= BX + beside_people)
completion_shooting();
if (bullet_move == "XRight")
if (AX + beside_people >= BX)
completion_shooting();
if (bullet_move == "YDown")
if (AY >= BY + beside_people)
completion_shooting();
if (bullet_move == "YUP")
if (AY + beside_people <= BY)
completion_shooting();
point_step += 1;
Battlefield.Refresh();
}
Даний компонент виконує математичну модель по розрахунку розміщення кулі в просторі та вираховує параметри Х та Y для моделювання плавного руху кулі по формі.
В ході курсової роботи перед нами постає завдання у реалізації комп’ютерної гри «Дуель». В розробці було вжито деякі особливості, на яких я би хотів зупинити увагу.
Реалізації взаємодії між гравцем та системою був розроблений за допомогою Microsoft Visual Studio.
На етапі основного виробництва виконується величезний обсяг робіт. Спочатку пишеться вихідний код, малюється графіка, такі як спрайт. Величезний обсяг роботи також припадає на створення та розробку моделей відображення об’єктів на формі.
Весь цей час доповнюється та змінюється ігровий дизайн, щоб відобразити поточне бачення гри. Деякі особливості або аспекти гри можуть бути видалені, деякі додані. Художня трактування може еволюціонувати, а процес гри - змінитися. Може з'явитися нова цільова платформа, а також нова цільова аудиторія.
З точки зору часу перший рівень гри розробляється довше за всіх інших. Оскільки при створенні самої концепції і графіки використовуються інструменти для створення та відображення об’єктів, потрібні можливості і зміни внутрішніх інструментів. З появою нових можливостей деякі рівні можуть застаріти, тому в перший рівень гри можуть вноситися різні виправлення. Крім того, в силу динамічної природи розробки ігор, дизайнерське бачення першого етапу з часом може змінюватися. Наступні етапи розроблюються значно швидше, так як список можливостей стає більш повним, а бачення гри - більш ясним.
Тести підключаються до гри, коли з'являється щось іграбельне. Це може бути один рівень або підмножина ігор, що може використовуватися в будь-яких розумних межах. На ранньому етапі тестування гри віднімає відносно малу частку часу. У міру наближення розробки до кінця, гра може почати відбирати для тестів весь час - і навіть понаднормово - оскільки тести намагаються охопити і протестувати нові можливості, для яких існують тести регресії. Сьогодні тестування є життєво важливим для ігор, оскільки, в силу складності більшості з них, одна єдина зміна може призвести до катастрофічних наслідків.
3.2 Загальні відомості про програму
Програма модель, яка реалізована як курсовий проект - цє комп’ютерна гра «Дуель». Вона розроблена в середовищі Microsoft Visual Studio 2010 та на об’єктно-орієнтовній мові програмування С# під платформу Microsoft .Net 3.5 з використанням XNA Framework 3.1.
Для того, щоб запустити мою програму необхідно мати на комп’ютері таке програмне забезпечення, як встановлений .Net Framework версії не нижче 3.0.
Для запуску програми необхідно мати файл .exe та папку Content із необхідними графічними файлами.
Програма разом з контентом займає 656 КБ пам’яті на жорсткому диску.
Характеристики персонального комп’ютера, необхідні для нормального функціонування програми:
- процесор Intel Celeron 800;
- 256 МБ ОЗП;
- не менш ніж 10 МБ вільного місця на жорсткому диску;
- установлене на комп’ютері програмне забезпечення Microsoft .Net не нижче 3.0 та Microsoft XNA Framework 3.1;
- ОС Microsoft XP Professional Service Pack 2;
- монітор Samsung або ін.
3.3 Тестування гри
В наш час одним з основних аспектів оцінки програмного продукту є його надійність та працеспроможність, тому для виявлення усіх можливих конфліктів було створено безліч методів виявлення помилок.
Наша програма модель є досить простою, але вона також потребує тестування перед її впровадженням. Вході тестування до неї було застосовано основні з сучасних методів виявлення можливих помилок.
Верифікація і валідація – це методи аналізу, перевірки специфікацій і правильності виконання програм відповідно до заданих вимог і формального опису програми.
Метод верифікації допомагає зробити висновок про коректність створеної програмної системи при її проектуванні і після завершення її розроблення. Валідація дозволяє встановити здійснимість заданих вимог шляхом їх перегляду, інспекції і оцінки результатів проектування на процесах ЖЦ для підтвердження того, що здійснюється коректна реалізація вимог, дотримання заданих умов і обмежень до системи. Верифікація і валідація забезпечують перевірку повноти, несуперечності і однозначності специфікації і правильності виконання функцій системи.
Верифікації і валідації піддаються:
– компоненти системи, їх інтерфейси (програмні, технічні і інформаційні) і взаємодія об'єктів (протоколи, повідомлення) у розподілених середовищах;
– описи доступу до баз даних, засоби захисту від несанкціонованого доступу до даних різних користувачів;
– документація до системи;
– тести, тестові процедури і вхідні набори даних.
Верифікація і валідація як методи перевірки правильності виконання заданих функцій і відповідності їх вимогам замовника подані в стандарті у вигляді самостійних процесів ЖЦ і використовуються, починаючи від етапу аналізу вимог і закінчуючи перевіркою правильності функціонування програмного коду на заключному процесі, а саме, під час тестування.
Для цих процесів визначені цілі, задачі і дії з перевірки правильності створюваного проміжного продукту на процесах ЖЦ. Розглянемо їхнє стандартне подання.
Процес верифікації. Мета процесу – переконатися, що кожен програмний продукт (і/або сервіс) проекту відбиває погоджені вимоги до їхньої реалізації. Цей процес ґрунтується:
– на стратегії і критеріях верифікації всіх робочих програмних продуктів на ЖЦ;
– на виконанні дій з верифікації відповідно до стандарту;
– на усуненні недоліків, виявлених у програмних (робочих, проміжних і кінцевих) продуктах;
– на узгодженні результатів верифікації з замовником.
Впровадження процесу полягає у визначенні критичних елементів (процесів і програмних продуктів), що повинні піддаватися верифікації, у виборі виконавця верифікації, інструментальних засобів підтримки процесу верифікації, у складанні плану верифікації і його затвердження. У процесі верифікації виконуються задачі перевірки умов: контракту, процесу, вимог, інтеграції, коду і документації.
Відповідно до плану і вимог замовника перевіряється правильність виконання функцій системи, інтерфейсів і взаємозв'язків компонентів, а також доступ до даних і до засобів захисту.
Процес валідації. Мета процесу – переконатися, що специфічні вимоги для програмного продукту виконано, і здійснюється це за допомогою:
– розробленої стратегії і критеріїв перевірки всіх робочих продуктів;
– обговорених дій з проведення валідації;
– демонстрації відповідності розроблених програмних продуктів вимогам замовника і правилам їхнього використання;
– узгодження із замовником отриманих результатів валідації продукту.
Рефакторинг (англ. refactoring) — перетворення програмного коду, зміна внутрішньої структури програмного забезпечення для полегшення розуміння коду і легшого внесення подальших змін без зміни зовнішньої поведінки самої системи. Слово «рефакторинг» пішло від терміну «факторинг» в структурному програмуванні, який означав декомпозиціюпрограми на максимально автономні та елементарні частини.
Вході виконання даних процедур до розробки програмної моделі гри «Дуель» не було виявленно значних помилок, які б могли вплинути на роботу даного проекту. Зважаючи на результати тестування даний продукт можна використовувати в повному обсязі відповідно до технічного завдання.
4. Розробка інструкції користувача
Дана програма на самому початку розробки носила характер гри, яка моделює саму фізику дуелі з її невизначеністю та випадковістю результатів. Тому при розробці велику увагу було приділено розробці самої логіки програми, а
02.04.2017 12:04-
Ділись своїми роботами та отримуй миттєві бонуси!
0%
Оголошення від адміністратора