Final Report

Our game concept was pretty consistent once we had decided on it for the initial project spec, the only major gameplay change I would say is that we removed some collaborative aspects (tasks requiring multiple players to complete) in favor of more chaotic aspects.

One major change is that we remove the randomized winning seats mechanic, which makes it more of a last-man-survival game. I do think it's a reasonable decision that fits with our chaotic gameplay better.

I was super happy with all the art and creative elements, I basically felt like whatever we could think of Luna was amazingly able to create. The game flow did change though – it was a bit too complicated at the beginning and I had this whole storyline going, but we simplified it to make the game easier to understand. Instead of a random number of players surviving, we just have one which makes it so much easier for the player. Also it made it easier to implement because the flow of the game is pretty clear.

Our game was pretty consistent to what we first had planned, I think I remember we wanted it to have a chaos vibe, similar to Overcooked, and having the ability to mess with others. I wanted the game to have both co-op and pvp at first, where each island, people needed to work together to solve some sort of puzzle to get to that island, but we scratched that. In a way the bridge building was the only co-op mechanic. Musically chair logic was also scratched, as we thought that the last man standing would be more funner. (We even had plans with musical chairs where there were multiple endings, like pacifist run where everyone survived, one survives and so on but I think it was a bit too much, as sometimes less is more.

Our game stayed mostly consistent with our initial plan, that being a chaotic pvp and pve game in which players had to escape and collect items and build up resources. Some small ideas were scrapped as the game went on, mostly because we were running out of time, but it also made the game more consistent in our original vision of it. I think we may bring some of these ideas back as alot of us have agreed to try and work on it during the summer to eventually prep for a release of the game on Steam, but overall I like our game design and what we were able to produce by the end of the quarter, it matched our initial plans very well.

I think our game concept mainly stayed the same from the beginning, namely art and visual aspects, alien-space theme and boss fight against a boss that follows sound. Things we did adjust were details: How exactly does the player win? What is the story we want to show? What do we want to prioritize out of all of the cool ideas we have? - these were narrowed down in the later parts of the quarter after the fundamental aspects of the game were done.

I believe we stayed pretty consistent throughout the project and I'd like to attribute that to us having a notion page where we hashed out game ideas before the class even started. So we had the ball rolling immediately which eased our final decisions.

The art+graphic aspect of the final project design is very consistent with my initial design idea, the cartoon-ish low-poly toon shading render style with vivid colors, aliens, and a weird/dreamy looking island. I came in with very minimal 3D art experience, so I had to learn everything on stage (Blender modeling, texture, skeleton animation). At the end, I'm glad that nothing is out of my expectations and I think it even went beyond my imagination :D

I always had full confidence in Luna and her creativity so with the design I feel like we really fulfilled everything we wanted :).

Once I checked out Luna's personal art portfolio, I was so amazed. She is such an amazing artist and we couldn't have done it without her. I felt like we had such a great group of artists, as pretty much everyone could draw (except for me). I really loved Yuehua's boss design, she also drew a really cute cat character that I wanted to be in the game but it ended up not fitting. However, I am forever grateful for the addition of the power ranger alien that Luna added to the game for me though :D

The art style stayed the same pretty much. We decided early on on a cartoon alien style vibe and all of our game assets matched this. The sound effects were more random and were just us having fun with different effects, especially for the purposes of having fun, but other than that everything looks exactly how we planned initially.

The designs stayed similar to what we've originally had in mind. Luna did an amazing job designing the models! And also Yuehua who designed the boss - really cool design!

Aesthetically there was barely a change!! Thanks to our amazing artist keeping it consistent

During the weeks our progress is definitely delayed from our original plan on the To-do list; however, in the planning stage, we did predict that we would definitely be slower than the plan, so it's still within our expectations? One major thing was that art was not making much progress until week 9 when I finally put the main map design together in a no-rest hardcore weekend lol, since I was mainly working on the graphic code and you can't split me into two :( . At the end, we did make significant progress in the final week and actually put everything together, even had time for polishing. Kind of what I expected, but even better.

Some tasks definitely took longer than others (e.g. boss pathing, map building) because they were more challenging than expected, and some tasks were started on much later than expected (once again, boss pathing and map building, but also the audio) because of the unexpected amount of infrastructure required to even begin working on those parts.

This was expected, but it took a bit to ramp up when we first started the project – probably longer than we initially thought. Once we implemented the core parts of our game it was much easier and faster to iterate, but I will admit it was a bit stressful to get to that point. It also makes sense because for most of us, this was our first time making a game so there was a bit of a learning curve. I will say that while I expected to devote a lot of time to the project, the amount of time we spent working and hanging out together far exceeded my expectations! :)

