Project Peer Review
Review form
General
- G1: How creative is the project? (
0
: I've seen this on Youtube, 1
: not creative 2
: average, 3
: creative, 4
: very creative, 5
: wow!)
-
Answer:
4
Very Creative
-
Justification: Despite being simple, it is a very original and unique game, not similar to any other well known game.
- G2: How difficult was it to implement the project? (
0
: no challenge, 1
: very easy, 2
: easy, 3
: fair, 4
: complex, 5
: insane)
-
Answer:
4
Complex
-
Justification: Creating a game is hard. Defining rules, coming up with a core mechanic and building gameplay on top of it is not easy, and this game was very well executed.
- G3: List 3 positive aspects of the project. Motivate your selection.
-
1. The project was very creative and ambitious, the game is fun to play.
-
2. The fact that the game is based around one core mechanic is a very positive design aspect.
It's a principle followed by many games, as it contributes to making the game enjoyable to play.
-
3. The graphics of the game look very good, it must have taken a lot of effort to make them.
- G4: List 3 negative aspects of the project. Motivate your selection.
-
1. Despite the game looks well polished when playing it, there are some problems with the code organization.
-
2. The game's difficulty is not perfectly balanced, it's very determined by luck in the early game.
There's also a chance to arrive at a point where the player has so much health that it's impossible to lose and the game goes on forever.
-
3. The
README.md
file doesn't mention all the programming techniques used. It's hard to tell how many techniques and which techniques were used.
Programming techniques
- PT1: Evaluate how well 5 programming techniques we learned throughout the course were adopted in the project. Assign a mark from
0
to 5
to each technique, where 0
means completely incorrect usage and 5
means perfect usage.
-
1. Exception handling
-
Answer:
5
-
Justification: Correct usage of
try/catch
blocks with methods related to file I/O which can throw exceptions.
-
2. File I/O
-
Answer:
4
-
Justification: Correct usage of File I/O with the
java.nio
package, although there are some problems with the FileLoader
class (see below).
-
3. Abstract classes
-
Answer:
0
-
Justification: The only usage of an abstract class (
Entity
class) is to implement an interface without implementing its methods.
-
4. Interfaces
-
Answer:
3
-
Justification: Correct usage of the interface
Entity_Interface
, but could have been an abstract class.
-
5. Serialization
-
Answer:
5
-
Justification: Great usage of
.csv
files to register the leaderboard.
Git repository
- GR 1: How appropriate is the
.gitignore
file of the project? (0
: missing, 1
: very bad, 2
: bad 3
: average, 4
: good, 5
: very good)
-
Answer:
3
Average
-
Justification: The
.gitignore
file contains most usually ignored files, but the .txt
extension should be removed.
- GR 2: How appropriate is the
README.md
file of the project? (0
: missing, 1
: very bad, 2
: bad 3
: average, 4
: good, 5
: very good)
-
Answer:
4
Good
-
Justification: The
README.md
files gives a good explanation about the project and the game.
It doesn't properly explain how and where the programming techniques are used.
Maven
- M1: Can you compile the project via Maven? (
0
: no, 1
: yes, but..., 2
: yes)
-
Answer:
2
Yes
-
Justification: The project can be compiled with
mvn clean compile
without any problem.
- M2: Can you clean the project via Maven? (
0
: no, 1
: yes, but..., 2
: yes)
-
Answer:
2
Yes
-
Justification: The project can be cleaned with
mvn clean
without any problem.
- M3: Can you run the project via Maven? Check
README.md
on how to run the project. (0
: no, 1
: yes, but..., 2
: yes)
-
Answer:
1
Yes, but...
-
Justification: The project can be run with
mvn clean compile javafx:run
as described in the README.md
file, but only after changing the pom.xml
file removing the javafx-graphics
dependencies for other operating systems.
- M4: Are the project's dependencies appropriately configured in
pom.xml
? (0
: no, 1
: some, 2
: yes)
-
Answer:
2
Yes
-
Justification: The required dependencies are appropriately configured.
- M5: Are all Maven plugins appropriately configured in
pom.xml
? (0
: no, 1
: some, 2
: yes)
-
Answer:
2
Yes
-
Justification: The required plugins are configured correctly.
- M6: Does the project adopt Maven's standard directory layout? (
0
: no, 1
: yes, but..., 2
: yes)
-
Answer:
1
Yes, but...
-
Justification: The project does follow Maven's standard directory layout, although some folders are misplaced.
Textures in the textures folder should probably be in the resources folder,
the tests should be in the folder src/test/java instead of src/main/test/java
Testing
- T1: Are all tests passing? Run
mvn test
. (0
: no, 1
: yes, but..., 2
: yes)
-
Answer:
2
Yes
-
Justification: All 13 tests pass when running
mvn test
- T2: How well do the tests cover the code? (
0
: no tests, 1
: no important method, 2
: some important methods, 3
: most important methods, 4
: all important methods, 5
: 100% test coverage)
-
Answer:
2
Some important methods
-
Justification: Only a few methods are covered by the tests, there are only 4 test classes of the 23 project classes.
- T3: Do the tests actually verify the expected behavior of the program? (
0
: no tests, 1
: useless tests, 2
: most don't, 3
: some do, some don't, 4
: most do, 5
: awesome tests)
-
Answer:
4
Most do
-
Justification: Most tests seem to correctly verify the behaviour of the program.
- T4: How well can you understand what the tests are supposed to verify? (
0
: no tests, 1
: what is going on?, 2
: most are not understandable, 3
: some are understandable, some aren't, 4
: most are understandable, 5
: all test are understandable)
-
Answer:
3
Some are understandable, some aren't.
-
Justification: Some tests are hard to follow, there are a lot of methods being called beside the one that is being tested.
The
Main_1
class also seem to have some methods that are only used for testing which should probably be in a test class.
Documentation
- D1: How understandable is the Javadoc written for classes, fields and methods of the program? (
0
: no documentation, 1
: very poor, 2
: poor, 3
: average, 4
: good, 5
: awesome)
-
Answer:
4
Good
-
Justification: The documentation is easily understandable.
- D2: How useful is the Javadoc written for classes, fields and methods of the program? (
0
: no documentation, 1
: irrelevant, 2
: little utility, 3
: average, 4
: useful, 5
: very useful)
-
Answer:
2
Little utility
-
Justification: Many methods don't have any javadoc, some of them have a
@param
or a @return
annotation with no text.
- D3: Can you generate documentation files for this project? Run
mvn javadoc:javadoc
. (0
: no, 1
: yes, but..., 2
: yes)
-
Answer:
2
Yes
-
Justification: Javadoc can be generated with
mvn javadoc:javadoc
- D4: How adequate are the non-javadoc comments written throughout the code? (
0
: mostly inadequate, 1
: average, 2
: mostly adequate, 3
: awesome)
-
Answer:
2
Mostly Adequate
-
Justification: There are some non-javadoc comments that explain what some lines are used for.
Code quality
- Q1: Is the code style adopted throughout the project consistent? Consider how whitespace is represented (spaces or tabs), tab size, naming conventions for classes, methods and variables, indentation, braces usage, line width. See Google Java Style Guide as an example of code style guidelines. (
0
: no, 1
: yes, but..., 2
: yes)
-
Answer:
1
Yes, but...
-
Justification: The code style adopted is mostly consistent, some methods are not separated by blank lines, some braces are preceded by a white space, some are not, some classes have underscores to separate words, some have capital letters.
- Q2: How would you rate the project in terms of code duplication? (
0
: a lot of duplication, 1
: some duplication, 2
: barely any duplication, 3
: no code duplication / only justifiable duplication)
- Q3: How easy it is to understand how the program works by looking at the source code? (
0
: mostly hard to understand, 1
: some fragments are hard to follow, 2
: not hard, but not easy, 3
: easy to understand)
-
Answer:
1
Some fragments are hard to follow
-
Justification: Most of the code of the program seem to be contained in the
Main_1
class, it could probably be separated into smaller classes.
Most classes are contained in only one package, a better organization might have helped with the development, separating GUI from game logic is also helpful.
There are many unused variables.
- Q4: Is any section of the program excessively inefficient? (
0
: mostly hard to understand, 1
: some fragments are hard to follow, 2
: not hard, but not easy, 3
: easy to understand)
-
Answer:
2
-
Justification: There is an efficiency in the
FileLoader
class.
The class contains a lot of fields which could be static, the loadAllFiles
method also loads a lot of image files which are not used, instead, a new image is loaded every time an entity is created.
- Q5: Does the program crash unexpectedly (e.g. by an uncaught exception)? (
0
: all the time, 1
: rarely, 2
: it happened once, 3
: never)
-
Answer:
3
Never
-
Justification: No crashes were experienced when running the project.