Sprint 2 - Level loading and collision detection

Due: BEFORE Oct. 12 11:59:59 pm:

Group Team Rubrics (Word) (PDF): Oct. 13 via email.

Objectives:

  • Implement up/down/left/right movement for Mario. It should not be physically based / jumping based.
  • Implement state transitions, collision detection, and collision response for Mario, enemies, blocks, and items. Mario should not be able to pass through blocks and any state changes for object may happen instantly (i.e. you do not have to animate between states after Mario gains an item or takes damage).
  • Add background elements (clouds and bushes) as individual objects or included in a repeating background image.
  • Define a level via a csv or xml file and write code to initialize objects based upon the files contents.
  • Create an artificial level that contains an instance of Mario and all types of blocks, pipes, powerups/items, and enemies that are found in level 1-1, but place them such that they all fit on the screen at the same time. The image below displays one possible arrangement. For this sprint, inclusion of the flagpole is optional.


The user should be able to use controls to move Mario up/down and left/right, and change Mario between jumping, standing, crouching, idle, and running states. The end result will be a testing ground for the collision detection and response. It does not require physics, sound, a moving camera, heads up display elements (points, timer, coin count, level number), pausing, or the ending flag sequence. Note: only Mario has to be able to move in the test enviroment, everything else can remain stationary and simply have frame changes if they are animated.

Sprint 2 Responsibilities:

  • DevOps - Scrum Tracking Task Status and Remaining Work (20 points):
    • Add dates for Sprint 2 (09/29 - 10/12).
    • Move any incomplete (Not marked Done) stories (with associated tasks) from Sprint 1 to Sprint 2.
    • Using PBI stories provided to you (Mario PBIs), add several product backlog items for the requirements for this sprint and assign them to Sprint 2.

      • Sprint 2 PBI

      • 13 - Control Player Vertical Movement via Keyboard
      • 14 - Control Player Horizontal Movement via Keyboard
      • 15 - Control Player Vertical Movement via GamePad
      • 16 - Control Player Horizontal Movement via GamePad
      • 17 - Collision Detection
      • 18 - Avatar Collision Response - Structural Entities
      • 19 - Avatar Collision Response - "Enemy Encounter"
      • 20 - Avatar Collision Response - "Power-Up Change"
      • 22 - Enemy Collision Response w/ Avatar
      • 21 - Structural Entity Collision Response w/ Avatar [Brick Block Bounce]
      • 25 - Structural Entity Collision Response w/ Avatar [? Block => Used Block]
      • 26 - Structural Entity Collision Response w/ Avatar [Brick Block Shatter]
      • 23 - Tile Map Definition
      • 24 - Level 1-1 (Artificial Level)
    • Add tasks, with an effort amount, under each backlog item. Be sure each task is assigned to someone. Finish adding tasks before class on 09/30.
    • 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 2 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 2.
  • 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 Rubric

Additional 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.

top