A. In the project review document, start by addressing these main questions:
1. 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 concept remained surprisingly stable from beginning to end. Our scope had to be cut down of course (we never implemented certain features, such as tractor beam turrets, and some details changed (the amount of tiles placed at once went from 3x3 to 5x5), but we basically stayed with the core concept of a cooperative team of 4 driving a vehicle, building and repairing said vehicle, and shooting at enemy vehicles.
2. Design: How does your final project design compare to the initial design, and what are the reasons for the differences, if any?
All of the features we considered "Must Have" were implemented, though some a little differently than we originally intended (bullets were more like lasers, tiles were placed as 5x5 rather than 3x3). We got a few of our "Nice to Have" features (randomly generated enemies, boss fights, a sort of death animation), as well. None of our "Cool if Ahead" features were implemented, but there were a few things that we did that we hadn't originally planned, such as different enemy types (beyond regular/boss). Some of the graphics features we originally planned (such as shadow mapping) didn't make it in, and transparency (which wasn't actually planned originally) only partially worked.
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.)
We stayed mostly on schedule throughout the ten weeks. We were able to integrate server and client by week 3, had basic ship and player by week 4. Sound was implemented by then as well so we did not have to worry about it later. We completed all the features we aimed for, except for win and lose conditions, for the minimum viable product. The win and lose conditions were postponed until week 9 while we were improving enemy ships and building off the bare bone features in the MVP. That work spilled into week 8 so we did not get to implement tractor beams and varied terrains. We decided to focus on the features we already had and entered feature freeze at the end of Week 9. For the entirety of week 10, we focused on game play. As the quarter was ending, many of our schedules became filled with work from other classes and responsibilities, so we ended up missing the week 8 features. However, missing the tractor beams gave the driver role the responsibility to collect drops which made the role much more engaging, so it was not much of a loss.
B. Then address these more general questions:
1. What software methodology and group mechanics decisions worked out well, and which ones did not? Why?
[Lo] I think modeling the architecture after Unity components worked really well in making development much easier. The structure we have is similar to the decorator pattern where new features are implemented in new classes and added as a child of the parent object. Adding features to the game became very simple.
[Knapp] I believe pull requests and branching worked out well for us to keep our code separate and prevent bugs from sneaking in through merges that happen on the master branch. Instead, we ensured that the code base on the master branch always ran properly.
2. Which aspects of the implementation were more difficult than you expected, and which were easier? Why?
[Wang] The transform class took a lot of time to iron out all the bugs. Especially since DirectX doesn't have a quaternion class, just a bunch of functions that act on vectors as quaternions. That and getting the quaternion multiplication order right is hard. The jump from glm having column major matrices and DirectX having row major matrices also confused things a lot. And when your testing process is debugging until it looks correct for the case your working on, you are typically left with another bug to fix down the line. The networking was easy to set up starting out, but as the project goes along, and you need to optimize it, you start needing to do more sophisticated things to your data. Animations also came together quite smoothly, minus fbx files not working quite right and trying to multiply and transpose matrices correctly.
[Kimball] Other than the getting the turret camera to work properly (which I handed off to Tim), there's wasn't anything that was significantly more difficult to implement than expected. Graphics was constantly running into bugs and hiccups, but that was expected. Most it (except transparency) was just a matter of sitting down for long enough to figure out a fix or workaround.
[Basiago] Shadow maps. Well, not exactly the shadow map technique itself (which I successfully implemented for a 163 project), but rather doing it in DirectX. I could not for the life of me figure out how to get rendering to a texture to work, despite combing the rastertek tutorials. I greatly underestimated the difficulty of DirectX compared to OpenGL, and wasted too much time stubbornly trying to get it to work (which is why I have no github commits past a certain point >.<)
3. Which aspects of the project are you particularly proud of? Why?
[Lo] I am particularly proud of how fun the game actually is. The gameplay went through a lot of adjustments during the last week thanks to the team and the end product was fast-paced and exhilarating.
[Kimball] I'm seconding Karen's thoughts on this. Our core gameplay worked surprisingly well. In addition, it was kind of interesting that we were the only group to have a strictly PvE game. Only one other project had PvE as a feature at all, but it was still primarily PvP.
[Wang] Ditto on the solid gameplay. I'm also really proud of how solid our engine was designed. This was definitely the cleanest code I've written in a long time.
[Knapp] I was personally really happy with how quickly we could modify the gameplay to try out new balances, gameplay speeds, movement, fire rates, enemy health and spawns. We could try out new ship designs and other features as well pretty quickly which let us focus on playing the game and making it fun.
4. What was the most difficult software problem you faced, and how did you overcome it (if you did)?
[Kimball] Transparency. Getting it to work at all wasn't bad, but I actually never got it working properly. I worked around it by just making sure to render certain things at the very beginning (the skybox) or at the very end (the UI). Everything else just had to hopefully look good enough (which it did, for the most part).
[Basiago] Having primarily developed in OSX throughout school, adjusting to Windows development was a challenge. I constantly ran into problems with Visual Studio.
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?
We used C++, so we didn't run into any language-specific issues outside of the standard C++ ones.
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.
Below is a screenshot of the Github "Contributors" page.
Philip (PsiKnapp) added a library; with those lines subtracted out his number are 717++, 128--
Also, using wc -l *.cpp *.h in each of our 3 VS projects, the line counts are: Client: 7810 Core (used by both Server and Client): 2004 Server: 5473 This includes starter code (which we then modified) from the RasterTek tutorials and Winsock tutorial.
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 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?
[Lo] Although I didn't work on the modeling, I used DirectX for sound. The tutorials for sound from RasterTek are great. Just be careful of sampling rates, file type, and other things the tutorial code checks too specifically. A good way to change these attributes is through Audacity.
[Kimball] The RasterTek tutorials let me set up the basics of DirectX 11 pretty easily. Originally we used the version of Assimp off of NuGet, but that was actually out of date and causing issues, so we got it directly of off Assimp's website. DirectXTex and DirectXTK did most of the heavy lifting with loading in textures (which Phillip made in Substance Painter). For the skybox, I took a set of six images that I found online that formed a skybox, used the Texassemble tool from DirectXTex to convert those into a dds file, then loaded in that.
[Wang] I don't trust Assimp to load fbx files properly, but it seems to handle other file types well enough. Also there's a really good guide on doing skinned animation with Assimp. http://ogldev.atspace.co.uk/www/tutorial38/tutorial38.html Converting it to DirectX wasn't too bad. There is some magic here and there I had to figure out, but it worked out in the end.
[Knapp] I used Blender to do all hard-surface modeling and Sculptris for the humanoid. I export OBJ from Sculptris and manually made it low-rez in Blender. I exported all models that have different textures as different files. That means each texture file had a corresponding obj file and vise-versa. This was so we didn't have to pull material data from files or try to use FBX. We used OBJs for the vast majority of models. I would unwrap them (UV map) in Blender, then export them to Substance Painter where I would texture them using materials supplied or found on the web (which I hand tuned after). I exported those textures along with the model and stored them in object specific folders (Turret-> Turret/Textures). For animated models, I exported to OBJ but I didn't manually rig it. I used Mixamo (Adobe online web software) which auto-rigs and then applies animations to your model. This let me quickly rig and export animations for our humanoid model which were exported as COLLADA ".dae" format.
8. Would you have rather started with a game engine or would you still prefer to work from scratch?
[Lo] Working from scratch simplified the program a lot, but it also meant we needed to be extra organized and structured. Working with a game engine makes it easier to create the game, but also adds complexity and extra features we may not need. Overall, I think I enjoy working from scratch more, but it would be much more difficult to do so alone.
[Kimball] For the purposes of learning new things and challenging myself, I prefered working from scratch. For the purposes of making as good a game as possible, I would have much rathered to have used an engine like Unity. Things that you can take for granted as effectively bug-free are already implemented (basic physics, rendering, object placement), Unity is far better documented that any tool we used, and there's a whole host of tools that you don't necessarily have when working from scratch (like a level editor). We probably could have made a better game than what we had in less than half the time we took if we had used a game engine. The only, drawback, of course, is that we probably would have learned half as much or less. So, despite my complaints about doing things from scratch, I'm actually happy to have done so here.
[Wang] I think as a learning process, starting from scratch is great to get a good understanding of what goes on below the hood. That said, if your goal is to simply make a game, 100% just use a game engine.
[Knapp] Working from scratch was a pain for trying to get something playable and modifiable. There are a lot of bugs to get through before a working game can be made, including excessive amounts of steps to export models and load them in rather than a game engine making it much cleaner. While good as a learning process, for a game, I'd work from a game engine to make it (until I've coded enough changes to the game engine to move on to my own engine).
[Basiago] Game engine for sure.
9. 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?
[Kimball] I actually looked into a few GUI libraries, but couldn't get any of them to work as easily as I was able to hack something together by hand that was good enough for our purposes.
[Wang] Networking went pretty smoothly even with just WinSock. I might want to try out Boost just for fun, but we didn't across any major networking problems so sockets are fine. Although, it is still a mystery to me as to why packets were never split when sending them, even though it should have been larger than the send buffer size.
[Knapp] We used Bullet, but very minimally. I think it worked for what we wanted it to, and importing it wasn't that bad but did take a bit of time (a few hours).
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?
[Lo] I learned to touch base with the team on what to work on each week and to make sure to reach out if I needed help. Early in the project, I was confused about the implementation of a certain feature and it turned out to be really simple once I asked for some explanation. I wish I asked early instead of wasting a lot of time trying to figure it out on my own.
[Kimball] It wasn't so much something I learned as something I was reminded of, but working in the same room at the same time as your teammates is incredibly useful. The team members who tended to be best informed were the ones who spent the most time in the labs.
[Knapp] Communication is key. I think having a group discord was useful to keep in contact and separate different types of communication. Being able to be directly contacted or leaving notes for team members allowed for progress to happen throughout the day since not everyone can always be together. Deciding group goals when everyone was together was also useful to know what we were going to be making and doing moving forward.
11. Looking back over the past 10 weeks, how would you do things differently, and what would you do again in the same situation?
[Kimball] I definitely don't think I did things perfectly, but I don't think my limitations were our processes, but rather my own limited knowledge of what I was working with. If I had to do it again, I would basically do the same thing, just more competently.
12. Which courses at UCSD do you think best prepared you for CSE 125?
[Kimball] CSE 167, CSE 190 (the VR graphics course taught by Jurgen Schulze), and CSE 169
[Wang] CSE 123, CSE 124, CSE 167, CSE 169. I may have chosen my classes specifically for CSE 125.
[Lo] Unlike nearly everyone else in the team, I never took a graphics course and the networking course I did take was CSE 123, which is a little too low level but helped give me a good idea how networking was happening for this game. The most helpful class/experience I had was CSE 198 which was an independent study for building a game in Unity.
[Knapp] CSE 167 (but minimally), I didn't do much coding for graphics, but instead mostly worked on textures and models which aren't really covered in any courses that I know about.
13. What were the most valuable things that you learned in the class?
[Kimball] On the technical side, I learned how to work with DirectX, and a bit about implementing some basic PBR. I also picked up a bit about networking from Tim and Patrick. On the organizational side, I was able to practice working in a team. There was no one big thing that I learned, but rather a bunch of details about myself and how I worked with others I noticed and improved.
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?
2. I will be teaching this course next Spring. What advice/tips/suggestions would you give students who will take the course next year?
[Kimball] Make your scope ambitious, but plan for when (not if) you have to cut it down. Make sure you know what you absolutely must have, and get that working first. Communicate clearly what you're working, and what you'd like to work on next, and anything that needs to be done in order for you to move to the next task.
3. How can the course be improved for next year?
[Kimball] It might be nice to have a few times during the course where you have the teams meet with each other and chat and see what everyone is up to. There were a few times where I saw what the other teams were working on, but there was at least one game I never saw before the demo day (partially due to missing the dry runs) and several that I only saw extremely briefly.
[Knapp] I agree with Kimball, I think it could be useful to get the groups to talk to each other and look at each other's games earlier in the quarter for issues they've been having, stuff they've solved, suggested workarounds or gameplay things. It could be useful to pass around different information and implementations between groups.
4. Any other comments or feedback?