Final Report.

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. We wanted a spooky vibe, but ended up with a meme.
   2. We were initially going for a horror, maze (labyrinth) theme.
   3. We were thinking of using AI monsters, flashlights and traps, with different classes and types of weapons besides just arsenal, like melee. We had also planned on having different looks for a player model, like girls with long hair, short hair, different types of clothes and such.
   4. Didn’t change much except for certain design (aesthetic) aspects and the story to go along with the game concept.
   5. Most changes were made due to time constraints.
2. Design: How does your final project design compare to the initial design, and what are the reasons for the differences, if any?
   1. We never really planned the design of our code thoroughly, the design just came to us in a dream and we executed on it. 
   2. It really was just trying to implement initial basic versions of things that will help implement features and they never got refactored.
   3. It was only way into the quarter (around week 8) when we actually refactored the code to make it more maintainable and readable.
   4. We had to make many cuts. Flashlight and trapping mechanic were nice to have, but we had no time to add them.
   5. The theme did look dark and scary, but not a horror vibe. The scene was not really dark enough to initiate any jumpscare, and we did not model spiderwebs and haunted abandoned houses.
   6. We could not have a diversity of unique looking characters and class types and weapon types. 
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. We barely followed it, mostly because some features like establishing a connection between client and server took (far -Shane) longer than expected. Collision also took longer than expected so the actual game was actually made mostly in the last three weeks of the quarter instead of our planned debugging and feature freeze beginning at week 7. 

General Questions

1. What software methodology and group mechanics decisions worked out well, and which ones did not? Why?
   1. Honestly we just randomly coded and hoped that there were no merge conflicts. In hindsight, we really should’ve planned and stuck to some form of schedule like a sprint or something.
2. Which aspects of the implementation were more difficult than you expected, and which were easier? Why?
   1. Boost is more difficult than expected. Repeat after me: “You Boost, you lose”. For example, in order to even save connections you have to go through making a shared pointer, a bunch of constructors, and a bunch of other things that makes showing a cube from scratch using OpenGL seem easy.
   2. Collisions were way more difficult than expected.
   3. Adding multiplayer support when one player was connected to the server was much easier.
3. Which aspects of the project are you particularly proud of? Why?
   1. Sound Design.
   2. Our animation and models looked very unique and life-like. They were really dynamic.
   3. Sam: Even though it’s really basic, collision and our “physics” engine took us a LONG time to make and to finally perfect, and I’m extremely proud of that.
4. What was the most difficult software problem you faced, and how did you overcome it (if you did)?
   1. Visual studio is a b word. Nuget packages can be fickle. Brute force, shotgun debug
   2. You Boost, you lose. There is no overcoming.
   3. Testing 
   4. Structuring the code depended on the packages and information passed between server and client, so we had to heavily rely on the  Networking team in the early stages to make any progress. We knew what we needed and what we wanted to pass, the question was whether we could pass it back and forth. 
5. 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. N/A. C++ is king. 
6. 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. It’s kind of hard to really assess how many lines of code we wrote because a lot of the time we were pair programming so while someone may have a lot of  code contributions, it is often the group’s idea of what to write.
   2. Thomas: I definitely wrote all that code and it’s not counting imgui or the assets at all. 
   3. Shane: I could have sworn I to contributed more than 3% of the code…
7. In developing the media content for your project, you relied upon a number of tools ranging from the DirectX/OpenGL 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. Animation

• Code SetUp – We used Assimp and OpenGL 
• https://ogldev.org/www/tutorial38/tutorial38.html
• https://learnopengl.com/Guest-Articles/2020/Skeletal-Animation

• https://learnopengl.com/Model-Loading/Model
• https://learnopengl.com/code_viewer_gh.php?code=src/3.model_loading/1.model_loading/model_loading.cpp

• Basically, what they’re trying to do is that Assimp is tryng to read the bone/joint information from a file (assuming it has animation).
• The Bone-Info hashmap is important. It stores each unique bone/joint information like its weight and id, and we use that information to look up each needed bone for each vertex we loop through and pass the weights of the bones to the shader. The Bone-Info hash-map takes a Bone ID as the key and weight information. That key (Bone ID) is basically the index to an array list inside the shader or just to access in the hashmap. Later on, as you loop through the vertex of each model/mesh, each vertex will be affected by a group of bones and its weight. You access those bones through their name, and you associate that bone name with their index in an array list to get their weights. 
• For example, say a model has 23 bones. (HeadBone, NeckBone, R-ShoulderBone, L_ShoulderBone, SpineBone, ButtBone….). A vertex can be affected by 4 bones. Say this vertex1 is affected by only HeadBone and NeckBone. Vertex2 can be affected by NeckBone, SpineBone, ShoulderBone, ButtBone. 
• Your job is to loop through a hierarchy of the skeleton and pass on it Binding pose transformation, and the parent bones that affect the child bones and weights done to your current bone, pass to shader, and alter the current position of the vertex to a new position. 

