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?

Our game concept did not change that much from our initial idea. We stuck with the space tower defense about a planet where players would defend the planet from enemy spaceships. However, we did end up spawning enemy spaceships from the planet instead of outer space due to time limitations. We also did not get to creating classes for players where each player would have different abilities and health stats. Instead, we introduced powerups into the game that would be dropped by the enemy spaceships. 

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

We swapped the user spaceship and Geisel spaceships–the Geisel spaceships were supposed to be the player-controlled spaceships, and the current user spaceship was supposed to be the enemy spaceship. The intent was to use Geisel with its all-powerful library of resources to defend the planet; however, we noticed that our game had less lag if we reversed the spaceships. This was because the complexity of the “user” spaceship led to stutters when loading hundreds of them for the waves.

Other small things we introduced were trees on the planet when we didn’t initially plan for any. We also meant to make clouds more transparent and fluffy but did not get to this.

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

Networking / Gameplay:

On the networking and gameplay side, we stayed pretty close to the original schedule. It wasn’t until week 6 that we decided to spend more time on gameplay before our “dev freeze.” The main cause for this difference was we underestimated how long it would take to get a substantial amount of gameplay features done before it was ready to demo. Giving us another week to focus solely on gameplay was perfect, and thankfully, we had a lot of buffer room for the last few weeks we could push into.

Graphics: 

Evan: I think I generally underestimated the amount of time to get basic models rendered (i.e. I didn’t have a full materials system that could render textured models until around Week 4). This probably could have been alleviated by using some of my CSE 167 code, but I decided against that because my CSE 167 code was really gross. Other than that though, I think everything for graphics went pretty close to as scheduled, and I was even able to add some extras like particle effects later on.

Art/3D Modeling: 

Intended to finish 50% of all models by week 3, but this did not happen because we were one person down; there was one week where no model progress was made. The plan to finish spaceship modeling was initially set to week 6, but because we needed this earlier, this was actually the first model made in week 2.

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

A big factor to our success was our regular meetings and openness to ad-hoc calls. We also utilized Discord with separate channels to focus on each aspect of the game (general, networking/gameplay, graphics, modeling); this helped keep a record of what we have completed in each area, and easily communicate across subteams. Another big factor was our choice to separate rendering code from gameplay/network code. It paid dividends in our productivity since it allowed the two subteams to work in parallel without having huge merge conflicts.

As far as methodologies that didn’t end up working, we intended to use GitHub issues but never got around to consistently using these. We used this in week 2, but never followed up with closing issues or attaching them to PRs. Another was merging branches into other branches instead of to main which turned the networking branch into the main branch.

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

Evan: Making sure my renderer was not spaghetti code. Became spaghetti anyway, but my design made a few things harder later. Luckily I didn’t really need those things. Honestly the octree took longer than expected too. 

Easier: idk ez game

On the gameplay side, we did not expect how difficult it would be to implement rotation about a sphere. It seemed like such a simple task during week 1, but ended up taking a few days to get to the place we wanted it. On the other hand, designing a system for a client and server to communicate the state of game objects was not as difficult as we thought it’d be. Moreover, we believe that adding sound would be more complicated than we expected. Turns out it was super straightforward and worked well with our implementation.

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

Evan: I thought the octree turned out pretty nice.

Cora: Really proud of Sun God!!! Thought I would have to get rid of this model because I couldn’t do the Triton Statue at all (too many muscles on that guy), and potentially have to simplify this bird and only end up with an approximate shape. However I actually got to paint its body all-around to be almost exactly like the real one.

Alex: I am really proud of how fun the game turned out to be. Gameplay was definitely a side feature until we got the entire system up and running, so it was hard to tell if all this work would end up paying off or if we’d have a boring game. Seeing all the parts come together and how rapidly we could add game features to tweak the game experience was very satisfying 🙂

Priyal: I am really proud of the clouds 😀 Just kidding, I’m really proud of the fact that the game works. I was very confused going into the class because I knew nothing about game development. The fact that we were able to build this and essentially had week 10 be a free for all feature fest sounds like something my pre-spring quarter self would never believe, so I’m really proud that we got to this point.

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

