Розробка ігрової програми для мобільних пристроїв з сенсорним екраном студента 4 курсу
| Вид материала | Документы |
СодержаниеРозділ 5. Реалізація 5.1 Загальна модель 5.2 Програмна реалізація 5.3 Отримані результати |
- Реферат роботи, 161.95kb.
- О. Л. Нечипорук „, 369.83kb.
- Методична розробка уроків та вимоги до неї, 75.68kb.
- Формат опису модуля, 51.04kb.
- Реферат метою роботи є обґрунтування та розробка ефективних технологій ведення гірничих, 201.97kb.
- Розробка програми просування товару на ринок Розробка стратегій розвитку підприємства, 24.48kb.
- Орієнтована на студента І базується на його навчальному навантажені, необхідному для, 91.14kb.
- Цей курс є одним з базових І охоплює широке коло пристроїв електронної техніки, які, 144.55kb.
- Організація самостійної роботи студентів, 563.53kb.
- Формулювання вимог до програми 7 2 Проектування програми 7 3 Кодування програми, 390.59kb.
Розділ 5. Реалізація
5.1 Загальна модель
В процесі гри відбувається постійний рух монстрів по спеціальних шляхах. Для цього потрібно перш за все проаналізувати карту гри на прохідність, і згенерувати усі можливі маршрути. Ігрове поле розглядається як неорієнтований граф, вершинами якого є клітинки придатні для пересування, а ребрами зв’язані сусідні клітинки, між якими можливі переходи. На такому графі виконується пошук в глибину з урахуванням того, що згенеровані шляхи не повинні містити циклів. Одержані шляхи конвертуються в набір точок на площині, які повинен пройти монстр. В залежності від його швидкості він поступово переміщається між ними.
Для організації руху і взаємодії ігрових об’єктів програма в своїй основі повинна містити цикл, що постійно повторюється. В тілі циклу проводиться звернення до всіх активних елементів і їх перемалювання. Кожна вежа перевіряє наявність монстрів в радіусі своєї дії і атакує їх відповідно до свого типу. При цьому повинна враховуватись скорострільність, а саме: вежа, час перезарядки якої ще не пройшов - не повинна взаємодіяти з монстрами.
Кожна вежа повинна автоматично вдосконалюватися. За кожне враження монстра додається один бал досвіду, при набиранні певної кількості балів, в залежності від виду вежі, може збільшуватись її сила, скорострільність чи радіус дії.
Також, в процесі гри повинна бути можливість додавання нових веж і ліквідації не потрібних. Ці можливості надає користувачу бокове меню, в якому можна обрати нову вежу для побудови. Також на ньому відображаються запас ресурсу, і інформація про обрану вежу. При виборі уже побудованої вежі в боковому меню активізується кнопка для знищення вежі. При побудові нової вежі необхідно враховувати наявність достатньої кількості ресурсу, і зменшувати його кількість відповідно до ціни.
5.2 Програмна реалізація
Готова програма являє собою Java мідлет, на базі конфігурації CLDC – 1.1, профілю MIDP – 2.1.
В процесі програмної реалізації було створено набір класів:
GameFild, Menu, MenuCanvas, Monster, MonsterFactory, Monster, Monsters, SimpleFactory, SimpleTower, SpeedTower, SplashTower, TDGame, TDCanvs, Tower, Towers, Trek, TrekBuilder, point.
Програмний код класів наведений в додатку. Ієрархію створених класів демонструє наступна діаграма.
Детальніше про кожен клас і його призначення:
TDGame – основний клас – Midlet , що є оболонкою для всієї гри.
MenuCanvas – організовує головне меню ігри.
TDCanvs – клас наслідник GameCanvas, реалізує графіку власне ігрового процесу, взаємодіє з користувачем, обробляючи дотики до екрану.
GameFild – містить у собі інформацію про поточне ігрове поле.
Menu – забезпечує бокове меню в ігровому процесі.
Monster – містить у собі інформацію про монстра, його характеристики, зображення, шлях прямування. Забезпечує малювання і участь в ігровому процесі одного монстра.
MonsterFactory – інтерфейс, що описує генератор послідовностей монстрів. Містить тільки один метод Monster genNext(), що генерує наступного монстра. У різних ігрових рівнях можуть використовуватись різні реалізації цього інтерфейсу.
SimpleFactory – реалізує інтерфейс MonsterFactory, генеруючи послідовність монстрів з характеристиками заданими випадковим чином в певних рамках.
Monsters – клас, що містить в собі масив усіх об’єктів класу Monster, і почергово опитує на кожній ітерації, для того щоб здійснити рух, і промальовування.
Tower – абстрактний клас, що описує одну вежу. Містить її характеристики, зображення, методи встановлення і ліквідації вежі. Два абстрактні методи attack(Monster[] m) і upgrade() – дають можливість описувати різні схеми поведінки: атаки і вдосконалення, в залежності від типу вежі.
SimpleTower – наслідує Tower, представляє звичайну вишку, що атакує одночасно тільки одного ворога.
SpeedTower - наслідує Tower, представляє вишку, що зменшує швидкість одного ворога.
SplashTower - наслідує Tower, представляє звичайну вишку, що атакує одночасно всіх ворогів в радіусі своєї дії.
Towers – містить посилання на всі присутні на карті вежі. Активує їх на кожній ітерації. Забезпечує можливість додавання нових і видалення старих веж.
Trek – містить шлях прямування конкретного монстра у вигляді послідовності контрольних точок.
TrekBuilder – генерує всі можливі шляхи слідування монстрів, на основі заданого поля.
point – клас, що представляє точку, містить координати х,y.
5.3 Отримані результати
Програма розроблялася в інтегрованому сереловищі NetBeans IDE 7.0. [6]
В одержаній реалізації, гра матиме такий вигляд.
Скріншот зроблено у програмі MicroEmulator 2.0.4.62.
Дана версія розрахована на дисплеї з роздільною здатністю 640х360 пікселів. Програма тестувалась на телефоні Sony Ericsson U1, де успішно працювала.
Висновки
В ході виконання роботи було запропоновано реалізацію гри, для мобільних пристроїв з сенсорним екраном на базі обраної платформи Java Micro Edition. Отримано досвід роботи з інструментами розробки програм для мобільних пристроїв, зокрема в середовищі NetBeans IDE 7.0.
Важливими особливостями такого програмування є розміри графічних елементів інтерфейсу – адже це значним чином впливає на зручність користування продуктом. При цьому потрібно враховувати роздільну здатність екрану і точність сенсору, а також користуватиметься людина стилусом, чи пальцем. Можливий варіант виходу з ситуації – розробка різних версій продукту для пристроїв з кардинально різними характеристиками. Завдяки універсальності платформи Java ME цей процес зводиться до заміни графічних файлів і констант, а не повного переписування коду.
Варто зазначити, що розробка ігрових програм для портативних пристроїв – доволі перспективна сфера, адже кількість мобільних телефонів з сенсорним екраном постійно зростає, а людству ніколи не набридне грати в цікаві ігри, що зумовлює попит на відповідне програмне забезпечення.