Final Report
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?
Ashley: Our game concept stayed pretty much the same in my view (since my game concept was used 😄) - a cooperative asymmetrical game based on the contrast of ability in vision, and we did it!
Manshi: It stays the same for a lot of aspects. I think we add a background story as our emphasis rather than explaining how Alice represents the marginalized group. And this definitely helps a lot while we doing the demo since we could use some visual elements to involve the audience.
Jack: The game had a clear vision throughout the whole class, though we kept adding to it as we progressed further into development, IE adding skills, background story, and other visual cues to show off what is happening in the game.
Design: How does your final project design compare to the initial design, and what are the reasons for the differences, if any?
Ashley: Honestly I did not expect a circus-themed hexagon maze at first, but after the concept art and music came out, everything started to make sense to me. The background story was also written after the design came out.
Manshi: For the skill’s design, I think it is a little bit different from our initial design. Initially, we plan to give three players totally different skills, even with different cooldown times. But either from the perspective of easy implementation or ease for the audience to understand the rules, we decide to choose the current three skills. And they all work pretty well!
Yingkai: While it was initially thought of vaguely as a maze, we specialized in having a hexagon shaped maze with three different submaps, each with their own themes. This ended up being a rather unique style of our game and allowed for fun variety in floor designs and music.
Schedule: How does your final schedule compare with your projected schedule, and what are the reasons for the differences, if any?
One difference is that we found out we needed a lot more art and music assets than what we’ve originally imagined, because of new ideas in the game design (e.g. 3 distinct areas in the maze) and advanced features we’d like to implement (e.g. skills). Also related to the skills is that we didn’t plan to do particles in our schedule but later wanted them for the skill effects. It was really nice to have two empty weeks on our projected schedule so that we were not stressed out, had some buffer, and could experiment with any new ideas and implement them.
Ashley: The physics side was mostly on track (shout out to Xiaoxiao for doing so much math on the hexagon!). The game logic side, though, took a lot longer than what we’ve originally planned but for some good reasons. We were focusing on MVP at first and didn’t want complicated gameplay, like skills. The time when we started to think about more gameplay details, is the time when we realized that we finished MVP rather early and had time to spare. Fortunately, we had lots of ideas already. Week 7 and 8 were empty on our projected schedule, but we were actually very busy and implemented many features that we thought would be nice to have.
Manshi: The network tasks progressed just as how we planned. And for game logic, we separated the entire gameplay into stages. And we completed all the tasks on time! (We should update these to our project spec lol.)
Zhiying: Thanks to our CEO and manager :) I think our project is just as what we planned out each week. We didn’t end up sleeping in the lab and we even leave early.
What software methodology and group mechanics decisions worked out well, and which ones (if any) did not? Why?
Manshi: We did not use a specific software methodology. But we usually use the lecture time when most of our group members presented to discuss specific features and effects of our game to ensure everyone agrees on the decision. Since we have sort of sub-teams on different aspects of the game, we also discussed some issues within sub-team discord or in person to get a final answer.
Which aspects of the implementation were more difficult than you expected, and which were easier? Why?
Ashley: Collision was definitely more difficult than I expected. When I signed up for it, I didn’t know there would be a hexagon maze, and I didn’t know the way we generated the maze (by transforming squares) would make the collision so difficult.
Manshi: Designing the game data object is challenging since it is totally possible that the data structure will be modified to accommodate more functionality. So be aware that serialization and deserialization should be flexible and easy to change correspondingly. The networking implementation is actually easier than I expected. Probably because I drew the network logic graph before I started coding so that I was confident the logic works fine.
Yucheng: Model loading, animation loading, and texture mapping. I haven’t taken any graphics courses before so I have to learn from the beginning. Rigging and skeleton animation is way easier than I thought since we use Adobe Mixamo’s auto rigging which allows us to upload our model and get the animation easily.
Xiaoxiao: Implementing all the essential game engine features in time is hard. Collision detection is somehow harder than I expected, since the hexagon map (which I generated by transforming squares) messed up the aabb collision detection. Particle effects are easier than I expected after I fully understand the logic.
Jiahui: The audio were much easier than I thought. By using SoLoud library, we can easily play our amazing tracks in the game. I guess SoLoud is powerful enough for our game but the most difficult part of audio is how to link our project to the SoLoud library.
Which aspects of the project are you particularly proud of? Why?
Ashley: The gameplay. The art. The music. All of these are very unique. Also how early we managed to get the network connected.
Yucheng: Ashley is right!
Xiaoxiao: Ashley is right!
Manshi: Ashley is right!
Yingkai: Ashley is right!
Jiahui: Yingkai is right!
Zhiying: CEO is right!
What was the most difficult software problem you faced, and how did you overcome it (if you did)?
Yucheng: Actually, the most difficult software problem is Visual Studio itself. In the first week, we are having a lot of trouble linking all the libs that we need into our game engine. In the other courses I took here at UCSD, the environment is set up for students and all we need to do is to code. This time, things are quite different since we are building and integrating everything from scratch. I spent the entire week 1 configuring all the environments in the game engine. Luckily, I was able to pack all the dependencies into our project which makes the game portable between windows computers.
Yingkai: The most difficult problem I faced was being unknowledgeable in major aspects of how our graphics code worked after I was done helping with networking tasks. I really just overcame it by asking the highly proficient members of our team many questions to fill in my knowledge gaps.
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++ 😄
Yingkai: Once we all agreed on Visual Studio 2022 it was smooth sailing from there 😀
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.
Network::Client: 704
Network::Server: 1,782
GameEngine: 9,910
Total: 12396
We used a vscode extension called VS code counter to count the code.
In developing the media content for your project, you relied upon a number of tools ranging from the underlying graphics libraries to modeling software. And you likely did some troubleshooting to make it all work. So that students in future years can benefit from what you learned, please detail your tool chain for modeling, exporting, and loading meshes, textures, and animations. Be specific about the tools and versions, any non-obvious steps you had to take to make it work (e.g., exporting from the tool in a specific manner), and any features or operations you specifically had to avoid — in other words, imagine that you were tutoring someone on how to use the toolchain you used to make it all work. Also, for the tools you did use, what is your opinion of them? Would you use them again, or look elsewhere? Are there any tools that you used but, looking back, you would avoid?
Zhiying: In the aspect of workflow of modeling, the most important aspect is the animation and skeleton of the model. Be sure to first think of the number and placement of the skeletons before starting the model after wise it’s hard to make changes.
Yucheng: We relied on a lot of tools to build our media content. We use blender to build the 3D model. Texture baking was a very complex task for us so we used a blender extension called SimpleBake to automatically do the UV mapping and baking. We also used Mixamo, a website that can auto-rig the model and apply the animation. All those tools were very helpful and I strongly recommend anyone who want to use blender to try.
Would you have rather started with a game engine or would you still prefer to work from scratch?
Yucheng: I would say I will use a game engine instead of writing one from scratch. In this quarter, we did implement a lot of features that a game engine should have, but our game engine is still very naive in terms of optimization and performance. We spent a lot of time this quarter building the game engine and if we are using a game engine those time could be saved to implement better features in the gameplay. However, building the game engine is definitely a unique experience for all of us.
For those who used a networking library (e.g., RakNet or Boost), a physics library (e.g., Rapier or Bullet), an audio library (e.g., SFML or SoLoud), or a GUI library (e.g., imgui or nanovg), which libraries did you use and would you use them again if you were starting over knowing what you know now? Describe any lessons you learned using it (problems that you had to troubleshoot and how you addressed them) for future groups who may use it. If you did not use a library for any of those modules, judging from the experiences of the groups that did, would you have used it in retrospect?
Manshi: For network, we did not use a networking library. After Jiahui and Yingkai finished the first version of serialization and deserialization, I found the code is actually easy to understand and modified (shout out to Jiahui and Yingkai for writing such maintainable and adjustable code). Later even we made many changes to the data structures, I could do simple modifications on my own. So I would still choose not to use a networking library in retrospect.
Xiaoxiao: For the graphic engine, we do not use any physics library or GUI library. Since we decided to do a tile-based map, we decided to do physics all on our own, however, since the map is a hexagon, I used bounding boxes which are in parallelograms to do the collision detection in order to have a better visual effect. We decided to not use a specific font library for GUI, just use images binding to the UI element. Since the physics and GUI design in our game is not that complicated, I would not use libraries in retrospect.
Yingkai: We used existing default WinSock functions to roll our own network. I have no clue about the comparison to using a more comprehensive library like boost, but it was somewhat simple to add more features on top to our networking system when necessary. It was also pretty easy to get started just by googling WinSock code as there are online tutorials with template code.
Jiahui: For audio, we used SoLoud library, which is very powerful and I think it is good enough for general 3D games. If you do not have better choice, just use it. However, make sure you read the document carefully before start using the methods. Otherwise, your audio will be weird and you won’t know how to debug.
For your group web pages, the groups this year used notion rather than hosting on the cse125.ucsd.edu server with wordpress. Were you satisfied with notion, or would you rather have used some other system for maintaining your group web pages? Is there another system would you have preferred to use (or even just doing everything on your own using HTML, CSS, and JavaScript)?
Manshi: I have to admit that I am not that familiar with WordPress. And it seems not so reliable since after I made a change to the address of the website, I suddenly could not even log in. So we decide to go with the notion website which is straightforward and simple to maintain.
Yingkai: Notion was so easy I love it 😄
Jack: Notion was a suggestion I had in the beginning because I had experience with it from other projects and I will say it is one of the most powerful tools I've used to organize files, docs, and ideas to this day! I web page probably would of been a bit more work as we would have to create a lot of the functionality ourselves which would take more time away from our game.
This is the third year we've used a discord server for the class. Would you recommend that we continue using discord in the future?
Yucheng: Discord is great for the course. It’s very flexible and we can communicate using it. Also, we shared a lot of game resources (images, models, blender projects) through Discord.
Jiahui: Discord is commonly used by students, so I guess most of students have an account, which means discord is a good choice for the class.
Jack: Discord is a great tool, it allowed us to share work to each other very easily and organize our thoughts into separate threads and channels. Plus everyone has discord so its nice and easy to get it all set up.
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?
Xiaoxiao: writing readable codes and communicating on progress are way more important than I expected.
Manshi: Finding a time during which every group member is available is important. Keep everyone in the loop is extremely helpful to follow our schedule in the project spec 😃
Ashley: Make sure you’re communicating clearly and don’t assume that people understood everything in the same way as you do - especially if you’re doing something original.
Yingkai: It can be hard to give out separate parts then tie them together properly, so it was really helpful for us to spend extended durations of time discussing features in terms of what we want the end result to be and how we should cleanly implement each feature.
Jack: Communication is key, being in the loop is needed or you will fall behind and not understand what is happening in the game anymore. Taking more time to catch up and orient yourself.
Looking back over the past 10 weeks, is there anything you would do differently, and what would you do again in the same situation?
Manshi: I was really glad that I drew the network graph before implementing it. It is also easy for me later in the project when we decided to add extra steps in the networking. I could just grab the graph and add several lines to it to make sure I did not miss anything or did something wrong.
Yingkai: Manshi did a great networking graph.
Jiahui: When I wanted to use other member’s methods, I usually directly used them after I knew how to use them. However, in fact I should understand how the code work before using them, in order to avoid issues, such as memory leak.
Jack: I would of liked to get an earlier start on music, producing full demos by week 3 so I could take a lot more time mastering the sound track of the game and making sure it sounds as good as it can on loud speakers
Which courses at UCSD do you think best prepared you for CSE 125?
Yucheng: CSE110, CSE120, ECE141
Manshi: CSE167, CSE120/CSE221, CSE123
Ashley: CSE100, CSE110, CSE120
Xiaoxiao: CSE169, MATH155A, CSE123, CSE120
Yingkai: CSE 100 gave me sufficient C++ prep
Jiahui: CSE 100, CSE 110, CSE 120, CSE 123
Jack: CSE 167, CSE 110, MUS174ABC, CSE 100
Zhiying: VIS 133 and my beloved YouTube
What were the most valuable things that you learned in the class?
Yucheng: Working in a complex project. How to write code that is readable by others and easy to update and maintain.
Manshi: Version control is soooo important. Thank Yucheng for teaching me Git skills!
Xiaoxiao: Version control is soooo important. Thank Yucheng and Ashley for teaching me Git skills!
Jiahui: I learned a lot from the course and from my group members. I guess the most valuable things are the knowledge about graphics and modeling.
Jack: I learned a lot more about producing music and making it fit into a theme. As well as how a game engine from scratch is built using OpenGL.
4 Final Screenshots
For the pizza celebration after the demos, what do you think about doing it in the B220 lab? (I originally thought to avoid any more time in the lab :-) Some students pointed out that if we do it in the lab, then people can play each other's games.
Manshi: It would be fine doing that in the lab! I would like to try other groups’ games 😊
Yingkai: Pizza was very tasty. Wouldn’t mind being in the lab for it.
Zhiying: Love the pizza! Anywhere is great!
What advice/tips/suggestions would you give students who will take the course next year?
Manshi: COME TO CLASS. Although there’s no lecture besides the first two weeks, it is still worth spending more time together with teammates, either in the aspect of making new friends or making good progress.
Yingkai: To not be intimidated by the challenge of creating a large project as it’s a great opportunity to learn new things and be involved in one of the more practical CSE courses.
Do you have any suggestions for improving the course?
Maybe having some other snacks during the pizza celebration, some of our group members are lactose intolerant 😠ðŸ˜
I think we should have more snacks 100%
Any other comments or feedback?
Zhiying: We made it!!!!!! Love you all!!!