For all of us, except for Evan, learning how to effectively use Visual Studio was difficult and took some time. It took a lot of Googling and begging Evan to explain to us what was going on to fully set up our project. From external libraries to properly linking files, Visual Studio was a new beast for us and just took time to learn. Once we learned it however, it became a very powerful tool for us and ended up increasing our productivity.

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?

Use Rust or Haskell!!!! Though all jokes aside, any language other than Golang is probably fine.

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.

Language                     files          blank        comment           code

C/C++ Header             42            1344           1364           7660

C++                             39            898            505           3306

GLSL                            21            115             37            294

SUM:                           102           2357           1906          11260

Used tool called cloc, from here https://github.com/AlDanial/cloc, and only had it run on our cpp, h, and glsl files.

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?

Evan (rendering):

  • Loading models -> Assimp: 
    • I had a lovely time using assimp, everything worked great out of the box. Would highly recommend using it, especially because it has a lot of resources online for how to use it. Just make sure you understand how Assimp’s scene tree is structured, and you should be fine (it can get annoying because it was made to be super general, just ignore anything you don’t need). The only caveat is that I have heard of other groups having issues with Assimp when trying to load FBX files, so I might be careful there.
  • Loading Textures -> SBTI: 
    • Also just worked great. Really simple library to include, and you basically must call a single method to load the image into a byte array. The only slightly tricky thing that could arise is to make sure you set your input channels correctly for the image (i.e. whether it is RGB or RGBA), or else SBTI will seg-fault due to an out-of-bounds read. SBTI will also tell you the number of channels when you open the file, so you can easily avoid this in code with an if-statement.
  • Animations -> Didn’t do animations.
  • Sound -> irrKlang: 
    • IrrKlang cpp library is very easy to use and support 3d sounds. Worked well for 3d games! We don’t have any problems with it so far, it seems to work smoothly.

Cora (modeling):
Note that these steps below are intended to be detailed to the fine grain, but rather to supply you with the vocabulary and keywords (that I did not have but wish I knew about earlier on) to search up the application information for your needs.

  • Exporting models (.obj and .mtl):
    • Before you export, make sure your model is centered to world origin in Blender, and not just have the origin set to the center of mass/geometry 
    • Export selection only, mark the checkboxes for both .obj and .mtl, but do not mark the checkbox for .obj groups — this will take forever to export and give you like 100 duplicates of the same file (to this day I still do not know what this does)
    • Do your models look fine in Blender and any preview application, but look transparent/have incorrect textures in game? 
      • Select your model, hit the tab key to enter edit mode, hit option + n, and recalculate normals to face outside.
      • I did not know what to google for this at all and had a kind soul on the internet come to my aid.
  • Baking textures (.png):
    • Enter editing mode, unwrap the object using smart UV unwrap. It also helps to set your viewing mode to UV Editing so you can see the UV map and object side-by-side.
    • Change the object view to the shader editor, and add an Image Texture node for every material that you use so that each material will be exported into the final baked texture. Set the image of the Image Texture node to be the same image file.
    • The render engine must be set to Cycles and not the default Eevee to be able to bake textures, and have the option to bake appear in Blender.
    • Once you have all of the above set up, you can hit bake (after selecting what kind of texture to bake; the only ones we needed were a combination of combined, normals, diffuse) and wait for your texture to be consolidated into a 2d image. After the baking process is complete, make sure to save the image file as a .png.
    • For each texture listed in the .mtl file, add `map_Kd <file path respective to project root dir.png>` to attach the texture to the corresponding material area.

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

Evan: I mean I am a sucker for systems, so I am always down to start from scratch. I think it is a lot more fun than using something like Unity, because at that point the limiting factor for me is my art skills.

