For this assignment, you will be giving feedback on the completeness of assignment two: Obscura. To do so, we will give you a rubric to provide feedback. Please give positive criticism and suggestions on how to fix segments of code.
You only need to review code modified or created by the student you are reviewing. You do not have to check the code and project files that the instructor gave out.
Abusive or hateful language or comments will not be tolerated and will result in a grade penalty or be considered a breach of the UC Davis Code of Academic Conduct.
If there are any questions at any point, please email the TA.
See the official course schedule for due date.
A successful submission should consist of a copy of this markdown document template that is modified with your peer review. This review document should be placed into the base folder of the repo you are reviewing in the master branch. The file name should be the same as in the template: CodeReview-Exercise2.md. You must also include your name and email address in the Peer-reviewer Information section below.
If you are in a rare situation where two peer-reviewers are on a single repository, append your UC Davis user name before the extension of your review file. An example: CodeReview-Exercise2-username.md. Both reviewers should submit their reviews in the master branch.
- name: [Michelle Lu]
- email: [[email protected]]
For assessing the solution, you will be choosing ONE choice from: unsatisfactory, satisfactory, good, great, or perfect.
The break down of each of these labels for the solution assessment.
Can't find any flaws with the prompt. Perfectly satisfied all stage objectives.
Minor flaws in one or two objectives.
Major flaw and some minor flaws.
Couple of major flaws. Heading towards solution, however did not fully realize solution.
Partial work, not converging to a solution. Pervasive Major flaws. Objective largely unmet.
- Perfect
- Great
- Good
- Satisfactory
- Unsatisfactory
Camera remains locked onto the target and the plus symbol is drawn correctly. All the cameras tested also work in hyperspeed mode.
- Perfect
- Great
- Good
- Satisfactory
- Unsatisfactory
Camera scrolls to the right at a constant speed, while the target appears to stay still. The target is also unable to leave the confines of the box.
- Perfect
- Great
- Good
- Satisfactory
- Unsatisfactory
The target is able to move ahead of the cross, giving the impression that the camera is lagging behind. The camera doesn't exceed a certain leash distance and speeds up when catching back up to the target when the target becomes stationary.
- Perfect
- Great
- Good
- Satisfactory
- Unsatisfactory
The cross is able to move ahead of the target, giving the impression of a "look ahead" camera. When the target stops, the camera returns to the target after waiting a set amount of time, and the camera never exceeds it's leash distance.
- Perfect
- Great
- Good
- Satisfactory
- Unsatisfactory
There are 2 boxes correctly drawn. When the target is inside the inner box, the camera doesn't move, but if it's in the outer box, the camera moves in the direction the of the quadrant of the box the player is in when the player also moves in that direction. The target is also unable to escape the outer box, fulfilling all the requirements.
Check the scripts to see if the student code adheres to the GDScript style guide.
If sections do not adhere to the style guide, please peramlink the line of code from Github and justify why the line of code has not followed the style guide.
It should look something like this:
- description of infraction - this is the justification.
Please refer to the first code review template on how to do a permalink.
I could barely find any style guide infractions, I believe the student has throughly read and memorized the Godot style guide and took care when coding to make it neat and easily accessible.
- Weird spacing in variable declarations - When drawing the crosshairs, the variable declarations at the top have uneven spacing
- A single line between functions - According to the Godot style guide, there should be 2 lines in between functions.
- Correct exported variable definition - Exported variables are declared at the very top, and there is spacing aroung the := operators.
- Correct use of comments - Comments about the code have a space after the #, while code that is commented out do not have the space - this is to distinguish which is a comment for information and which is code that is just disabled. Almost all the rules in the style guide were followed correctly.
If the student has followed best practices then feel free to point at these code segments as examplars.
If the student has breached the best practices and has done something that should be noted, please add the infraction.
This should be similar to the Code Style justification.
- Honestly would not find any infractions of the Godot Best Practices guide, student did well in making their code and project as efficient as possible.
- snake case - variables are correctly declared in snake case.
- _process is used in vessel.gd - Correct use of _process over _physics_process.