I remember we were on track for the first 4-5 weeks, it was really slow for the first 6-7 weeks, but after building a strong foundation, we really took off and stopped updating our schedule (maybe it's only me), and just kept iterating as a group on ideas that we come up on the spot.

The final schedule was VERY different. We made an initial weekly layout of when and what we wanted to get done, but as expected, we didn't follow this for long. Whether it be things taking longer/shorter than we expected, or new ideas we had that we wanted to implement, or ideas being scrapped for the final project, etc., many things caused us to deviate from our initial plans. I think this worked out better for us though, the environment for CSE 125 isn't meant for one long term goal to stick to. There are so many different things that can happen to change your plans where it just doesn't make sense to have such large overarching plans. We ended up just going through lists of tasks every week at whatever pace we could, and this worked very well for our group.

I think the goals we set for ourselves stayed around the same but sometimes they would get delayed, especially in earlier weeks. When we just started I feel like it was harder to estimate how much something will actually take, and also a lot of important foundational things were done then so we took our time. After we got that done and we started working on developing actual gameplay the progress started moving really fast, everyone was very excited about the game and wanted to put in as many cool features as possible.

geez alot of factors really changed up the schedule for me, most were outside my control and some were the class itself. For a project that is ever evolving, you have to pick your battles on what part of the game you want to focus on. For example, I really wanted to add to the models but doing that ate up time that could've went to more urgent matters like coding.

We didn't support MacOS or Linux, which was initially problematic for me because I use Linux. This turned out to be not as much of a problem as I'd initially though because I just camped in the basement all day 👍 (and squeezed as much of my other classes as I could into my off-campus time), but if you have group members who need to be remote (or understandably don't like being stuck in the basement for 8 hours a day), this may not be as good of a solution.

In terms of tools we did use, our repo was hosted on GitHub (obviously) and we used Visual Studio with vcpkg/CMake for packages and building, which was very convenient later on but more problematic in the beginning.

I'm one of the lucky ones who's able to run the game on my gaming laptop, which made my development process so much easier because I can still do work at home.

We used Visual Studio to develop with vcpkg/Cmake, all of which were huge learning curves for me. Fighting with Cmake almost made me cry at the beginning. I have a Mac so I couldn't run the game on my laptop and with our networking library I didn't want to add a bunch of stuff to support Mac too, especially because I'm the only one. So I just camped in the basement which was fun anyways and probably made me more productive. For future groups, I would say communicate early on how you like to work, and encourage in-person collaboration. Being in the same environment physically and developmentally can be a huge strength! If people are comfortable with running the game or figuring out how to run it, that works fine too but for me it was more effort than it was worth.

It was all my fault for the non supportiveness for multiple platforms. I followed a tutorial for the networking part that used winsock, so it would only work on windows. (I think there was also linux support but I did not get to it :( sowwey Yuehua). However, I think it was good because we got to spend a lot of time together in the basement. Also, the tools I used were Visual Studio Code 2022, cMake, Github, and Discord for communications.

windows only, vs studio, winsock, vcpkg, cmake, glm, opengl, nlohmann/json, gemini, claude, copilot, antigravity, pain and suffering. Overall, it was very difficult to get all these different systems to work together or just in general, but there was always numerous tutorials online and AI was very well versed in these libraries/frameworks so it was always easy to fix up.

I was also lucky because I got to run our game and develop on my own laptop since it's Windows. We developed in Visual Studio and used vcpkg/cmake which was difficult to set up but was really convenient after that.

I suggest future teams have a set up doc ready or set up the demo computers as early as possible.

Worked well: Camping in the lab. As the weeks progress, I realized that in later stages our group doesn't need much micro-management since everyone is very active in communicating and working together, therefore a lot of logistical stuff was dropped (updating timeline, doing code post, writing pr details, etc). At the end, we still follow a very good code-review process pipeline (thanks to our pr master), which I'm glad of.

Working well: seconding camping in the lab; as well as getting to know a lot of the code that you aren't writing, it's great for building team spirit. And snacks. Not working so well: we had difficulty separating tasks at the beginning (outside of Luna camping the entire graphics aspect) so there were issues with overlap and people doing the same thing in different ways. We additionally had issues where task separation wasn't as good as we thought it would be (e.g. a task depending on someone else's task, but they were busy with other classes, etc); greater flexibility with who does what and taking over tasks might've helped earlier on.

Worked well: THIRDING camping in the lab. Bonding with your teammates and absorbing knowledge of the code base whether you want to or not is very valuable! And while Discord was great for communicating, being in person and just quickly asking a question will always be my preference. Hang out with your team!! Support your groupmates and their efforts and celebrate their successes!! Not working well: Also go outside with your group! Get some sun lol <3

Worked well: FOURDING camping in the lab. I felt at home in the lab and I made so many great memories there. Doing things together makes it more enjoyable. Like Sun Tsu once said, pick a job you like doing and you'll never spend a day working at a job. Communication was key to our teamwork, we bonded in humor and we all knew what each other were doing after the first few weeks.

Fifthdering camping in the lab? Us all being together not only helped so much with team bonding, but also our productivity. The CSE 125 project gets so expansive and it becomes impossible for any one person to know everything about the project. Having our team there made it super easy to ask people what was going on and learn what we needed to in order to make the project work together with all its complicated parts. This is always very difficult to do since other people get busy, I know I had a busy quarter and I wasn't in the basement with my team nearly as much as I wanted to be, but if people on the team can do this, the quick communication we gained from all being together was invaluable to our project. I think also splitting up discussion topics in different Discord channels was very helpful since we communicated ALOT and it would've been impossible and overwhelming to catch up on every message in that chat when it spanned multiple different technical conversations.

Worked well: Sixthing camping in the lab. Even though I was able to work at home with my Windows laptop, I preferred to work in the lab with my teammates because it was a lot of fun, and I think it helped our team bond. It personally motivated me a lot to get work done. Also I liked the process of making prs and code reviews - it also helped collaboration. Not working well: Sometimes in the beginning it wasn't super clear what should be worked on and how that will come together with other people's work which I think is expected. But clear communication about what each person is going to be working on this week helped with that.

worked well: seventhing camping in the lab.

As someone who doesn't really play video games, I was surprised by the difficulty of implementing the boss (two weeks straight of unsatisfying boss pathing and/or boss having a seizure). The audio was easier than expected despite everyone telling me it would be easy. Something I expected to be hard but was still harder than I thought was actually testing my changes (especially audio triggers on certain events) because I had severe skill issues.

I feel like the more embedded something was or the more mechanics it involved, the harder it was. The stereotype of merging being difficult is pretty true but on a higher level than just resolving merge conflicts. Things like merging and resolving conflicts with code you don't understand is pretty hard :). And especially communicating and not writing conflicting code is harder than I thought, made easier when everyone is IP together.

I felt gameplay was pretty easy to implement after figuring out and understanding how the physics system works. For me the hardest part was anything related to ui, or graphics animation side, as I remember Anya asking me to do a pr review for one of her UI implementations and I had no idea what I was looking at =D

The Skeleton animation and Particle system implementation. I thought I could reuse my code from CSE 169, but it turns out that since we are using GLB export, it's actually a completely different pipeline. Therefore, the 3-day amount of work I expected turns out to be 3 weeks. The easiest implementation was the visual effect from the atomic bomb/blinding black screen effect; the implementation took like 5 minutes, and it worked so well.

PHYSICS WAS HELL which was something I knew coming into this class, but WOW did it really show. I didn't even work on many of the physics mechanics but for the ones I did work on, which largely involved setting up the foundations for our custom-built physics, was very difficult to do. Planning out how to make colliders happen, how to define where a player is in space, how to apply forces like friction and gravity, how to interact with objects in the game, how to walk, how to make triggers, all of these were very difficult when making it from scratch, especially figuring out how to best implement it for the game when you dont have all the details yet and plans end up changing. This will definitely make you the most hated on the team, especially if you have a teammate like Luna 🙃. Definitely one of the hardest, but most rewarding parts of the project overall.

I feel like a lot of things I did were related to other people's code and adding onto it, so the hardest part for me was understanding different parts of the codebase. Merge conflicts and making your code compatible with existing code (and new code being merged at the same time as yours) was sometimes tedious too. But implementing actual features/details was a often easier than I expected.

Merging honestly.

I would finish a part of the project and never do a pr which costs me hours on fixing it up instead of immediately pushing it. Audio and UI were pretty simple to implement but took time to get in the sounds and designs

Every part :) If I have to pick, I'm very proud of the shading/visual style I'm able to convey using my own graphic render pipeline! Also, we actually have fewer bugs in our game than I expected.

From a finished product point of view, the audio was a lot of fun and added a lot to the game in proportion to the amount of code I had to write. From a developer perspective, I'm pretty proud of how the system turned out as a whole?

Maybe the sun transition!! Not that I designed the sun. Also the serialization/deserialization while pretty simple was a big learning opportunity for me.

For me, it was implementing the picking up and throwing logic, although it was pretty simple (teleporting the held object to the same position as the player object), it made me really happy, it unlocked something in my brain and it was the foundation that built pretty much most of the gameplay logic that we had in the game.

I think seeing all our messy code come together at the end of the project was the most rewarding. While all you see when playing our game is the fancy art and the fun things you can do in the game, behind the scenes was WEEKS of agonizing bug fixes, code malfunctions, difficulties in communication and defining what we wanted fo the game, plans changing causing code to have to be completely revamped, and more. All of this work and the payoff at the end when we finally had a working product, especially all the bug fixes happening within 2 days before the final project demo, and just seeing the project come together is what really made me happy. In other words, the journey was so so so rewarding after reaching the finish line.

I'm proud of all the parts. We had a lot of fun developing the game, and people's creativity and hard work is captured in every part of the game. I look at every detail with love because when I see them I also see my friends working in the lab, and laughing together, and their effort, and creative vision, and immense talent they all brought.

Everything!!!! And this website :)

