Розвиток школи NRW - програмування за допомогою GLOOP - навчальні проекти - асоціації

Область орієнтації (мітки переходу)

  • ООП із GLOOP
  • Швидкий початок
  • Викладацький проект
    • вступ
    • Послідовне програмування
    • Контрольні структури
    • Власні заняття
    • Асоціації
    • Спадщина
  • документація
  • встановлення
  • FAQ
  • Контактна особа
  • Ліцензія

CMS_VALUE [3]

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

матеріалів:

  • Вступний етап UV IV.1 (Посилання)

Послідовність сцени

Цей модуль запускається за допомогою класичної ігрової ідеї. Програмується гра, в якій внизу екрана видно невеликий НЛО, який гравець може переміщати вліво та вправо за допомогою клавіш зі стрілками.

Зараз астероїди прилітають зверху, чого слід уникати. Якщо НЛО потрапив під астероїд, гра закінчена.

Спочатку гру слід реалізовувати лише з трьома астероїдами. Крім того, всі об'єкти знаходяться в площині XY, тобто вона моделюється двовимірно.

Рисунок 1: Ескіз планування для ігрового проекту НЛО

Аналіз цієї проблеми швидко призводить до того, що НЛО складається з декількох об'єктів GLO, які необхідно переміщати синхронно, якщо НЛО ухиляється. Такий склад вже відомий.

Проблема тут полягає в деталях, якщо запитати, як слід реалізувати зіткнення між НЛО та астероїдом. Одним із можливих підходів є спочатку виключити цю проблему і лише здійснити контроль над НЛО та переміщенням астероїдів. Тоді відповідне моделювання без зіткнення виглядає так:

Рисунок 2: Моделювання простого прототипу без зіткнення

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

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

Скидання астероїда може бути передане на відповідний приватний метод.

Окрім цього, зіткнення ще має бути реалізоване. Кожен астероїд повинен мати доступ до НЛО, щоб він міг перевірити зіткнення і, за необхідності, метод вибухнути () НЛО може зателефонувати. Для цього посилання на НЛО передається в конструктор астероїда і зберігається ним. Тоді розширене моделювання виглядає так:

Рисунок 3: Моделювання простого прототипу зі зіткненням

Методи скинути за замовчуванням () і зустрів () є приватними методами класу астероїд і знаходяться в Перемістити () з астероїд зателефонував. Метод зустрів () перевіряє на зіткнення з НЛО і повертає значення правда, якщо він є. Метод Перемістити () з астероїд потім вибухне НЛО.

Малюнок 4: Гра НЛО у двох вимірах

Щоб вирішити, чи є зіткнення, астероїд використовує теорему Піфагора для обчислення відстані між ним і НЛО. Для цього він повинен знайти положення НЛО за допомогою методів gibX () і gibY () може запитати. Якщо відстань нижче певного порогового значення, передбачається зіткнення.

Тут слід зазначити, що об'єкт типу НЛО тепер доступний з двох різних місць. Крім того, використовуються два посилання, які навіть можуть мати однаковий ідентифікатор, оскільки вони знаходяться в різних класах.

Якщо гра НЛО закінчена таким чином, першим кроком у розширенні може бути її розширення до третього виміру. Камера нахилена на 90 градусів і рух НЛО навколо методів рухатися вгору () і рухатися вниз () розширений. Позиціонування астероїдів також буде розширено на один вимір, так само як розрахунок відстані між астероїдами та НЛО повинен бути перетворений у три виміри.

Оскільки зараз є значно більше місця для ухилення, кількість астероїдів слід збільшувати за допомогою поля. Результатом може бути моделювання, як на малюнку 5.

Малюнок 5: Гра НЛО у трьох вимірах

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

поглиблення

Для того, щоб поглибити принцип багаторазового посилання на об'єкти, доступно кілька ідей проекту, які базуються на подібному моделюванні, як гра НЛО.
Альтернативою є проект ловлі м’яча. Три кулі рухаються на квадратному ігровому полі. Коли вони досягнуть краю поля, змініть напрямок, щоб вони не покидали поле. Гравець керує невеликою коробкою-пасткою через ігрове поле і повинен викликати зіткнення з м'ячами і "ловити" їх таким чином. Якщо куля зловлена, вона зникає. Коли всі кульки зловлені, гра закінчена.

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

Рисунок 6: Ескіз планування для проекту Кугельфанген

Моделювання для цього проекту має включати класи Пастка від куль, Куля, коробці і сірникове поле включати. Моделювання в контексті бібліотеки «Ручки та миші» або в Greenfoot, як правило, обходиться без класу сірникове поле, тому що вони трактують екран як ігрове поле. Оскільки бібліотека GLOOP не має екрана, тут слід розробити окремий клас. Можливе моделювання може виглядати так:

Рисунок 7: Моделювання проекту лову кулі

Створюючи об’єкт класу Пастка від куль гра починається. Він створює всі інші об'єкти і викликає метод для поля та трьох куль в циклі анімації переміщення () на. Залежно від клавіатури, спосіб setMovement () покликав коробку. Новий напрямок руху коробки передається їй за допомогою двох параметрів, завдяки чому pVX - складова руху в напрямку Х і pVZ складова руху в напрямку Z. Тому гра моделюється в площині XZ. Під час руху і коробка, і м’яч перевіряють, чи не дійшли до краю ігрового поля. Для цього вони можуть отримати доступ до ігрового поля та запитати його ширину та глибину. Кулі також перевіряють, чи не відбулося зіткнення з коробочкою і, можливо, стають неактивними та непомітними.

Гра закінчується, коли всі кулі неактивні.

Наступний вихідний код представляє метод переміщення кульки:

Метод вихідного коду переміщення куль

Тоді готовий результат може виглядати, як показано на малюнку 8.

Рисунок 8: Модельне рішення для проекту Кугельфангена

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

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

Рисунок 9: Водіння та більярд як подальший варіант спеціалізації

  • QUA-LiS NRW
  • Професійне навчання
  • Стандартне резервне копіювання
  • подальшу освіту
  • Захист даних
  • відбиток