Alex: As someone who has used various game engines likes Unity and Unreal, I think working from scratch is still better. If it wasn’t for this course, I probably would have never had the chance to write something from the ground up. I’ve learned a lot this quarter from having no pre-made luxuries and having to make everything ourselves. While it may not be as good as Unity’s game engine, it worked for us and taught valuable skills for the future. There are so many great tutorials online to learn these game engines that people can follow, but building a game engine from scratch is something you may never get the opportunity to do, plus it is much more impressive.

Priyal: Definitely from scratch. The amount of things I learned through the project are incredible. Not only did I learn coding skills, but I also learned effective communication and how to navigate online forums to find the one deeply buried correct answer. Not to say that all this wouldn’t have happened if we used a game engine, but I am a lot more confident in my abilities now and also know that the game is entirely our creation.

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?

For network libraries, we used the Asio C++ library. The library is pretty straightforward to set up and the Youtube tutorial from javidx9 about setting up the network is really useful. One of the most important network lessons that we got was to set up the synchronization correctly. The Asio library was a great middle ground between giving us the ability to deal with lower level implementations, while also not going as low as TCP connections and completely raw sockets. Overall, we recommend the Asio library and the tutorial by javidx9. 

We did not use a physics library and a GUI library.

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

We thought WordPress was pretty great. The only slightly annoying thing was the image issue we had where we could only insert images by copying and pasting, not uploading. We could probably have solved this with a bit more research, but once we found a solution. Other than that issue, it was great to be able to easily copy-paste the reports we made on Google Docs (including the styling). If we had a choice, we’d probably use another system similar to WordPress, like Wix.

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

We loved the class Discord, please keep it for future iterations of the class! Like mentioned above in what made tooling/communication work out for our team, having a Discord setup provides a great place to keep persistent links, post screenshots to celebrate mistakes or surprises. Overall, it is a great place to keep your teammates in the loop and have a transparent working process.

We also really liked the demo machine queueing system and you gotta meme on the haters voelkerWHAT!

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

Despite the difficulties of having to do everything remotely, Zoom was awesome. Some people used liveshare, but didn’t really work for us. It would glitch out everywhere causing inconsistencies in the code shown on the two screens. As expected, Git helped deal with collaboration issues well. Additionally, asking each other to hop on quick calls on Discord voice channels, letting teammates know if you can’t get to something by x time or what time you plan to deliver by (so that you don’t have unknown dependencies that go unaddressed within your team) was great for communication.

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?

It is important to meet often, and to meet early. Also make sure to over-predict rather than under-predicting. We also learned that it is important to leverage the diversity of your team, everyone has their own specialties so it’s important to make a plan and assign tasks that considers your team’s strengths.

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

We think overall it was good! The main thing we would change is to  set up expectations on course workload earlier so that people don’t have to drop. We would also update the schedule so that we have a better gauge of our speed and ability. And, obviously, implement the rainbow shader in week 1.

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

Evan: CSE 12 (Godly Gary Version), CSE 120, CSE 123, CSE 167. Honestly, I think it is a shame that there isn’t a class that teaches modern C++ other than the tiny bit I learned in Gary’s CSE 12, cause I think that would help a lot of students. Specifically, we ran into a bug early on when implementing our Mesh class where the meshes wouldn’t render at all sometimes, even though we were creating them correctly. Turned out the issue was because the copy-assignment operator was calling the destructor on the Mesh object being copied, which would then deallocate the Vertex Array Object and Vertex Buffer Objects in OpenGL. Honestly, that bug would have been a nightmare to debug if I didn’t know about all the implicit calls in C++.

Alex: Have to agree with Evan: CSE 120, CSE 123, CSE 167. I used a little of each class in multiple aspects on this project. Having a broad spectrum of knowledge also helped with working on different parts of the project and integrating features together.

Priyal: CSE 120, CSE 123 and CSE 124. Networking was made so much easier because I had the basics and the vocabulary down. CSE 123 also helped because we wrote our own marshalling and unmarshalling code for the network, and that’s something that we wouldn’t have thought of if it weren’t for CSE 123. And to my biggest surprise, we used synchronization primitives in the game, so CSE 120 came in handy 🙂

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

