Final Report

Here it is, we’ve reached the bittersweet end. Thank you Geoff and Edward for a great quarter!

Main Questions:

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?

Our game concept began from a want to create some type of single-player fantasy world exploration game to realizing that we had to incorporate 4 player gameplay. Initially, we thought that the player would inhabit a map with three other bosses to fight, but we switched this perspective to a 3v1 action game – and included story through a main boss going through the five stages of grief. We figured this would be the most conducive to fun gameplay as we could split gameplay into five stages. Major changes throughout the course of the quarter included making it so the boss did not have to go through all five stages of grief (i.e. because they could be killed prior) and that the hunters sort of became the protagonists of the story, rather than the monster. Due to the 4 player nature of the game, there had to be more elements of game mechanics, and this is what allowed for that.

Design: How does your final project design compare to the initial design, and what are the reasons for the differences, if any?

For the most part, our final project design follows very close to the initial design documentation. The few differences are that: we did not implement a fog of war, zero enemy AI, and unfortunately no voice acting. The fog of war idea was essentially replaced with just a zoomed in perspective, so in a sense, there is a fog of war because the map is big enough compared to the view distance on the client side. There was zero enemy AI because we did not have time to implement AI and were more focused on getting the game to feel great with just the 3v1. The voice acting was a very cool idea but we never had time to do it. However, these differences are purely just our “would be really nice” and “cool but only if ahead of schedule” features.

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.)

[Rajen] I eyeballed a lot of my own work schedule and simply created assets as needed. It was hard to keep to tangible deadlines and I felt it easier to just note what the game was missing and add it in, especially as time went by.

[Nakamoto] I was able to stay on schedule most of the time, except I did have one week where I did not have time to implement the revive mechanic, which was later given to Amrita to implement.

[Siu] In the bigger picture, we were actually ahead of schedule, but decided to cut a few features (like enemy AI and multiple maps) and implemented more of our would-be-really-nice features earlier than expected. If anything, the main differences in our schedule was that we did not spend much time beta testing, rather that week was spent mostly squashing bugs and putting in last minute features.

[Srinivasan] My schedule was fairly eyeballed/fast-and-loose as well, and I just created whatever assets were necessary at the time. I wasn’t able to work as consistently as I hoped, due to a variety of factors such as medical issues and other classes, but I’d like to think I did an okay job managing my time. 

[Liao] Like what others have noted, we were mostly able to stick with our initial schedule; even though some components were done a little sooner and some a little later, the flow of our development were close to what we had planned for the most part I think due to the fact we were able to smoothly transition from one part of development to another.

General Questions:

What software methodology and group mechanics decisions worked out well, and which ones did not? Why?

[Kohli] Using pull requests with an approval required to merge code worked out well. 

[Nakamoto] We had an agile-ish development process, where features were assigned every week and were implemented before the following week. We reviewed the features in pull requests and talked about them in our weekly meetings. I think this worked out well because it allowed us to work fast and gave us a clear understanding of what needs to be done.

[Siu] Our agile development process was good. We were able to map out what we needed to do each week to get our final game.

[Liao] We did have rather specific plans for what we want to have done for each week at the beginning, but I think about 1/3 of the quarter in, we kind of transitioned into doing what we thought could be done for that week.

Which aspects of the implementation were more difficult than you expected, and which were easier? Why?

[Nakamoto] Working with the game engine was more tedious than I anticipated, which made optimizing and implementing features more difficult. In contrast, it was rather painless to implement features between the graphical client and the backend (server), which I expected to be difficult because the game needs to run synchronously for all clients.

[Liao] I think the most difficult aspect of the implementation was runtime optimization because towards the later stages of our development, we had a lot of objects and different types of objects to render, and CPU bottleneck and RAM usage issues were something we only discovered and had to fix along the way.

[Siu] Honestly, I did not think working on and debugging the graphics client would be so hard. The main reason was that the stack traces and print statements would never give me an indication of where the bug exactly was. Moreover, there were some things I assumed that the graphics client could do with zero work from our side, but I was completely wrong (e.g. week 9-10 weekend crunch to get mtl files working).

