Шукати в цьому блозі

Практичне керівництво з розробки ігор в Gideros 2.

Частина 2/4

Зміст:

**************************************************
  1. Управління сценами та  Gideros OOП
  2. Обрізані зони екрану
  3. Ігнорування автоматичного масштабування для позиціонування обє'ктів гри
  4. Створення сцен (рівнів гри)
  5. Gideros OOП
  6. Створення нашого першого класу
*********************************************************

Управління сценами та  Gideros OOП



Тепер, коли ми знаємо всі основи, створімо власну гру. Ми будемо створювати клон гри Mashballs , з простою 2D-фізикою, де головною метою гри є відтягування і запуск м'яча в будь-якому напрямку, щоб відбити і ударити всі інші кулі на екрані.
Ви можете знайти додаткову інформацію про гру, а також завантажити її з: http://jenots.com/mashballs.


Ми будемо використовувати об'єктно-орієнтоване програмування Gideros (OOП) і створимо власні класи, які ми будемо використовувати протягом всієї гри. Також ми навчимося керувати кількома сценами та перемикатися між ними, а також як зберігати прогрес гравців  у грі.


Нижче наведено теми, які ми розглянемо в цій главі:

  • Налаштування нашого проекту
  • Введення в ООП Gideros
  • Ознайомлення з scene manager
  • Створення власних сцен з Gideros OOП
  • Створення стартового екрана для гри
  • Створення екрана "опціі гри"
  • Зберігання прогресу гри
Налаштування нашого проекту
  • Масштабовання спрайтів
  • Обрізані зони екрану
  • Абсолютне позиціонування
Масштабвання ї графіки за допомогою AutoScaling


Відкрийте Gideros Studio і створіть новий проект. Давайте назвемо це MashballsClone. Поки ми знаходимось там, створіть файл main.lua для нашого початкового коду, а також створіть папку images для зберігання наших зображень.


Щоб зробити наш проект більш читабельним, краще скопіювати файли проекту Gideros в ті самі папки, доки ви додасте їх у програму Gideros Studio. Наприклад, створіть папку images (і будь-яку іншу папку, яку ми будемо створювати) у вашій файловій системі та перед тим, як додати зображення до папки проекту Gideros

скопіюйте їх у відповідну папку, а потім додайте їх у project Gideros Studio. Таким чином, структура буде однаковою для project Gideros та вашої файлової системи.



Тепер давайте зробимо необхідні налаштування. Клацніть правою кнопкою миші на папці MashballsClone на панелі project та виберіть «Properties.». Натисніть вкладку "Settings" та виберіть t For iPhone and iPad " в меню для  Retina Display та Autorotation,, що означає, що ми підтримуватимемо Авторотацію і для iPads, і  для iPhones 



Тепер перейдіть на вкладку «Input» і виберіть, щоб генерувати події як для  Touch. так і для Mouse,(якщо вони ще не вибрані) та встановіть order на Mouse, Touch. Оскільки ми, в основному, вимагатимемо окремих дотиків, ми будемо використовувати події для миші дуже багато, тому це має бути спочатку. Якщо ваш додаток взагалі не використовуватиме Touch(сенсорне керування), його можна вимкнути, якщо хочете.

І як останній, але і найважливіший момент, давайте встановити режим масштабування та розмір екрану; щоб встановити їх, перейдемо до вкладки Graphics.



По-перше, ми можемо встановити орієнтацію пристрою як Landscape Left (як оригінальну орієнтацію гри Masbballs) і встановити FPS  60.



Оскільки ми розроблятимемо гру на всіх пристроях Android і iOS, ми повинні працювати з різними розмірами дисплеїв. Для цього ми будемо використовувати автоматичне масштабування Gideros і автоматичну роздільну здатність зображення. В якості базової роздільної здатності ми виберемо 800 x 480 дисплей. Це те, що ми можемо встановити в  Logical Dimensions.



Потім встановіть Letterbox в меню  Scale Mode , що означає, що Gideros автоматично підвищить або зменшить масштаб екрана та графіки, зберігаючи співвідношення сторін і не обрізаючи екран.

