Sprint 5 - extending your 2D platforming game
Due: BEFORE Nov. 30 11:59:59 pm:
Group Team Rubrics (Word) (PDF): Nov. 30 via email.
Objective: Extend your implementation of your 2D platforming game engine in some interesting way. You may choose topics from the list below or come up with your own. Regardless of what you choose, your group must contact the instructor (email or in person) with your proposed topics for approval prior to end of the planning phase in order to determine if the workload is sufficient.
In general, you can come up with your own ideas by breaking down Super Mario Bros. into components and thinking about what can be modified and what can be added. Below is a list of starting ideas you can use.
- Misc. Features
- Simultaneous multiplayer
- Add new powers and/or states for Mario
- Alter the behavior of existing movement (jump, run, walk, etc.) during run-time
- Add level 2-2 (or any underwater level)
- Add level 1-4 (or any other level with Bowser in it)
- Alternative cameras
- Player controlled enemies
- Achievements
- Input processing - cheat codes ; special moves (ex: down down-right right punch)
- Console for changing game constants
- Game event log file
- Genre-crossing
- RPG elements (leveling, stats)
- Puzzle elements (find keys, push blocks, mazes, etc.)
- Limit player vision (fog of war or cone of vision for mario)
- Gravity control
- Portals
- Time control (entire world or just mario) ; undo/redo
- Horde mode (enemy spawners)
- Nightmare mode (killed enemies haunt mario)
- AI escort
- Random events
- Graphics
- Shaders
- 3D Mario
- AI
- Control Mario for optimal play (solves level fastest or with maximum points)
- Control Mario for Turing Test (plays like a human)
- Alternative enemy AI
- Player assisting AI - passive (displays prompts to help the user - think quick time events)
- Player assisting AI - active (AI takes over Mario control when in danger)
- Procedural Content - level generation
- Ensure a procedurally generated level is solvable
- Ensure a procedurally generated level is solvable for an AI player
- Infinite Mario, create a neverending level
- Hardware - Input
- Mouse
- Kinect (the department has a few that can be borrowed - ask the instructor for details)
- Multitouch (MS Surface)
- Trackball
- Tiltable or shakable devices
- Altering gameplay for non-traditional users (toddlers, adults with Carpal Tunnel syndrome, adults with slow reaction times)
- Hardware - Output
- Mobile device
- High definition televisions or monitors
- Supporting changing screen size
- Software Engineering + Design
- Control mario via file input, ghost race
- Perform data analysis on your VSTS server
- Written documentation (on your system, requirements, C# and .NET features, other game development environments and tools)
- Graphical documenation (UML diagrams for use-cases or class interaction/coupling)
- Testing (somewhere in the neighborhood of 6000 test cases)
- Game state/world tracking - undo/redo, replay camera, save states
- Port to XBox360
Important note: During the planning phase, make sure everyone has something to work on and that you are not exceeding the amount of work your team can accomplish in two weeks.
Sprint 5 Responsibilities:
- DevOps - Scrum Tracking Task Status and Remaining Work (40 points):
- Add dates for Sprint 5 (11/10 - 11/30).
- Using PBI stories you create, add several product backlog items for the requirements for this sprint and assign them to Sprint 5.
- Add tasks, with an effort amount, under each backlog item. Be sure each task is assigned to someone. Finish adding tasks before class on 04/02.
- Grading will be based on:
- Quality of the PBI (20 points).
- PBI Decomposition into Tasks (10 points).
- Task Assignment and Tracking (5 points).
- Quality of the Burndown Chart (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 5 Release (60 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 (40 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 5.
- 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.