[Rajen] Polishing up the game with the number of days in the single digits proved anxiety inducing. A lot of it was me incessantly pinging Eric and asking him to tweak the saturation on some obscure thing or load in an entirely new asset I had created because I wasn’t entirely vibing with the way the game looked. If you’re going to be a game artist you absolutely need someone on the coding end willing to do a lot of the heavy lifting and help bring the game to completion. There’s so much teamwork and coordinating at the last minute was stressful.

Which aspects of the project are you particularly proud of? Why?

[Ouyang] I am super proud of our game’s concept and all the art work. At the start, we spent a lot of time discussing the genre and theme. We were not thinking of a game that we have played before, we were actually trying to come up with a game that belongs to our own. At the end, we decided to do a combat game with a dark soul story behind it. This makes our game special and this experience unique. With our amazing artists, we could deliver our concept and thoughts to the users.

[Siu] I would want to echo the same thing Duolan said, and also I am very proud of how fluid the movements were in the game. Honestly, I played/launched the game so many times that I got so used to how good it looked. It wasn’t until I saw the final demo that I realized how smooth the gameplay actually was.

[Nakamoto] I was extremely impressed with the work done by our Art and Audio team. As a result, the final build of our game looked super polished compared to when we first started. I am also proud of the Game logic and UI team for implementing so many quality-of-life improvements in such a short period of time, which noticeably boosted the quality of the final build.

[Rajen] I’m proud of doing style research beforehand – it really helped us cement what kind of theme we were going for super early. I’m also happy with what I was able to do with the number of days in the single digits, especially when it came to fixing up the UI and adding menus.

[Kohli] I’m proud of the art work and soundtracks in our game, and all the unique features we were able to implement for every character.

[Liao] I am proud of the fact that we are able to do the majority of what we have planned initially. I could only roughly picture how our game would look at the beginning, and I am surprised at how good our game looked at the end. I think we have encountered a lot of technical obstacles along the way, but we have surmounted them in the end. 

[Srinivasan] I’m most proud of the game’s concept and final design — it actually looks like something you’d purchase and play, not a class project created in ten weeks. 

What was the most difficult software problem you faced, and how did you overcome it (if you did)?

[Rajen] Learning to use Blender proved quite difficult. Overcoming this challenge mainly included creating many low-poly assets in place of Ghibli style assets. It was really challenging working with the graphics team to include 3D assets that could actually work with our engine. For instance, the polygon count was WAY too high on an initial dummy asset created and we had to kind of just wing it and figure out a better (simpler) way to do things. Overcoming a lot of the pipeline problems meant just Googling around and tweaking things where we could, where we had the understanding to do so. We had to scrap some ideas entirely because neither the art team nor the graphics team had the knowledge for it.

[Kohli] Figuring out where things were. We had to work with a lot of class files, header files, and folders and since I didn’t lay out the skeleton code it took me some time to get used to the structure of our project. For each change I wanted to make, I had to edit several, often unexpected, files.

[Siu] The most difficult problem was figuring out why we couldn’t build on Release and why some objects were displaying different materials from their Blender preview. We eventually fixed both those issues by re-reading the graphics code and saw off-by-one errors. We generated only 2 buffers for 3 VBO’s and the mtl loading code was using vectors with differing sizes.

[Nakamoto] Figuring out how to project the cursor to the game world was extremely difficult. Eric eventually decided it would be easier if we tied the cursor to the ground plane, which allowed the implementation of our projectiles to function correctly.

[Liao] It is the same issue Eric brought up. I included texture coordinates later on in the development but without adding the lines to let OpenGL create the buffer for it, so this created some nasty memory issues that sometimes harmless buffer overflows would allow the the program to work, and some other times, the program would have segmentation fault.

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?.

We used C++ and Visual Studio. We used the nupengl + glm packages for graphics. Some libraries were TinyObjectLoader (mtl loader), NanoVG (GUI + HUD), and SoLoud (audio).

[Liao] We for the most part used C++ with Opengl as our graphics API. The thing with C++ is that depending on the compiler, it might not tell you enough error information of your program at compile time, and we had some rather tricky issues with memory allocations. As for OpenGL, I would recommend it because it is a top level graphics API, so it is not too difficult to take on, and students get the benefit of learning about it from CSE 167.

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.

