| Table of Contents |
|---|
| Setup/Installation Procedure |
| Video Tutorial |
| Package and class diagram (UML) |
| Design Patterns Used |
| Tests Coverage |
| Other Considerations |
-
-
- Download the jar here.
- Run the file from the terminal or by double-clicking it.
-
- Clone this repository and open it with Android Studio.
- Set your Run Configuration to work in android/assets folder.
- To assemble a release apk you will need to change the signing settings to your own, or assemble an unsigned apk.
Original package and class diagram for reference. This was drafted before we began development.
-
The Game features three main packages:
- Model: It expresses the application's behavior in terms of the problem domain, independent of the user interface (Controller package). It directly manages the data, logic and rules of the application.
- View: An output representation of the model's information.
- Controller: Accepts input and converts it to commands for the model or view.
Why we decided to use it:
- facilitates simultaneous development;
- seperates responsabilities;
- reduces coupling of components and, therefore, facilitates testing;
- models can have multiple views.
-
Participating classes: ViewFactory and B2DFactory.
Why we decided to use it:
- Creates objects without exposing the instantiation logic to the client (therefore allowing for higher abstraction and cleaner code).
-
Participating classes: EntityView and all sub-classes (BallView, PowerUpView, ...).
Why we decided to use it:
- Allows the subclasses to decide which class to instantiate (useful for when a class knows it should create an object, but not it's type).
-
Participating classes: NullGameServices.
Why we decided to use it: Prevents constant null checks which would result in no actions being executed.
-
Participating classes: EntityView and ShapeView.
Why we decided to use it: facilitates updating all view entities in the game.
-
Participating classes: GameController (handles input), GameModel (updates game) and GameScreen (renders).
Why we decided to use it: decouples the progression of game time from user input and processor speed.
- 100% class coverage
- 100% method coverage
- 98% line coverage
-
We had initially planned for the GameModel class to implement the Singleton pattern, but eventually it became more troublesome than the problems it solved. It increased code coupling and made automated testing unnecessarily difficult.
-
We estimate a total of 300 hours (evenly distributed between the two developers).
-
- Frustratingly trying to integrate google play services (and getting it to work on a release build);
- Releasing an alpha on the play store, while adhearing to Google Play App Signing.
(These are fairly simple once you've done it a couple times, but for first-timers like us it required understanding the inner works of Android Studio)
-
If you see any references to 'Spheral', it was the original name of this project. We decided to rename it mid-development to Armadillo to better reflect the art style.
-
Project developed for 'Object Oriented Programming Laboratory', a second year subject @FEUP.
Authors: Andre Cruz and Edgar Carneiro.
-
A big thanks to Mariana Silva for providing most of the art we use in the game.
-
As a result of our difficulties in setting up Google Play Services, we decided to write a detailed tutorial on this task: Setup Google Play Services in LibGDX.
Tutorial Authors: @AndreFCruz and @antonioalmeida.