I finally had time to dedicate myself to it, so I had bunch of fun making this site and having it emulate our game and it's silliness for people to see.

The random lagging on my laptop bug? Turns out to be a 1-line network code error that Claude's code spent 20 minutes to figure out for me. Also, someone's janky physics system just never works, so I always have to fix it for them. (jk we enjoy mutual bullying <3)

The random lagging was never an actual problem for me because I had too many skill issues to attempt playing the game. Jokes aside, the code I worked on was never particularly difficult and we didn't really run into any game-breaking bugs–the greatest difficulty was for our flashbang effect, I wanted to pause the background music but I couldn't figure out how. It turned out that checking if FMOD isn't playing a sound isn't sufficient to determine that it's finished playing, the FMOD_STUDIO_PLAYBACK_STOPPED status exists for this very purpose.

Lowkey the cmake at the beginning was such a pain and I overcame it with a lot of trial and error. Also this IT thing that happened where my AD account got locked and then the hosts I was on had to be reset was the most difficult software problem.

3 billion CMAKE errors, forever grateful for Katy who was there, never gave up and we (she) got through it. Sorry to my teamates about the network lag, I stopped touching it after the second week and never looked back :c

The JSON ended up being a hude scare for me, as any merge conflicts with that would end up wiping out someones changes entirely, but this rarely happened since we were all diligent in what we were doing. Also the expectation that physics would work when models were set up to have inconsistent center points, so defining collision boundaries was very difficult to maintain and I would always have to fix it for them. (jk we enjoy mutual bullying <3)