[Nakamoto] ~1772. I looked at my commit history on Github and totaled the number of lines I wrote, excluding comments and blank lines. 

[Kohli] About 300. I used my GitHub branch commits and pull request history that shows how many lines were added and added them up.

[Ouyang] ~3200. I contributed to ~60% of the game module code which is about
3000 lines. I also added some minor changes/fixes to graphics code and server code, which is about 200 lines.

[Siu] Not sure how accurate this is, but this was my process for finding out my LOC:

1. git log –author=”Eric Siu” –pretty=tformat: –numstat > git-log-output.txt
2. Run the git-log-output.txt through the following python code, which does a trivial filtering through the packages and extra folders:
   
3. With this, I only look through .cpp, .h, or .c files. Double check the printed lines that have > 100 lines of code changes are not library code. I did not include map_parser.py, which was my python script for parsing map info, which is about 111 lines.
4. Total Added: 11151, Total Deleted: 2172, Total Lines: 8979. 
5. Note: this count probably includes code that I may have written but was deleted by someone else. I decided not to go through all the latest versions of files and count all the lines I’ve written because I’ve touched so much code that I’ve forgotten which code I’ve written.

• 2099 lines from just the gui folder (I think I was the only one touching the gui folder)
• 300+ lines are from the networking code.
• The other ~6900 lines are from probably everything else. I believe I touched all parts of code — including the Game Logic, Graphics, GUI, Audio, and Networking. Although, some of that graphics code probably was me copying Jordan’s graphics code to make my own ObjElement.cpp / ScreenElement.cpp / TitleWindow.cpp / other graphics code. 

[Liao] I essentially traversed through the latest version of the files, and counted all the portions that I wrote excluding all the parts that are reused for asset loading and draw calls in different object classes. I wrote roughly 2300 lines, and all of them are on the graphics/client side.

[Rajen] I wrote 0 lines of code, but from an art standpoint, the animations were so intensive I feel this can apply to this question. There were approximately 8 frames on average per animation, and four directions, and five characters. Which yields 8 * 4 * 5, or 160 frames drawn in total (!). Not all were hand drawn as left and right frames could be mirrored, but animations add up quickly, so be aware if that’s what you’re doing.

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?

[Rajen] This will be long, so bear with me.

Animations:

All concept art for the animations began in Procreate. I recommend picking a digital art program you are highly familiar with-  or just interested in learning all of the facets of. Once you open it, just start doodling and see what comes to mind. A lot of the brainstorming took place via looking at what typical game assets look like in the style we were trying to achieve. It really helps to just pick a “genre” and stick to it. Whether it be pixel art, illustration, whatever.

I began by creating a default sprite in Procreate on a single layer in a 300px x 300px canvas. I created my own Pixel brush, I followed this tutorial: https://www.youtube.com/watch?v=WepVBzhYoP8

After creating the asset, I cloned this layer, mapped the new sprite onto the old one, and redrew it. I highly recommend just getting a dose of the animation principles if you don’t have any prior experience animating. I also highly recommend coloring AFTER you work out the shape of the object. Quick tip – if you are animating sprites, the goal is to simplify everything for the viewer. Think about giving the illusion of movement!

Next, export the entire file (all the layers!) to Photoshop as .psd format. Note that you have to do this in order to blow up the image properly!

Next, I resized my images by a factor of 8, and then resized that again at a factor of 2. Why two separate steps, just because it would otherwise appear pixelated due to the zoom size capping at 800%. Also, resize with Nearest Neighbor (bicubic) so that the image retains its pixel quality! Here is where you’re going to use the Timeline panel to create animation frames. I recommend following this guide here: https://helpx.adobe.com/photoshop/using/creating-frame-animations.html (Note: I didn’t mess around with blending modes, but feel free to get creative!)

Once you have the frames in the exact sequencing you want (and don’t be afraid to mess around with the ordering!), export each one as an image format – I used .png for higher quality, but .jpeg works too.

