Game concept: How and why did your game concept change from initial concept to what you implemented?
Michael: We initially had more planned for inside the ship, such as depleting oxygen levels, alien invasions, carryable/upgradable weapons, upgradable ship parts, character death and respawning, etc. I feel like overall the game was initially meant to be focused on the inside of the ship, but ended up being a balance between outside and inside.
Amanda: Michael mentioned some of the ideas we were unable to implement, but we still were able to finish a large portion of our initial project description. The main reason we didn’t manage to implement is mainly the tight schedule a 10 week course requires. We had a large (expected) slowdown during midterm week, and maybe we could have fit in one more feature if it wasn’t for that. However, we knew when we coming up with ideas that some of it would be scrapped. We figured out the ones that were Must Haves and our Would Be Nice To Haves mostly got left out, and we followed that pretty closely.
Huajie: To supplement Michael, we also planned more resource restrains to the gameplay. For example, spare parts would have been required to fix cracks; the spare parts in turn need to be ‘produced’ from a specific machine. It would give players more things to do, but yeah, Would Be Nice to Have.
Anish: We also had ideas to implement VR integration, which would have been really cool considering most of our game is first person interaction. However we were limited by hardware support, but still consider it a great potential addition to our game.
Yuxiang: Initially I thought about adding a radar that reflects four players’ real time positions on the map. But in the end we didn’t have a larger interior space that makes it necessary and it was not a Must-to-have feature. Instead, Huajie produced a static map on the last day of the development and added to the game. That was also pretty cool.
Amanda: Michael mentioned some of the ideas we were unable to implement, but we still were able to finish a large portion of our initial project description. The main reason we didn’t manage to implement is mainly the tight schedule a 10 week course requires. We had a large (expected) slowdown during midterm week, and maybe we could have fit in one more feature if it wasn’t for that. However, we knew when we coming up with ideas that some of it would be scrapped. We figured out the ones that were Must Haves and our Would Be Nice To Haves mostly got left out, and we followed that pretty closely.
Huajie: To supplement Michael, we also planned more resource restrains to the gameplay. For example, spare parts would have been required to fix cracks; the spare parts in turn need to be ‘produced’ from a specific machine. It would give players more things to do, but yeah, Would Be Nice to Have.
Anish: We also had ideas to implement VR integration, which would have been really cool considering most of our game is first person interaction. However we were limited by hardware support, but still consider it a great potential addition to our game.
Yuxiang: Initially I thought about adding a radar that reflects four players’ real time positions on the map. But in the end we didn’t have a larger interior space that makes it necessary and it was not a Must-to-have feature. Instead, Huajie produced a static map on the last day of the development and added to the game. That was also pretty cool.
Design: How does your final project design compare to the initial design, and what are the reasons for the differences, if any?
Guillermo: I feel like when we initially came up with the idea, we were more interested in what the game could become rather than what we could feasibly do within the time constraint. As Michael mentioned, we didn’t reach most of our stretch goal ideas, but nonetheless made a game that I am proud to have helped create.
Amanda: Some of our initial design had aspects outside of the ship on the client. Originally asteroids were created on the client, but once we wanted to add collision with the ship that triggered damage done, it had to be moved over to the server. Our GameObject classes ended up being sufficient for our need, but towards the end, all of our classes started to get convoluted. This was mostly due to lack of time to sit down and truly design every aspect we could at the beginning. Our server code became one giant class at the end as well, which definitely wasn’t an initial design decision. We tried to refactor a few times, but it’s easy for things to get messy without a strict design.
Anish: We also did not understand how long it would take and how frustrating it would be to implement certain features. Things like model loading and UI implementation took way longer that expected, so it is always good to overestimate times as well.
Amanda: Some of our initial design had aspects outside of the ship on the client. Originally asteroids were created on the client, but once we wanted to add collision with the ship that triggered damage done, it had to be moved over to the server. Our GameObject classes ended up being sufficient for our need, but towards the end, all of our classes started to get convoluted. This was mostly due to lack of time to sit down and truly design every aspect we could at the beginning. Our server code became one giant class at the end as well, which definitely wasn’t an initial design decision. We tried to refactor a few times, but it’s easy for things to get messy without a strict design.
Anish: We also did not understand how long it would take and how frustrating it would be to implement certain features. Things like model loading and UI implementation took way longer that expected, so it is always good to overestimate times as well.
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.)
Michael: Overall our schedule was fairly accurate, except a few things on the end got bumped off (like Alien AI), and everything got pushed slightly/significantly back. The major reason for this is because we didn’t really know how long we would take to accomplish a lot of thing, since we hadn’t done a project quite like this before.
Amanda: We had left week 9 and 10 open because we knew that there was going to be something in the schedule that got pushed back. For me, adding objects and events past the initial one took almost the entirety of the last few weeks. I believe the initial schedule was just too ambitious in that regard. Also, the GUI was supposed to be started with the initial parts during week 6, but it was such a pain to get integrated, that we didn’t get much going until week 9!
Amanda: We had left week 9 and 10 open because we knew that there was going to be something in the schedule that got pushed back. For me, adding objects and events past the initial one took almost the entirety of the last few weeks. I believe the initial schedule was just too ambitious in that regard. Also, the GUI was supposed to be started with the initial parts during week 6, but it was such a pain to get integrated, that we didn’t get much going until week 9!
What software methodology and group mechanics decisions worked out well, and which ones did not? Why?
Amanda: We decided to not have a strict leadership or roles in our group and allowed for decision by consensus. I think it worked out well because everyone in the group had a say on the decisions affecting the game. On the other hand, we created a Trello and Slack for people to use, but our group communication mostly devolved into Facebook messenger chat. It wasn’t always the most effective in figuring out what others were working on!
Anish: We tried many different tools to keep things organized, and they worked at different parts of our project but eventually died out. What I was personally proud of was how our git was organized, and how we eventually got good using source control with one another! Good job guys!
Anish: We tried many different tools to keep things organized, and they worked at different parts of our project but eventually died out. What I was personally proud of was how our git was organized, and how we eventually got good using source control with one another! Good job guys!
Which aspects of the implementation were more difficult than you expected, and which were easier? Why?
Huajie: Integrating libraries. We had two separate instances where we have great trouble adding a new library (Assimp/SOIL and imGUI). I used to think integrating libraries were nothing more than downloading a source code package and then compile (or even simpler, to be honest). But no, we had to deal with wrong linkings, extra main files, 64-bits v. 32-bits, release v. debug, etc. It was not an easy task.
Michael: Blender was both easier and harder than I expected. I found that making basic models wasn’t THAT difficult but then I faced extreme difficulty trying to improve the models and to add details. Also my lack of artistic skill kind of limited what I could actually make.
Amanda: I thought the networking parts would be more involved, but we were able to use the starting code with very minor changes. The most networking we did was figuring out our Protobuf messages to send, which wasn’t difficult to implement. (We changed our Protobuf a lot as our game developed though!)
Anish: It was surprising to see how easily the multiplayer aspect of the game came together, but major props to Huajie for making that remotely possible. What was especially hard I thought was debugging and figuring out what seemed like random bugs in our program but had to do with networking issues. Also what was hard was implementing the math behind certain linear algebra operations to get the game exactly how I wanted it to . It was certainly rewarding to learn however!
Yuxiang: To supplement Huajie, it was really hard to setup a developing environment with Visual Studio. In the first two weeks I was trying to get the initial code running on my virtual machine, but there were several incompatibilities with OpenGL and other libraries, so I finally gave up and had to work in lab all the time. Besides, the implementation of GUI took me more time than I expected. ImGui does not have a mature documentation, so I had to go through it’s source code to figure out what that API does and what parameters I should set.
Michael: Blender was both easier and harder than I expected. I found that making basic models wasn’t THAT difficult but then I faced extreme difficulty trying to improve the models and to add details. Also my lack of artistic skill kind of limited what I could actually make.
Amanda: I thought the networking parts would be more involved, but we were able to use the starting code with very minor changes. The most networking we did was figuring out our Protobuf messages to send, which wasn’t difficult to implement. (We changed our Protobuf a lot as our game developed though!)
Anish: It was surprising to see how easily the multiplayer aspect of the game came together, but major props to Huajie for making that remotely possible. What was especially hard I thought was debugging and figuring out what seemed like random bugs in our program but had to do with networking issues. Also what was hard was implementing the math behind certain linear algebra operations to get the game exactly how I wanted it to . It was certainly rewarding to learn however!
Yuxiang: To supplement Huajie, it was really hard to setup a developing environment with Visual Studio. In the first two weeks I was trying to get the initial code running on my virtual machine, but there were several incompatibilities with OpenGL and other libraries, so I finally gave up and had to work in lab all the time. Besides, the implementation of GUI took me more time than I expected. ImGui does not have a mature documentation, so I had to go through it’s source code to figure out what that API does and what parameters I should set.
Which aspects of the project are you particularly proud of? Why?
Huajie: Sound? They really have this epic feeling. I remember audience being awed by the explosion SFX.
Michael: Particle effects. I thought the engine exhaust added a nice effect as well as the explosions. Really just our entire outside environment was cool though.
Amanda: It’s so hard to pick, but I really love the outside of our ship. It looks awesome! For my own work, I am proud of how the object interaction ended up. Even if two objects are overlapping, the correct object will get picked. It wasn’t difficult to implement this type of behavior, but I thought it was something really nice that I added during the last week of playtesting. It’s something that could be easily overlooked, because it’s how someone playing the game would expect interacting with certain objects to be.
Anish: Modeling the outside of the ship was super cool because I always wanted to implement a sort of procedural environment like that. It looks really cool with Willie’s lighting as well and the ships and lasers that are flying everywhere. I also really liked the “everything moves around the ship” strategy to make our game logic more clean.
Yuxiang: I’m really proud of the ship-navigation game play. It’s really cool to see the ship navigates through the asteroid field and destroys enemy ships with laser. It feels intense and exciting.
Michael: Particle effects. I thought the engine exhaust added a nice effect as well as the explosions. Really just our entire outside environment was cool though.
Amanda: It’s so hard to pick, but I really love the outside of our ship. It looks awesome! For my own work, I am proud of how the object interaction ended up. Even if two objects are overlapping, the correct object will get picked. It wasn’t difficult to implement this type of behavior, but I thought it was something really nice that I added during the last week of playtesting. It’s something that could be easily overlooked, because it’s how someone playing the game would expect interacting with certain objects to be.
Anish: Modeling the outside of the ship was super cool because I always wanted to implement a sort of procedural environment like that. It looks really cool with Willie’s lighting as well and the ships and lasers that are flying everywhere. I also really liked the “everything moves around the ship” strategy to make our game logic more clean.
Yuxiang: I’m really proud of the ship-navigation game play. It’s really cool to see the ship navigates through the asteroid field and destroys enemy ships with laser. It feels intense and exciting.
What was the most difficult software problem you faced, and how did you overcome it (if you did)?
Huajie: Heisenbugs. And yes we ended up not fixing many of them because of non-reproducibility. One example of fixed heisenbug is that sometimes the client would prompt that the game has ended even though apparently the server side hasn’t send out game end signal yet. And it happened randomly. So to counter this we changed the code to not react on the first game end signal. Instead, only consecutive game end signals (that lasts for 1 second) are considered valid.
Michael: I was trying to pass image textures into openGL and I kept getting unhandled exceptions. I could not figure out why this was happening for a long time, until I found one sentence in an openGL documentation page that said that image textures must have pixel width as multiples of 4.
Yuxiang: I tried to use the ImageButton API in ImGui, but I never got it working. I suspected it was because some low level opengl conflicts between ImGui and our existing code. So we ask the users to press keyboard instead.
Michael: I was trying to pass image textures into openGL and I kept getting unhandled exceptions. I could not figure out why this was happening for a long time, until I found one sentence in an openGL documentation page that said that image textures must have pixel width as multiples of 4.
Yuxiang: I tried to use the ImageButton API in ImGui, but I never got it working. I suspected it was because some low level opengl conflicts between ImGui and our existing code. So we ask the users to press keyboard instead.
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.
Total: +~24117 -~8990, via git log + grep + gawk pipeline. wc on existing code shows about 13350 lines in .cpp and .h 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 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?
Huajie: For sound we used FMOD. Generally it is a great audio library. It has sufficient support to major formats, has intuitive APIs, has OK documentation, and wasn’t particularly hard to integrate to our existing codebase. Avoid stock fade off though. It needs some delicately calculated parameters to work, which is the opposite to the intuitive. Manually change channel volume at each tick instead.
Michael: For modeling we used Blender. If you haven’t used it before, there are a couple of things to keep in mind. You should always export everything at the origin, you should exclude stray edges when you export (they will crash SOIL), you should make sure paths to your image textures are relative and correct.
Guillermo: In order to import Michael’s obj models, We used SOIL which must be imported as an external library, and Assimp, which thankfully has a nuget package on Visual Studio. Make sure to use Assimp v140, which has compatibility with more file types. Additionally, this tutorial helped a great deal: https://learnopengl.com/#!Model-Loading/Model
Michael: For modeling we used Blender. If you haven’t used it before, there are a couple of things to keep in mind. You should always export everything at the origin, you should exclude stray edges when you export (they will crash SOIL), you should make sure paths to your image textures are relative and correct.
Guillermo: In order to import Michael’s obj models, We used SOIL which must be imported as an external library, and Assimp, which thankfully has a nuget package on Visual Studio. Make sure to use Assimp v140, which has compatibility with more file types. Additionally, this tutorial helped a great deal: https://learnopengl.com/#!Model-Loading/Model
Would you have rather started with a game engine or would you still prefer to work from scratch?
Huajie: Personally speaking starting from scratch is fine, but that’s probably because I didn’t touch most of the physics and collision detection code. We had existing network code, based on which we did a lot of changes to fit our need. The config file reader was used mostly unchanged, less fixing some really risky integer operations.
Michael: I prefer starting from scratch because you learn more, but I didn’t have to write a lot of the base game engine because I was modeling. I did have to work out some of the animations though, and while they are not nearly as nice as animations from a library, I did learn a lot of openGL because I had to do it myself.
Guillermo: I think starting from scratch is a better way to learn the entire pipeline of the game making process, even if modern game development does not typically go through this channel.
Amanda: I have to echo what the rest of the team is saying. Starting from scratch teaches you a lot of the pitfalls of making a game that wouldn’t be seen using another’s engine. I feel learning the bad and good helps understand a system better, so that in the future, you can make an more informed decision on choosing a premade solution if need be.
Anish: I’m going to be “that” guy by saying starting from scratch is perfectly fine and we learn a lot by doing it from the ground up. I think organizing it better would have been nice to such that all the pieces fit together, which is very hard to do in this class considering how much we have to do in such a little amount of time. So basically build it from the ground up with refactoring!
Yuxiang: well, my team said everything, and I agree.
Michael: I prefer starting from scratch because you learn more, but I didn’t have to write a lot of the base game engine because I was modeling. I did have to work out some of the animations though, and while they are not nearly as nice as animations from a library, I did learn a lot of openGL because I had to do it myself.
Guillermo: I think starting from scratch is a better way to learn the entire pipeline of the game making process, even if modern game development does not typically go through this channel.
Amanda: I have to echo what the rest of the team is saying. Starting from scratch teaches you a lot of the pitfalls of making a game that wouldn’t be seen using another’s engine. I feel learning the bad and good helps understand a system better, so that in the future, you can make an more informed decision on choosing a premade solution if need be.
Anish: I’m going to be “that” guy by saying starting from scratch is perfectly fine and we learn a lot by doing it from the ground up. I think organizing it better would have been nice to such that all the pieces fit together, which is very hard to do in this class considering how much we have to do in such a little amount of time. So basically build it from the ground up with refactoring!
Yuxiang: well, my team said everything, and I agree.
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?
Amanda: We used Google’s Protobuf. It was fairly easily to use once it was set up and integrated. Huajie was the one that set it up to start with so I’m unaware of the difficulty in that. The main annoyance was that when we started, we couldn’t keep the Protobuf folder in our school accounts because it was too large, so we had multiple different configurations for our Visual Studio based on school computers or personal computers. Eventually, we merged the configurations together with a relative path to our main project, and it became less of an issue. We also had to manually compile it, as we didn’t set it up within Visual Studio to be compiled (if that’s possible).
Anish: Really interested in seeing how Bullet could be put to use considering Group 1 used it very successfully! Yuxiang: We used ImGUI. I would not recommend this to the first time GUI developer. I would probably choose a better documented library or learn some opengl and write my own library if time permits.
Anish: Really interested in seeing how Bullet could be put to use considering Group 1 used it very successfully! Yuxiang: We used ImGUI. I would not recommend this to the first time GUI developer. I would probably choose a better documented library or learn some opengl and write my own library if time permits.
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?
Huajie: Talk. “See something, say something.” is not a joke here. Keeping the teammates in the blind, whether it is because something didn’t work out, or because you need to be away for a while, or you need to make huge changes to code, is never a good idea and will in the end hamper the team’s effort.
Michael: I think that meeting in person more would have saved confusion and been more efficient at times, but most of our schedules didn’t align all that well. Direct communication is always important (e.g. saying exactly what you need from someone or feeling free to share your opinions).
Amanda: Definitely be open with your schedule and ability to finish a task by a deadline. If you can’t finish a task, letting others know is better than surprising them at the end of the week with no code.
Anish: Like the guest speaker Robert said, I also think it’s always best to work in person just because you can walk around, talk and communicate clearer, have a better idea of what everyone is working on, and finally be more efficient since everyone else is working too.
Yuxiang: Working in person is really productive, as we can help each other whenever a problem appears, and solve it with least efforts.
Michael: I think that meeting in person more would have saved confusion and been more efficient at times, but most of our schedules didn’t align all that well. Direct communication is always important (e.g. saying exactly what you need from someone or feeling free to share your opinions).
Amanda: Definitely be open with your schedule and ability to finish a task by a deadline. If you can’t finish a task, letting others know is better than surprising them at the end of the week with no code.
Anish: Like the guest speaker Robert said, I also think it’s always best to work in person just because you can walk around, talk and communicate clearer, have a better idea of what everyone is working on, and finally be more efficient since everyone else is working too.
Yuxiang: Working in person is really productive, as we can help each other whenever a problem appears, and solve it with least efforts.
Looking back over the past 10 weeks, how would you do things differently, and what would you do again in the same situation?
Huajie: My progress definitely slowed down on last two weeks of development. Also I feel I didn’t learn as many new things as I wanted to. I would like to learn more about software engineering aspects that I didn’t known much about.
Michael: I wish we could have had a dedicated artist so that I could have started more on the code from an earlier stage. I think I may have learned more about the overall structure of such a huge piece of software if I had participated more in early development stages. Something I would do again would be to volunteer to do as many things you’ve never done before as possible.
Anish: I wish I took the time to add more features personally, and perhaps do a bigger overhaul towards the end. I personally think we slowed down towards the end as we saw our game get more and more complete, which I personally did not agree with.
Michael: I wish we could have had a dedicated artist so that I could have started more on the code from an earlier stage. I think I may have learned more about the overall structure of such a huge piece of software if I had participated more in early development stages. Something I would do again would be to volunteer to do as many things you’ve never done before as possible.
Anish: I wish I took the time to add more features personally, and perhaps do a bigger overhaul towards the end. I personally think we slowed down towards the end as we saw our game get more and more complete, which I personally did not agree with.
Which courses at UCSD do you think best prepared you for CSE 125?
Huajie: 120/3/4/7, and 110. Yes we didn’t need to implement a Punkbuster or whatever for our game, but at least 127 made me know that I need to keep an eye on different integers and char arrays.
Michael: 110 kind of helped because that class was such a disaster that I learned what to change this time around. I haven’t taken any graphics classes which I’m sure would be more helpful, but I used a lot of linear algebra/vector math for my graphics code.
Amanda: 123/124 to understand what’s happening with the networking, even if we didn’t have to write a lot of networking code. 110/112 because source version control. Seriously, knowing how to git with a group, deal with merge conflicts, and the like is extremely important. The 160 series is certainly useful ( I didn’t take them ), but I wouldn’t know where to start with graphics, while Anish and Guillermo knew that much at least after taking 167.
Anish: 124/167 definitely helped stitch together the connection between graphics and networking which what I was mainly responsible for throughout the quarter. It gave me a good idea of how the overall system worked.
Michael: 110 kind of helped because that class was such a disaster that I learned what to change this time around. I haven’t taken any graphics classes which I’m sure would be more helpful, but I used a lot of linear algebra/vector math for my graphics code.
Amanda: 123/124 to understand what’s happening with the networking, even if we didn’t have to write a lot of networking code. 110/112 because source version control. Seriously, knowing how to git with a group, deal with merge conflicts, and the like is extremely important. The 160 series is certainly useful ( I didn’t take them ), but I wouldn’t know where to start with graphics, while Anish and Guillermo knew that much at least after taking 167.
Anish: 124/167 definitely helped stitch together the connection between graphics and networking which what I was mainly responsible for throughout the quarter. It gave me a good idea of how the overall system worked.
What were the most valuable things that you learned in the class?
Huajie: Aim high, so that we can scale back, which would still end up yielding an acceptable amount of contents.
Michael: Probably the group dynamics of a large software project. I feel like we had hit our stride as a group at about week 7 or so.
Amanda: Working together with a team that actually pulls their weight. In 110 and 112, it’s easy to get a large 10+ group where only 1-3 people actually put much work in. With such a large goal (creating a game), that type of behavior would be the death of the project. So, it was great to see how it is to work with a whole team of people who are determined and dedicated to making a great final product.
Anish: Start early, work fast, and get a fine group of people to depend on so that you know the stuff will get reliably get delivered. Thanks guys for a great quarter!
Michael: Probably the group dynamics of a large software project. I feel like we had hit our stride as a group at about week 7 or so.
Amanda: Working together with a team that actually pulls their weight. In 110 and 112, it’s easy to get a large 10+ group where only 1-3 people actually put much work in. With such a large goal (creating a game), that type of behavior would be the death of the project. So, it was great to see how it is to work with a whole team of people who are determined and dedicated to making a great final product.
Anish: Start early, work fast, and get a fine group of people to depend on so that you know the stuff will get reliably get delivered. Thanks guys for a great quarter!
Please post four final screenshots of your game on your group pages for posterity. I will display them on the group web page.
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?
Amanda: I thought this book was helpful: http://gameprogrammingpatterns.com/ I didn’t read all of it, but it gave me ideas on how to approach our game objects structure. I think there’s a lot in there that could help various design decisions, but there’s also a lot that is overkill for the scope of our 10 week projects.
I will be teaching this course next Spring. What advice/tips/suggestions would you give students who will take the course next year?
Michael: Make sure you have an artist, communicate directly and frequently, and learn as many new things as possible!
Amanda: While the course is a lot of work, it can be a lot of fun if you take a light workload in your other classes. Fun + no stress from a ton of other assignments!
Anish: Don’t be afraid to try things differently, and make sure to always keep on top of things, even if it seems annoying. It will save you a lot of time!
Amanda: While the course is a lot of work, it can be a lot of fun if you take a light workload in your other classes. Fun + no stress from a ton of other assignments!
Anish: Don’t be afraid to try things differently, and make sure to always keep on top of things, even if it seems annoying. It will save you a lot of time!
How can the course be improved for next year?
Anish: I think it went great. Personally I wish the guest lecturers focused more on the game dev side of things, and how things are divided up instead of the business. That kind of insight would help greatly as we build our systems! Still very thankful that they could come in and present.
Any other comments or feedback?
Michael: Maybe you could make new students read some of these reports to gleam more tips from the beginning.