Question A-1
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?
Our game concept remained fairly close to the initial idea we had come up with. The original concept was a space game where space ships complete tasks like getting fuel for the mothership and gathering other materials in order to bring the ship back to a stable condition. This is still currently the overall structure of the final implementation; our version is just more evolved. We kept the idea of having different roles for the players and gathering fuel and other materials, but we added obstacles and emergencies. These include the space virus, the warren bear lasers, the thief alien, and fires. We decided to add these in order to add more complexity to the game and overall difficulty to win.
Jacky
Regarding game design, since I came up with the original game pitch, originally my idea had a lot bigger focus on hard sci-fi aesthetics and supply chain logistics with mostly realistic physics. However after working with a group, and since a lot of our team wasn't super familiar with space games, the game shifted to be a lot more accessible and casual. While I would have liked to see how the original idea played out, I think the game went in a good direction that is suitable for this project.
Question A-2
How does your final project design compare to the initial design, and what are the reasons for the differences, if any?
Art
On the art side, we were initially striving to create a hard, realistic sci-fi game. The concept art is much more detailed compared to the actual in-game models. We decided to dial back on the realistic and go slightly cartoon-ish due to time constraints. That is why most of the models are low-poly while we also have a very fake 3D planet in the background of the game. The overall space theme helps though because anything goes in space. Other cheats we used for the game aesthetic were to use a 2D image of a planet instead of modeling one (idea from one of the guest lecturers), and any animations are created via computer graphics and are not Blender native.
System Architecture
On the system side, the general structure stayed the same from week 1 to 10. We had a separated client-server architecture, where the client primarily handled rendering and sending input events, and the server received input events, updated game state, and sent the state to the client. The client still follows the same loop of receiving inputs in a buffer, sending them to the server, receiving server data, and rendering it. And the server still follows a general flow of opening threads for connections and adding inputs to a buffer, updating game state, and then sending out the game state at a specified tick rate. Since our game itself was relatively simple due to being in space and not requiring terrain, there wasn't a need to add optimizations that would change the structure; the optimizations we did have ended up being small changes and if-cases that didn't change the structure instead.
Game Design
On the game design side, we ended up choosing to make the space movement and boosting unrealistic to actual space. At the start, it was very difficult for us as players to navigate around the world when energy / velocity is preserved. Therefore, adding friction helped make movement much more fun and intuitive. Other than this, the design followed what was initially decided generally.
Question A-3
How does your final schedule compare with your projected schedule, and what are the reasons for the differences, if any?
Our final schedule was fairly close to our original projected schedule (besides the graphics part). However, we think we completed the work planned for the first six weeks a little faster than expected, which allowed us to spend more time on the final four weeks of work. During the last week and a half, we also revised and improved a lot of earlier work, such as graphics and some game design elements. We had not originally accounted for this extra iteration because we did not expect to have enough time for it.
Question B-1
What tools did you use? What was your build workflow? How did you support multiple platforms? Any tips for future groups?
IDE & Build
Most people used Visual Studio Code (VSCode) or Visual Studio. To build, the developers on VSCode ran variations of cmake ..; cmake --build from the command line, and the developers on Visual Studio used the built-in cmake support. We did find that building with Visual Studio's built-in cmake support was generally faster than building from the command line, but we also had some issues with code building in Visual Studio but not from the command line.
Cross-platform Support
In the beginning, we made sure that the game could run on multiple platforms like MacOS, Windows, and Linux — mostly out of necessity as everyone in the group used a different OS. This was done by using CMake and #ifdef rules, which specified platform-specific dependencies in header files to be able to compile the program. However, as we picked up speed, we didn't have enough time to manually verify every pull request worked on all three platforms, and ended up dropping Linux support. This could have been solved with a CI/CD pipeline, but it didn't seem worth the time investment we would need to put into it. We also had major performance issues on Linux compared to Windows and MacOS, which contributed to the Linux drop. This was before we switched the client from sleep waiting to spin waiting between each frame, so maybe Linux's sleep wait implementation is very different from Windows and MacOS's.
Art Pipeline
Our artist used Blender for modeling and texture touch-ups and Apple Procreate to create the textures. This art pipeline probably only works if your game engine only renders .obj (more details in Question #6). These file types are quite simple to handle, and one issue we ran into often was that our artist wanted to make some quick edits when the .obj file did not render correctly in-game, but .obj files cannot be reopened inside Blender because they are so simple. As a result, our artist always needed to remember to keep the original Blender file and not delete it. This is all to say working with only .obj might be a pain, but it is doable.
UI Art
For the UI, free online vector and .psd editors, Vectorpea and Photopea, were used, and Apple Procreate was also used for the drafting. We believe that this pipeline is really great, and we strongly suggest making 2D arts in Vector so scaling becomes easier.
Advice for Future Groups
Our advice would be to just use what each person is comfortable with. The effort to make things compatible with different operating systems is worth it, especially since LLMs can almost always figure out how to make your build cross-platform compatible.
Question B-2
What group mechanics decisions worked out well, and which ones (if any) did not? Why?
Choosing to use Discord for communication helped keep everyone on the same page, where custom server channels allowed for easy classification of information.
More specifically, the to-do channel on our Discord server worked wonderfully well. In that channel, we simply put a task on a chat message, and those who want to work on it can simply react thumbs up to it, and finished tasks are reacted with the checkmark reaction. This works really well because it prevents members doubling up on each other's work, our progress can be very easily seen, and the available tasks are very clear.
Aside from online communication, our decision to meet in the basement during lecture time to work together worked out well. It allowed us to have time to work together, discuss ideas, test our game, and overall kept us all on the same page.
One thing that also worked out pretty well was getting everyone's progress merged in time, so the merge conflicts were never too bad and we never had issues where people were working on very divergent branches. Usually we would each make progress in our branches throughout the week and by the end of the week the PRs will have been merged. We all had turns checking each other's branches as well so we were mostly informed about what everyone else was doing.
Question B-3
Which aspects of the implementation were more difficult than you expected, and which were easier? Why?
Sofia
I really thought modeling would be fast and easy to learn; it was only that way the last two weeks on the project because I got so much practice weeks prior. Also, I was a tad bit surprised that Blender would not run on my 2019 Mac and did not expect to rely on the basement computers so much.
Nora
Something that I found more difficult to implement was hosting from across different devices. Even when we thought we had it working, we ran into more issues. Something that took us a while to figure out was that there was already a server.exe running that was blocking our server from running. While this was a simple fix, it was time consuming and difficult to find.
Kane
Implementing the initial server-client model was easier than I expected. Since the professor emphasized it as one of the key milestones of the course, I intentionally made sure we implemented it as a group. Therefore, we were able to come up with an effective structure for the initial base game.
Bernico
Iterating from the base engine to the gameplay mechanics like entity health, emergencies, dead entity cleanups, lasers, and enemies, turned out to be a lot easier than I expected. Since we had almost no gameplay up until weeks 5-6, I was initially worried that we were lagging behind on work. However, I realized that because the core structure was already solid, adding onto it turned out to be fairly easy. Meanwhile, implementing collision detection was harder than I expected. We initially thought that it's either doable through a library and displaying the hitboxes wouldn't be too much of an issue, but it ended up requiring us to define separate hitbox sizes with corners that must be precisely defined and having another object be used to visualize them.
Zoe
One thing that was difficult at times was working on different OSes. There were times when something wouldn't build on my Mac, or a text library wouldn't work on Windows, etc. I hadn't expected to run into these issues at all, so that was something to work through. On the other hand, a lot of changes were easier to implement than I had expected. After the client-server loop was working and we could play on multiple devices, it seemed like many changes were relatively simple and adding new things to our game was easier.
Jacky
For me, achieving acceptable server-side performance for our use case of 4-player local multiplayer was a lot easier than expected. Throughout the entire project, we had a lot of ideas for optimization, namely in collision detection and networking, for if the game lags too much to be playable, but turns out almost none of it was necessary. The only real optimization done to the collision system was just to skip checking if two objects are very far away. Turns out C++ is really, really fast if you're running mostly barebones code like we are.
Alex
The entirety of graphics. Graphics isn't just loading in models and applying textures. Implementing more complicated lighting, bloom, volumetric clouds, etc. requires tons of research, reading other people's code, trial and error, and time.
Question B-4
Which aspects of the project are you particularly proud of? Why?
Sofia
I'm very proud that I spent this quarter really learning Blender and contributing to game art! I'm glad that I did not have to help with networking or computer graphics and could focus solely on Blender and creating a pipeline (thanks team!).
Nora
I am proud of the game design and the unique ideas the team came up with. I think we came up with fun obstacles and impressive graphics.
Bernico
I am proud of the way our team implemented and accounted for game balance. I think it's really great that we could make sure that the game is both challenging and fun to complete, with all ship classes having a role to play.
Zoe
I am proud of our game as a whole! I personally found it really fun to play, and I think it was a very well thought out concept and playable game.
Jacky
While it was pretty simple and a bit jank at times, I'm proud of our GameObject engine architecture that works with transforms, entities, and our update loop. We initially modeled it after how the Unity engine worked, and while it's definitely not as easy to use, I think once the architecture was solid it made actually implementing game mechanics quite smooth.
Alex
I am most proud of the thruster "animation" and ambient particles. I tried so many thruster particle implementations, and in the end we didn't even use particles, just six cones stacked on top of each other with their dimensions changing every tick. Also going from something like 3 render classes in week 8 to around the 20 we have now — I feel like I really figured out how to make the game look better in week 9, after meeting with an industry game artist.
Question B-5
What was the most difficult software problem you faced, and how did you overcome it (if you did)?
Nora
I am also particularly proud of the PR where I was able to decrease the lag we were experiencing significantly. By caching all of the models, we were able to load each model once rather than for every entity. It was extremely rewarding to see the game go from a 10 second lag at the beginning locally to loading within milliseconds.
Kane
For me, debugging difficulties in hosting a client and server on separate machines was my most difficult software problem. Since I never took CSE 123, I had to learn a few things about networks on the way. There were a few steps to overcoming this, such as first and foremost realizing that separate network routers cannot easily connect to each other so it's important to stick to the same network. Additionally, that Windows firewall blocks specific network files if you accidentally bring up a permissions prompt. And finally, fixing a configuration in our code made it so no error was thrown if the port was already taken and therefore stealing incoming client connections.
Alex
Just generally refactoring code to be more maintainable. I made the mistake of refactoring while people were working on it, and had to deal with a large amount of nontrivial merges. On the bright side, this really forced me to understand the codebase, since I essentially had to rewrite much of the incoming code to complete merges.
Question B-6
Detail your toolchain for modeling, exporting, and loading meshes, textures, and animations. Be specific about tools and versions, non-obvious steps, and features to avoid.
a. UI Pipeline
Apple Procreate → draft, Vectorpea → draw vectors, Photopea → export to .png, stb_image.h → display using OpenGL. (All using latest May-June 2026 versions.)
For modeling using Vectorpea, be sure to be okay with having multiple shapes (layers) in order to draw one sprite. It's a lot more expressive and easier to do than if you're limited to just one. Furthermore, to draw curves in a continuous sprite (curves after another), hold and drag from the vertex that you want to draw on, and be sure to alt-click the vertex afterward to make sure the next curve you draw doesn't affect the previous one.
For exporting, don't bother to export in Vectorpea because you'll have those separate sprites be separate PNGs. Rather, save the .ai file and open it in Photopea. Then, group the sprites you want to export as one asset, put -e- in front of the group name, and afterward you can export your asset as good quality PNGs by exporting layers.
We believe that these tools are great and we definitely would use them again, especially considering that they're free with the exception of Procreate, which was only used for drafting anyway (feel free to use any of your preferred 2D drawing programs instead).
For rendering text, we used GlyphGL, and for debug menus, we used Imgui. Both were very simple to work with.
b. Rendering Objects
For rendering objects, we made an abstract Mesh class with a draw() function, which allowed us to have both pure OpenGL meshes as well as custom models under the same class. Models were imported using tinyobjloader, and it handled everything well. We did have an issue with imported models missing triangles in-game, which was fixed by checking the "Triangulate Faces" option in the Blender export menu.
c. Rendering Everything Else
For rendering everything else, we made classes for each layer of things to render with a draw() method, and called each one of these in succession in our main rendering loop, which was called every frame. This included UI, particles, the skybox, debug menus, fog, etc. Maybe we could've bundled these together under another class for the sake of OOP, but it still works.
d. Dependencies
For all of our dependencies, we chose to commit copies of them to our own repository. This way, if Microsoft implodes and GitHub disappears, our code will still run because it doesn't rely on CMake's FetchContent, and we won't have to deal with any breaking version issues twenty years down the line.
e. Main Game Art Pipeline
Uses latest version of Blender 5.x and Procreate as of June 2026.
.obj and open in Procreate → Upload .png from Procreate and touch up color in Blender → Export .obj and make sure the .mtl has the correct filepaths.
There is probably a better way of doing textures like baking and procedurally generating, but our artist did not want to learn how to do these things because direct texture painting seemed easier. However, the only caveat with that is you must remember to save your painted UV texture; otherwise, when you export, your native Blender paint strokes will not be exported. It's confusing because you can see the correct version in Blender. Remember to save image in Blender.
To join or not join, that is the question. Our artist advises heavy caution when joining different model parts because if your model is more complicated, it can create shapes with missing triangles and/or weird UV maps. Our artist did not want to fix even more missing triangles. Granted, having individual model parts and needing to resize their UVs into different corners of one image was a pain, but nothing is more painful than fixing Z-fighting.
Resource Links (make sure the video is close to the Blender/other software version you are using):
- Learn Blender hotkeys from the famous donut tutorial
- https://www.youtube.com/watch?v=b48faAwOQcQ - Blender to Procreate
- Blender StackExchange - Why did the texture I painted disappear?
Question B-7
Which networking, physics, audio, or GUI libraries did you use? Would you use them again? Describe lessons learned.
Nora
I used FMOD as an audio library. I would use it again if I were starting over knowing what I know now. I originally began with the mini audio library, which did not have 3D sound. Therefore, I had to calculate distance in order to implement this. Using FMOD allowed me to just use the library's 3D functions. I did not run into any lessons/issues with FMOD to recount for other groups in the future; in fact, I would recommend they use FMOD from the start.
Jacky
We explicitly chose not to use a physics library for our game, because (1) a lot of the physics library functionality wouldn't really apply to our zero-gravity gameplay, and (2) the physics we needed was all relatively simple to implement. The most complex bit of physics we needed was just collisions, and we just used a fairly simple bounding box method. This was definitely the right decision because we didn't have to go through the trouble of learning how to use a physics engine, and we also had finer control over how we want the physics to feel. In the end, although the collisions are a bit jank and inaccurate at times due to not lining up with the model, it was mostly fine because collisions are pretty rare in our gameplay, so I'm glad we didn't waste too much development time making it perfect.
Alex
We used imgui to render debug information (like coordinates, fps), other in-game information (like health, fuel) before we implemented a real UI, and a menu to show keybinds, implemented in five minutes an hour before the demo. Imgui was extremely easy to use, and I believe literally every other group used it as well for debug information.
Question B-8
If you used an LLM as part of your development process, what did you use it for? How well did it work? Do you have advice for students about using (or not using) an LLM for CSE 125?
Nora
I often used LLMs to implement things that I have not worked with in the past. Things like graphics especially required me to use an LLM since I have never implemented something graphics-related in the past. This worked extremely well. It gave me a base to work with and I was able to read through it and understand the different moving parts of the code. I think using LLMs for CSE 125 is helpful and allows students who have not taken certain courses to be able to contribute. Looking back, I would do the same. I was able to learn about things like graphics and have a basic understanding now. Otherwise, I would have avoided those tasks altogether.
Bernico
I used LLMs mostly like StackOverflow — that is, only use it to generate code that I 100% didn't know. One example I used it for is calculating whether two objects are colliding since I didn't have any base knowledge to work on, and it worked well. I recommend avoiding using LLMs for most tasks, especially for tasks where you have some ideas on how to approach it, but don't know the full details. Trying it out and finding out the problems are part of the experience that taught me a lot about systems development, and I definitely do not regret not using LLMs for these kinds of tasks.
Zoe
I frequently used LLMs such as GitHub Copilot to help me understand various aspects of this project. Since I had never worked on a project of this size or complexity before, these tools were particularly valuable when I was implementing unfamiliar features or trying to understand code written by teammates before extending it. However, I would always be sure to read through the LLM's implementation and understand what it is doing and why. I would encourage other students to use LLMs when they find them helpful, but to do so in a way that supports their learning rather than replaces it. It's important to ensure that you still understand how the code works and why it was generated before incorporating it into your project.
Jacky
I only used LLMs for understanding C++ and physics code, and also sanity checking architecture decisions; I never let an AI modify the codebase. This was partially because I wanted to learn more by implementing things myself, and also because I usually already had a good idea how I wanted to do things and I didn't really trust an LLM to do it better. There are definitely places where I could have used LLMs harmlessly more though, for example creating the variant swarm aliens based on already existing code, which might have saved some time. Looking at the AI-generated code that some of my teammates added, while it was usually very functional, and I trust that my teammates were using it responsibly, I feel like there are often serious issues in maintainability — for example defining a lot of constants in isolated code and a lot of duplicated code sections that could have fit better in existing systems. For the purposes of our project it's fine since we aren't going to build on it further, but I would use caution when applying LLM code to a longer-term project.
Alex
I implemented many of the little visual effects in our game myself. However, I am a graphics amateur. I did not know how to implement volumetric clouds, or bloom, or glowing, and I still don't know how to implement volumetric clouds or glowing. I think the most important part about using an LLM is to make your code more modular before the LLM writes anything, so that even if you don't understand how a function is implemented, you still understand the rest of the codebase, and you can safely think of that part of the code as a black box. If it works it works; if it doesn't work, you should be able to just comment out one or a few lines of code to get back to an acceptable state.
Question B-9
If you used an implementation language other than C++, describe the environments, libraries, and tools used. Would you recommend it for future groups?
We used C++ for our entire game and CMake for building.
Question B-10
How many lines of code did you write for your project?
15,651 lines, counted using the following bash command:
find ./server ./shared ./client \
-type f \( -name "*.frag" -o -name "*.vert" -o -name "*.cpp" -o -name "*.h" \) \
-print0 | xargs -0 cat | wc -l
Question B-11
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?
Sofia
It's important to take initiative while balancing being flexible. I think especially in the first few weeks, it was difficult to get the ball rolling because we were trying to get to know each other as a team, so I appreciate my other group members doing that in the beginning. More subtle things like creating a to-do list of tasks and having a space for members to freely assign themselves was another important way that we were able to continue working as a group asynchronously. Flexibility was also important, especially in the last few weeks of the quarter.
Nora
I think in a group project (like Sofia said) it is important to take initiative and also communicate. Nobody will want to tell you what to do, and you should pick up tickets as they come. I also think it is important to let your group know if some weeks might be busier for you, so that they can accommodate. It is also important that they know what you are working on, so that nobody works on the same thing as you. This saves time and energy.
Bernico
I learned that work-together sessions are very useful in large group projects over an extended period of time such as this. When we're meeting offline biweekly, we end up being able to discuss so many things together as they appear, and so many of our project's great ideas come from these small discussions. The fact that we work on our own parts during that time doesn't make us go silent towards one another, but instead it means any problem from any parts can be tackled and solved together. As such, I think offline meetings where we just work on tasks is very important in group projects.
Zoe
I learned about the importance of communication. One thing that stood out to me about our group's dynamic was how frequently we communicated; we met in person to test aspects and work together, but besides that we were constantly communicating via Discord. This allowed us to work independently, ask questions, and still be on the same page. This also ensured that if someone was working on something that needed to be completed before another teammate could do their work, there was clear communication and understanding about when that would be done.
Alex
Second opinions are very valuable, use them.
Question B-12
Looking back over the past 10 weeks, is there anything you would do differently, and what would you do again in the same situation?
Sofia
I would probably try to stick to our timeline for game art more strictly, or recruit another game artist because I was sad that we left our game audio to the last minute. I really wanted to work on that. However, some weeks I did work too much on the project that my hand hurt from using the mouse, so … moderation and more manpower I guess.
Nora
I think that we could've had one meeting where we all sat down around week 7 or so to make finalizing decisions regarding game design. I think we made way too many large changes in the last two days that did not leave us enough time for testing. I think things like game design and gameplay should have been decided and finalized with time for play testing. For example, we decided to add a second textbook the week of and added it essentially the day before. This led us to not testing important functionality like the game win conditions, where the second book was not checked for. Aside from this, I think I mostly would have done the same as we did.
Bernico
I think we could've made infrastructures such as helper functions to add new features faster. For example, when needing to send over new arrays from the server to the client, we must add them to around 3-4 different files just so the client can see the new changes on the game snapshot correctly. This philosophy in the infrastructure was mostly because we just wanted to get the infrastructure done as soon as possible so we can start working on the actual game. However, in reality, I believe that towards the end, the process ended up causing us to take longer just to add new features, and caused many unnecessary bugs that could have been avoided with simple helper functions. Aside from that, I think I would have done everything else the same as we did.
Zoe
As some of my teammates have also mentioned, I think certain aspects of our game's design were finalized later than they should have been. Looking back, I wish our team had scheduled a meeting around weeks 8 or 9 to clearly define the features we wanted to include in the final version of the game. Instead, many decisions were made very close to the deadline, which led to a rush to implement several new features during the last few days of development. As a result, we did not have enough time to thoroughly test everything, which contributed to some issues and unexpected quirks in the final product.
Alex
Start copying from existing games earlier, or at least look at them before blindly seeing if something will look good in the game.
Question B-13
Which courses at UCSD do you think best prepared you for CSE 125?
Sofia
CSE 167 is good for introduction to Blender and computer graphics in general. I did not take the next courses in the graphics sequences, but I'm sure it would be helpful to take. Also, some VIS classes focus on interactive graphics so maybe ask some ICAM majors :) MUS 173 A/B is a great way to learn about and practice sound design! CSE 169: I heard you use Unity in that class, so knowing what a game engine should do by using a popular one is great! (If not, you can also attend VGDC's workshops hehe)
Nora
I don't know if any one class best prepared me for CSE 125. Honestly, I have come to realize what classes I want to take/where my knowledge can grow. I wish I would have taken any of the CSE 120s (120, 123, and 124 specifically). I also think a computer graphics course could have been helpful. However, like any other class, I think anyone can learn anything while doing it. 125 allowed me to learn about several topics and I was able to figure them out by completing tasks. From the classes I took, CSE 110 and CSE 190 (with Soosai Raj) were the two most helpful since they were classes where I worked in teams or on large code bases. I think having experience with large codebases is helpful because you learn how to apply your knowledge in any situation.
Bernico
I very much believe that CSE 124 and CSE 120 were what allowed us to finish working on the basic server-client networking so quickly. They both teach you to be comfortable with establishing connections, sending over information, and working with locks and threads to make sure the connections run smoothly. I also think that classes like CSE 167 are great for the graphics side, while classes like CSE 165 and its usage of Unity helped you with a frame of reference as to how we should design the game engine in the first half of the project.
Zoe
I think courses such as CSE 110 and CSE 190: Large Code Bases helped prepare me to be an effective teammate. These classes taught me how to communicate clearly with team members and collaborate on projects where multiple people are contributing code independently. In particular, the emphasis on code comprehension, version control, and teamwork gave me valuable experience that translated directly to this course.
Alex
Truthfully, none of the classes I've taken so far really give sufficient preparation for such a big project. Knowledge of Git from CSE 110 is probably the most useful thing from course work, but I believe software engineering skills can only really be developed through building and architecting large projects from scratch, which none of the courses I took here offered (besides 110 I guess, but I'm not a fan of that class).
Question B-14
What were the most valuable things that you learned in the class?
Sofia
There is huge value in meeting as often as you can in-person, even if it's just to co-work. You can get so much work done when you can ask questions and get answers so quickly. I was able to ask questions about aesthetics and could quickly make changes to the model coordinates if something was off during in-game rendering.
Nora
The most valuable thing I learned is that you should not be afraid to learn new things. I worked on several different sides of software engineering and realized that with even a basic knowledge of anything, you can figure out anything (there is no rocket science in coding). I also learned a lot about different OSes and how that can affect your work (which has inspired me to take 120 in the Fall, see you then!).
Bernico
The most valuable thing I learned in the class is that using your CS knowledge to create something is not only very easy with enough motivation, but also very fun. I thus learn that I should realize my ideas more often and make things using the knowledge I've learned from my classes.
Zoe
I learned the importance of taking initiative when working as part of a larger team and gained confidence in my ability to take ownership of tasks and see them through to completion. I also learned a lot about testing, debugging, working with different OSes and troubleshooting cross-platform issues.
Alex
I got much more experience with git than I had before. If you're reading this, learn git as much as you can.
Question B-15
Please post four final screenshots of your game on your group pages for posterity. I will display them on the group web page.
Question C-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 (and all of its content) 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 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). If you used Google docs for your group's web page content (e.g., specification, weekly reports), it could be fine as is or it might be good to create an archive version. If the Google account used to host the content is a permanent account (e.g., a personal account) then it can be available online indefinitely (e.g., the Google doc for the final report from Tansen's 2014 group is still online). However, if it is a school account that will expire after graduation, then creating an archive version (e.g., saving to pdf to the cse125.ucsd.edu server) would be much better (otherwise your content will quickly be unavailable).
We used the CSE 125 sites althroughout!
Question D-1
For the pizza celebration after the demos, what did you think about having it in the B270 lab so that people can play each other's games? Should we do it again? Or were you completely exhausted?
Sofia
Loved the celebration after the demos! It was so great to end the quarter in the same lab that we started in, with so much energy and joy!
Nora
While I was not there for the pizza celebration, I did enjoy the Thursday dinner pre-celebration! I think that the basement was a fine place to enjoy some food and company.
Zoe
Sadly I had to leave the pizza celebration early to study for a final the next morning, but I enjoyed it when I was there!
Bernico
I think it was great! It should be done again!
Question D-2
What advice/tips/suggestions would you give students who will take the course next year?
Sofia
Even though there is one assigned artist, try to have 1-2 other people to help out!
Nora
Don't change things last minute. The two days before the demo are only for bug fixes or well tested changes. The day of should only be building essentially; do not merge anything unless extremely necessary.
Zoe
I agree with what Nora said. Honestly, I wish we had set an internal "deadline" to have our game done 2 days before the demo, so we could have fully tested it and prepared for the demo itself!
Bernico
Other than what is said above, I think it's also important for you to stay positive with your game and believe in your team! It's easy to feel that you're lagging behind other teams, or feel the imposter syndrome of your game not being the best, but you should just trust the process and stay focused with your work.
Jacky
Don't reinvent the wheel and don't overthink about optimization early.
Alex
If you're doing graphics, look at other games in your genre for inspiration. By look, I mean literally play it yourself or watch a video of someone playing it, and try to notice every single little thing that happens on the screen, and whether you want that in your game or not. Also, it's fine if everything isn't perfect — this is a 10-week fun class. Unexpected imperfections during your demo are more memorable than if everything goes as expected.
Question D-3
Do you have any suggestions for improving the course?
Sofia
I think if some of the guest speakers could be 3D game artists that would be a huge win!
Question D-4
Any other comments or feedback?
Sofia
I'm so glad that I was able to take this course! I really appreciate the weekly group meetings and the feedback you gave us!
Nora
Thank you for all the guidance and support through the development of our game. I had a great time taking the course and would recommend it to anyone!
Zoe
Thank you for an amazing quarter! I learned so much and grew so much throughout this course!
Bernico
Thank you so much for the help throughout the development process! I think it's one of if not the best course throughout CSE!