One thing that was less obvious was exporting a frame twice if I wanted that specific frame to delay longer – for instance, an inhale or exhale. Have fun with it and be creative.

…now bug your graphics team and have them do the importing. And you’re done with 2D animations! Just kidding, art is never done. (Hint: for mvp, I highly recommend only doing three directional animations – front, left, and back. you can mirror left and right)

Low-poly assets:

For creation of the asset, I always deleted the main light and camera in blender. Annihilate the default cube (blender junkies can get this reference) and create the asset. For my export settings, I used these:

(Note: Our final shader couldn’t support the render , but here’s how one of the assets looks in blender with a principled bdsf shader. I recommend reading about them here, they can give the game an amazing look and feel: https://docs.blender.org/manual/en/latest/render/shader_nodes/shader/principled.html

[Siu] After getting the mtl/obj files, the graphics side:

1. Manually load obj files (or use a library like assimp or tinyobjloader)
2. Used TinyObjLoader to load mtl files if any (we assume mtl files have no texture maps, which is not true for some mtl files)
   • If you have texture maps, you will need to load textures for those texture maps.
3. Make a shader to feed them through (we used a modified phong shader for those with mtl files w/o texture maps) 
   • For anyone using OpenGL: https://learnopengl.com/Getting-started helped me a lot to understand the code and shaders
   • Note on shaders: don’t be afraid to create custom shaders for specific purposes. For example, we had a saturation phong shader and saturation texture shader entirely used for modifying specific color saturations to make objects to fit the color in Blender or to make it look brighter. With customized shaders, you can do pretty cool things like modify the color on characters to display some type of burn/heal/damage effect without the artists having to painstakingly add more character textures for each effect.
4. Create VAO/VBOs/EBO for the obj data and create a draw() method to draw the object in the render loop using the created shader program.

For 2D characters (only .png files with RGBA):

1. We created a billboard.obj that essentially is a rectangle/square in 3d space.
2. Apply the character sprite texture to the billboard with a texture shader (which discards pixels with alpha value < 0.1 to implement the transparency mask).
3. If you want the character not to look like a billboard, you will have to rotate the billboard around the x-axis (or whatever axis goes left to right relative to the camera) to face the camera, so it looks like an image instead of a 3d rectangle. 
   1. Without facing the camera (squished):

2. With facing the camera (looks like the png):

As you can see, the player model on the bottom looks less “squished” because the picture is actually facing the camera instead of being at a higher angle. However, the top could also be a “feature”, if you wish to make it seem like you’re seeing a 2d character at a higher angle.

[Liao] Much of our issues with opengl were due to CPU bottlenecks. If there are a lot of objects in a scene, and one were to draw them one at a time calling draw(), the program would quickly run into a CPU bottleneck with the creation and removal of the call stacks. Having draw calls for each object can be sustained with maybe up to 300-400 draw calls and still have a reasonable framerate but not much higher than that.

A possible solution for this issue is to draw multiple objects that have the same mesh and textures all at once using either GLDrawArray() or GLDrawElementsInstanced(). This approach will decrease the number of draw calls but will not decrease the amount of object drawn on the screen.

Another solution could be limiting the objects drawn geographically by maybe only drawing the objects near the camera. This can be done using spatial data structures like spatial hash table or some other hierarchy trees. Our game utilizes a spatial hash table. It works by taking in a 3d coordinate and returns an index to a pre existing bounding cell in 3d space that contains this coordinate. This data structure has the benefit of having a low time cost of O(C) for look up, insert and delete, and being memory efficient since a bounding cell would not be created in the first place if no object is inserted into it, and therefore, theoretically this data structure is not limited to the size of the map, but rather the number of objects in it. The equation to get the cell index is the following (floor(coord.x / h) * 73856093) ^ (floor(coord.y / h)* 19349663) ^ (floor(coord.z / h) * 83492791)) / (size of bounding cell list); h is the bounding cell width.

To actually use the spatial hash table, the program has to insert an object into the the table using the indexing equation above. To find out what objects are in proximity to the camera, the program has to actually query for cells near by. For 3d space, if the program wants to draw objects near by the camera, it has to query for camera’s own position, also camera position plus or minus one cell ahead, behind, to the left, to the right, up, down, and diagonal; a total of 27 cells. The objects in those cells are the ones immediately near by.