b.  Blender – Make sure you save constantly. Don’t apply modifiers until you are ABSOLUTELY sure you want to make those permanent changes.

Texture: Smart UV unwrap and image texture is your friend. When you quit Blender, save the modified images or else they will disappear. 

Exporting: We had good luck with the Collada (.dae) format, since it can store both material properties and animations in one file.Apply modifiers before exporting. It also supports objects with only diffuse colors, which is really helpful for adding simple objects which don’t need textures. We didn’t handle any textures like specular maps or normal maps, but assimp supports those with Collada too. We really should have used the node hierarchy for all models, not just the ones with animation. This meant that we had to tweak our export settings depending on whether the mesh had an animation. 

Model with Animation:

Dope Sheet’s Action Editor and NLA are great. 

You need to bake your animations. In Object mode, click on the rig object.

Make sure there is something in the action area

(this one has no animation if you try to bake and export the file, even though you will see animations in Blender)

(The orange area will be your final animation exported to the file)

Turn off “Include all Actions” so that it does not warp your animations by meshing all your work into one from other animations you might not want. This option is tricky, I just turn it off cause it made things look very bad

Model without Animation:

8. Would you have rather started with a game engine or would you still prefer to work from scratch?
   1. Shane: I liked working from scratch, it makes me feel very accomplished. The only thing is that I somehow feel like it would have taken less time to have just ported my CSE 123 code and written networking from scratch…
   2. Aneesh: I would prefer starting with a game engine but I did enjoy the process of building one from scratch for the learning value. This way, even if I am using a game engine that doesn’t have direct support for what I want, I could implement it myself through customizations.
   3. Sam: I preferred to work from scratch, because you get to learn so much more about a game’s intricacies when you have to make them all yourself, it actually is a very fun process of considering every aspect that we need to make in order for a game to work, and i’m much more appreciative of other games and more forgiving of the random bug and quirks that other AAA games might present sometimes. 
   4. James: Working from scratch is a good learning experience, but only do it once. There’s no reason to reimplement the same physics multiple times.
   5. Sheila: I RATHER WE HAD A GAME ENGINE. I have regrets about not being able to implement more game logic because we were limited by time, space allocation and just trying to figure out how to use and combine the tools we had. To be honest, physics and math is not my forte, and having physics logic like built-in gravity and rigid body collisions would’ve been nice for what we were trying to do. But, making things from scratch was very refreshing and worthwhile.
   6. Thomas: I really liked working from scratch, but it means you need to think really far in the future. If you make bad decisions early on, it ends up coming back to bite you later. We pulled some code from 169 to help with loading shaders. 
9. For those who used a networking library (e.g., RakNet or Boost), a physics library (e.g., Bullet), or a GUI library, would you use it 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, judging from the experiences of the groups that did, would you have used it in retrospect?
   1. Shane: Let me start off by saying you Boost, you lose. Now onto the real stuff, but first, a word from our sponsors: Raid, Shadow Legends ®. ….. If you want to use Boost, make sure to start off with the async example code because changing it later is a pain. If you want to use Boost, know that you would have to deal with a lot of online examples that don’t work, bad documentation, and extremely obscure errors. Here are some important tips you MUST remember if you are using Boost. If you are even on the fence about using it, PLEASE remember this section so there may be no more victims:
      1. When reading from streams, EOF DOES NOT MEAN END OF FILE. EOF here means that connection is reset by peer. This means that your connection died instead of what you may have guessed instead.
      2. IOContexts REALLY like dying. Like, they are literally Mr. Meeseeks, the moment they finish all the queued jobs they die. You must have the same IOContext throughout if you don’t want your connection to be reset. This means, you should put the IOContext creation in some top level function (main) that will never finish executing.
      3. If you are doing async, you should call the function again after it executes because if an IOContext runs out of work it dies.
      4. If you are doing async, you will need threading. Luckily, this is one of the only easy things to do in Boost.
   2. Aneesh: Our group used Boost for networking and Dear ImGui for GUI. With Boost, our experience initially was pretty bad because we were running into random issues when trying to send a simple message across the wire. The error we received was EOF but the actual reason was a disconnection (i.e. socket close). It was more related to the way Boost works, with a context that needs to be active and have things to do for the entire duration of the use of Boost. However, once we figured that out, things got a bit easier in other future feature implementations. Another lesson was to always consider asynchronous execution when working with networking code. With Dear ImGui too, my initial experience was that it was pretty hard to understand how things work. But I later realised (after scouring through the github repo to figure out how to change the color of a health bar) that the library uses a state based system for rendering gui elements. That made things a bit easier to look for in the future but it was still a challenging process. I think with both the library modules I used in the project, the problem was poor documentation of the library that made it difficult to simply integrate it.
      1. Boost tip – you can provide the IOContext with idle work so it never dies.
      2. Dear ImGui tip – To change colors of a UI, use the PushStyleCol() function and change the value of the desired global color variable (ImGuiCol_xxx). Don’t Don’t forget to PopStyleCol() to go back to the previously used value for that color variable.
   3. Sam: we wrote the physics engine, and i would use it again, It’s amazing, and it also has unintentional bhopping 