Building, running and testing the game in the beginning, when I was unsure how to do that or when we were facing lagging when developing on local computers, were challenging.

The fmod library never uploading correctly to github. Everytime we built the audio branch in a new computer issues came up till all the libraries finally stayed their place.

For assimp (model loading) Luna can probably give more in-depth tips, but learnopengl.com/Model-Loading/Assimp and the official Assimp documentation were the sources I used.

For audio, we used FMOD, which was pretty intuitive with many tutorials available online. The only thing that took a little bit was setting global parameters (which you set from the audio system object) vs. setting local parameters (which you set from the event instance object).

We actually used mostly tinygltf to replace Assimp later stages of the model/animation loading. Assimp is still used for glb model loading and parsing the file, but it might reorder vertices that would mess up with the joint weight of the skeletons. Tinygltf is used on top of assimp to read the GLB Skeletons. It also reads the VRM model extension, which allows us to add the mToon shader effect from the models.

I think using VRM material is one thing I did that kind of stood out from other groups: There is a blender extension for it, and I found their shader code online and applied into my game for the visual effect. Normally, it's commonly used in anime-style models such as Genshin Impact or Vtuber models. An overview of the tool chain process of model uploading for our project is: Blender modeling using VRM material -> Export into .GLB file and load into our asset folder -> Load in model(material, MeshData) into main render loop using the tinygltf -> Mtoon shader applied + shadow map -> Draw() onto the scene. If the model contains Skeleton Animation, it will be go through the animator pipeline by loading the Skeleton + Skin + GLTFClips instead and getting drawn onto the scene.

