Sprint 3 - First level movement, physics, and gameplay
Due: BEFORE Oct. 26 11:59:59 pm:
Group Team Rubrics (Word) (PDF): Oct. 26 via email.
Objectives:
The end result will be a reasonable facsimile of the first level of a 2D platforming game (Super Mario Bros level 1-1) [with leniency on the accuracy of physics and camera control compared to the original], and without sound, heads up display elements (points, timer, coin count, level number), level/camera transitions (the secret underground area), and the ending animation (flagpole sequence).
- Implement the core gameplay of a 2D platforming game.
- Update your level file to include all of the objects in the first level of your game. Additionally, at the start of the level add an instance of every block and item type. That way you (and the grader) will save time during manual testing.
- Implement movement and jumping for the player character (Mario). Note: allowing the user to jump higher (but still with some height limit) by holding jump receives more credit than jumps with fixed height.
- Implement the player's transitionary states (changing powerups or taking damage).
- Implement movement for enemies.
- Implement movement for powerups and items.
- Add any projectiles made by players or enemies (Mario's fireballs).
- Add movement for blocks and platforms (where applicable, such as block bumping).
- Update collision detection and handling to deal with the new types of moving objects. You may also need to make modifications to handle cases where objects are colliding with two other objects at the same time (ex: mario intersecting with two blocks)
- Add a scrolling camera (you may or may not enforce the restriction of never scrolling back to the left - better yet use an interface and implement both!).
- Implement resetting the level upon the player character's death.
Sprint 3 Responsibilities:
- DevOps - Scrum Tracking Task Status and Remaining Work (20 points):
- Add dates for Sprint 3 (10/14) - 10/26).
- Move any incomplete (Not marked Done) stories (with associated tasks) from Sprint 2 to Sprint 3.
- Using PBI stories provided to you (Mario PBIs), add several product backlog items for the requirements for this sprint and assign them to Sprint 3.
Sprint 3 PBI
- 49 - Level 1-1 Complete Experience>
- 8 - Side Scrolling
- 9 - Parallax (Background) Scrolling
- 27 - Structural Entity Collision Response w/ Avatar [Item Reveal and Block transition]
- 28 - Control Player Movement via Keyboard (Jumping and Falling, Walking/Running and Falling)
- 29 - Control Player Movement via GamePad (Jumping and Falling, Walking/Running and Falling)
- 48 - Avatar "Falls down a Pit" and loses a life
- 30 - Power-Up Movement (Mushrooms, Star)
- 31 - Enemy Movement
- 44 - Level Reset
- 50 - Projectile Flowers (Fireball)
- 51 - Enemy Collision Response w/ Avatar (Koopa Troopa)
- 52 - Koopa Troopa Shells
- Add tasks, with an effort amount, under each backlog item. Be sure each task is assigned to someone. Finish adding tasks before class on 10/14.
- Grading will be based on:
- Completeness of tasks based on covering the requirements (stories) for the sprint. This is worth 10% of the points for this sprint. I'm reviewing Tasks for Quality of Content. Tasks should describe the HOW from the Assignees perspective to accomplish the WHAT fromthe related Story (PBI) (10 points)
- Did everyone have a task(s) assigned to them and track progress over the course of the sprint - you lose points when I can tell from reviewing history that the Work Remaining goes from 0 to N and back to 0 in time less than it took to reasonably accomplish the task (5 points)
- Quality of the Velocity and Burndown charts at the end of the sprint (5 points).
- During the Sprint:
- Each team member should implement the tasks assigned to them.
- When you sit down to work on this sprint, drag the task you are going to work on to in-progress on the board.
- If you finished the task during that session, Update Work Remaining to 0, drag it to Done and check your work into DevOps.
- If you did not finish, but it compiles, Update the Remaining Work for the task and check your work into DevOps.
- If it is not finished and does not compile, Update the Remaining Work for the task and make sure your work is saved (or shelved).
- Sprint 3 Release (80 points):
- Run Code Analysis on your solution and fix any reported warnings or errors. For warnings you do not wish to fix, provide justification in the readme file. More details on this are posted below the grading outline.
- You should place a high priority on code quality for maintenance and flexibility of the system. For the file you performed a readability review on for the initial implementation, you should now do a code review. Discuss code quality in terms of metrics discussed in class and come up with constructive criticism to improve the code quality. More details on how to do code reviews are posted below the grading outline.
- Grading will be based on:
- the amount of features and the level of difficulty in implementing them (15 points)
- implementation quality and correctness - how much was completed and does it work (50 points)
- amount of Code Analysis warnings (5 points)
- did everyone contribute to the implementation (5 points)
- did everyone contribute to code reviews on code quality (5 points)
Work to turn in:
- Do a Build->Clean Solution in Visual Studio and without rebuilding, create a .zip of your Entire project directory (Make absolutely certain your .zip contains the .sln and the Content hierarchy).
- Next perform a Build in Visual Studio; you will now add the bin directory (Debug or Release) and its contents to the zip file. Make SURE you independently verify the bin folder is complete and your submission will RUN!
- Upload the .zip using Carmen under the dropbox for Sprint 3.
- The dropbox is set up to accept multiple submissions, only the latest submission before the deadline will be graded.
- Please let the instructor know if you have any difficulties submitting your work.
Grading:
See above. In addition, your individual scores will be weighted based on the team rubrics and activity in DevOps.
Notes on grading of sprints
Sprint RubricAdditional information - same as in earlier sprints
On code reviews:
In the root folder of the project, add a folder to store code reviews. You can add plaintext files to the project in this folder by going to the Project menu, add new item, and select text file under the general option.
Each of the submitted code reviews must contain commentary on code for the Current Sprint. The expectation is not for you to "go through the exercise simply checking the boxes". The expectation is you invest time to review the current Sprints code contributions to identify potential problem areas for future improvement.
In the plaintext file for a code quality review, include the following information in this exact order:
- Author of the code review
- Date of the code review
- Sprint number
- Name of the .cs file being reviewed
- Author of the .cs file being reviewed
- Specific comments on code quality
- Number of minutes taken to complete the review
- A hypothetical change to make to the game related to file being reviewed and how the current implementation could or could not easily support that change
On refactoring:
You should be using some of the features under the analyze tab in Visual Studio. Calculating Code Metrics will give you some idea on the general quality of the code, and running Code Analysis will give you specific lines of code to change to fit style guidelines. Configure Code Analysis to use “Microsoft Basic Design Guideline Rules”. If you are having trouble figuring out how to use the Code Analysis tools, Microsoft offers a lab to help learn it here. Alternatively you can use this document or this tutorial video. Fix as many code analysis errors as possible, if fixing one forces a design change that your team does not have time to complete, document it in a readme file placed near the root folder of the project. You should also have a readme to document user input if the suggested controls above are not used.
