Describe your development environment. What tools did you use? What was your build workflow? If you supported multiple platforms (e.g., MacOS and/or Linux), how did you support making your project work on all platforms? Do you have any tips or suggestions for future groups for their development environment?
Most of us used VS Code for development, and we created a Makefile building with MinGW. The demo machines sadly did not like this and insisted on using Visual Studio to build and run (the client at least).
[Hannah] I sadly recommend at least familiarizing yourself with Visual Studio. Even if you do most of your development in VS Code or another IDE, you might end up needing Visual Studio for the demo machines :(
[Vincent] Changing the makefile generator to Visual Studio also generated a solution file which worked for building the project. This is what I used for most of my development. While there was some amount of weirdness with properly setting up the libraries with Visual Studio, I’m pretty sure it didn’t really affect development on VS Code too much - the CMakeFiles worked for both platforms.
What group mechanics decisions worked out well, and which ones (if any) did not? Why?
Making decisions all together worked well since we all got a say in how our game turned out. Making sure we all had a voice helped keep motivation from falling more. We weren’t able to hold ourselves accountable super well when we fell behind schedule, though. Maybe being more communicative about where everyone was in their tasks (such as by having daily or biweekly standup sort of meetings) could have made our progress more transparent and made it easier to get help on a task when any of us were stuck? I think because so many people were working on so many different pieces, it got sort of confusing what people were working on and how far into it they were, which led to some redundant work
Which aspects of the implementation were more difficult than you expected, and which were easier? Why?
Physics and collisions ended up being pretty difficult and taking longer than expected…. I think having the general idea down was okay, but then there were just so many bugs that kept occurring with either setting up the bounding boxes or setting up how certain collisions should occur. I think experimenting with Blender to learn how bounding boxes work and some graphics knowledge would have gone a long way for physics, but we didn’t put enough effort into this early on.
Including audio ended up being easier than expected. We only played one file at a time to avoid needing to use a mixer, so we just had to keep track of what was playing and when a new track should start.
Which aspects of the project are you particularly proud of? Why?
[Hannah] I think I was most proud of the structures of our networking and client/server core modules, at least more toward the beginning of the quarter when these were more organized and we were able to take time to test more thoroughly. I think putting in that effort upfront made it easier to return to those modules later on to debug.
[Jeffrey] I was really proud of the NPCs, I thought creating NPCs and balancing them and having them behave as you want to was a really difficult challenge, but allowed a feeling of cooperation between the players which made our game really fun.
[Suprith] I was really happy about how the art and animations turned out (thank you Sally). Really set the tone for our game and features.
What was the most difficult software problem you faced, and how did you overcome it (if you did)?
The issues we encountered in week 10 (server crashes, random black screens, etc.) were some of the more stressful problems we faced, though they may not be “software” problems per se. In particular, the server crashes were the result of a misuse of our networking module, and we didn’t determine how the other issues came to be and kind of lucked out that they disappeared for the demo.
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?
We mostly used Blender to create the 3d models and exported as FBX files to load into the graphics engine. FBX file format is able to store animations, which is really nice so we sticked to using FBX format for all of our models. Some of the models (e.g. our aliens and NPCs) were created in Nomad, which is a similar 3d modeling software but on Ipads. It’s easier to mold meshes in my opinion since you can use a pencil instead of a mouse [Sally]. But during the export from Nomad to Blender, there may be some difficulty with reserving the colors and materials since Nomad doesn’t support exporting files as FBX.
Assimp was used to load the models and animations into our game. LearnOpenGL has really great tutorials on how to get that set up, [Vincent] but I remember running into a lot of broken links when trying to get to its documentation, I think they’ve changed the location that they’re hosting their documentation on and the old sites were still pretty high on Google search results. Hopefully that’s better by the time other groups work on their projects.
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: Winsock was pretty easy to set up and generally pretty usable, but it would complain about random things that we had no idea to expect before bugs started showing up in seemingly-random parts of the code. Printing or logging the 1xxxx error codes was useful in helping resolve networking problems, but sometimes a problem didn’t throw an error at all and just sent data different from what we intended. Networking ended up causing a couple of our hard-to-find bugs in week 10 that really stalled development for a couple days while we tracked them down. Not sure if this would have been any better with a different library though.
Graphics: Assimp worked fine, though we did have to build the library ourselves, and the only thing I can think of for future groups is to be careful about what aspects of assimp to include as the debug build may result in a library that’s too big to be pushed to GitHub, and also to use the proper preprocessing steps when importing your models. Also, pay attention to the materials on each mesh in your models! Assimp interprets each material as their own mesh, which can result in duplicate meshes with different material properties.
I do wish we used a physics library. Even though building the physics library is cool, ultimately, because we spent so much time getting it to work, we weren’t able to implement all the interesting physics that we wanted to. Spending more time on game features rather than the physics library would have allowed us to work on things that were a lot more fun and interesting I feel. There is a tradeoff with learning and working with libraries for simple functionality, but having a physics library might allow for more interesting game features.
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++)
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.
At our best estimation, we wrote about 5500 lines, when newlines are included. After cloning the repo and deleting files which were unoriginal or not code (such as art or configuration files), here were the results of a line count:
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?
[Hannah] I think my main takeaway regarding group work was in regard to how we match people to tasks based on interest and skillset, as well as how we support each other in our tasks. For example, a few of us were spinning for a weekish on trying to display static images, but when Vincent was able to give it a shot he did it like perfectly the same day lol. Personally I think I found I was better at debugging code that already had a start than I was at researching how to implement new functionality. In general I think we just could’ve gotten “unstuck” on some things faster if we were more communicative and able to help each other when needed.
[Sally] I definitely agree with Hannah’s point. in addition to that, I think we made ~50% of progress on our game during the last week alone because we were all able to come to the lab and work together. I think this is really important for working on such a large project, since we can exchange ideas more freely and help each other out when getting stuck, it’s easier and faster to make progress this way than working mostly individually on different parts.
[Jeffrey] Yeah working together in person definitely is always super productive, but not always possible with everyone’s busy schedule. I think one thing is to not get super pidgeon holed into what you are working on and try to learn a bit of everything. Like Hannah said, we were really struggling with getting static images to work without Vincent, but that was because he was the sole person who developed all of the graphics. Having multiple people understand different parts of the codebase allows more redundancy so when one person is swamped, there is someone else you can ask about what is happening.
[Vincent] Every project I do just makes me more aware of the importance of having a dedicated project manager. It’s hard to be on top of things and be aware of what needs to be done and what’s already being covered by someone else, as well as keeping your team updated on your own progress as well while also actually going and doing the work that’s required. Meeting often is definitely important to make sure that everything is updated, but having a GitHub Projects board was definitely helpful to figure things like that out between them, though it was difficult for us to find the time to keep that board updated throughout the quarter given our already limited time was mostly spent on working on the project itself.
[Sandy] I agree that having an overall project leader is really helpful. They can keep things organized and make sure everyone knows what they're supposed to be doing. It also helps to have clear tasks assigned to each person, so there's no confusion about who's responsible for what. This helps keep the project moving forward smoothly and ensures that everyone is working towards the same goals. I also think meeting in person as a group is great. It makes it easier for us to share ideas and help each other out.
[Suprith] I believe it's a great idea to discuss and collaborate on how we'll implement certain functionalities before we each dive into our dedicated tasks. This way, everyone stays on the same page. When I was working on physics, more involvement with the graphics team from the start would have made better progress (or even taking time to learn fundamentals instead of being isolated would have helped). It's crucial to have multiple people working on features at least in the beginning and to keep up frequent communication about any obstacles and progress.
Looking back over the past 10 weeks, is there anything you would do differently, and what would you do again in the same situation?
[Hannah] I wish we’d started a little stronger with our key building blocks (networking, graphics, physics mainly). I think it was hard to get motivated to do those, so we ended up taking a long time and settling for sometimes disorganiztted code that was hard to use later on.
[Sally] Meeting and working together more frequently.
[Jeffrey] I wish we used a physics library because building the physics engine was so annoying and really wasn’t interesting. We only got to build game features that last couple of days, so it really felt like a slog for much of the quarter. Also, I definitely should’ve been testing our network on multiple computers the entire time, because when you add code, stuff tends to break. Having a more concrete plan of what people are working and splitting labor more efficiently would’ve been helpful too.
[Vincent] Splitting up the graphics work and getting more people familiarized with the graphics code early on. It definitely felt like some features had to wait until I was finished with certain code on the graphics side of things before they could be properly implemented and tested and it really felt bad to be holding back progress especially considering how unexpectedly busy this quarter ended up being for me.
[Sandy] Have more time in the lab with the group to work together, and testing on the demo machines earlier to identify and solve any problems sooner rather than later.
[Suprith] Finding time to work together in person more would have kept each other more accountable. Learning graphics, more communication and collaboration to get physics sorted out sooner.
Which courses at UCSD do you think best prepared you for CSE 125?
[Hannah] CSE 120 was helpful as a somewhat complex project course. I’m not sure about other classes… I think extracurricular projects were most useful to me personally. but very specifically not CSE 110. Awful class.
[Jeffrey] I think CSE 123 was pretty helpful because it helped me better understand networking and packets and what was happening. Also, it just boosted my knowledge in C++ and working with complex code bases.
[Vincent] CSE 167 and CSE168 for sure, not only for the graphics knowledge but, at least when I took 167 with Ravi, makes use of Visual Studio and allows you to really get comfortable with its use in a large project (building a ray-tracer for the final project). CSE 168 is another big project that builds on 167’s final project so it was a great excuse to keep developing in the same environment. These classes allowed me to get really comfortable with C++ and with Visual Studio (I really love its debugger… other things less so), especially since Visual Studio has so much going on with it that it needs the months of experience to even really know what is going on with it.
[Sandy] CSE 167 was helpful as it gave me a great introduction to computer graphics, covering topics like ray tracing and shaders.
What were the most valuable things that you learned in the class?
[Hannah] My number 1 takeaway is how staying organized and building a strong foundation can help make a longer-term and/or larger project easier to maintain.
[Jeffrey] I think the most valuable thing I learned in this class is definitely working in a large group and maintaining a large codebase. Having a billion branches was definitely something we suffered from, but at least there was some method in the madness. Learning how to divvy up work and keeping certain branches clean was incredibly helpful and not something I got to learn in any other class.
[Vincent] That seemingly impossible tasks are usually a lot more possible than they seem. I’d never have imagined it would even be possible to complete a game project for a class without the use of a game engine, let alone in 10 weeks, but the fact that we were able to accomplish such a feat really gives me the confidence to tackle other difficult projects in the future.
[Sandy] Things may not be easy, but taking it step by step makes it achievable!
[Suprith] just getting started no matter how uphill it seems, working with a larger group
Please post four final screenshots of your game on your group pages for posterity. I will display them on the group web page.