F. Discussion

Discussion 

Our group was from the onset enthusiastic about doing any of the card game for our software development project as they all had seeming straight forward rules and game play loops that would be easy to make within MATLAB. We settled on war due to being able to meet the 2-point minimum requirement while still being relatively simple. This simplicity was only superficial as we promptly ran into an issue as the creation of a randomly shuffled and split deck, this was harder than we expected as we kept running into repeat cards. This led to a strenuous redesign of the code to create the deck as a logical array to make sure there was no repeats. This was the first of many issues as we settled in to work on the code that ended up being harder than expect. 

 The next solution we had to brainstorm a way to different the suits of the cards which we accomplished with use of a mod function which allows the number in question to be divided by a certain number with a remainder. This function allowed us to base suits of the amount of time a number would divide. Around this time was when we had a major shift in our coding as we started to abandon our use of one single script file to program the game. This single file was quickly becoming convoluted and we were having many issues with the sequencing of the code and the code was quickly becoming confusing. Due to this we had to go back and reevaluate the task at hand, breaking the game down into separate steps that we could code as separate functions. This allowed for the programming of many different smaller tasks like drawing cards, shuffling the deck, and comparing the cards. This use of functions helped us immediately as it made sure that these frequently used commands wouldn’t have to be reprogrammed and the main code was instead just used to call functions. This made the work easier to break up as we could assign everyone specific functions to work on. This also helped the organizing of the main code script as it was less bloated with code as code was instead stored in functions. These functions also came in handy for the coding for our second game as many these functions could be carried over as it is also a card game. This change in mentality didn’t solve all our difficulties, as we quickly ran into an issue as the war loop would occasionally get in an infinite loop should we had to make a function to reshuffle the cards to get out of the loops.  

Now that the game’s mechanics were completed, it was time to add sprites and other dynamic elements. Initially, a lot of time was wasted on trying to implement a system that played an audio file but sadly we couldn’t find a way to have it run concurrently with the game. This led to the scraping of this idea and a refocusing on the sprites. Like our approach to our main game we found that breaking the sprites code into a function made it much easier to process and again allowed it to carry over to a separate game. The we initially wrote also was overly complex with the game failing to display the sprites until we commented out most of the code. This code was held onto, until we noticed that the same functions were being accomplished within the simple game engine. Simple game engine was more complete then thought, with all most all of the specifics of the sprites code being pre-programmed within.  

When final testing came time, the code had been condensed into multiple different functions and a main script all inside a single downloadable folder. This allowed for a pain free testing of the game as it was a user-friendly system that only required you to download the folder. This coding process had successfully showed the effectiveness of properly separating tasks and defining the problems posed. This was essential to success as many roadblocks were traversed by simply stepping back and re-evaluating the problem at hand. If those at task, simply broke down the coding into understandable steps it made even those poor at coding understand the process. This all fell in line with our DR. PIE (Develop. Research. Plan. Implement. Evaluate) method learned earlier in the semester, which also preached the importance of separating tasks and attacking them with a thorough approach.