Would you have rather started with a game engine or would you still prefer to work from scratch?

[Liao] I think that depends on the purpose of this class. If it were to just make a game, I think using an existing game engine would be more efficient in allowing us to actually think more about game content. However, if it were to explore how games sort of work behind the scenes, I think students should just create a game engine of their own. Personally, I prefer the latter for the course because it allowed me to actually use knowledge from past classes taken.

[Kohli] Having made a game with Unity before, I definitely found that method easier. By working from scratch, however, I learned a lot more about how networking is done. So while it may have been easier to start with a game engine, I appreciate working from scratch as it taught me more.

[Nakamoto] Working from scratch was a great experience and gave me a new perspective on the difficulties and challenges that go into game development. For the purposes of this course, working from scratch is my recommendation. With that said, I would have preferred to use an engine ONLY because it would have allowed us to build a more complete game since we wouldn’t have to implement every aspect of the game.

[Rajen] I think it would be really cool to see what students can create if you give them a ready to go engine. It could allow people to flesh out their game concept more and having an engine with shaders could lend to really amazing looking projects. Not having an engine in the beginning was super stressful and this is even considering I wasn’t on the networking side of things. That being said, it is so impressive that teams must start from scratch and it really allows the programming to shine.

[Srinivasan] Because of the purpose of this class, and the concepts we’re working on, working from scratch fits better. However, if we decide to expand on this game and actually make it into a complete marketable product, using a game engine would be the far safer and less time intensive route. 

[Ouyang] I would definitely choose a game engine, even though I do enjoy the process of doing everything from scratch. For a game engine, I assume there are already a lot of wheels which are optimized and in good shape. Using them will save you a lot of time, so you can spend more time actually working on the game concept itself.

[Siu] If we were planning to focus on getting a game out, I would say game engine. However, working from scratch taught me a lot about how things are put together, which is a great thing to learn. Moreover, I feel that if we wanted to make an optimized game, I would say a personalized game engine from scratch would be better, but Unity/Unreal would probably allow us to prototype new versions of the game quicker.

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?

We did not use a networking library or physics library. The “networking library” we used was WinSock (specifically TCP sockets).  Judging from the other groups’ troubles with Boost, I would say just use TCP sockets. We were able to get our networking code up and optimized WAY much earlier in the quarter. I would say our foundational networking code (with delta optimizations) was done within the first 4-5 weeks of the quarter. 

We did use a GUI library called NanoVG, which helped us get images onto the HUD and screen faster. NanoVG was a bit weird at the beginning because it would not render the images correctly, but it worked later in the quarter. Essentially, a good way to troubleshoot was to look at the example code and see what differences there are between your code and their code. For NanoVG, as long as your ImagePattern and the rectangle that you are filling are the same size, then you are chilling. You can scale the image by changing that size.

[Siu] I honestly wished we got more deep into networking in games, because I was looking online at how games used UDP. It would’ve been cool to see the game working over the Internet rather than LAN. 

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)?

[Kohli] I didn’t mind WordPress. It was fairly simple to work with!

[Srinivasan] I didn’t mind using WordPress either. It was customisable enough to include everything we wanted to, and writing/formatting weekly reports wasn’t too much of a hassle. 

[Rajen] WordPress is definitely the best hosting site for people who know code. Though I am a huge fan of Squarespace and find the UI super intuitive. There are also a lot of templates and there’s a lot of chances to customize it to your liking. I definitely think this could take out some of the sharp edges of creating a developer log you enjoy looking at.

[Siu] WordPress got us up and running pretty quickly. Daryl did a great job inputting some cool plugins, so the website looks really nice. I would prefer a more customized website, but WordPress’s convenience was much better.

[Nakamoto] WordPress was a good middle-ground between ease-of-use and customizability. In the future, I would like to see an option for students to use something more powerful, since a lot of “cool” features cannot be implemented in WordPress without paying a fee.

