ANDROIDGAME: Зв’яжіться ВСІ РАЗОМ

&nbsp

Ми майже закінчили невеликої каркас нашої гри Все, що залишилося зробити, – звязати всі разом, реалізувавши інтерфейс Game, за допомогою класів, написаних у попередньому розділі Список завдань виглядає наступним чином: організувати управління вікнами У нашому випадку це означає правильно обробляти життєвий цикл активності використовувати WakeLock і відстежувати його роботу, щоб екран не тьмянів інстанціювати і віддавати посилання на Graphics, Audio, FilelO і Input тим елементам, яким вони потрібні управляти екземплярами Screen і інтегрувати їх у життєвий цикл активності

Наша головна мета – отримати єдиний клас Androi dGame, на якому ми можемо грунтуватися Все, що ми хочемо робити згодом, – реалізувати метод Game getStartScreenC, який запустить нашу гру, наприклад ось так:

Сподіваюся, ви розумієте, чому було так важливо організувати хороший компактний фреймворк перед тим, як зайнятися безпосередньо програмуванням самої гри Ми зможемо заново використовувати даний фреймворк у всіх наших майбутніх іграх, які не вимагають інтенсивної роботи з графікою Розглянемо лістинг 515, який демонструє клас AndroidGame

Лістинг 515 AndroidGameJava звяжемо всі разом package combadlogi сandroi dgamesframeworki mpl:

Визначення класу починається з того, що Androi dGame доповнює клас Activity і реалізує інтерфейс Game Далі визначаємо кілька членів, які вам вже знайомі Перший – Androi dFastRenderView, в якому ми будемо малювати і який буде керувати потоком основного циклу Члени Graphics, Audio, Input і FilelO будуть зберігати примірники класів AndroidGraphics, AndroidAudio, Androidlnput і AndroidFi1e10 Як бачите, нічого дивного тут не відбувається Наступний член зберігає поточний Screen І нарешті, ще один член відповідає за WakeLock, який потрібен для того, щоб екран не гаснув

Уже знайомий метод onCreateO, що викликається при запуску Activity, починає свою роботу з виклику методу базового класу onCreate, як це і потрібно Далі ми робимо активність Activity повноекранної У наступних декількох рядках встановлюємо штучний фреймбуфер Залежно від орієнтації активності нам необхідний фреймбуфер розміром або 320 х 480 (в книжковій орієнтації), або 480 х 320 (в альбомній орієнтації) Щоб визначити орієнтацію екрану, яку використовує Activity, вибираємо член ori entati on з класу Conf i gurati on, який ми отримуємо за допомогою виклику getResources getConf i gurati on Грунтуючись на значеннях даного члена, встановлюємо розмір фреймбуфер і сода Bitmap, який ми передамо екземплярам класів AndroidFastRenderView і AndroidGraphics трохи пізніше

ПРИМІТКА

Примірник класу Bitmap має колірної формат RGB565 Таким чином, нам не доведеться витрачати память, а всі наші малюнки будуть обрабативаваться трохи швидше

Ми також можемо обчислити значення seal ЕХ і seal eY для класів Si ngl eTouchHandl ег nMultitouchhandler, які необхідні для перекладу координат подій торкання в нашу систему фіксованих координат

Далі інстанціруем AndroidFastRenderView, AndroidGraphics, Androi dAudi про, Androidlnput і AndroidFi lelO з необхідними значеннями аргументів конструктора Потім викликаємо метод getStartScreen, який реалізується нашою грою, і задаємо AndroidFastRenderView як вид з контентом Activity Всі ці допоміжні класи, які ми тільки що інстанціювати, звичайно, будуть виконувати ще деяку роботу у фоновому режимі Наприклад, клас Androidlnput звяже свій обробник торкань з видом Androi dFastRenderVi ew

Переходимо до методу onResumeO з класу Acti vity Як звичайно, перше, що ми робимо, – викликаємо метод батьківського класу, як це і належить при програмуванні на Android Далі отримуємо WakeLock і переконуємося, що Screen отримав інформацію про те, що гра (а відповідно, і активність) була відновлена Потім просимо AndroidFastRenderView відновити потік візуалізації, також запускає основний цикл гри, в якому ми вказуємо поточним Screen оновити дані і відобразитися на кожній Інтерація