10. For your group web pages, we used wordpress. Were you satisfied with wordpress, or would you rather have used some other system for maintaining your group web pages? If you had a choice, what other system would you prefer to use (or even just doing everything on your own using HTML, CSS, and JavaScript)?
    1. I have no complaints about WordPress, it’s a little restricting I guess.
    2. Sometimes, dragging pictures onto the website is a pain and formatting can be a bit finicky sometimes, but I think having wordpress is still much easier than actually coding everything on our own. (this message was proudly brought to you by the sponsor of our project, squarespace). 
11. Edward introduced using a discord server for the class. Would you recommend that we continue using discord in the future (e.g., even if the next class is in person)?
    1. Yes, Discord is great
    2. Yep Yep Yep
    3. It’s the better slack/piazza because it feels more casual and has voice calling features. Piazza might feel too formal at times and it’s hard to ask a question. 
    4. Discord is very flexible on having multiple people screen-sharing at the same time, so switching back and forth without needing permission is great.
    5. Pro tip for people with 4k monitors, use “Better text readability” option.
12. This quarter was particularly difficult having to do everything remotely. What tools and strategies did you use to collaborate, communicate, and work together?
    1. Playing video games together is a good bonding exercise and it helps to reveal those who totally suck at video games and designate them as those who deserve no voice when suggesting new game mechanics. (for legal reasons this is a joke)
    2. Having fun by adding stupid things (like dabbing) into the game definitely helps make it less boring.
    3. In-person meet up for Ramen to get to know your teammates better and then work better with them.
13. 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. Sam: Casually insult each other throughout the quarter to build camaraderie. Take it easy, it’s meant to be fun.
    2. Suffering can bring people together
    3. Optimal coding hours are 2am-6am.
    4. Team meetings need not, nay should not, be completely serious. It’s fun to have some friendly banter or a couple face-offs in Pokemon Go or a game of League of Legends….. during a coding party.
    1. Shane: This class is still a class after all, if you just treat it like a normal class without taking the time to bond and have fun it would be extremely boring.
14. Looking back over the past 10 weeks, how would you do things differently, and what would you do again in the same situation?
    1. Probably plan better. 
    2. Get Network out ASAP, then all the magic happens (bro I tried my best what more do you want)
15. Which courses at UCSD do you think best prepared you for CSE 125?

CSE 110, CSE 167, CSE 169, CSE 123, CSE 124, CSE 100, MCWP 50, WCWP 10, CAT 1

16. What were the most valuable things that you learned in the class?
    1. GAME DEV IS HARD!!! But FUUUUNNNN! And something I want to try doing professionally.
    2. Have a clear plan on what to do before executing on it otherwise the code can become a bit unmanageable, although it is hard to see where the code will go when initially just starting.
    3. You should probably start with async in mind. I think most groups will need it unless they want to limit the players’ actions per frame.
    4. You Boost, you lose.
17. Please post four final screenshots of your game on your group pages for posterity. I will display them on the group web page.
    1. Cat’s bootyhole

2. Dabbing

3. Forest

4. Lobby

5. Dog Flag and Cat Flag

1. What advice/tips/suggestions would you give students who will take the course next year?
   1. Lol, no advice, good luck kiddos.
   2. Great video tutorial series on game development: https://youtu.be/dQw4sWJ1asWQ
   3. You Boost, you lose.
2. How can the course be improved for next year?

I would like a small session on how to set-up and export methods for certain software and how to use them, like Boost, Blender, FMOD etc. 

3. Any other comments or feedback?
   1. Play our game!!!! (NOT) Available on all major gaming platforms!
   2. https://github.com/ucsd-cse125-sp21/cse125-sp21-group5
   3. This class gave us one of the most intense/fun/tiring/stressful/meaningful/exciting 10 weeks of our UCSD career, and we’re eternally grateful for it.