Project Review

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 overall game concept remained largely unchanged throughout the entire development process; we only removed the “nice to have” parts due to time limits, but everything else remained the same. We wanted to have an animal-themed co-op puzzle game with several levels that the players had to overcome, and that essence prevailed. The “nice to have” things were:

• Farmer (Boss) - He would be sleeping, and would wake up every couple of minutes to “check” his animals before going back to bed. If you moved, you would be a target, and he would start chasing you to bring you back to the tutorial level.
• Timer - A countdown in the UI to let the user know how much time they have until the farmer wakes up to work and not go back to bed (thus, ending the game because you can’t move if he’s awake).
• Mini individual tutorial levels - Teach the player about his character’s unique abilities.
• Ridable Horses - To have a final escape mission after completing the barn and before winning the game.
• Animations - To make everything less “static”.
• Cut-scenes - To enrich the story and hook the player.

We are happy to have remained consistent with the original idea since the beginning because that saved us a lot of time and allowed us to focus on making a working game, which was the whole goal of this class.

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

Our final project design also remained the same throughout the development process. We wanted to have a low-poly style game — that’s why you don’t see a lot of detail in the models, and everything has a plain, matte color. Because we are a low-poly game, I decided to have 2D Pixel Art for the UI, as Pixel Art is the “low-poly” in the 2D world. I always wanted to do a Pixel Art game, so this UI decision was also influenced by this personal desire. I’m glad it turned out great!

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

Looking back, it appears we were pretty optimistic when we created the initial timeline for our project. One critical bottleneck was the client and server integration, which didn't get finalized until week 7. This caused a lot of “waiting” for the game logic implementation. In our final schedule, we spent most of our earlier weeks creating stable server/client communication, and much of the actual gameplay was implemented during the last three weeks.

General Questions

Describe your development environment. What tools did you use? What was your build workflow? If you supported multiple platforms (e.g., MacOS and/or Linux), how did you support making your project work on all platforms? Do you have any tips or suggestions for future groups for their development environment?

When we started our project, we wanted our environment to support both Windows and Mac users since every team member used one of these platforms. As a solution, we built a Linux-based environment that supported both platforms by using WSL2 for Windows users and native macOS for Mac users. Contrary to our initial plan, we faced continuous difficulties running our program on WSL, mainly due to problems with incompatible OpenGL functions. By the end of the quarter, we ended up running our server executable on WSL and the client executable on Visual Studio, which was the best non-breaking, compromise solution we found in the short time remaining as we neared the end of the quarter. As most past teams had done, we relied on CMake to compile and execute our programs, which in my opinion worked amazingly well. The tool allowed us to fetch all open-source dependencies during the build process without having to manually download them into our repository. In our actions workflow, we also utilized an automated formatting tool that helped maintain consistency in our code style. If I were to leave some advice for future groups, I would definitely not recommend using WSL. Even though it is a great tool, it just doesn't work well with OpenGL. Instead, I would spend the first week or two focusing on development logistics by figuring out how to run the program on Visual Studio for Windows users and natively for Mac users.

What group mechanics decisions worked out well, and which ones (if any) did not? Why?

😀

• We used Discord for everything. Discord has channels, video calls, can be used as a storage platform, and you can share your screen with others. Everyone was communicating the whole time, and Discord made it so much easier to interact remotely. This positively impacted our final product.
• We organized our repository structure into three main directories: server, client, and shared. This clear structure allowed us to easily maintain the separation of server and client codebases both visually and in practice.

😢

• Using WSL for Windows users. This made compilation significantly slower compared to Visual Studio, and the environment just doesn't work well with GLFW.
• Not enforcing standards for tracking individual tasks. While we initially intended to use GitHub issues as a place to track tasks, this practice slowly faded away. As a result, we faced some miscommunication between members because we didn't have a clear way to know exactly what each person was working on on a daily basis.

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

• [Jonathan Duong] Level design was much easier than I expected. We had like 3 days left and we only had the Barn level done. My goal was to get the Mill level finished, but after I completed that pretty quickly, I found that I had time to do the Silo level as well. I believe that Skyler’s idea to use Godot and the script that he wrote to generate a json file with the objects and their collision boxes enabled me to purely focus my efforts on the look and structure of the level. This made designing levels much quicker and easier than I expected.