A. In the project review document, start by addressing these main questions:
1. Game concept: How and why did your game concept change from initial concept to what you implemented?
We mainly stuck to our original game concept of fat chickens participating in a game of capture the flag. The game concept as a whole remained intact throughout the project.
2. Design: How does your final project design compare to the initial design, and what are the reasons for the differences, if any?
We originally wanted the chickens to parachute down from the sky. Since this was a “nice-to-have” feature rather than a “need-to-have,” our actual end result was to have chickens fall from the sky instead due to time constraints. We wanted mounts, but we couldn’t make it that far. We dismounted the mount idea. We also wanted a bean stalk where we could have gone to like, another field in the sky. Barbara’s hot tub was stationary, we envisioned it to float higher and to move around.
3. 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.)
The whole team was really behind schedule. I think we simply overestimated everything and miscommunicated too much. I think we planned to have like, moving object block visually present and connected to the server by week 3 or 4 but didn’t get it until week 5. Everyone was still learning how to get things working and I would say that was the slowing point of the project. Animations took a lot longer than we had hoped. Miscommunication of graphics and network side cause some problems. Merging was always a hassle because sometimes we stray away from master branch. Early on, some of us weren’t too pressure and probably didn’t put in 100% work power so some slack built up.
B. Then address these more general questions:
1. What software methodology and group mechanics decisions worked out well, and which ones did not? Why?
We used JIRA, which was helpful for the first half, but as time went on we neglected it. While we used it it was useful to see what everyone was working on, but also to know what we each needed to get individually.
We also used git for our source control, keeping master as the working branch (most of the time :^) ). We also tried to use pull requests as our Code Review, but no code review was actually done and pull requests weren’t a good platform for that either because you can’t really inspect the exact lines of code for good/bad code.
2. Which aspects of the implementation were more difficult than you expected, and which were easier? Why?
[Matt] I ran into a couple issues when implementing animation; I certainly expected it to be a lot easier than it was. One issue was figuring out how to get a file format that would load into our project. Another was the lack of much code implementing animation in Modern OpenGL. When things went wrong I wasn’t sure if it’s because the tutorial was bad or I was doing something wrong in my pipeline so I had to check all my bases. Also it’s stupid that people use row-major matrices. Also, adding shadows was more difficult because I had trouble with using multiple shaders. Modern OpenGL was a lot more difficult than expected, because I knew nothing about shaders.
[John] Bullet had its ups and downs. We had a disaster just before our demo because of the Bullet mesh objects. Collisions with those mesh objects caused our server to crash and David had to hard code our physics objects as static objects really quickly.
[David] Trying to figure out the Bullet physics engine with poor documentation was rather bothersome and took longer than estimated. Unexpected behaviors of the engine caused various problems throughout the project duration, but overall I think the engine really helped with 3d collision detection and handling. Additionally, it was quite an educational experience to write both client and server side projects that were connected through networking. Because of the complexity, team communication and collaboration were definitely more difficult than expected.
[Brian] I think the idea of having two parts to the game (Server/Game) made it really difficult to debug. Networking team didn’t touch the graphical things too much until later on in the quarter. That meant when we started hooking up the two worlds and if bugs were to appear, we would doubt whether it was our networking or graphical. We had a bug that made the bullets graphically appear farther away from us then it was supposed to. We were fairly certain it was network problem but it turned out to be graphical in a spot that John and I would have never looked.
[Phoebe] Animation took way more work than I expected because there weren’t many resources available online to help and it was difficult to debug the shaders we were using. The UI portion of the game also took more than I expected because I used LearnOpenGL to learn how to render text, but the text rendering originated at the bottom lefthand corner of the screen rather than the top left, so I had to spend a lot of time figuring out how to change the vertices matrices so that it would render the way we wanted. I didn’t want to have to use two different coordinate systems for text and 2D sprites because that would get real crazy, real fast.
3. Which aspects of the project are you particularly proud of? Why?
In terms of graphics: animations! They make the game feel more realistic and fun to watch. It also allows you to have the fun of taunting. Also the shadows for the same reason of realism.
[Matt] An object that I really like is the corn maze because it’s a fun location to fight around and hide in.
[John] Other than the whole thing, I like some of the weapons that I implemented. The teleport gun and the egg mine were really cool to do and Bullet actually made the teleport gun really easy to create. There were a lot of other weapon ideas that I had that I didn’t have time for though.
[Brian] I really enjoyed doing the network and actually utilizing CSE 123 in something practical like making a game. Coming up with map ideas was also really fun.
[David] I really liked how the server-side physics was set up with field detection and general collision detection. Also, getting the vertical rotation working so that the player could aim was a nice touch, considering the differences of the camera angle to the chicken.
[Phoebe] I’m super proud of our animation! 🙂 It brings so much more life and character to our game.
4. What was the most difficult software problem you faced, and how did you overcome it (if you did)?
[John] Bullet’s mesh objects crashed our server right before our demo. David had to hard code the physics objects super quickly to get our server stable again. The last hour of making everything stable again was really stressful. We were also stress testing the server and squashing out the last of the crashing bugs while David was getting the physics reimplemented. As that hour of fixing was coming to a close, we just threw David’s stuff in along with our modifications and some of Matt’s modified sound stuff and prayed that it would work during the demo.
[Brian] ^What John said.
[David] It definitely was stressful to deal with the last minute physics engine issue with imported meshes. The clutch fixes with music and hardcoded physics objects were definitely a relief and arguably the most difficult problem given the time span.
5. 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?
6. 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 used wc -l on all files, subtracting files that were totally or mostly unwritten by ourselves.
[Matt] I edited/rewrote a lot of the files that I got from OGLDev because it was terribly written or didn’t fit in our pipeline, so I included that as the count as code I wrote.
7. 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 next year 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?
[Animation, Matt] Models were rigged and animated in Maya, then were exported as FBX files. In our code we loaded the animation files with Assimp, but had to compile it on our own rather than using Nuget’s package of assimp which could not load FBX files. I think we got the latest version of Assimp from their repo (https://github.com/assimp/assimp), using CMake to get our Visual Studio project file. For some reason CMake didn’t work the first time I tried, but it did another day. I don’t know why. Afterward I parsed the Assimp scene into my own AnimatedModel/AnimationPlayer/AnimationMesh classes to handle multiple animations because I don’t think you can put multiple animations in one FBX without some manual delineations for which seconds belong to which animation.
[Textures] Models were created in Maya and exported as OBJ files.
[Modeling, Matt] One issue we had was trying to display our models at a certain location, but it didn’t seems to be there and that was because the models were not centered on the origin, but offset for the sake of creating a map. Translate models in your model matrices.
[Audio, Matt] I used Simple and Fast Multimedia Library (SFML) for audio. It was simple and fast, but I needed my audio to be in wav/ogg format and in mono rather than stereo in order to have spatialized sounds.
8. Would you have rather started with a game engine or would you still prefer to work from scratch?
[Michelle] I liked that we worked from scratch because we learned how to do everything from the ground up.
[John] I’ve never used a game engine, so I have nothing to compare this experience to, but I would think that there are advantages to both. Building from scratch is a ton of work, but it’s easier to do what you want since you’re building the framework. Using an engine can cause trouble since the engine might not let you do what you want to do and you would have to fight against the engine. I would just say it depends on what kind of project I want to do.
[Matt] Working from scratch is a lot of work, but rewarding. At the same time you get some messy code that could be written and designed better and unless you’re really good you’ll need to refactor your pipeline, which could be painful.
[Brian] I think working completely from scratch was very difficult and confusing at first. I like how we ended up doing things and it worked out well in the end. I wouldn’t mind seeing how the game engine scene would work so I utilize it in the future if necessary.
[David] I think that it was very rewarding to work from scratch and have more customizable choice in the physics and graphics portions. Doing this project definitely gave me an appreciation for what game engines provide, and so I’m very glad to have experienced working from scratch; I would still prefer working from scratch for the experience and customization power.
[Phoebe] I love that we were able to start from scratch and really understand how the whole system works in a networked game, but if I were to make the game again or make a new game, I’d use a game engine because it’d allow us to do so much more in the same amount of time, not having to reinvent the wheel.
9. For those who used a networking library (e.g., RakNet or Boost) or physics library (e.g., Bullet), 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?
[Brian] For networking, we used WinSock which was provided as a skeleton code by the professor. I personally would use the WinSock code again. We had to set up packet types and structures which was really interesting. John and I learned this from 123 which was really helpful. After the initial setup of WinSock, we really didn’t know how to have code to actually work over the internet like using sockets and IP. The skeleton handled that really well for us. I would like to learn how to set that up myself eventually and get it to work on other operating systems. After working with the physics engine Bullet, it made it easy to see how stuff should be done like handling physical objects like planes or rigid bodies. I originally wanted to start with a self built physics engine, but we defaulted to bullet. It has brought a lot of insight and would love to make our own in the future. For bullet, don’t use mesh objects to represent OBJ files.
10. 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?
We had all taken CSE 110: Software Engineering in which we developed a mobile application in a team of 10, so we had each worked in a large group before. However, this experience was better because we have now developed different skill sets from classes (graphics, networks, etc) and could bring a lot more to the table prior to the start of development. We learned that when there are subteams working on different parts of the game (server side and client side), it’s important to often go over each part so that we can integrate them seamlessly. At times, there were delays in integrating branches (such as between physics & graphics, and
11. Looking back over the past 10 weeks, how would you do things differently, and what would you do again in the same situation?
[John] Where do I even start? There are a lot of things I would do differently. I’ll just mention one thing. The server side architecture wasn’t planned out very well and we kind of put hack on top of hack when building it. It made things difficult to do without refactoring. We had some god classes that had methods that could have been and should have been modularized. I would say planning is the biggest thing that we lacked and it came back and bit us.
[Brian] When John mentioned how he planned everything out from the very beginning for a separate project and how well it flowed out throughout the project’s span, I would have had a solid plan and map of how everything should have been laid out. I suppose it would have been hard if new ideas were to pop up though if we spent a solid time talking about it then it would have been better.
[Matt] A lot of me is frustrated that animation took so long and part of me thinks that it was because Phoebe had no background in graphics (though I appreciated her work), but as she tried to debug it it wasn’t getting better, and maybe worse. So I wish I could have worked on animation first.
[Michelle] I would have scheduled more team meetings to work together in the lab.
[Phoebe] I agree with Matt that it wasn’t the best to have me work on getting animations running since I had no experience with graphics – it would’ve been better if Matt or Michelle had been tasked with that responsibility. I think we would’ve saved a lot more time.
[David] I think communication and a solid understanding of the project goals could have been improved. Certain design decisions were implemented without additional features in mind that were decided or imagined later. Having a more set and defined project idea would have helped initial implementation of the classes, and would have made later work much easier.
12. Which courses at UCSD do you think best prepared you for CSE 125?
[Michelle] CSE 167, 168, and 169 prepared us for implementing graphics into our game.
[Matt] +1 to Michelle’s response. Also for the experience in writing C++ code.
[Brian] CSE 123 really helped with the networking aspect of our game. I thought it was
really helpful to set up the network and understand packet structures. I suppose CSE 110 could
be helpful if you had an nice experience with it for a team.
[John] 123 was helpful for networking. 120 helped with identifying and dealing with any race conditions due to the networking.
[Phoebe] CSE 120 and 123 was useful for the networking side, and COGS 121 helped with our UI and menu design and working on a project at an extremely fast pace.
[David] CSE 123 helped with my understanding of networking, CSE 131 helped me deal with horrible Bullet documentation, and some aspects of CSE 110 and 120 helped with semaphores and design decisions.
13. What was the most important thing that you learned in the class?
[Brian] The power of friendship.
[John] The power of planning and the lackof.
[Michelle] The power of coffee. [John] I didn’t drink any coffee. I am powerless 🙁 .
[Matt] How to learn. <- That’s actually a real answer. I think it was good to take on challenges that I didn’t know how to solve and be okay with going into it.
[David] Becoming comfortable with not knowing what you are doing, but learning and doing it anyways. I think it’s a good life lesson that could be applied to a lot of things.
[Phoebe] The power of chickens (and teamwork).
14. Please post four final screenshots of your game on your group pages for posterity. I will display them on the group web page.
C. Finally, if you wish, I would appreciate any feedback on the course (entirely optional):
1. What books did you find helpful that were not on the recommended list but should be? What books were on the recommended list but were not useful and should be removed?
We didn’t really use any of the books :(.
2. I will be teaching this course next Spring. What advice/tips/suggestions would you give students who will take the course next year?
Plan out your software architectures and make sure to communicate between your subteams. Miscommunications made it tricky to merge stuff sometimes and some things were implemented twice because of it.
Sit down, spend a good day or two (More if you need to) and plan everything out your map design (allow room for change, but don’t plan on it), physics structure, weapon hierarchy, everything possible that you can think of. Worst mistake you can make is to think: “We can think of this later when we actually start implementing it.” <- Biggest lie you’ll tell yourself.
Don’t get far from the working branch. If you are, be conscious of what is out of date and what you’re adding. You’ll make merging really difficult if you don’t do that and no one wants to go through that.
[Matt] Also, don’t suck at C++ coding/object oriented design (use keyword “override” when overriding a base class function, delete dynamically allocated memory/use smart pointers, “Don’t repeat yourself” e.g. call your other constructors in your constructors, forward declare classes as much as you can to prevent circular dependencies/long build times, etc.).
3. How can the course be improved for next year
[John] I love how the course is run already. Maybe more guest lectures?
[Brian] The freedom of the course made it really nice. In the beginning of the course, other than the two requirements (3D and multiplayer), nothing else was needed. The support provided via Piazza, in person help from Prof. Voelker and TA, other teams’ help, and books in the cabinet are all helpful. Nothing really needs to be changed in my opinion.
[Matt] I was kind of looking forward to guest lecturers more.
[Phoebe] I think it’s already great. 🙂
[David] I enjoyed the freedom given in the course to succeed and fail on our own, but also the amazing help provided when asked for. If anything to improve, more guest lecturers would have been nice to give ideas or perspectives of relevant projects.
4. Any other comments or feedback
Thanks Prof. Voelker and Ruiqing for the awesome experience! We appreciate the patience and kindness in the food provided to the extra time to fix our code during the demo 🙂 Stay awesome.
[Brian] I love you all.
[David] Thank you so much for this amazing experience to attend the class and work on our own video game project. This really made an amazing last quarter and a huge impact on my entire college career.