To be honest for these tools I'm not super familiar with how they worked, especially any of the graphics one. Otherwise, things like Visual Studio and the merge editor were GREAT though there was a learning curve. Explore the different 'Views' – the folder view, the git view, etc. Most of what I did was code and/or merging based so my workflow was code writing and/or Claude (honestly was really helpful, worth a subscription but use with care!!). Git/Github PRs and then merge conflict editor. AVOID blindly using AI hehe

Using a JSON to save a layout that could be parsed to load our initial game state and load all the game objects, models, animations, etc. was very helpful in preventing like a bajillion hard coded values. However, we never really had a good system to save to it without having merge conflicts between branches. While it ended up working for us pretty well, I can see how a group could get tied up with that system very easily. If a group in the future wants to do this, but make a better system to save to it and handle merge conflicts better, or just be very very careful when modifying it, then I would highly recommend this system.

We used FMOD for audio, and I would say that for our purposes (many one-off spatial sound effects and different game phase bgm loops), it served pretty well. The documentation is a bit of a pain to use, but the simplicity of the API mitigates most of the pain.

The most useful library we used is: ImGui (Immediate Mode GUI), a debug/editor overlay that renders using our existing graphics API. We used it to build our editor window, debug window, and even Ui and some graphic effects. It is especially useful as I made it into an Editor window that works together with our JSON maker tool—Users are able to directly edit the map using the ImGui panels, read and write into our JSON files. I think the method calls and documentation are very intuitive, which makes it very easy to pick up and use during the development process.

For networking, I followed a tutorial that used the WinSock networking library. It was pretty easy and straightforward to use and I would use it again if I were to start over. However, if future groups have a lot of members that use Linux or Macs, then I do not recommend it.

First, use fmod if your game is audio heavy trust me.

Second lemme give you the audio pipeline that i struggled with a bit:



Third, you don't need to do anything within the fmod application itself, you can could out everything, and i mean everything.

I used copilot code completions during the latter half of the quarter after I switched lab machines and forgot to turn it off. I would say that it wasn't as helpful earlier on in the project (hence why I turned it off) when we were designing our system, but once we had well established patterns, it was pretty good at filling in repetitive code. I didn't consult LLMs directly, although that's more of a habit of tunnel vision and preferring to read documentation/sketchy stack overflow posts.

I used Claude to explain code that I did not understand, (Like how rotations, camera angles work, etc) but I felt like that was a lot of time as I ended up still confused and went to watch youtube tutorials instead. I also used it a lot to do bug fixes that I literally have no idea why (most of the time its bugs that happens because of my lazy coding practice of just copy pasting code, as most of my gameplay implementations were really similar to each other), so when bugs happen and I can't figure it out, I first ask Yuehua to see if she could find out why, and most of the time she could, (I had a lot of bugs with booleans because I used an int as booleans and I would always initialize them to -1 in the gameObject classes @_@), and in the rare chance that me and her can't figure it out, I would ask Claude, and most of the time it is very trivial 1 to 2 lines bug fixes. Where I used it the most was in the part where I was editing the JSON file for our map, as we load our map from a json file, and we have like 12,000 lines of code in there, and Claude saved me a lot of time when I was wiring up the resource collections spawners, and adding in new resource objects to test in the JSON file. My advice for students in the future about using LLM is that it is very helpful for bug fixes, and tedious tasks. But you should always write and understand your own code, and make sure you understand how everything works, and it is better to ask your teammate the code that they wrote since they are the expert at them and will be much more helpful than LLM.

I would have just done a Claude subscription earlier than I did; with less developed models or the slow copilot on VS it's just not helpful. AI was really helpful in opening up the world of what I could implement/learn. It can help understand other people's code or point you to where a bug might be. Just make sure never to lose control of the code – versioning is very important especially if you're using Claude to actually write. And always make sure you are following along and understanding. Genuinely if a bug comes up and you can't figure out where, an LLM is very helpful to give you possibilities or help you add relevant print statements. But it should not replace verbal communication between people or (somewhat) descriptive commits/prs or your understanding of the code.