Автоматичне масштабування є відмінною функцією для роботи з різними типами розв'язків, але є також деякі моменти, які необхідно враховувати при впровадженні гри. Ви можете зіткнутися з парою проблем при використанні автоматичного масштабування та підтримки якомога більше пристроїв. Проблеми:
Перша проблема, звичайно, полягає в тому, що масштабована графіка може виглядати піксельованою. Але ми вже знаємо, як це виправити  Ми будемо використовувати роздільну здатність автоматичного зображення та встановимо масштаб зоображення  Suffix @ 2 і Scale 2
Це означає, що крім зоображень, які ми зробили для роздільної здатності 800 x 480 px, наприклад ball.png, ми також можемо (але не обов'язково) надавати двічі більше зоображення(як для 1600 x 960) з суфіксом @ 2 , наприклад ball@2.png. І в Gideros, при застосуванні автоматичного масштабування, він автоматично вибере найближчтй підходящий по розміру малюнок, тому зображення буде мінімально збільшено / зменшено. 

Не забувайте, що в нашій грі ми все одно працюємо  з роздільною здатністю 800 х 480 пікселів, наприклад, позиціонючи об'єкт. Саме для цього мають бути логічні виміри. А координати екран і розмір зоображень  під інші розміри дисплеїв перерахоується атоматично.

Тепер, коли ми розібрались з масштабованням графіки, перейдемо до наступної проблеми - Обрізані зони екрану
.


Обрізані зони екрану


Як я вже казав раніше, за допомогою масштабування Letterbox зберігається співвідношення сторін екрану, це саме те, що нам потрібно для даного типу гри, із спеціально визначеним ігровим полем.
 Проблема полягає в тому, що різні пристрої мають різні пропорції та зберігають наше визначене співвідношення сторін у грі, Gideros автоматично масштабуватиме нашу гру, щоб заповнити якомога більшу частину екрана.
Якщо на пристроях з іншими  пропорціями сторін в грі можуть зявитися путі  обрізані  зони екрану.


Подивимося, що я маю на увазі. Створіть зоображення з розмірами 800 x 480 px, назвіть testbg.png та скопіюйте її в папку Gideros, потім додайте її до папки  images
 на панелі Project. Після цього створіть новий файл в Gideros і назвімо його test.lua.

Всередині test.lua ми створимо растрове зображення  та збережемо його в змінній testbg. Після цього ми просто додамо змінну testbg до змінної stage , щоб малюнок відобразивсь на екрані..
Синтаксис: Lua
local testbg = Bitmap.new(Texture.new("images/testbg.png", true))
stage:addChild(testbg)

Тепер давайте запустимо наш проект на десктопному Gideros player і встановимо роздільну здатність IPad   в налаштуваннях програвача. Вам, можливо, доведеться встановити менший масштаб, щоб ви могли бачити весь екран  Gideros player на моніторі.

І після запуску, ви повинні побачити пробіли вище та нижче зображення


Так малюнок розміром 800x480 виглядає на роздільній здатністі IPad, з пробілами над і під графікою.


Щоб не було  цих пробілів нам потрібно робити графіку гри трохи більшу за розміри екрану, щоб заповнити ці простори. Ось чому я віддаю перевагу пропорціям екрану 800 x 480 px. Це приблизно посередині, між самими широкими та самими вузькими екранами.

Ми можемо припустити, що найбільше співвідношення сторін буде для IPad екрану(2048 x 1536), а найменше - для екрану iPhone 5 (1136 x 640).

Отже, давайте підрахуємо, наскільки великий фон, який ми повинні зробити, щоб покрити пробіли на iPad

Спочатку ми обчислимо співвідношення екрана iPad як 2048/1536 = 1,33333333333.

З нашого експерименту ми знаємо, що наша гра відповідає ширині iPad (2048 пікселів), але має пробіли по висоті; таким чином, для обчислення необхідної висоти для нашого фонового зображення ми розділяємо нашу ширину гри 800 на співвідношення iPad (800/1,33333333333=600,01)  отримємо майже 600 px.
Таким чином, ми знаємо, що для покриття роздільної здатності iPad із логічними розмірами 800 x 480 пікселів, нам потрібно зробити фонові зображення розмірами 800 x 600 пікселів.


Тепер давайте розрахуємо потрібну ширину для iPhone 5. Знову ж таки, ми беремо співвідношення сторін iPhone: 1136/640 = 1,775. І ми знаємо, що на цей раз Gideros заповнить висоту екрану, але залишить пробіли ліворуч і праворуч. Таким чином, ми беремо висоту гри (480px) і помножимо її на співвідношення iPhone 5:
480 * 1.775 = 852

Отже, роздільна здатність, необхідна для створення наших фонових зображень гри з пропорціями 800 x 480 px для масштабування без пробілів під iPad та iPhone 5, становить 852 x 600 пікселів

Тепер давайте створимо зображення з роздільною здатністю 852 x 600 px та замінимо існуючий testbg.png  ним.


Нам також потрібно розташувати фонове зображення в центрі, тому на нього не вплине масштабування; змінимо наш код і встановимо точку прив'язки "anchor" зображення по центру. А також позиціонуємо  зображення у центрі екрана,
використовуючи директиву getContentWidth () і директиву getContentHeight (), щоб отримати ширину та висоту екрану , яку ми встановили в налаштуваннях проекту.

local testbg = Bitmap.new(Texture.new("images/testbg.png", true))
testbg:setAnchorPoint(0.5, 0.5)
local halfWidth = application:getContentWidth()/2
local halfHeight = application:getContentHeight()/2
testbg:setPosition(halfWidth, halfHeight)
stage:addChild(testbg)



Ви можете спробувати запустити його з різними роздільною здатністю Gideros player. Не забувайте повторно запускати проект після зміни параметрів резолюії player. Наступний скрін: Gideros player з. встановленою  з роздільною здатністю як в iPad:

Наступний скрін:  Gideros player має роздільну здатність, встановлену для iPhone:


Ігнорування автоматичного масштабування для позиціонування обє'ктів гри


І остання проблема, яку нам доведеться вирішити, - це абсолютне позиціонування об'єктів.
    Хоча елементи гри,  повинні позиіонуватися відносно один одного,  деякі елементи- наприклад кнопки,  потрібно розмістити біля верхньої сторони екрана. 

Наприклад, незалежно від резолюції екрану, окрема кнопка завжди повинна з'явитися у верхньому лівому куті. Зазвичай це легко зробити, ви просто встановите його положення (0, 0) координати.

Але тепер, оскільки ми використовуємо автоматичне масштабування, в залежності від пристрою ми можемо мати відступ з верхньої або лівої сторони, а кнопка, розташована у координатах (0, 0), більше не буде у верхньому лівому куті.

Давайте спробуємо. Візьміть просте зображення, таке як ball.png,  додайте його   до папки images  в проекті  Gideros Studio

Як завжди ми створюємо bitmap з цієї текстури і позиіонуємо його до (0, 0) та додаємо його до stage
Синтаксис: Lua
local ball = Bitmap.new(Texture.new("images/ball.png", true))
ball:setPosition(0,0)
stage:addChild(ball)
Позиція за замовчуванням вже є (0, 0), але я додав його в код, просто підкресливши це.

Знову ж таки, ви можете спробувати різні резолюції, і ви побачите, що у випадках, коли є відступи, наше зображення не розташовується у верхньому лівому куті. Не забудьте перезапстити проект після зміни резолюції. плеєра Gideros 

Цей відступ, має такуж причину, через яку ми збільшили і розмістили фонове зображення у центрі.

Отже, нам потрібно забезпечити абсолютну позицію (незалежно від масштабування) для зображення, і це насправді дуже легко зробити. Потрібно розташувати зображення з деяким зміщенням. Ми можемо обчислити ці зсуви на осі x і y і застосувати їх до нашої поточної позиції; таким чином, м'яч міг бути розміщений всередині видимої зони Ipad.

Нижче наведено код для розрахунку зсуву та його застосування до нашого зображення:
Синтаксис: Lua
local dx = application:getLogicalTranslateX()/application:getLogicalScaleX()
local dy = application:getLogicalTranslateY()/application:getLogicalScaleY()
Тож давайте змінюємо наш попередній код, щоб позиціонувати його за допомогою зсуву таким чином:

local ball = Bitmap.new(Texture.new("images/ball.png", true))
ball:setPosition(-dx,-dy)
stage:addChild(ball)

Тепер ви можете перезапстити  проект і побачити, що наше зображення  буде у верхньому лівому куті.

Точно так само, якщо ми хочемо, щоб його позиціонували до інших кутів, нам доведеться обчислити зсув для інших позицій.

Спочатку нам потрібно буде отримати розміри екрана:
--отримати ширину екрана
local width = application:getContentWidth()
local height = application:getContentHeight()
А потім розраховуйте зсув  для позиціювання кожного  кута окремо:
--верх ліво
ball:setPosition(-dx, -dy)
--верх право
ball:setPosition(dx+width-ball:getWidth(), -dy)
--низ ліво
ball:setPosition(-dx, dy + height-ball:getHeight())
--низ право
ball:setPosition(dx+width-ball:getWidth(), dy + heightball:getHeight())
Тепер, коли всі проблеми з автоматичним масштабуванням вирішені, встановлені параметри проекту, давайте створимо нашу першу сцену в грі.


Створення сцен (рівнів гри)

Тепер у нас повинен бути файл main.lua і test.lua. Перший порожній, а другий має наші експерименти з налаштуваннями проекту. Але зверніть увагу на це, якщо ми додамо якийсь код до main.lua, то код з обох файлів (main.lua і test.lua) буде виконаний. Це тому, що Gideros автоматично виконує всі додані файли Lua.

Це може бути чимось новим для досвідчених розробників Lua, оскільки ви не будете вимагати кожен файл, який ви хочете використовувати; і це забезпечує набагато більш гнучкий підхід у роботі проектів. Але вона також має свої обмеження
Наприклад, якщо весь код виконується автоматично, як ми повинні розділяти різні сцени щоб організвати проект оптимальніше? Або в якому порядку виконуються файли? Що робити, якщо один файл залежить від іншого?

 За замовчуванням файли виконуються в тому порядку, в якому вони були додані, але ми  не повинні покладатися на випадковість. Правильний спосіб керувати проектом полягає в тому, щоб розділити весь ваш код на окремі класи. Це можна зробити, створивши окремі класи для кожної сцени, а також для об'єктів на сцені,
і зберігати кожен клас в окремих файлах. Там ніколи не повинно бути рядка коду, що виконується поза сферою застосування методу класу
Окрім  файлу main.lua. Чому main.lua настільки особлива? Тому що він завжди виконується як останній файл;
це означає, що всі попередні файли вже завантажені, і не буде жодних проблем із залежністю. Таким чином, правильний спосіб використання глобальних об'єктів - це створення функцій і функцій викликів всередині main.lua. В основному, він використовується для запуску гри, створення об'єктів і показати перший екран гри.
Інший спеціальний файл, який ми повинні відзначити, - init.lua; якщо ви створюєте цей файл, він завжди буде виконуватися як перший файл. Зазвичай це робиться для внесення деяких змін до класів Gideros та їхньої поведінки, якщо це необхідно, але ми не будемо йти так далеко й будемо використовувати тільки main.lua.

 І якщо  main.lua недостатньо, ви також можете встановити залежностей за проектом, клацнувши правою кнопкою миші на файлах Lua на панелі Project та вибравши «Code Dependencies,», ви можете вказати, чергвість виконання файлів.  Інший спосіб керувати ним - запскати файли не автоматично а програмно через Lua ;

ви можете виключити кожний файл із автовиконання, клацнувши правою кнопкою миші та вибравши "Exclude from Execution.". Тоді вам буде потрібно кожний файл завантажвати прописавши його в програмному коді гри, коли це буде необхідно.
Оскільки ми продовжуватимемо створювати нашу гру, нам більше не буде потрібен файл test.lua. Ви можете видалити його з проекту, натиснувши його правою кнопкою миші та вибравши Remove "Видалити" або просто виключити його з виконання та залишити його в проекті, якщо ви захочете пізніше експериментувати з ним.

Gideros OOП

Перш ніж почати створювати  нові сцени, щоб відокремити логічні екрани нашої гри, давайте спочатку ознайомимось із Об'єктно Орієнтованим Підходом в Gideros. Ви вже бачили деякі класи, наприклад, Bitmap, Texture і Sprite. І ви знаєте, що для створення нових екземплярів потрібно викликати метод .new () і передавати деякі параметри, такі як Texture.new ("image.png "). Тоді ці нові методи повертають екземпляр класу, де ви можете викликати методи, використовуючи: methodName (), наприклад, sprite: setPosition (100, 100).

 Дуже важливо зрозуміти різницю між викликом функції за допомогою крапки [.] або використанням двокрапки[:]. 
В Lua  Методи можуть використовуватися як як метод екземпляра, так і статичний метод, передаючи екземпляр як перший аргумент.

Тут ми створюємо екземпляр sprite та встановлюємо його положення за допомогою методу екземпляра.
Синтаксис: Lua
local sprite = Sprite.new()
sprite:setPosition(100, 100)
Але ми також можемо повторно використовувати той самий метод, що й метод класу, і передавати екземпляр як перший аргумент.
Синтаксис: Lua
local sprite = Sprite.new()
Sprite:setPosition(sprite, 100, 100)
Ви бачите, що використання двокрапкою означає, що ми передаємо посилання на екземпляр  першим аргументом.

Отже, тепер ми знаємо, як визначити метод і посилатись на екземпляр всередині, давайте спробуємо створити наш власний клас, який ми будемо використовувати пізніше. Але спочатку створіть папку classes (класи) усередині нашої панелі Project, щоб просто організувати файли. Після цього створіть новий файл Lua під назвою Button.lua всередині папки classes 




Створення нашого першого класу

Щоб створити простий клас Gideros, нам потрібно лише викликати функцію Core.class (), і вона повертає порожній клас.

Давайте створимо наш клас Кнопки "Button" , а також визначимо для нього конструктор (визначивши метод init), який буде просто виводити текст на консоль


Синтаксис: Lua
Button = Core.class()
function Button:init()
 print("ініціалізація кнопки")
end
Тепер, якщо ми спробуємо створити екземпляр для нашої кнопки у main.lua, він повинен надрукувати "ініціалізація кнопки"  на панелі Output, оскільки автоматично викликає метод init при створенні нового екземпляра.
local button = Button.new()
Якщо це так, вітаємо; Ви успішно створили свій перший клас Gideros.

Але оскільки наша кнопка повинна бути елементом інтерфейсу користувача, ми також повинні відобразити її на екрані. Вона не має нічого для відтворення, але все-таки спробуємо додати її до stage
stage:addChild(button)
та запустити проект.

О-о, що сталося? Ми отримали нашу першу помилку . У полі Output він говорить:

main.lua:2: bad argument #1 to 'addChild' (Sprite expected, got table)
Чому це так?

Тому що не кожен клас призначений для додавання до ієрархії візуалізації, так само, як не кожен клас може перетворити текстуру, подібну до Bitmap. Ці класи мають щось особливе всередині них, позаду сцен, що робить їх тим, чим вони є.

Але що робити, якщо ми хочемо, щоб ми могли додавати наш клас до ієрархії візуалізації, як об'єкт Bitmap або Sprite? Тоді ми просто повинні успадкувати клас Кнопки від Sprite. І це можна зробити, вказавши так званий базовий клас при створенні класу Button, як тут:
Синтаксис: Lua
Button = Core.class(Sprite)
Тепер наш клас клавіш успадкує всі можливості класу Sprite, що дозволить додавати його екземпляри до ієрархії візуалізації. Крім того, вони автоматично успадковують всі методи Sprite, такі як setPosition () та setAlpha ().


Спробуйте і запустіть проект зараз. Нічого не відображатиметься, тому що ми не маємо нічого для відображення, але також не буде виводити жодних помилок.

Насправді клас Sprite є базовим класом для всіх об'єктів, які можна додати до ієрархії візуалізації. Наприклад, обидва, класи Bitmap і Shape успадковують від Sprite і додають власні можливості.

І це - краса системи GIDEROS OOП, розширюваність класів, що використовують спадковість.

Тепер давайте змінимо конструктор класу Button, щоб прийняти будь успадкований об'єкт Sprite, як Bitmap або TextField. Потім ми додамо цей об'єкт Sprite до екземпляру нашої кнопки, використовуючи self: addChild, щоб показати його на екрані. Нам не потрібно додавати його до класу stage , оскільки ми вже додаємо екземпляр Button до класу stage ;
і, як і вся ієрархія, відображається  і цей спрайт, який був доданий до нашого екземпляра за допомогою методу addChild, також буде показано.
Синтаксис: Lua
function Button:init(sprite)
 self:addChild(sprite)
end
В  main.lua нам тепер треба створити об'єкт Bitmap з текстурою нашого зоображення і передати його на кнопку.
Синтаксис: Lua
local bitmap = Bitmap.new(Texture.new("images/ball.png", true))
local button = Button.new(bitmap)
stage:addChild(button)
Тепер ви можете спробувати запустити проект, і ви побачите, що м'яч повинен з'явитися на екрані. Ви також можете спробувати змінити положення кнопки за допомогою директиви: setPosition (x, y), щоб побачити, що наше зображення змінює позицію.

Далі ми повинні зробити це, щоб отримати event (подію), коли ми доторкнемося до неї. Адже це кнопка.

Для мишки(mouse) існує три види подій:
  • Event.MOUSE_DOWN   -кнопка була натиснута
  • Event.MOUSE_MOVE   -кнопка була натиснута і курсор переміщено
  • Event.MOUSE_UP  -кнопка була натиснута і відпущена
Для сенсорного екрану(touch) такі події:
  • Event.TOUCHES_BEGIN   -палець торкається сенсору
  • Event.TOUCHES_MOVE  -палець переміщається по сенсору
  • Event.TOUCHES_END  -палець торкнувся сенсору і відпустив
Подія для миші mouse при запуску з мобільного пристрою викликає  подію сенсора  touches.


Це саме те, що нам потрібно, і саме тому ми будемо використовувати події для миші. На даний момент нас цікавить лише подія MOUSE_UP. Можливо, ми також використовували подію MOUSE_DOWN, але завдяки вказівкам щодо інтерфейсу від  Apple краще надавати користувачам спосіб перенести палець з кнопки та випустити його, не викликаючи натискання.
Це зменшує можливість випадкових кліків, і тому ми будемо використовувати подію MOUSE_UP. Тож давайте визначимо метод onMouseUp і надрукуємо щось на панелі Output
звідти.
function Button:onMouseUp(event) print("ти натиснув мене")end
Ми не повинні пов'язувати цей метод з подією MOUSE_UP, тому він буде називатися автоматично, коли користувач натискає нашу кнопку. Для цього в межах нашого методу init класу Button ми визиватимемо метод addEventListener і передаємо назву події, метод, який оброблятиме подію та додаткові дані до нього.
self:addEventListener(Event.MOUSE_UP, self.onMouseUp, self)
Найбільш заплутаною тут є те, що, хоча ми маємо метод екземпляра, який ми будемо використовувати за допомогою двокрапки  , ми передаємо метод addEventListener за допомогою символу крапки. Оскільки ми не називаємо метод onMouseUp, а просто передаємо його як аргумент, і, як ви бачите, існує також третій аргумент-self змінна, яка автоматично буде передана методу onMouseUp, щоб він поводився як звичайний метод екземпляру.

Якщо ви ще цього не розумієте, це нормально, це є частиною реалізації OOП Lua, і ви можете використовувати його як шаблон і пірнути в специфіку Lua OOП в контексті Gideros, пізніше.

Тепер, якщо ви запустите проект і клацнете на зображенні, ми побачимо,"ти натиснув мене" на панелі Output. Але, привіт, що це таке? Навіть якщо ми натискаємо зображення поза межами зображення, все одно друкується  повідомлення.

Так працює Gideros для події миші та сенсору. Вони надсилаються на всі зареєстровані об'єкти, навіть якщо ви натискаєте їх за межами них. Є причини для цього, ще раз, щоб викликати  події, при роботі з кількома подіями або об'єктами, розташованими один над одним. Але виправити це легко.
У кожного успадкованого в Sprite об'єкта є метод hitTestPoint, який перевіряє, чи координати , належать цьому об'єкту Sprite чи ні.

Оскільки об'єкт події надає координати  x і y, ми можемо легко здійснити цю перевірку.
function Button:onMouseUp(event) 
 if self:hitTestPoint(event.x, event.y) then  
print("ти натиснув мене")  
end 
end
Тепер, якщо ми знову запустимо проект, ви побачите, що лише кліки, безпосередньо на зображенні, забезпечують вивід повідомлення "ти натиснув мене" в консоль, і наша кнопка працює як очікується.
Але, звичайно, ми хочемо визначити, що наша кнопка повинна зробити під час натискання, і ми повинні мати можливість надавати різні дії для різних екземплярів без жорсткого кодування дії класу. Для цього ми будемо використовувати ту саму систему подій Gideros, яку ми просто використовували, щоб отримати подію MOUSE_DOWN, але в цьому випадку ми  створимо і надішлемо власну подію .
Для цього нам потрібно створити новий об'єкт Event з нашим власним іменем, click, і передати його методу dispatchEvent нашого класу Button.
Але до цього, як ми вже визначили, яка подія об'єкту була викликана, ми можемо зупинити її подальше поширення (event:stopPropagation() ), щоб заощадити наші ресурси .
Синтаксис: Lua
function Button:onMouseUp(event)
 if self:hitTestPoint(event.x, event.y) then
 event:stopPropagation()
 local clickEvent = Event.new("click")
 self:dispatchEvent(clickEvent)
 end
end
Тепер у main.lua ми можемо слухати цю подію click і надаємо функцію, яку слід викликати, коли ми отримаємо подію .
button:addEventListener("click", function() print("you clicked me")end)
І у нас є повністю функціональний клас кнопки. Давайте рухатись далі, щоб створити нашу першу сцену гри

далі

Немає коментарів:

Дописати коментар

Підписатися на: Дописи (Atom)