Evan:

  • Don’t use raw pointers, no matter how much Alex wants you to. 
  • Start early, start often

Alex:

  • When planning a project schedule, it is important to incorporate buffer days into the plan. Although some features may be finished quicker than expected, there will definitely be some that take longer. 
  • I gained a valueless amount of knowledge on how to write ‘modern’ C++, as coined by Evan. I’ve taken other classes where I’ve learned how to write C++ code, but I’ve never had the opportunity to make such a large scale project with it and apply modern features.

Priyal:

  • Talk to your teammates about every small detail!!! It will help prevent gruesome debugging down the line.
  • Things about how C++ and the ASIO library work, though I am not sure if I necessarily wanted to learn this.

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


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

Evan:

  • Please please please brush up on your C++ (or write your game in a superior language like Rust or Haskell)
  • Have fun! Writing code is much more enjoyable when you don’t have huge deadlines or have to follow an assignment spec. Don’t treat working on the game as work, but as a fun challenge.


Cora:

  • If you come in without any modeling knowledge or experience, don’t start off making a model; start off with a Blender crash course! Takes only 3 hours — set aside an afternoon/evening and you’ll get through the whole thing. This is an amazing one: https://www.udemy.com/course/blender-crash-course/

Carlos:

  • If you need some guidance/tutorial for game networking, watch this tutorial: https://www.youtube.com/watch?v=2hNdkYInj4g. It is based on the Asio C++ networking library. It is handy for setting up your first echo server!

Alex: 

  • Be prepared to dedicate a large amount of your time to this course! I purposely planned to have a very light quarter when taking this class so I could focus as much time as needed into it. This course is much more enjoyable when you can focus on having fun when coding rather than worrying about getting features complete by a deadline.
  • I’m not sure if Evan will agree with this, but it’s keeping the game together so he can’t complain too much (also I peaked at his rendering code and yikes something happened after week 6). It’s okay to find a hacky solution sometimes, especially when it won’t affect your code later down the line or isn’t essential. I know we all want to write code that is perfect, but we are, after all, only given 10 weeks to make a giant project.

Priyal:

  • Don’t be intimidated by the complexity of the project. Just focus on your weekly tasks and trying to achieve them. You will be there in no time (quite literally…).
  • Sometimes it’s better to have things working than having them be perfect. It’s okay to have a collision detection system that is 70% accurate and moving on to implementing other aspects of gameplay. You can always make things more refined if you have time, but it’s hard to implement something from scratch when you have to demo in 2 days.

How can the course be improved for next year?

Evan:

  • I think something that needs to be abundantly clear is:
    • 1. Graphics != Art
      • Maybe instead of saying “Graphics”, say “Rendering” because it sounds less cool and more technical
      • The biggest reason I say this is it seemed like there was some confusion at the beginning of the course about exactly what “Graphics” meant (i.e. was it art vs rendering).
        • (+1 from Cora; sorry we ended up roping you into doing graphics because of this misunderstanding Evan! but you did an amazing job <3)
    • 2. Graphics is hard, don’t try to learn it during this course
      • Because this is a game, getting a really basic rendering pipeline going should be one of, if not the first thing done. This will only take a couple of days if you already took 167, but if you didn’t, it could take weeks ….

Cora:

  • Make it easier to find past reports from past teams on the course website by explicitly providing a link to https://cse125.ucsd.edu/ in initial course logistics and not just https://cse125.ucsd.edu/<year>; did not know until now that is where we find past reports/would have been helpful to read and lurk in these out of boredom, especially to learn about modeling since I did not have past experience

Alex:

  • Our team ended up working out really well, but I did hear some experiences of other teams struggling with technical aspects, specifically rendering. I could tell there was some management at the beginning of the course to help prevent this, and I think it did help a lot. I think it wouldn’t be a bad idea to double down on this and ensure every team is equipped enough to achieve their goals.

Any other comments or feedback?

Evan:

Cora:

  • thanks for making and maintaining this course all these past 21 years; it has been an amazing experience being able to actually make something that we can not only show to friends and family but also have them interact with:)