Breakout Game
The instruction of installation can be found in the first page of documentation
Post Mortem
Going into this project we as a team didn’t have a lot of experience programming in C++. As such, some of the biggest take aways were about following C++ best practices such as how to/when to use pointers, how to separate out declarations and implementations using .h and .cpp files, and how to work with some of the different parts of the standard library. Besides that, we also learned to use about how to/when to use different design paterns such as the singleton pattern that we used for creating our resource manager. In particular, we learned when not to use the singleton pattern while trying to make our level loading initially. While at first we tried to make it a singleton, we later realized that the goals of the pattern did not necessarily align with what we were trying to do for our levels since we wanted full control on when our levels were initialized. Another key takeaway from this project was the benefit of time management. While our group did manage to complete all the requirements with no major issues, we definitely could’ve worked to ensure everybody was on the same page with regards to getting everybody set up properly and deciding on a specific plan of action better. If we were to work on this in the future, we may have decided to have more regular team meetings/check ins instead of simply talking over Discord.
As for future changes, there are a number of improvements we would’ve liked to make both architechurally and design wise. For one, while our game overall works without issues, there are some code design choices we made for the sake of time that could be improved. In particular, a lot of our game logic lives inside the SDLGraphicsProgram implementation. This lack of separation between the SDL logic and the game logic makes it difficult to find exactly where changes need to be made. It would be nice if we moved the game logic entirely into its own class with a similar interface as the SDLGraphicsProgram. On the design side, there are plenty of features we could add such as making some special effects when the collision happened, designing multiple balls with different “skills or power”, and more levels with different types of bricks. These changes could be doable with what we currently have but would be better implemented if we took time to improve our ball and brick logic to allow for alternative implementations and behaviors. Besides just features, it would be nice if we could create tools for completing some of the more design heavy parts of the game. In particular, a level editing GUI of some sort would’ve been greatly appreciated while trying to create the CSV files for our levels. A tool that allowed us to visualize and place bricks and saved the results into a CSV file would definitely have allowed us to create more unique and interesting levels.
ScreenShots