Метод onPauseC знову викликає метод батьківського класу Далі він вивільняє WakeLock і перевіряє, завершено чи потік візуалізації Якщо ми не завершили потік візуалізації до того, як викликали поточний onPause Screen, можуть виникнути проблеми конкурентного доступу, так як потоку для користувача інтерфейсу і потоку основного циклу одночасно потрібен Screen Коли ми впевнилися, що потік основного циклу завершено, ми наказуємо поточним Screen зупинитися Якщо Activity повинна бути вилучена, ми також повідомляємо Screen про цю подію, щоб він міг виконати необхідну очистку

Мабуть, методи getGraphi cs і getAudi o зрозумілі без пояснення Ми просто повертаємо викликає стороні відповідні екземпляри класів Викликає сторона завжди буде однією з реалізацій Screen нашої гри

Метод setScreen, який ми успадковуємо від інтерфейсу Game, на перший погляд здається досить простим Оскільки пі Л як значення Screen нам не підходить, виконуємо класичну nul1-перевірку Далі вказуємо поточним Screen зупинитися і знищити себе, Щоб ми могли звільнити місце для нового Screen Наказуємо новому Screen поновитися й оновитися з дельтою часу, рівний нулю Далі присвоюємо полю Screen значення нового Screen

Давайте задумаємося, хто і коли повинен викликати метод setScreen Коли ми створювали Містера Нома, ми визначили всі переходи між різними екземплярами класу Screen Зазвичай ми викликаємо метод AndroidGamesetScreenO в методі updateO одного з екземплярів цього класу Screen

Припустимо, у нас є Screen головного меню, де ми можемо перевірити, чи натиснута кнопка Play (Відтворити) в методі updateO У цьому випадку нам знадобиться перехід до наступного Screen, і ми можемо його виконати за допомогою виклику методу Androi dGame setScreen Про з методу MainMenuupdateO з новим екземпляром класу наступного екрану Screen Після виклику AndroidGamesetScreenC) екран MainMenu отримає управління, після чого він повинен відразу ж повернути управління, оскільки не є активним Screen У даному випадку викликає сторона – це AndroidFastRenderView в потоці основного циклу Якщо розглянути ту частину основного циклу, яка відповідає за оновлення і візуалізацію активного Screen, то видно, що метод updateC) буде викликатися для класу MainMenu, а метод present буде викликатися для нового поточного Screen Цього краще уникнути, оскільки ми визначили інтерфейс Screen таким чином, що методи resumeO і updateO повинні бути викликані як мінімум одного разу перед тим, як Screen повинен буде відобразити себе Тому ми викликаємо два цих методу в методі Androi dGame setScreen для нового Screen Потужний клас AndroidGame виконає всю супутню роботу

Останній метод називається getCurrentScreen Він просто повертає поточний активний Screen

Таким чином, ми створили каркас простої гри для Android Все, що нам залишилося зробити, – реалізувати Screen нашої гри Ми можемо також заново використовувати даний фреймворк для будь-яких майбутніх ігор, якщо вони не вимагають значної потужності при обробці графіки (інакше не обійтися без OpenGLES) Слід також замінити графічну частину фреймворка Всі інші класи для аудіо, введення і файлового вводу-виводу можуть бути використані заново

Підводячи підсумок

У цьому розділі ми з нуля створили повноцінний фреймворк для 20-ігри на Android, який зможемо використовувати в майбутньому для інших ігор (якщо в них немає якоїсь позамежної графіки) Досить докладно був розглянуто зручний і розширюваний дизайн Щоб наш містер Ном став ЗБ-грою, необхідно просто взяти цей код і замінити в ньому частини коду, що відповідають за візуалізацію, за допомогою OpenGL ES

Тепер, коли фреймворк готовий, сконцентруємося на нашій основній задачі – написанні гри

Джерело: Mario Zechner / Маріо Цехнер, «Програмування ігор під Android», пров Єгор Сидорович, Євген зазноби, Видавництво «Пітер»

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*