Skip to content

Almeida-Oco/LPOO1617_T1G1

Repository files navigation

FINAL PROJECT DELIVERY

BCH compliance

Architecture Design


Packages


Controller


GameLogic
Translates input from Android to commands to be given to model

Model


Model UML

Entity
An abstract class which represents a single entity of the game, has what an Entity should implement and common methods between them
Mario
Abstract class which represents Mario, classes which extend this one are the various states Mario could be in
MarioRun
State in which Mario is running, meaning it can transition into every other state
MarioClimb
State in which Mario is climbing, meaning it can only transition to the death state and run state after finishing climbing the ladder
MarioFall
State in which Mario is falling, meaning it can only transition to the death state and run state after finishing the fall
MarioJump
State in which Mario is jumping, meaning it can only transition to the death state and run state after finishing the jump
MarioJump
State in which Mario is dying, meaning it can not transition into any other state, merely used for animations purposes
Fire
Represents a single Fire from the game, the fire has 2 different behaviours which can be swapped at run-time, making it either smarter or dumber
MovementStrategy
Abstract class which represents what a movement strategy of the Fire should contain. It implements methods common between strategies such as moving horizontally and vertically
SimpleMovement
Extends MovementStrategy, used to make the Fire movement as simple as possible, meaning most of its movements are in a random direction and of random duration
SmartMovement
Extends MovementStrategy, used to make Fire movement follow Mario wherever he is on the map
Donkey Kong
The Villain of the game, will mostly hold the animations of him.
Barrel
Abstract class which represents what a barrel should implement, has implemented methods which are shared by all child classes, such as collision detection
BarrelFall
State in which barrel is falling, meaning it can only transition to Rolling state after finishing the fall. The fall can be free-falling meaning it falls all the way to the end of the map, or a simple fall which is a transition between crane levels
BarrelRolling
State in which barrel is rolling, while it rolls every time it passes a ladder it may or may not choose to go down that ladder, in which case it transitions to the Fall state
DonkeyKong
Represents the DonkeyKong, there can only be a single instance of it per program run. Used for collisions with Mario and type updates
Map
Represents a single game map. Has many methods used both to know when an objects collides with the map and whether that object is in ladder, jumping, near a crane etc.
Pair
Represents pair of values, mostly used for coordinate storing

View


View UML

PlayScreen
Abstract class which represents a game screen
MainMenu
One of the possible game screens, holds the buttons for the main menu of the game
Play
The other possible game screen, represents the actual game screen
ScoreTimer
Class which holds labels to show current score, how many lives Mario has left and how much time has passed

Entity

ElementView
Abstract class which represents what a view of an object should have, implements methods such as draw, set position and update sprite
ViewFactory
Used to hold the various possible views and its sprite. When correctly used guarantees no more than 1 object of each view is created
MarioView
Holds the sprites to be drawn for mario, as well as their position and scale
BarrelView
Holds the sprites to be drawn for a barrel, as well as their position and scale
FireView
Holds the sprites to be drawn for a fire, as well as their position and scale
DonkeyKongView
Holds the sprites to be drawn for the DonkeyKong, as well as their position and scale
BarrelFireView
Holds the sprites to be drawn for the flaming barrel, as well as their position and scale
PrincessView
Holds the sprites to be drawn for the princess, as well as their position and scale

Design Patterns

FLYWEIGHT
Sprites are only loaded once so every time we need to use that sprite we simply go get it. Implemented thanks to LibGdx AssetManaget
SINGLETON
There can only be a single GameLogic and a single DonkeyKong
STRATEGY
Fires can change their strategy mid-game, meaning they can either get smarter or dumber based on current strategy
STATE
Mario has a number of states that transition between themselves as well as Barrel

Design Decisions

For this project we decided to use the Model View Controller architectural pattern to help maintain the loose coupling between packages as well as providing an easy to comprehend and high mutability of the Project.

Conclusions

Looking back there are some aspects of the project that we perhaps would change. First and foremost we would definitely not use physics in our game since arcade games have such an unique physics which is hard to mimic using actual correct physics. Due to this divergence between game physics and real physics we had some difficulties implementing both the collisions and a portable multi-device way to represent everything that involves gravity, such as jumps or falls. Other aspect we would reconsider is the use of a ViewPort in the game. When we first started implementing the game we were aware that we had ViewPorts available to us. However these would either not fill the whole screen as we wanted or would deform the game map in a way that did not seem pleasant to the eye. Therefore we decided not to use one. This made us have to worry what would happen in case screens of different size were used to play the game, so we added a scaling functionability, however it is not working properly. With a ViewPort all of this could be avoided and we could have honed the project even further.

In regards to how much time was spent on the project, we counted approximately 180 hours of work. This counting started when we finally managed to work properly with Android Studio, which by itself took a while. The work distribution is the same between group member, which means :

João Francisco Barreiros de Almeida (up201505866) 50%

José Pedro Dias de Almeida Machado (up201504779) 50%

USER MANUAL

  • Menu: very simple with only two buttons, the play button to start playing and the exit button to exit the game

Menu

  • PlayScreen Tilt the phone to move Mario, tilt left to move Mario to the left, tilt right to move Mario to the right and if Mario is aligned with the stairs tilting up the phone will allow Mario to climb the stairs. Only completes stairs allows Mario to go next floor but the breaked ones can be used to avoid barrels.

Exemplo 1

Exemplo 2

Move the phone up quickly(acelarometer) and Mario jumps, jump over the mario adds 100 points to your score and jump over fire gives you 500 points.

Exemplo 3

You die if any barrel or fire collides with Mario and you win if you rich to the platform where the princess is, Mario has 3 lifes, when ir reaches the 0 files the game ends.

Exemplo 4

SETUP/INSTALATION PROCEDURE

  • Installation: download the game from this repositorie (DonkeyKong.apk), go to your mobile device settings and allow installations from unknown sources and click on the file and then click on install.

  • Setup to open the project : Donwload Android Studio from here and then download the project from here, open Android Studio and click on Open Existing Project and select the file with this project

About

Repo for LPOO Projects

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages