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?
In the end, the overall project remained the same, staying as a third-person cooperative tower defense game on Mars. However, we did need to adjust the ways certain features were implemented due to technical challenges.
Design: How does your final project design compare to the initial design, and what are the reasons for the differences, if any?
The game design closely resembled what we intended initially. We kept the resource collection and tower placing aspects that we initially planned to do. The major differences were really added-on features, such as the increased focus on the rover shooting and the inclusion of powerups.
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.)
We mainly stayed ahead on everything except for UI. [Vladimir] For UI the timeline got flipped where the implementation took a lot more time the intended and polishing took a lot less time the intended.
What software methodology and group mechanics decisions worked out well, and which ones (if any) did not? Why?
The group mechanics worked out great. The were of course some small issues with implementation, however, the group was able to overcome and usually, those challenges led to better implementations.
Which aspects of the implementation were more difficult than you expected, and which were easier? Why?
UI: UI was supposed to be something that would be easy to implement, but hard to polish. In the end implementation took a lot more time. [Vladimir] There were a lot of issues with rendering and positioning that required workarounds to make it work, which in turn made the simple actions like putting a label in the correct place a much more tedious and difficult task, in comparison tasks that initially seemed hard like button connections and their cross talk were easy and quick to do and implement.
Networking: Some aspects were easier since the website had a helpful guide on how to implement the basics of networking using winsock which we followed. However attempting something more advanced like managing the partial packets since the client is operating with no consistent tick-rate we struggled a bit making our own solutions.
Game Logic: Game Logic was probably one of the easier aspects of our game. We built our game on the concept known as the Entity Component System (ECS), which turned out to work really well. Many of the high level ideas of how enemy AI would work translated well into the ECS and the code felt decoupled enough that bugs were not super hard to find and fix.
Physics: A simple physics system was easier than expect since the Game Logic infrastructure (ECS) was extendeble enough to add collision detection in a straightforward way. We did have to add an event system for collision resolution.
Graphics: Learning how to properly import and render Blender objects with their respective materials and textures proved a bit more complex than I had anticipated. There were a number of different formats that I had to learn such as how assimp imports Blender objects into meshes and models and then set things up such that we’re able to render them. Alternatively, it was pretty straight forward to setup a skybox and create the infrastructure for GUI elements since rendering squares and mapping textures to them was something that I had done in the past.
Which aspects of the project are you particularly proud of? Why?
Our game has a lot of features, many of them are noticeable like power ups and building selection, some are hidden like the adjustable pathing and statistic collection. However all of the features work seamlessly and are not a gimmick. They all serve an actual purpose and have some impact on the game and the player.
[Patrick] I’m most proud of the powerup system. Though it was implemented very late in the process, I feel it made the game a lot more fun.
[Jeannelle] I’m super proud of how many features we were able to implement in this game. It made the game really fun and exciting for the entire 15 minutes or so of gameplay.
[Vladimir] I’m feel really proud about the complexity and the idea of our project. And that aspects of the game that were the hardest to implement are not noticeable(In a good way). Personally, I am proud that the UI came out to be seamless and easy to understand, that its not overloaded with information, but at the same time it provides you with all of the essentials.
[Sahil] I am really proud of the final optimized collision implemented near the end. It was really cool to reduce the basic O(n^2) to O(nlogn) and seeing the performance increase directly in the gameplay.
[William] I am proud of the refactored object-loading code that Cory and I worked on. It heavily optimized the client-side graphics engine and enabled us to render the large number of objects that were in the game.
[Cory] Same as William, I think our refactored rendering code was one of the best investments we made and it allowed for the addition of different models with just 2 lines of code. This allowed us to go from maybe 6-7 models to maybe 30 different models very easily. I’m also really proud of the particle system that I implemented in the last few days of the project and the effects were better than I initially imagined.
What was the most difficult software problem you faced, and how did you overcome it (if you did)?
[Vladimir] UI rendering. UI rendering had an onslaught of weird behaviors. The issue was not solving one particular bug/issue, but the fact that one issue got replaced by another and the another. Even at the very end we had multiple UI features that were ready, but just did not render on the screen. Each time the we fixed and issue it felt like we were treating a symptom not the illness. In the end, were came up with multiple workarounds(greenscreen effect, manual relative positioning, new naming and sizing practices ) that gave us the ability to create a great looking UI, at the expense of some features.
[Patrick & Sahil] The biggest issue we faced was a bug where all of a sudden the client would crash, and we had no idea why. We quickly figured out that it was a bug in networking when we would be sending too much data that we overwrote the local buffer that held all of the network data. We fixed this by implementing some checks to determine if a data packet was being cut off, and reconstructing the packet the next time data was received. We never really tackled the core of the issue though, and still had some back, malformed packets (which we just ignored), even on demo day.
[William] The biggest issue that I faced was definitely when I couldn’t get our model loading code to properly render Blender objects. It was difficult to debug and pinpoint the issue since there were so many different elements in the graphics rendering pipeline. At the end of the day, I was able to overcome this software problem by trying a lot of different things and carefully dissecting my code logic. For example, one of the fixes was simply configuring stb_image to process textures with the vertical axis flipped or not.
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?
N/A, we ended up using C++.
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.
We wrote a total of 10,032 lines of code. This number was calculated by looking at the last line of each file in our main branch that was NOT a library file. Keep in mind this total includes white space, comments, and lines that are just a single curly brace.
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?
[Jeannelle] For whoever is going to be making the 3D models (we used Blender), I recommend being in constant contact with the people implementing the graphics engine. It helps to know if the materials and textures work, and if not, what you can do to fix it. Making the meshes themselves ended up being easier for me personally, and I think the materials are pretty complicated so I highly recommend watching youtube tutorials and getting familiar with how to work with the shader editor and learning how to texture bake. Focus on texture baking the base color first, then worry about texture baking the extra stuff, like roughness or normals, later. I liked Blender, but I also have nothing to compare it to. It’s kind of complicated so good luck to anyone who ends up learning how to use it from scratch for this class!
Would you have rather started with a game engine or would you still prefer to work from scratch?
[Vladimir] For me, it depends on the scale of the project. If I am working on an Indie project, there is no reason for me to create my own engine. Same goes for AAA money printing tittles in those games people do not really care that the final product uses a generic engine underneath. However, if I was working on a game that had the potential to influence the industry in a new direction, the costs would justify the means.
[Dillan] After this experience I still prefer working in a game engine. I understand that starting from scratch can offer a degree of freedom not possible in engines where many decisions are already made for you, but I don’t think our 10 week experience was quite enough time to really explore this and reap its benefits. Nonetheless I still enjoyed the experience of starting from scratch for the first time.
[Jeannelle] I would prefer to work with a game engine. I think starting from scratch could help you learn a lot especially in terms of taking this class, but with the availability of so many game engines I don’t think it’s necessary to start from scratch.
[William] I would prefer to start from scratch. While we are by no means doing everything from scratch as evident by our use of different libraries, I think building everything ourselves in this class gives us a greater sense of ownership over the code that we write. I’ve also gotten a better sense of what constitutes a game engine to begin with.
[Patrick] I feel that would have preferred working with a game engine, mainly because I don’t really have experience using them, and would’ve liked to explore how things are “supposed” to be done. I also feel that for a project on such a short timescale like this one, working to make a game from a game engine feel unique and distinct would’ve been a fun challenge.
[Sahil] I preferred working from scratch because I liked learning about how a networked games runs from the ground up. Since I already had experience with game engines this was a new experience how how something like a game engine could be built.
[Cory] I really enjoyed working from scratch as it gave me a better appreciation of the smaller things implemented in games. It also gave me a better understanding of the role of game engines and how they work. I think this class is so great and the project was so fun because it was from scratch. It would also be cool if there was a follow up class where an even bigger system is created using more available tools like game engines.
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?
Networking: For networking, we used winsock. For the implementation, we followed the tutorial on the CSE 125 website, occasionally looking at the official winsock API for understanding when we needed to. The simple network implementation worked until we ended up sending too much data that it filled up the data buffers. To fix this, we implemented some simple checks to determine if a packet was cut off, and process it correctly from there. [Patrick] If we started again, I might try a different networking library that could handle the issues, or at least detect them and throw an error.
Physics: [Sahil] I think for our project a physics library would have been overkill. All the physics we wanted to simulated consisted of collisions, and we didn’t really care about realistic collision where things bounce. Hearing from other groups, many physics engines have lots of overhead that I believe would counteract the benefits in a project this size. This made it a good learning experience as well.
Audio: [Patrick] For the audio, I chose to use FMOD with the core API based on the final reports of previous groups. It was simple to implement using the getting started white paper (https://www.fmod.com/docs/2.00/api/white-papers-getting-started.html) on their API site. For a simple project like this, where the audio was not too complex and mainly consisted of playing files, I would use it again. FMOD also made it simple to have 3D sound and looping sounds as well.
GUI: [Vladimir] We did not use any libraries. The only thing that I would have done different is to get an image rendering library, to solve all of the issue that we had with UI. Because even now we have 5 more UI features that are ready but are unable to be displayed because of rendering issues.
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)?
[Jeannelle] I am very satisfied with using Notion since it’s easy to use and easy to organize everything. Our pages were very readable and hopefully that made it easier for the professor to understand what we are talking about. I made a template for the weekly reports so we wouldn’t have to make the weekly reports with all the subpages inside every single week which saved a lot of time.
[Patrick] I was satisfied with Notion, it was simple and intuitive to use and learn.
[Vladimir] Notion is decent, but I would still prefer tools like Evernote, that do not have weird issues that we experienced while using notion.
[William] I was also satisfied with Notion. The only caveat with using it this quarter was the problems we had involving running out of space.
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?
[Jeannelle] Yes, I think Discord is awesome! I think it’s very accessible for students, especially students who are avid gamers. I like that we can have separate channels to talk about certain topics and not clog up one chat. And it’s super helpful to have the ability to voice chat and share screens without opening up a whole Zoom meeting.
[Dillan] Yes! Discord offers a lot of convenient features, is free, and most computer science students (especially those interested in video games) will already have an account they frequently use.
[Vladimir] Yes. Discord is currently the easiest and most effective way to communicate with people in college.
[Patrick] Yep.
[Sahil] ^
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?
[Dillan] Personally I felt like it was MUCH easier to message individual people when things came up and globally share progress when milestones were reached than it was to schedule a meeting and have everyone show up at the same time. We kind of subconsciously shifted to doing this over the course of the quarter and it ended up working out pretty well. I think our groups less than 100% attendance at the Tuesdays meetings might reflect this.
[Vladimir] I think that it was much more effective to organize small clusters for each subject as we did. It gave us the opportunity to be much more agile. I think this is what allowed us to be ahead of schedule on the majority of things. The group size itself only offered benefits as it allowed people from one cluster to help out people from another cluster which sped up the project development.
[William] I think it was really beneficial to learn to work with other people who were responsible for features in the game that I had no clue about. This allowed me to be able to fully trust their expertise in merging and fixing that particular feature. On the flip side, working with someone else on a feature can have its pros and cons. In the case of GUI elements, while I built the infrastructure that allowed them to be rendered on screen, Vladimir handled actually using that infrastructure and populating our UI. However, whenever there was a issue with the GUI infrastructure or if there was a feature he wanted, we would have to communicate with each other often and sometimes even wait for the other to patch a bug or add a feature.
[Jeannelle] I think depending on the group that you have it could make or break the difficulty of the project. I was lucky enough to have awesome team members who were easy to communicate with through Discord and they were literally on top of everything. They were very understanding of my circumstances when I had to take a break from the project and that only made me want to work harder and pull through in the end.
Looking back over the past 10 weeks, is there anything you would do differently, and what would you do again in the same situation?
[Jeannelle] I think it would have saved me a lot of time if I made simpler 3D models and then fixed and refined them as I went. I would have also saved time just making a base color texture first (before worrying about normals and roughness) and then moving on to more 3D models. Then once all the 3D models and base color textures were made, I could refine them by learning more about roughness and normals.
[Vladimir] I think we should have started on UI graphics earlier and finished them earlier or we should have used an image rendering library. It would have allowed us to avoid/eliminate rendering issues. Issues that forced us hide or miss out on some features, many of which were ready, but just could get rendered.
[William] In terms of the graphics engine, I think I would have liked to be more consistent in adding more features to it such as better lighting and shadows. Even though, at the end of the quarter, we had a functional graphics engine capable of rendering the game properly, I wanted to be able to create a very visually appealing world to show players.
[Sahil] I’d say taking the long view by implementing a game logic framework first and foremost really helped us later in the quarter when adding new features and I would definetly do it again. However I might use a more flexible system than we did because eventually we had to develop some hacky workarounds to get around our own engine which was annoying. ECS may have been overkill, although maybe our implementation was too restrictive.
Which courses at UCSD do you think best prepared you for CSE 125?
Computer Graphics (CSE 167), Software Engineering (CSE 110), Geometric Computer Graphics (Math 155A), Computer Animation (CSE 169), Networking (CSE 123)
What were the most valuable things that you learned in the class?
The idea that each team member needed to implement the own solutions, which only they and maybe one or two more people can fully understand. We believe that aspect of our group work is something that we otherwise would only first experience in the industry, not something we could learn in school.