Лабораторная работа №1 (итог: mariolab01)
Проблемы (задачи):
П1. Goomba и Player не должны знать друг о друге.
П2. Goomba не должен управляться собственным локальным таймером.
ООП1: конструкторы, деструкторы, сигналы и слоты.
План работы:
1. Исследовать жизненный цикл экземпляра Goomba. Определить, как происходит изменение координат спрайта, изображения для спрайта, когда осуществляется перерисовка спрайта. Обратить внимание, что происходит с Player и Goomba при столкновении.
2. Вынести таймер Goomba в MyScene (после вызова конструктора для m_goomba). Связать сигнал таймера с новым слотом MyScene updateGoomba(): сделать вызов пересчёта координат для спрайта Goomba.
3. Вынести проверку пересечения из Goomba::nextFrame() в MyScene::updateGoomba(): добавьте в после пересчета координат.
4. Составьте отчёт в электронном виде, записав все внесённые изменения в код по сравнению с предыдущей лабораторной работой (что и где удалено, добавлено, отредактировано). Ссылайтесь не на номера строк, а на содержание. Например, как выше: «добавлено в функцию MyScene updateGoomba() после вызова Goomba::nextFrame()».
Лабораторная работа №2 (итог: mariolab02)
П1. Следует удалить пару сигнал/слот коллизии Goomba и Player, так как и сигнал и слот определены в классе MyScene.
ООП1: конструкторы, деструкторы, сигналы и слоты.
План работы:
1. В updateGoomba() убрать emit: вместо сигнала marioSizeStatus(1) и слота setMarioSize(1) должен быть прямой вызов setMarioSize(1) как обычной функции после удаления персонажей при коллизии.
2. В результате имеем ошибку. Обратите внимание, что окно с сообщением появляется, но дальше приложение завершается. Подсказка: присвойте nullptr указателям на Goomba и Player при коллизии; проверьте для всех действий этих персонажей, что они выполняются не при нулевых указателях; остановите таймеры Player (их два).
3. Придумайте тесты для исправленной версии: какие варианты управления движением Player нужно проверить.
4. Составьте отчёт в электронном виде, записав все внесённые изменения в код по сравнению с предыдущей лабораторной работой (что и где удалено, добавлено, отредактировано). Ссылайтесь не на номера строк, а на содержание.
Лабораторная работа №3 (итог: mariolab03)
П1. Рефакторинг Goomba. Сделать Piranha неподвижным аналогом Goomba.
ООП1: перегрузка функций (наследование и полиморфизм QGraphicsItem->Goomba).
ООП2: преимущества виртуального деструктора.
План работы:
1. Удалить всё лишнее в Goomba (.h/.cpp), то есть сделать рефакторинг (повышение продуктивности восприятия кода человеком).
2. Внесите изменения в прототипы методов Goomba, чтобы подчеркнуть использование полиморфизма (см пример собственного класса потомка для QGraphicsItem https://doc.qt.io/qt-5/qgraphicsitem.html).
3. Выясните, почему некоторые функции из пункта 2 имеют модификатор (спецификатор) const.
4. Обратите внимание на то, какие конкретные члены класса Goomba расширяют спецификацию базового класса QGraphicsItem.
5. Сделайте Piranha неподвижным аналогом Goomba.
6. Определите, каким образом вызывается nextFrame для Piranha, сделайте вызов по сигналам того же таймера, что и для Goomba (таймер запускать, когда оба персонажа созданы).
7. Замените функцию MyScene::updateGoomba на MyScene::updateEnemies, которая содержит по два действия: обновление спрайта (для каждого персонажа отдельно), потом проверку коллизии (для каждого персонажа отдельно). Проверку коллизии с последующей обработкой вынесите в MyScene::checkMarioEnemyCollision(QGraphicsItem* item), параметр – персонаж Goomba или Piranha.
8. Обратите внимание на удаление Goomba через деструктор QGraphicsItem
(https://www.quantstart.com/articles/C-Virtual-Destructors-How-to-Avoid-Memory-Leaks
https://wiki.sei.cmu.edu/confluence/display/cplusplus/OOP52-CPP.+Do+not+delete+a+polymorphic+object+without+a+virtual+destructor
)
9. Составьте отчёт в электронном виде, записав все внесённые изменения в код по сравнению с предыдущей лабораторной работой (что и где удалено, добавлено, отредактировано). Ссылайтесь не на номера строк, а на содержание.
Лабораторная работа №4 (итог: mariolab04)
П1. Добавление второго Goomba, обработка сбора монет и их утраты при коллизии.
ООП1: добавление новых экземпляров существующих классов, исследование отношений между экземплярами разных классов.
План работы:
1. Добавить указатели на новые экземпляры WallPlatform, BrickPlatform и Goomba, добавить их в сцену.
2. Как связаны WallPlatform, BrickPlatform и Goomba логически и визуально? Как связаны длины WallPlatform, BrickPlatform и путь, который проходит Goomba?
3. Добавьте код, который заставляет BrickPlatform «переливаться» (анимация), тем же способом, что и код для имеющейся платформы.
4. Добавьте изображение с фреймами монеты (для анимации монеты). Зарегистрируйте его в файле ресурсов.
5. Выясните, какая функция отвечает за сбор монет персонажем Марио. Экземпляры каких классов обеспечивают логику учёта и отрисовку монет?
6. Проверьте, чтобы функция сбора вызывалась во всех функциях, которые отвечают за движения Марио.
7. Добавьте в соответствующий класс функцию setZero() для обнуления количества собранных монет. Пропишите вызов этой функции при обработке столкновения Марио с грибами Goomba и растением Piranha.
8. Выберите редактор заметок, чтобы поверх скриншотов с кодом, которые пойдйт в отчёт, добавлять красочно комментарии об изменениях! Составьте отчёт в электронном виде, записав все внесённые изменения в код по сравнению с предыдущей лабораторной работой (что и где удалено, добавлено, отредактировано). Ссылайтесь не на номера строк, а на содержание.