I mainly used Claude code to help me understand the current codebase + implement graphic functionalities/shader code. I found it really useful on the graphic side because most of the graphic code doesn't interfere much with the main gameplay functionalities, such as translating existing shader code found on the web, creating some kind of visual effect that, if it worked, it worked. I agree with Thanh that I use it a lot to add new entries to the json file since that's just a lot of pointless manual labor, but in terms of editing the json property, I found it easier to manually edit the json file rather than writing a paragraph prompt and waiting for claude to think for 500 seconds. However, the main graphic pipeline, such as the model/skeleton/particle systems, still requires a lot of manual look-up and implementation, or at least I need to plan out a solid structural foundation rather than letting it be fully handled by LLM (Thanks to Yuehua for helping me together to establish a solid graphic system). My opinion on AI usage is that you can feel it and tell whether you are confident in your understanding of the codebase. It's a great tool for increasing productivity in redundant implementations, but never let it take over your original creativity and the joy of programming.

I was too cheap to pay for Claude, and Copilot got too limited in its tokens to be useful during the project. I installed and used Antigravity 2.0 and connected it to the project repo. I used it for explaining code, creating bug fixes, and writing code for me. I used it more in the later part of the project when most of our effort was just coding up new features nonstop. Earlier in the project, I used it to generate ideas for how to set up physics systems, what should be included, and whether those setups would work for the ideas we had. I think this was particularly helpful in my initial research since I had no idea what I was doing when setting all of that up. With coding, I think it was a little lackluster. It would frequently get things wrong, make code that ruined other features, or code that didn't compile correctly. If I had set up the model better, like giving it access to more context for the project, it may have done a little better. I imagine this will be less of a problem as AI continues to develop, but I found myself debugging the AI more than I was making progress with code. It also had difficulties interacting with certain libraries compared to others. For example, when trying to create colliders based off an objects mesh, despite doing the collider creation correctly, it would never work perfectly and there would always be some colliders that were misaligned. Turns out the error was that the island model was rotated 90 degrees from what Antigravity expected the orientation of the colliders to be, and this took a while to debug. Little things like this made the project harder to do, but AI was still an invaluable addition to the team and we couldn;t have gotten as much done as we did without it.

I used GitHub copilot (free student account). I used it mainly to understand existing code and approach problems/errors I was unsure how to solve myself. I think using copilot helped me develop faster. However, my advice would be to not lose control over it and always be the driver. For example, that would include not being comfortable with pushing code that you don’t fully understand or that does what it’s supposed to but in a weird way (also doing pull requests and code reviews is helpful to ensure code quality). You yourself should make sure that code that goes into your project repo is correct and clear.

I relied on claude heavy especially at the start when there was alot of stuff that I didn't understand or know how to do. It helped me out understanding some networking stuff too.

We used standard C++ and OpenGL for graphics.

15341 lines from 112 files. I used PowerShell command: (Get-ChildItem "src","include" -Recurse -File | Where-Object { $_.Extension -ne ".json" -and $_.Name -ne "stb_image.h" } | Get-Content | Measure-Object -Line).Lines Which gives all the .h/.cpp files we have in the src and include directory, excluding the .json files we have for map, and stb_image.h, the 8k line for glb image import.

4,464 lines including some small edits to libraries we made across 45 total files. I got this by looking through git history.

Spending a lot of time with people kind of naturally brings you together. I was worried about not being able to get along since everyone in the group knew each other beforehand (except me), but it was surprisingly easy for me to meld in.

I still think it takes both luck and effort: I'm lucky to be in a team that we actually share a common interest and really come along, share similar working habits, etc. At the same time, putting effort into communication and spending time working collaboratively is also really important to build up our group bond.

Make sure you make everyone feel comfortable. If you see/feel that someone is being left out, you should reach out and try to make them feel included, as team work and team bonding is very important. Again, communication is key. Be serious when things matter, but also remember to have fun. Make jokes, but light hearted ones, not at someone else's expense.

Communication is key. We came out of this project as very good friends, partially because we are all just awesome people and we all have personalities that match, but also because there weren't any major hiccups in our project that made any of us hate each other forever. I had personal issues that cam eup during the quarter which led me to be unable to work on the project for a long period of time. During this time, I didn't properly communicate to the rest of the team that I wouldn't be working as hard as I otherwise would've, and it led to some frustration with me in the group. I felt very bad about this and I was worried I ruined team dynamics. While I always knew communication to be important, it became even more apparent here just how important it was not just for the sake of the project, but for making friends throughout the quarter.

Clear delineation of tasks would have helped a lot I think, and to achieve that we would have needed to plan out the architecture of our server/client at the beginning, so I would probably do that.

Spend more time IP basement camping earlier and also a clearer architecture up front/studying together about what our game should look like.

