Sprint 1 - Objects, Sprites, and States

Due: BEFORE Sep. 28 11:59:59 pm:

Group Team Rubrics (Word) (PDF): Sep. 28 via email.

Objectives:

  • Continue to familiarize yourself with the software tools for project progress tracking and source code control.
  • Create interfaces for different types of 2D platforming game elements/objects (examples could include: players, enemies, items, projectiles, platforms, blocks)
  • Create a class for each object included in the first level of your game.
  • Implement the animation (update + draw) for the default state of each object.
  • Implement the animation (update + draw) for all possible states of the player character that can be reached via user input (i.e. pressing left/right/up/down, run, and jump buttons) and by gaining items, except for temporary powers (i.e. star in Mario Bros.)
  • Note: you do not need to implement up/down/left/right motion for objects, just state and animation frame changes.


Strongly Advised Design Suggestions:

  • Make use of the Command design pattern to separate concerns of UI or events from actions.
  • Make use of the Factory Method design pattern to separate the concern of creating/selecting a sprite on a spritesheet from individual animated sprites.
  • Make use of the State design pattern to separate the concern of object state/behavior from the object.

Note - the Sprint requirements are structured to limit the scope of your project and gradually add new features in each Sprint (as is the practice in Agile Software Development). However, you should have a rough idea for what will be needed to complete the first level of the 2D platforming game you are cloning, to help in designing a system that can easily be modified to add gameplay functionality as the project progresses.

Sprint 1 Responsibilities:

  • DevOps - Scrum Tracking Task Status and Remaining Work (20 points):
    • Make sure all team members have been added to your DevOps project.
    • Add dates for Sprint 1 (09/15 - 09/28).
    • Using PBI stories provided to you (Mario PBIs), add several product backlog items for the requirements for this sprint (controllers, commands, objects, sprites, etc.) and assign them to Sprint 1.

      • Sprint 1 PBI

      • 1 - Player One Avatar Visuals (Avatar Sprites)
      • 2 - Enemy Visuals (Enemy Sprites)
      • 3 - Item Visuals (Item Sprites)
      • 4 - Change Avatar 'Action' State via Keyboard
      • 5 - Change Avatar 'Power-Up' State via Keyboard
      • 6 - Change "Block" State via Keyboard
      • 7 - Obstacle Visuals (Block Sprites)
      • 11 - Player Input (Controllers)
      • 12 - Player Actions (Commands)
    • 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/16.
    • 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 from the 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 1 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 1.
  • 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

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