Game : Analysis

Now that the project has been turned in, take a few hours to relax and reflect, then analyze your experience. It is important for you to review your past performance, analyzing its positive and negative aspects to maximize what you learn from this experience. The goal of this retrospective is to draw meaningful conclusions to help you learn from your past successes and failures. They are an integral part of a project because, if taken seriously, they can be an extremely productive method of improving your development practices.

Submission

Complete the following parts in the appropriate repositories noted for each (as well as a form):

• Documentation: in your game_NETID repository, complete the project DESIGN document (note, any part of this document can also be used within your analysis as appropriate)
• Project Reflection: complete this Google form, in which you analyze on the project's planning and progress and what you learned from doing this project
• Written analysis: in your portfolio_NETID repository, complete the template file, already started for you, called 01_game/ANALYSIS.md using Gitlab's markdown format
• Code masterpiece: create an example of well designed code totaling no more than 300 lines (including comments) to review with your mentor UTA
  • in your game_NETID repository, refactor your existing code to improve its design and verify the new design compiles and the code still works
  • in your portfolio_NETID repository, simply copy one or more classes from your game repository to your portfolio repository's 01_game/ folder for review

Specifications

This analysis is your opportunity to demonstrate your knowledge of design concepts represented (or not) in the project's code. The course staff can readily identify the good and bad aspects of project's design, so we are looking to see if you can also acknowledge these as well. If it is also an honest and thoughtful reflection, it can also help you identify specific actions you can do to improve future projects.

Personal Project Report

This Google form represents your view of the project's planning and progress. Analyze your plan and how the project's outcome could be improved. Describe specific, important, events during the project's time line to justify your comments rather than general terms like "always late", "bad code", etc.

Design Review

This written report represents your personal view of how your program is organized and why it was done that way. It can be a chance for you to describe how you might fix a problem or refactor the design if you did not have time to actually change the code. If you think something is good, justify your opinion. If you think something is bad, justify your opinion, and suggest how to improve it. Use specific code examples and reasons related to principles discussed in class or in the readings rather than general terms like "clearly/obviously", "good/sucks", "elegant/ugly", or "like/hate". Note, since no design is perfect, including both pros and cons of a design (i.e., its trade-offs) or alternate designs you considered is highly encouraged.

The following sections must be included in your analysis. Questions are provided to get you started thinking about what to consider within each section; you may, of course, include anything else you feel is relevant. In other words, do not be limited by these questions, but respond to them at least.

• Status
  Reflect on the coding details of the project by reviewing the code.
  • Is the code generally readable (i.e., does it do what you expect, does it require comments to understand)? why or why not?
  • Are the dependencies in the code clear and easy to find (e.g., instance variables, parameters, return values, or within constructors) or do they exist through "back channels" (e.g., global variables, order of method call, or get methods)?
  • Describe two pieces of code in detail:
    • Describe the purpose of this code in the overall project.
    • What makes this code easy (or hard) to read and understand?
    • What GIT commits (identified by their message) contributed to this code?
  • What were the purpose of those commits (i.e., new code, refactoring, debugging, etc.)?
  • Why did you choose to package these changes as a commit?
• Design
  Reflect on how the program is currently organized.
  
  • Describe the overall design of the program, without referring to specific data structures or actual code.
  • As briefly as possible, describe how to add a new level to the game.
  • Justify why your overall code is designed the way it is or what issues you wrestled with if you think its design is lacking in some way. Are there any assumptions or dependencies in your code that impact the overall design of the program?
  • Describe two features from the assignment specification in detail:
    • What classes or resources are required to implement this feature?
    • Describe the design of this feature in detail (what implementation details are encapsulated? what assumptions are made? do they limit its flexibility?).
• Alternate Designs
  Reflect on alternate designs for the project based on your analysis of the current design.
  • Describe two design decisions you made, or wish you had done differently, in detail:
    • What alternate designs were considered?
    • What are the trade-offs of the design choice (describe the pros and cons of the different designs)?
    • Which would you prefer and why (it does not have to be the one that is currently implemented)?
  • What are the three most important bugs that remain in the project's design or implementation?

Your analysis must be completed using Gitlab's markdown format and must be named 01_game/ANALYSIS.md.

Code Masterpiece

Take part of the project and refactor it to demonstrate what you now think of as good design. It should represent a feature or component within your larger project that is small enough to be separable, but functionally significant enough to have some interesting design element. I use the term "component", rather than "class", because it may be several classes that work together, e.g., a few classes that work together or a superclass and its sub-classes. Note, if your component is specifically intended to be superclass, it must include enough detail that it is clear how to extend it and at least one example subclass.

In comments at the top of each class included, describe this code's purpose and why you think it is well designed (i.e., what you think it shows that you have learned so far in the course). Every line of code in the class(es) you submit will be reviewed, you cannot specify only part of a class to review or include large sections of commented out code. Simply copy only the Java code files you want us to grade from your project to your portfolio's 01_game folder without renaming them so we can easily compare them to previous versions (you do not have to include other files they depend on as we will not be compiling these versions, just commenting on them).

Your masterpiece code must total between approximately 150-300 lines, including comments.