Everything was perfect, I would do everything again. I think if anything, I wished I could've helped out more with the Graphics side.

A better way to organize tasks would've helped alot. I frequently forgot what things I was supposed to be working on since we didn't have a consistent task tracker for alot of the quarter. I think something like github projects would have been good, as we could then have everything we wanna work on listed, with priorities. Also, we can see whos been working on what taks, for how long, and even communicate how muhc longer we think it would take. Other than that though, our group was a very well-oiled machine in terms of what we got done, how we got it done, and the fun we had along the way.

I think everything was great! If I were to do it again, I would definitely try to get into it faster in the beginning, and help out on more different things to learn more.

I would've managed my time wayyyy better and did more PRs as I had this false sense of needing to complete everything before presenting it. I wouldn't change anything with our team dynamics tho <3

CSE 169 is a must for a graphic person; that class basically gives you everything you need for basic graphic effects (starter code, bone/skeleton, animations, state machines, cloth, particle system, and even physics for collision boxes and rigid bodies). If you are using C++ and OpenGL for this project. Additionally, CSE 167 also gives an intro to computer graphics(even some 3D modeling) but I didn't lock in much in that class, so I regret a lot.

Any course that has you thinking about a large system and how the parts work together (e.g. CSE 120, 124). I believe that the technical aspects can be learned on the fly, but developing thinking patterns that put your work in the context of the entire system is pretty important. CSE 167 is also important if you plan on touching anything graphics related (OpenGL, making shapes, model/camera/view/whatever matrices, etc), which I fortunately did not have to do past week 2 :D

CSE 120 and CSE 110 were very helpful. 110 for the large group situation and versioning practice. 120 for the systems and thinking patterns. Also CSE100 for the C++. For graphics you're going to need those classes above <3

CSE 110, I had a horrible experience with working in a large group in my 110 class. However I did learn a valuable lesson that, no matter what, you should always try your best to work together, even if you don't agree with each other on ideas. Like Professor Voelker said in the beginning of class, it is better to have a cohesive game where everything makes sense, rather than having a bunch of random stuff/ideas trying to please everyone. And of course CSE 120, as that was one of the funnest class where I had to navigate around a large code base to understand how everything works, and I also had a small team where I learned to be a better teammate. CSE 120 Office hours was where I found my amazing teammates for CSE 125.

CSE 110 I would say only because it would be a horrible experience to have CSE 125 be your first large scale group project experience. Your first group project will always be a horrible experience, so I would recommend leaving that with CSE 110 and not experiencing it in CSE 125. But otherwise, CSE 100, CSE 120, CSE 167, CSE 169.

CSE 120, 167, 110 and 190 (Working with Large Code Bases)

ECE 140 a and b (my equivalent for 110), CSE 167 as I did some graphics with the ui, and most importantly cse 120

Aside from obvious pain and gain from the technical aspect, I learned more about communicating, trust, and supporting each other within such a great team. As someone always in the mindset of "worst case I will just do everything", this class makes me realize it's impossible to do everything—we need to work together as a team. Every moment we spent together this quarter is the most valuable experience I gained in this class.

I learned that there is a lot that can be squeezed out of two days. I also learned that it's very easy for 10 weeks to go by like they were nothing! Not sure I like how time passes.