[Liao] WordPress is generally easy and efficient to use because it allows you to reuse document templates quickly, which might be an issue if we were to write a new HTML page every time or add to one.

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)?

[Kohli] Definitely! Discord is amazing for communication and it was implemented really well.

[Nakamoto] I have always advocated for Discord, please continue to introduce it!

[Srinivasan] For sure. However, instead of a central server for the entire class, maybe specific servers for groups could’ve worked better (it’s what we ended up doing anyways). 

[Siu] Discord is cool and I would recommend using it in the future. However, I would prefer Slack for work-related/school-related stuff.

[Liao] Discord is very useful. In addition to voice chatting, internal streaming, it also allows us to leave messages for teammates to read at a later time.

This quarter was particularly difficult having to do everything remotely. What tools and strategies did you use to collaborate, communicate, and work together?

[Kohli] We used a Discord server with several channels to categorize information. We met every week and sometimes even more when needed. We used Trello for task management. We would let others know when we were online to work together virtually in our Discord server’s voice channels. We used vailable.io to find common available times for meetings.

[Nakamoto] Discord was the MVP, it helped us organize our ideas and work and also allowed us to communicate with each other efficiently and effectively.

[Siu] To add on, having a person lead team meetings is definitely more productive because if not, then the meeting may go off on a tangent for too long.

[Liao] Discord was very helpful, and we also try to stick to having at least one meeting per week to clear problems and discuss new issues and features.

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?

[Rajen] Collaborating on art assets requires clear communication with not only the art team, but the graphics team and whomever is going to be doing the heavy lifting for you – let alone the entire group as a whole. There comes a point where all the code is implemented, but the game doesn’t quite look like a game yet. This is where the weight starts to fall on the artist and it’s super important to start early on any concept art or ideas you have, because if these aren’t semi-fleshed out already, the game could start to look like a hodge podge later on. Try to stay as organized as possible with assets too, you will have to send it back and forth across teammates and following naming conventions for the graphics team helps them out on the coding side of things 🙂 And don’t be afraid to ask things of your team!

[Kohli] In the beginning of the project, I felt lost and out of place as I was assigned work to be done individually – something I wasn’t used to doing in a team project. It was challenging because I didn’t have my teammates around me in-person or at the same time to ask questions right away, as soon as they came up. Upon communicating my concerns with a teammate, we came up with a solution that led to better collaboration. We decided to let others know when we’re online, kind of like office hours, so we could collaborate and work on things together and pair program if desired. My takeaway from this experience is that solutions can come through communication and brainstorming as a team. 

[Nakamoto] Hearing and understanding everyone’s opinion even if it goes against my own. Working in a large group setting really helped me learn to make decisions that were better for the group and the project as a whole.

[Siu] I learned that larger groups require more communication because lots of information is being shared at one time and no one has time to read all the messages. A great way to do that was through the Trello board. 

[Ouyang] Do tell people about your thoughts and concerns. Since this is a large group and a huge project, and this is not the only course you are taking, it is hard to stay on top of everything unless you are Eric. Communicating to others about concerns either towards the project or your own study/work is a good way to ease anxiety.

[Liao] I think comprehensive communication was very important because this is not a personal project in which your own thought process is perfectly reflected, and there are a lot creative ideas being generated very frequently. Therefore, it is very important to make sure you understand other people’s opinions and ideas clearly as soon as possible, so that development can flow more smoothly.

Looking back over the past 10 weeks, how would you do things differently, and what would you do again in the same situation?

[Rajen] If I could time travel, I’d make sure my art fundamentals were as strong as they were when I ended the class as compared to when I started. I feel I can truly start to animate things properly now and some of those movement sets that I created at the very beginning look kind of questionable. This also would have saved me time in not redoing assets as much. I also would have drafted far more concept art and scenes. Ideally, it would have been epic to create a 3D manor scene in Blender and have that serve as the environment for the game. I would have spent a lot of time getting to know Blender. I’d also do more shader research and try to learn more about their implementation.

[Kohli] I would want to participate in other aspects of the project to, at the very least, see and understand what was happening in those parts of the project. I would still work primarily on the backend, as I enjoyed it and felt my skills were best used there.

