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?
   1. From the beginning, we knew we wanted to do a rhythm-based cooperative game. The idea of the boss fight was also decided early on in the initial concept phase. Although the art style was very up in the air until about halfway through the project, the core identity of the game did not change.
2. Design: How does your final project design compare to the initial design, and what are the reasons for the differences, if any?
   1. Initially, we wanted to have different roles and character types (ex. tank, healer, fighter, etc). However, due to a combination of time constraints and realizing the amount of work it would take, we opted for a more simplified version that captured our original MVP.
   2. The final design of the characters was a step away from what we initially planned for, because we found that the process of creating our own characters and animations was too slow.
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.)
   1. The main difference was that the MVPs were pushed back. We ended up getting blocked fairly often when we merged major architectural changes, because new undefined behaviour/bugs kept getting introduced. We ended up with a final product that was along the lines of our original MVP.

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?
   1. We used CMake to build our executables. It was nice because we could build for Mac and Windows OSes. For cross-platform compilation, we used MinGW to have access to common UNIX compatibility features, like threads.
   2. Another option would have been compiling through Visual Studio, but it would have made it harder for it to be cross-platform.
   3. We used OpenGL, C++, FMOD (for the music/rhythm aspects), and Assimp for asset loading.
2. What group mechanics decisions worked out well, and which ones (if any) did not? Why?
   1. The combo combat system worked well in that performing different combos made the game dynamic and interesting. There were tense moments when all but one player was dead, and it was up to a single player to keep the game going.
   2. With the combo system, we found that inexperienced players had difficulty keeping rhythm well enough to execute a full combo. This made it challenging and frustrating for players who did not have a strong musical background to play the game effectively.
   3. The arena-style boss phase system kept players engaged at all times, but we found that once players figured out the phase logic, the game became much less dynamic, as most players stuck to doing one thing for the entire duration of the phase.
   4. The music phase system kept players on the edge of their seat, adding tension and excitement as the game progressed. However, we found that some phases lasted way too long, giving listener fatigue, as the music phase kept looping.
3. Which aspects of the implementation were more difficult than you expected, and which were easier? Why?
   1. Staying organized and merging were more difficult than expected (feat. our 70+ branches). The setup of the game infrastructure also took us a while, but it paid off and made adding the game logic on top easier.
   2. Adding game mechanics was easier than expected, since the Colliders, models, and networking were set up separately.
4. Which aspects of the project are you particularly proud of? Why?
   1. The music (s/o Shane) because it’s super catchy and the music transitioning with the phase of the game is a very neat effect.
   2. The rhythm-based gameplay and combos turned out well, so we’re also proud of those. It’s pretty cool how we have the boss with different phases and corresponding attack styles as well!
5. What was the most difficult software problem you faced, and how did you overcome it (if you did)?
   1. We found that networking problems were particularly hard to debug. We had a networking issue that arose during our demo, where the program crashed, likely due to an incomplete packet being sent. This was resolved by setting up a loop that waited for the entire packet to be received.
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?
   1. Our 3D models were largely created using Blender (versions 4.0 and 4.1). We exported into .gltf and .bin, and we had to bake in textures for the models then export those as .png files. For this reason, we also had to avoid geometry nodes and other more complex Blender features.
   2. This process seemed complex at first and took some troubleshooting to get the pipeline working, but it was manageable after a while. We used Google Drive to share the files, so that part was a little clunky, but it worked.
   3. We used the assimp library to load models. Our group didn’t run into any major issues using the library, so we’d use it again.
   4. To get the actual size of the model from Mixamo you need to apply the scale transformation in blender(control + A). However, this is going to break the animation. To fix it, you will also need to scale the animation down.
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?
   1. We used FMOD engine for audio and rhythm input. It was effective at getting the rhythm-based gameplay functional, so we would use that library again.
   2. We would encourage people to use FMOD studio as opposed to the FMOD engine library, as it has a lot of built-in controls that we ended up having to build ourselves. We opted to use the engine initially because it was more lightweight and did not require installation of a separate program.
   3. We did not use a GUI library, but would highly encourage future project groups to use one, as GUI was one of the harder things to implement and make it extensible.
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?
   1. We used C++11, built for Windows using g++ with MinGW, and for Mac using clang++.
      1. MinGW is a pain to setup initially. We would suggest not opting for cross-platform C++.
   2. If planning to use C++ strictly on Windows, use Visual Studio.
   3. It’s extremely hard to debug undefined behaviour due to bad memory accesses or multithreading. Our advice would be to draw things out first and code against that as a single source of truth.
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, but state how you counted.
   1. Approximately 83389 lines
   2. We used git-quick-stats and got all lines added, then removed any sufficiently large outliers that appeared to be from libraries (e.g. anything over 50,000 lines). We are almost certainly overcounting, however.
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?
    1. Have more group work sessions! And make sure everyone consistently is able to meet for syncing up and working together.
    2. [Ryan] Showing up is super important. The valuable part is not only the project, but the people you got to work with.
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?
    1. Building the game engine was fun and rewarding! If we were to do it again, we would probably try to make our engine architecture simpler.
    2. We would load models in earlier, since seeing progress visually is much more motivating than debugging and verifying functionality through prints :)
    3. Also, merge often and smaller commits.
    4. [Jacob] Would buy red bull again
12. Which courses at UCSD do you think best prepared you for CSE 125?
    1. CSE 120, 123, 124, 167, and 169
13. What were the most valuable things that you learned in the class?
    1. You can make a game! It’s possible to do it from scratch.
    2. Time management skills and setting realistic goals + milestones.
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