Things that you think are impossible may or may not be. The capacity you have to learn is large especially if you work together and ask for help. Technically, I gained understanding in the server/client architecture, some networking (from looking at Than's code only), C++ stuff. This was the project I have learn the most from and it's hard to capture the details but the structure of the game also, github, prs, merge editors!!!

I was deathly afraid of merge conflicts before CSE 125. I remember the first 5-6 weeks, I always asked Yuehua to help me with my merge conflicts before I even pulled. Over time, as I watched her resolve many conflicts, I started to do them on my own, and they are not as intimidating as I thought, I think understanding the code base as a whole really helped with that. I also learned how to make a multiplayer game! Videos games were mostly a black hole to me but after this class, they seems very possible to do, its not magic, its the power of passion and friendship (maybe). Speaking of friendships, I learned how to make real friends, it's about trust, communication, being genuine, and to not be afraid of being yourself (farts builds strong bonds.)

I think this course gave me more experience in collaborating in large shared codebases, which is always a great skill to learn. Also, setting larger goals, even if you fall short, is always encouraged in this course, which I think gave me a lot more confidence in my abilities. I alone was able to achieve more in this course than I thought I would be able to, let alone the entire project and how amazing it looks. I never thought any of us would get as much done as we did, but we did it and I am still amazed by it.

I learned a lot on the technical side. I was unsure how such big systems like games are made which I was concerned about in the beginning. But seeing how different aspects of the game are built and combined into one codebase and how they interact with each other was interesting and also will be helpful for future work on big projects. I also learned how fun teamwork on a class project could actually be, the importance of structure, communication and trust in a team, and how fast your final quarter flies by.

Communication and taking a chance on doing stuff even if you have zero clue on what's happening, cause everything will work out in the end.

I really like the pizza celebration idea even though I couldn't stay :)

It was great I loved it.

It was great, although I was pretty exhausted (and I could see that some of the other group members were too) from the cramming and staying up, I don't think there's a better time to do it rather than right after.

I was tired but everyone just leaving after the demo would be sad :( I feel like we need time to decompress and process that it's over.

I think the celebration was awesome! I was very hungry afterwards and really wanted food so it was great for me. I think it would have been better if mroe people showed up to the basement to playtest games. The space is very small, but I think giving everyone the chance to play the amazing games they see in the demo is good to have.

I really enjoyed the party after. It was a nice celebration!

Mayhaps a bigger space? I think the pizza and timing was perfect though sadly I couldn't stay long.

Communication and proactivity are key. It's important to communicate what you'll do before you do it (so there isn't overlap between tasks. Sorry Richard...), and it's important to communicate asap so you don't leave people waiting on tasks you're not working on. On the proactivity side, there's a balance between giving people time to do their thing and needing to get things done by the end of 10 weeks—it's much better to err on the latter side than the former.

Be ready to be dedicated to this course.

Remember to have fun, your teammates are in their last quarter and will be graduating, don't take the time you have with them for granted.

Spend time with your team. Communicate asap if you need help, or if there's a change in schedule. I can't emphasize enough how important the physical time in the basement on the computers was for most of us.

Keep up good communication with your group, not just texting them in the group chat, but good task tracking, visions for goals, etc. Other than that, just have fun! And be prepared for a very difficult and time consuming, but rewarding course. Definitely don't take more than 3 classes including CSE 125.

Communicate with your group a lot, and spend time together - people, team communication and bonding is what makes the class so memorable, meaningful and fun!

have a day dedicated to working and try not having an incomplete loom over u either. Have fun!!! This will be the last quarter for the majority of you guys so create memories and friendships that'll last a lifetime

Hold it in the winter so seniors don't have to deal with the double whammy of leaving both 125 and their undergrad as a whole ): (jokes aside, emphasis on in-person group work or planning ahead might help, but then again, I'm not sure how well students would follow it anyway.)

In person emphasis (but that was always made clear, Yuehua's right that people might just not listen). Could do some fun team bonding stuff in the middle; ik it's based on budget but could do a dinner thing in the middle of the quarter in the basement as well :)

BIG BIG EMPHASIS on being physically together. More encouragement of group bounding time. Maybe a private reflection section each week where each member can send you private feedback about how they are feeling, but I guess there are office hours so maybe not. Also, it would be great if the course lasted 20 weeks ;D (125A Winter, 125B Spring?) That is probably too much to ask :p

Forcing more in person time together! Make class section required or other times if students agree on it. Working with your group in person and having more in person meetings helps so so much with speeding along goals, task assigning, and getting things done!

A later section? It would be amazing to have had this class be at 11 am when meeting the guest lecturers, if not a zoom link for the people who aren't able to attend.

I know I have everyone's discords etc etc but I'm still going to miss y'all after we go our merry ways :(

LOVE U GUYS

Everything about this class felt like a dream, I enjoy every part of this class :)

Oh take me back, to the night we met….

So sad its over but I loved the journey! Thank you CSE 125 2026 Group 1! Thank you for putting up with all my bs and tolerating me as a groupmate! You guys were amazing and theres no better group I could've gotten! And thank you Professor Voelker for cotuining to keep this course going, it was an amazing experience and a great way to end my Bachelor's! And thank you for being such a cool guy overall, idk anyone else at UCSD that'd help a stinky cs guy get a shower in the CSE building and it was very appreciated!

Thank you for the amazing quarter, I'm going to miss hanging out with you all!

I wouldn't have wanted to end a four year journey in any other way!!

A class that stands as a testament to all I learned. A professor who is a great mentor and advisor. A team that made it all happen in style.

I'll miss you guys, I can't wait to see all the great things you will accomplish :)

Thank you for everything!! And thank you to anyone who is reading till the end!