[Nakamoto] I would have worked on the graphics more, even though I lack formal experience in graphics. We had a lot of issues getting objects imported and looking correctly in the engine, and maybe if we had better foresight we could have had a basic lighting system implemented.

[Ouyang] I would say the same as Daryl. If I started to study graphics from week 1, I definitely could start to make contributions to the graphics code at week 8. 

[Siu] Help implement graphics related things earlier in the quarter. I think we didn’t get to import Reesha’s trees with somewhat the correct color until week 9/10, which was nerve wracking because the amount of days left was literally in the single digits.

[Srinivasan] I would’ve just… tried to figure out a way to contribute more in general. As it stands, I didn’t exactly do as much as I would have liked. Maybe investing in a less bad computer might have helped. 

[Liao] If there is a chance to go back to week 1, I wish to plan out the client side game/graphics engine more thoroughly. At the beginning, I did have some considerations for more efficient graphics asset loading mechanisms, but as requirement piled up, a lot of things were not done most efficiently. For example, our Window class is taking on too much functionalities that at the end, it is kind of bloated with code for GUI, game logics, and central graphics logics. It could be split up into separate source files so that they could be better maintained.

Which courses at UCSD do you think best prepared you for CSE 125?

[Liao] CSE 100, CSE 120, CSE 167, CSE 169; the latter two for graphics side

[Siu] CSE 12/100/110/120/123/221

[Nakamoto] CSE 110/112/120/100/124

[Ouyang] CSE12/120/123/124

[Kohli] CSE 12, 15L, 110

[Rajen] CSE 110 just for the Git stuff. From an art perspective, all the art classes I’ve ever taken.

[Srinivasan] CSE 12, CSE 15L, CSE 120

What were the most valuable things that you learned in the class?

[Siu] Game design is really fun. Communication and Clarity is very important when it comes to building an idea that can have so many perspectives. Especially when it comes to game design, many people have different perspectives or ideas about specific functionality due to their individual experience with games. Some game concepts do not make sense if not everyone has played the same type of games. 

[Nakamoto] Learning to reach a consensus on a singular vision among a pool of great ideas and opinions. Additionally, it was hard to pick and choose features to implement because we had so many great ideas, but the team did a great job of communicating, which made decision making easier. I also strengthened my skills to build-upon code I haven’t written and worked on communicating issues I was having, rather than saying nothing.

[Ouyang] The most valuable thing I have learned is writing code that scales from small to large. When wrapping up all the work in week10, I said to myself that thankfully we had such a nice structure. Our initial structures were thoughtful and carefully designed, so that it was really easy to add/modify things. For the backend, after Eric finished the initial network code and I finished the initial game structure code, we barely changed the structure. The most valuable thing I learnt here but can never learnt in other classes is designing a good structure so you do not suffer later.

[Rajen] So much communication goes into conveying an artistic vision. You really need a lot of time on your side to be able to relay what you are thinking not only to your teammates but to what you will be showcasing. And procrastinating will never be on your side :’) Visually speaking, everything that you get out of the game will be everything that you put into it. People notice everything and it shows when you put time and effort into even the little things. Which is also what makes the art side so difficult – people notice everything.

[Liao] I learned that communication is important because I am no longer writing code for myself anymore, and I also need to consider how my code would be used by others. Therefore, writing and documenting code clearly are essential in teamworks. Also for code components that would be repeatedly used, it is better to add functionalities to them instead of modifying existing functionalities just to enable some new features because this will reduce the number of issues later in the development.

Please post four final screenshots of your game on your group pages for posterity. I will display them on the group web page.

C. Optional Questions:

What advice/tips/suggestions would you give students who will take the course next year?

[Kohli] I would advise students to have fun with this class, use it to learn new things and get to know your group.

[Nakamoto] Start early, talk to your teammates, don’t procrastinate.

[Siu] Since the networking code is going to be very minimal (if you’re doing TCP sockets), I would suggest trying to get the server/4 clients up very early in the quarter and then move on to other things. The Microsoft Getting Started page for WinSock is really good for getting it running quickly. 

