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 changed pretty dramatically from initial concept to implementation. Originally, we all agreed that we liked the concept of a defense game with rounds, in which some type of AI is attempting to reach an end goal, and the players are actively trying to stop it. We also all agreed that we liked the theme of a grocery store and a game that poked fun at many people’s immediate responses to the pandemic. However, we had long discussions deciding if we wanted to add combat to our game, unique player abilities, a complex economy system, friendly AI and interactions, and more. Ultimately, we never decided on game mechanics that everyone was satisfied with, so we left these components of our game very vague. While working on the game, we focused on the aspects we all agreed on; we created the map with the grocery store design, we created AI that pathed inside our store towards the goal, and we created obstructions that players could use to slow the AI. But, we realized that this would not create an interesting and engaging game, so we decided to modify our design. We came up with a simple system for players to interact with the AI, so that players would actively be participating during the entire course of the game, and it would also help with balancing the economy system to limit what players could do with their resources. To implement this system, we created AI with different weaknesses, and players need to match certain items with the respective AI to satisfy them and make them disappear. This system was not part of our original game idea, but we believe it worked out well in the end. Compared to our original ideas, this new system created tasks for players that made the gameplay much easier to understand while preserving a lot of the features of our game concept that we liked, so we think it was a successful change to our original game concept.
Design: How does your final project design compare to the initial design, and what are the reasons for the differences, if any?
Our design ended up remaining pretty similar to what we initially brainstormed in our initial UML diagrams. From the start we already had an idea of how the game engine should run, having separate threads for handling the network messages and which parts are responsible for what, so the overall design remained the same. That said, we began to deviate from the initial design once we completed the core functionality represented by the designs. For instance, we didn’t include in our original plans a strategy for managing systems such as waves, AI, economy, etc. Thus, we ended up implementing new classes or extending on our shared gameState to handle each new system as we developed it. In retrospect, we probably ended up putting too much functionality into the gameState class that was meant to just transfer data between server and client, but the system still worked well enough for us. Towards the end, we started to focus on adding features in a hackathon approach which was never the plan but luckily we already had the core features so we didn’t cause any major issues or bugs.
Schedule: How does your final schedule compare with your projected schedule, and what are the reasons for the differences, if any?
Our schedule varied significantly from our original plan. We started off with plans to create an initial client/server connection, as well as create a simple client with some models that accepted user input and moved the models. We intended to have this done by week 3 or 4 and we were able to get it done on time. The next steps were to create a system for the client and server to communicate gameplay events, and to improve the client’s graphics using shaders and new models. Unfortunately this step took us much longer than expected, because of factors outside of this class and teamwork issues early on. For the server team, we didn’t have the gameplay events implemented and working properly until close to week 9. For the client team, we only had a few models that we were working with, and the shaders had bugs up until week 9 as well. We also ran into issues with the libraries that we were using to load in models from files, so this created a significant hurdle that slowed down our progress for some weeks before it was resolved. These delays really accelerated the rest of our schedule because we only had a few weeks left to work. We intended to create a particle effect system in weeks 4-6, but we didn’t get a chance to work on and complete the system until week 8 because of these delays. We wanted to have a basic UI done by week 5, but we didn’t have anything in this area until week 8, and it wasn’t complete until the beginning of week 10. We had our gameplay mechanics scheduled throughout the quarter from weeks 4-8, but we spent so much time on infrastructure that the implementation for most of these mechanics was delayed. For example, we wanted to have collision detection done by week 3, but we didn’t start working on it until week 6. Essentially, most of our schedule for the server team was pushed back because we took too long to finish a basic server, client, and the interfaces to allow them to interact.
What software methodology and group mechanics decisions worked out well, and which ones did not? Why?
One group mechanics decision that worked out well was our biweekly meetings. We meet on Tuesdays and Thursdays at the same time every week to discuss everyone’s progress and plans for the current week. For the most part, we were able to figure out what needed to be done, and who would be doing it. I think it was also useful as a teamwork exercise for everyone to meet at least twice every week during this time where we didn’t interact often.
One group mechanics decision that didn’t work well was our original plan for teams. We created a team dedicated to the network, a server team, and a client team. But, we realized quickly that the work of the network team was frontloaded, and the work of the server and client teams overlapped significantly. After a few weeks, we started working across teams and that ultimately ended up being more productive.
Which aspects of the implementation were more difficult than you expected, and which were easier? Why?
Christopher Maytom
Implementing events was harder than I expected and I think this was due to the fact that we tried to treat all events similarly when in fact it would have been better to split them up and have different ways to handle them. Another thing that added to the challenge was the fact that we decided for the client to have a different game state representation which ultimately restricted our implementation. Implementing UI was surprisingly easy since we used Imgui which just needed to be added to the project and then it worked straight away.
Steven Hausman
For the graphics, creating the particle effects was more difficult than I expected. I created a basic particle system very quickly, but it wasn’t very convincing. It took a lot of trial and error to make the particles appear correctly with the right textures and size, and move in the ways that made sense.
Thiago Marback
I found that implementing audio was surprisingly easy. Despite looking somewhat intimidating at first, FMOD is pretty straightforward to work with in code once the toolchain (read: CMake) is configured to use it.
Cameron Foster
For how robust our network backend was, it was relatively easy and straightforward to implement.
Which aspects of the project are you particularly proud of? Why?
Christopher Maytom
I’m proud of the server game state loop logic and network code since we were able to get it to work even when we had the server running on one of our computers and we all connected to it. From what I could see, no other team was able to achieve this level of game play over the internet which is amazing. For the amount of time we put into UI, I am amazed at how clean it looked compared to the other teams that also used Imgui.
Steven Hausman
I am proud of the ways in which the server team was able to implement interactions. Figuring out what state the player is in and what the player is looking at is not easy, and I think the server team did a good job of implementing this so that players could interact with shelves to pick up items, place barriers, etc. I am also proud of how our visuals came together. Although they are simple, I think that actually improves the quality of the game and retains a cohesive design.
Thiago Marback
I’m proud of how well the network backend worked (enough that running the client from our own computers was actually more playable than using the demo computers through VLC). Also lowkey proud of the mostly straightforward setup and compilation process after CMake was properly configured (assimp issues aside).
Cameron Foster
I’m proud of all the hard work the graphics team put into the game assets. It was so cool to see everything come to life and take form in the last week or two as models, shaders, and particle effects were incorporated one by one.
What was the most difficult software problem you faced, and how did you overcome it?
Christopher Maytom
The hardest software problem I faced was communication with my team given the remote conditions we faced. My attempts to fix this included trying to be more active in our discord channel and consistently being in a public voice channel so that others can join, work or even just hang out.
Steven Hausman
One of the most difficult software problems we had was working with external libraries. We had a hard time installing the library we used to load external models from files on the client. This took multiple days to solve, and we couldn’t even figure out a clean way to do it so we had to make it work in whatever way we could.
Patrick Liu
The most difficult tools problem for me was probably CMake, which was overcome mostly by copying existing CMake files(thanks Thiago)
Thiago Marback
Setting up CMake, which was overcome through lots of googling and trial-and-error.
Cameron Foster
The most difficult problem I faced was getting finicky external libraries to cooperate with Visual Studio. Solving this boiled down to many, many hours of googling, tinkering around, and bouncing problems off of my group mates.
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 did not experience this. (should have used Rust)
How many lines of code did you write for your project?
The total for our team is about 22,516 when you include .h and .cpp and exclude imgui. Used the command `find . -name "*.h" -o -name "*.cpp" | xargs wc -l | sort -nr` to figure out.
From Github Insights
Christopher Maytom
40,681
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?
Models
We used Blender 2.83 to create all of our models with textures. There are a lot of tutorials and resources for learning Blender, so these were very helpful in learning how to use the tool. We intended to use blender for animations as well, but we did not end up implementing animations. After creating the models, we exported them using the COLLADA format to save the texture, rig, and animation data from Blender. We used custom settings in the export to convert the Blender axes to axes that are compatible with OpenGL, and to save the UV map so that textures map onto the model properly. We exported the texture files from Blender as well, as a .png file, to preserve transparency. We used the latest version of Assimp to load the models, because it was convenient to use the functions to get all of the vertex data from the COLLADA files without having to parse the XML format. We also planned to use Assimp to load the animations from the same COLLADA files, but we did not implement animations so we were not able to try this. We had difficulty installing Assimp, and ultimately ended up downloading the repository from github, manually compiling it, and dragging the files into our project in the appropriate places. For our graphics client, we used OpenGL. We had experience with OpenGL from CSE 167, so we did not run into any difficulties using this. I think this entire toolchain and process was very effective, so we would likely use the same thing again if we were to do this project again.
Audio
For our audio, we obtained free audio clips from the Internet, imported them into FMOD Studio, then used said FMOD Studio to set up sound events, then exported them all into FMOD’s proprietary sound bank format, which could be loaded directly from code using FMOD’s API. CMake was also set up to automatically copy the built bank files to the output directory after compilation. This setup was very painless to use so we would definitely use it again.
Would you have rather started with a game engine or would you still prefer to work from scratch?
Christopher Maytom
It depends on the goal of the project. I feel like starting from scratch enables you to learn about the underlying systems of a game engine which means more of your time is spent on nonvisual aspects. While starting from a game engine would mean that the complex systems we create for the game would have to be added on top and would be gameplay related. I think both cases could provide great experiences working with complex systems but having to make it from scratch makes it easier to know what kinds of systems we are going to implement. Since I have worked with game engines before, I am glad that we started from scratch.
Steven Hausman
I am personally glad that we started from scratch, because I think I now have a greater understanding of what goes into building a game. Even though I was not on the network or server teams, I understood some of the decisions my teammates made and the issues and breakthroughs that they went through. For my pieces of the project, I enjoyed using the skills that I had learned to bring my tasks to life. It would have been nice to start with an engine though, so that we could have made a more complete and refined game.
Thiago Marback
Using an engine from the get-go would likely have allowed us to focus more on the game itself, but it would also likely have limited options for how to implement certain things. Starting from scratch was also a great learning experience, so for a class like this I would still prefer to start from scratch.
Anthony Lau
I quite enjoyed building the engine from scratch, as doing so helped me appreciate the complexities that general game engines like Unity or Unreal have to deal with under the hood. Furthermore, it allowed us to be more flexible in implementing our own custom systems, such as a pathfinding and collision detection without rigid body physics.
Cameron Foster
While starting with a game engine probably would have allowed us to make further progress overall, the flexibility gained from creating an engine from scratch was more beneficial. On top of being custom built to our own needs, it provided a much deeper learning experience than would have been possible if we were given a game engine from the start.
For those who used a networking library, a physics library, or a GUI library, would you use it again if you were starting over knowing what you know now?
Team answer
Networking Library
We decided to not use a networking library because as a team we wanted to implement our own network code from scratch. We learned a lot doing this and would do it again.
Physics Library
We decided to not use a physics library because our gameplay doesn't rely on realistic physics.
GUI Library
For our UI, we chose to use Imgui which can be included by adding header files into the project. The only things we used were different fonts including font awesome icons. To get this to work we had to download the fonts as ttf files and then load them into Imgui using AddFontFromFileTTF(...) and then for the icon fonts we used a header file to map the icon characters to unicode constants. Only issue we faced was with loading one of the icon fonts which ultimately was due to the file being corrupted. I would definitely recommend using imgui for a quick and easy text based ui system.
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?
Our team didn’t use Wordpress and chose to find a html, CSS, and JS template that we all liked. This was very straight forward to setup and gave us a lot of freedom to make changes.
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?
Christopher Maytom
Since we were working remotely, I definitely became more aware of the importance of working in person and became more comfortable communicating virtually. We didn’t have a structured approach to task management which definitely hurt or ability to work together. When we did assign tasks they tended to overlap and depend upon each other which wouldn’t have been an issue if we were all in the same room working next to each other.
Steven Hausman
Since we were working from home during this time, I think it added an extra level of difficulty. We had a very hard time finding time for team members to meet up and work on tasks together, and this really slowed down our progress whenever we ran into difficulties and bugs. We had a Discord server set up for communication, which eased some of these communication issues because we were able to notify each other in real time when we ran into issues, but this still did not solve our timing issue completely.
Thiago Marback
It was pretty clear that working in a group like this can easily be bottlenecked by communication, as often it becomes necessary to use or edit someone else’s code, and it’s hard to do so without asking them things about it.
Cameron Foster
It’s very easy to let tasks fall to the wayside if it’s unclear who should be working on something. This is something that I personally dealt with due to the remote nature of the project and the general uncertainty of being in quarantine. I learned that it is important to keep individual group members personally responsible for certain tasks to ensure that they get finished.
This quarter was particularly difficult having to do everything remotely. What tools and strategies did you use to collaborate, communicate, and work together?
Working as a team on its own is hard, but working remotely makes it 10 times harder. We chose to have biweekly full team meetings where we all would spend about an hour discussing the status of each task and what we expect to see done by the next meeting. Originally we set up a trello to keep track of tasks but ultimately didn’t use it since it was another thing to keep track of. As a team we chose to use Discord as our main form of communication since it enabled us to see when others were online and most of us already had it setup.
Looking back over the past 10 weeks, how would you do things differently, and what would you do again in the same situation?
Christopher Maytom
If I could go back and change anything, it probably would have been to set up more structured expectations for our team. This would probably have included weekly programming sessions and more project management tools to keep everyone up to date. I found that when we could get everyone online together, we would make a lot of progress in a short amount of time so it would have definitely been beneficial to have worked together from the start.
Steven Hausman
I think we did not do a good job of creating specific tasks and assigning them to specific team members. If we were to do this project again, I would outline specific tasks every week, post them in some form for each team member to see, make sure that at least one person was assigned to each task, and ensure that these tasks are completed on time by the start of the next week. Since we were working remotely, I would also like to schedule times for multiple team members to join a Zoom call and work together on the project. We tried to do this to some extent but it wasn’t official so it wasn’t very effective.
Anthony Lau
I’d make sure we have a more structured form of code review and integration. One issue we had when working independently was that new code was not immediately integrated into the main functionality, and it took more work later to make sure all of the systems ran together smoothly. Also, if we had more time, I’d have loved to set up an automated CI/CD pipeline to ease our testing and deployment woes. e.g. using Jenkins to marry our github repository to testing and build tools. And as another add-on, I’d advocate more heavily for a Linux server, since while Visual Studios and Windows C++ were passable for our development, it felt like Visual Studios added too much bloat and complexity and Windows C++ didn’t seem to have enough benefit to justify its use on the server.
Cameron Foster
I 100% agree with Steven. I believe the idea of assigning specific people concrete goals and deadlines was a good idea that we implemented into our team much too late. The beginning few weeks lacked a bit of direction in terms of who was meant to be working on certain aspects of the project, but as the weeks went on we got more accustomed to working remotely and our vision became clearer. In the same situation, I would try to set out clear tasks from the beginning and establish an official team work session.
Which courses at UCSD do you think best prepared you for CSE 125?
Christopher Maytom
I believe that CSE 110 and 112 are useful since they teach you about the dynamics of working in teams and design patterns that make it easier to add to the project. I was taking CSE 112 at the same time and there were definitely a few things that were going well in that group project that I wish I could have incorporated into this course.
Steven Hausman
I think CSE 124 is useful for those that are interested in the networking code, and CSE 167 is useful for implementing the client graphics, because that class teaches the basics of OpenGL.
What were the most valuable things that you learned in the class?
Christopher Maytom
The most valuable thing I learned in this class is that I should be confident in my abilities which are the result of my education. I was worried about completing this project from the start since I haven’t ever worked on something of this magnitude before but in the end we did it and I learned a lot.
Steven Hausman
I learned a lot of skills related to managing a larger project. I did not have a lot of experience working with git to manage many different versions of the project, and integrating new features into a project. I also have no experience working remotely on a project, so we had to experiment a lot with different teamwork strategies, and I think I learned some things related to paired programming and discussing issues that I did not know before.
Anthony Lau
In terms of software, I learned how tough it is to design a sane data structure hierarchy for a complex project that both makes intuitive sense and is extensible to whatever features we need. In particular, it felt like we ended up with some redundancies and some unintuitive ownership/referencing of data structures that could be improved if we continued to iterate. More on the social side, I learned that it’s very difficult to develop a large scale project without constant, direct engagement with other team members, and I can see why a lot of companies, even though their work can theoretically be done remotely, choose to enforce people physically coming to work together.
Cameron Foster
I learned a lot about the difficulties of working on a large scale project, both on the group and the individual level. I also learned to believe in my abilities. This project seemed quite daunting from the onset, but using all that we have learned over the course of our studies we were able to design and develop a functioning game. That achievement alone taught me that I should have more confidence in my abilities.
