Final Project Review Document

Due: Friday, June 14 online at 2pm

Format the document as a web page, link it into your group web site, and email us with the URL. Think in terms of roughly 4 pages, but you can certainly write more if you would like to (and you can see what other groups have done in the past).

The hard part of the course is over with, and now there is just one more thing to do: Write a project review document. The purpose of this document is to summarize the software design and implementation process that you experienced throughout the quarter. Prepare the document as a group, but I also encourage you to make points individually — just append it to the group response for the question, and annotate it with your last name (e.g., "[Voelker] I also thought that ..."). For examples, you can browse through the final reports from past years (e.g., 2023, 2021, 2015, and 2014 ).

At the start of the class, you wrote a game concept document, a project design specification, and a schedule for completing the project. These were all projections looking forward. Now that the class is ending, you can look back and compare what actually happened with what you planned.

A. In the project review document, start by addressing these main questions:

  1. Game concept: To what extent did your game concept change from initial concept to what you implemented? If it did change, how did it change and why?
  2. Design: How does your final project design compare to the initial design, and what are the reasons for the differences, if any?
  3. Schedule: How does your final schedule compare with your projected schedule, and what are the reasons for the differences, if any? (You should be able to glean this from your status reports.)

B. Then address these more general questions:

  1. Describe your development environment. What tools did you use? What was your build workflow? If you supported multiple platforms (e.g., MacOS and/or Linux), how did you support making your project work on all platforms? Do you have any tips or suggestions for future groups for their development environment?
  2. What group mechanics decisions worked out well, and which ones (if any) did not? Why?
  3. Which aspects of the implementation were more difficult than you expected, and which were easier? Why?
  4. Which aspects of the project are you particularly proud of? Why?
  5. What was the most difficult software problem you faced, and how did you overcome it (if you did)?
  6. In developing the media content for your project, you relied upon a number of tools ranging from the underlying graphics libraries to modeling software. And you likely did some troubleshooting to make it all work. So that students in future years can benefit from what you learned, please detail your tool chain for modeling, exporting, and loading meshes, textures, and animations. Be specific about the tools and versions, any non-obvious steps you had to take to make it work (e.g., exporting from the tool in a specific manner), and any features or operations you specifically had to avoid — in other words, imagine that you were tutoring someone on how to use the toolchain you used to make it all work. Also, for the tools you did use, what is your opinion of them? Would you use them again, or look elsewhere? Are there any tools that you used but, looking back, you would avoid?
  7. For those who used a networking library (e.g., RakNet or Boost), a physics library (e.g., Rapier or Bullet), an audio library (e.g., SFML or SoLoud), or a GUI library (e.g., imgui or nanovg), which libraries did you use and would you use them again if you were starting over knowing what you know now? Describe any lessons you learned using it (problems that you had to troubleshoot and how you addressed them) for future groups who may use it. If you did not use a library for any of those modules, judging from the experiences of the groups that did, would you have used it in retrospect?
  8. If you used an implementation language other than C++, describe the environments, libraries, and tools you used to support development in that language. What issues did you run into when developing in that language? Would you recommend groups use the language in the future? If so, how would you recommend groups best proceed to make it as straightforward as possible to use the language? And what should groups avoid?
  9. How many lines of code did you write for your project? (Do not include code you did not write, such as library source.) Use any convenient mechanism for counting (e.g., scc), but state how you counted.
  10. What lessons about group dynamics did you learn about working in such a large group over an extended period of time on a challenging project?
  11. Looking back over the past 10 weeks, is there anything you would do differently, and what would you do again in the same situation?
  12. Which courses at UCSD do you think best prepared you for CSE 125?
  13. What were the most valuable things that you learned in the class?
  14. Please post four final screenshots of your game on your group pages for posterity. I will display them on the group web page.

C. Archiving

  1. While external sites like Notion are convenient, we do not have any control over how long those sites continue to serve content. So we would like to host a static snapshot of your group's pages on this server. If you already hosted your group site on cse125.ucsd.edu, then you're done! If you used Notion, then please follow these instructions for creating a snapshot of your pages. Only do this step once you have completed the final report. Then send us a link when you are done. On the groups page, we will link to both the static locally-hosted version and the version on Notion (e.g., the 2023 groups page is a good example).

D. Entirely optional, I would appreciate any feedback on the course:

  1. For the pizza celebration after the demos, what do you think about doing it in the B220 lab? (I originally thought to avoid any more time in the lab :-) Some students pointed out that if we do it in the lab, then people can play each other's games. Other students said that they were exhausted and just sitting and having pizza was enough.
  2. What advice/tips/suggestions would you give students who will take the course next year?
  3. Do you have any suggestions for improving the course?
  4. Any other comments or feedback?
And then, finally, you'll be done!


voelker@cs.ucsd.edu