[Rajen] I made sure I took this course when it was the only thing I was taking. In other words, you’re going to want to spend a lot of time with this class. Make sure you can. Also – have fun with it! There’s a lot of room for creative expression in this course. And really, try not to procrastinate. Easier said than done I know, but the week 10 crunch is real.

How can the course be improved for next year?

[Siu] Not sure if this can be done, but assign at least 2 people with graphics experience to graphics. I believe Jordan was the only one with Computer Graphics experience and I had to learn from nothing. It was fun and rewarding when I fixed bugs, but it would be less stressful with more graphics experience.

[Nakamoto] I echo Eric’s opinion.

[Rajen] I think having people apply officially under the art label could be really helpful and even that there’s one or two artists per team. Having even the smallest art team really helps bring the vision together quicker. Also, I do think a 2 player requirement minimum could open a lot of doors in terms of gameplay, surprisingly enough. I do think that the more people on the screen, the harder it can become to manage assets and gameplay experience. On a similar note, I really do see a huge future in 2D games. I understand the 3D requirement, but I really do believe students could have a great (and also challenging) time coming up with an engine and assets for a 2D game. There’s a lot of creative options here and even though they can be less CPU intensive, it still could be realistic to create in the 10 week span. Ideally, I would love to see a sprint-type style for this class over the span of two quarters? So the first quarter, you get your game to this working/playable state, and the second quarter, you start to make those heavy QoL improvements that really could bring a game to life. I really feel I was starting to get the hang of Blender and creating assets on day 5 of week 10. With two quarters, there’s also room for two demos: one after the first quarter and one after the second so people can really see the games bloom!

[Liao] I love the part that I have to figure out how to make something work on demand, but I do wish there was a bit more guidance. Maybe there could be a weekly lecture, or class wide discussion on software engineering to talk about design patterns or anything that students might want to use or encounter.

Any other comments or feedback?

[Kohli] I appreciated the fact that there were no major assignments for this class, allowing us to concentrate on actual game development. I also think that it should be included in the course description on the UCSD website that this class involves designing a game, as I actually didn’t expect that. I was expecting that we would be able to choose any type of project based on the course description.

[Siu] CSE125 is by far the most interesting and fun class I’ve taken. It’s probably the only class where I felt empty once demos were over. As I said before, this is probably the only project class that I was more focused on getting the game to look and feel good instead of thinking “I wonder if this is enough for an A” or “I think it’s fine, we’ll still get an A” when looking at a bug. 

Side note: I’ve noticed UCSB and UCI both have courses designated as Game Design courses. I feel like UCSD can benefit from having similar courses under CSE, especially with the growth of games.

[Nakamoto] This course was so much fun because I love playing video games and I finally got to build something in that realm. I would honestly love to see this course transition into a semester-long course to give students more time to work and polish. For our group, we had our game in a great state in week 10, but had no time to implement additional quality-of-life improvements which would have made the game that much better.

[Rajen] I had so much fun in this class – it was the first class that I didn’t care about my grade because I was just so passionate about the outcome that it didn’t matter. I dedicated 90-99% of my effort this quarter to this game and it’s bittersweet looking at the game in its initial phases vs how it is now. This class taught me that I would absolutely love to be creative director / art lead on a video game in the future. There is so much room for creativity in this class. Take it if you can! Do not pass up the opportunity! I applied on the last day possible because I was debating over the previous few weeks if I’d even be a good fit for the class. I am so glad I doubted my own doubts and sent in my application anyway. This was the most bittersweet ending to my UCSD career and one of the best windows to see what it would be like to work as a creative. Thank you for doing this for 21+ years. It means so much to people so passionate about this field in any way, shape, or form.

[Liao] I wanted to take this class because I once saw its game demo on Twitch back in spring of 2019, and I thought it was so cool. This class is definitely one of my most memorable classes taken in UCSD. Even though Its purpose is very much alike to CSE 110 Software Engineering, however, you get to work with people who also personally want to take this class, and that makes it all the more enjoyable because you get to work with people who likely share the same passion as you. I cannot believe that 10 weeks flew by so quickly, and I would certainly recommend this class to anyone who enjoys playing video games and who are also passionate about making one.