For this assignment, you will be giving feedback on the completeness of Exercise 1. To do so, we will be giving you a rubric to provide feedback on. For the feedback, please provide 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 review the code and project files that were given out by the instructor.
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. The file name should be the same as in the template: PeerReview-Exercise1.md. You also need to include your name and email address in the Peer-reviewer Information section below. This review document should be placed into the base folder of the repo you are reviewing in the master branch. This branch should be on the origin of the repository you are reviewing.
If you are in the rare situation where there are two peer-reviewers on a single repository, append your UC Davis user name before the extension of your review file. An example: PeerReview-Exercise1-username.md. Both reviewers should submit their reviews in the master branch.
- name: Quinn Broderick
- email: [email protected]
To assess the solution, you will be choosing ONE choice from unsatisfactory, satisfactory, good, great, or perfect. Place an x character inside of the square braces next to the appropriate label.
The following are the criteria by which you should assess your peer's solution of the exercise's stages.
Cannot find any flaws concerning the prompt. Perfectly satisfied all stage objectives.
Minor flaws in one or two objectives.
A major flaw and some minor flaws.
A couple of major flaws. Heading towards a solution, however, did not fully realize the solution.
Partial work, but not really converging to a solution. Pervasive major flaws. Objective largely unmet.
- Perfect
- Great
- Good
- Satisfactory
- Unsatisfactory
Allows for all player movement is functional, the player is always at center of screen for the camera, 5x5 unit cross is drawn when draw_camera_logic (F is pressed) is true.
- Perfect
- Great
- Good
- Satisfactory
- Unsatisfactory
Player movement is allowed in all directions and the box is drawn when draw_camera_logic (F is pressed) is true. The box does move horizontally at a constant speed, player is kept within confines of the box and is pushed forward if they lag behind. (Only issue would be that the top and bottom of box are not visible in the camera view and the player is allowed to move off the screen within box confines in z-direction).
- Perfect
- Great
- Good
- Satisfactory
- Unsatisfactory
Player movement is allowed in all directions, camera follows player at a slower speed, camera catches up to player when player stops moving. 5x5 unit cross is drawn when draw_camera_logic (F is pressed) is true. (Only issue is player leash distance doesn't seem to exist, player is allowed to move seemingly endless distance from camera center).
- Perfect
- Great
- Good
- Satisfactory
- Unsatisfactory
Camera leads player in direction of input, camera approaches player when player stops moving. 5x5 unit cross is drawn when draw_camera_logic (F is pressed) is true. (Only issue is player leash distance doesn't seem to exist, player is allowed to move seemingly endless distance from camera center).
- Perfect
- Great
- Good
- Satisfactory
- Unsatisfactory
When player is in inner box, camera doesn't move, when it's in the space inbetween the outer and inner box (not touching edges of outer box) camera moves at push_ratio with player. Issues with player touching edges of either box. If touching inner box edges then moves again inside inner box, player position is oriented off the edge. Not allowed to touch the edges of the outer box (but does move appropriately ie moves as though it is touching the edge). Issues with corner of outer box, can't move player into corner of the box in any way.
Check the scripts to see if the student code follows the .Net style guide.
If sections don't adhere to the style guide, please permalink the line of code from GitHub and justify why the line of code has infractions of the style guide.
It should look something like this:
- description of infraction - this is the justification.
Here is an example of the permalink drop-down on GitHub.
Here is another example as well.
I really couldn't find any issues with code style, great job!
Everything was formatted correctly, all variables were declared in the proper positioning, functions were organized properly, basic comments made interpretation easy w/o overloading program with in-line comments.
-
all function formatting universal, I.E. indentations, spacing, etc.
-
consistency with all the draw_logic functions makes them more comprehensive
-
universal organization/correct organization of class name and export/public variables
If the student has followed best practices (Unity coding conventions from the StyleGuides document), then feel free to point at these segments of code as examples.
If the student has breached the best practices and has done something that should be noted, please add the infracture.
This should be similar to the Code Style justification.
Occasional interesting spacing choices inbetween lines but otherwise all variables/classses named appropriately using correct naming practices for each. Functions are written in a chronological order that makes sense and are easy to follow, comments were also useful for understanding sections of the code.