The gamestate was handled with std::unique_ptr to make sure it disposes of the pointer automatically when it goes out of scope. Smart pointers acts as a wrapper for other pointers in order to handle the lifetime to the object being pointed too. We used smart pointers to handle our gamestate as well as to handle our renderer state. The quality of the functions from the standard library is in all likelihood better than other third party libraries we might end up using. Our thread management was by using std::thread and even out random number is accessed trough std::random_device, std:: default_random_engine and the std::uniform_int_distribution. We use std::vectors in stead of arrays and other collections, and we use std::for_each where it was the better choice. One of the many features of our game is the use of the standard library. This also would set us up for extending the game with more gamestates handily. We made gamestate a virtual class as an interface and made state classes that implemented this functionality. We decided to structure the game in game states, and cycle the game loop according to the current state the game was in. We have a collision detection class that only has two external methods collision and brickCollisions that returns the amount of brick hits. We did the same with all the game logic elements. This ensured a cleaner codebase and something that would be more scalable if we wanted to expand our program in the future. The advantage we got was to give the classes specific arias to handle. For one, we just needed to make one SDL Window so to handle that and to handle only one renderer we made classes. We decided quite early that we needed to split up different areas of the code in order to easier handle different aspects of the program. We did this to complete some last parts of our project that we wanted to do before we turned in the project. This is the act where one of us was the driver (person writing code) and the other was an observer (reading trough every new line of code and commenting out loud if it needed to be changed). We made a sharable link to our project if you want to take a look please visit Pair programmingĪt the end of 25 of April we sat together on one computer and did pair programming. Our Github will reflect this work quite well. to the evening of 25.april) working tirelessly on the code. We sat together everyday during the exam period period (from the morning of 23. We used Github heavily to ensure a god flow of code and sharing of progress. In the beginning of the week we sat down and wrote all the features and improvements we wanted to add to the project. The game is now much more advanced and also a lot more enjoyable. We started out with some basic code for the game since one of us made the basic structure for the game as his work-assignment. Ingame: Move sideways with arrow- or A/D keys.Main Menu: Move up / down with arrow- or W/S keys.Hit as many bricks as you can, clear the board to win.Or you can run the included cmake script yourself. The program is extensively tested on both operativsystems. CLion (Tested on CLion on both Mac and Windows) and hit the run button. Colors display the number of hits you will have to make on one simple brick in order to break it. The bricks get harder and harder to break the closer to the top you'll get. The game at first glance may look simple, but make no mistake. Our solution is built using SDL as graphics library and as much as possible of the C++ standard library. This is our edition of the classic game Arkanoid.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |