Made general edits, focusing on fixing section 5

Doc/TestPlan/TestPlan.tex

@@ -628,31 +628,34 @@ For additional detail, please consult the \href{https://gitlab.cas.mcmaster.ca/y
 	
 \section{Comparison to Existing Implementation}
 
-The final product of Blaze Brigade is a strategical Tactical, Grid based role playing game. Blaze Brigade is based on a previous implementation of this genre called Tactics Heroes. It is important that this project is compared to it's previous implementation in order to determine the future of the project. Depending on the project's progress, there might need to be changes in the scope for the final product. This would mean that if there are some requirements that can't be met within the time constraint, then the scope could be narrowed. Tactics Heroes helped derive a set of constraints for the project.The following subsections of the functional requirements were named, GUI, Game Structure, Unit Movement, Unit Attacking, Combat Damage calculations. The requirements that belong to Unit Movement have been fulfilled, and this section is completed. The GUI section is nearly completed, and everything else still needs to be developed. Seeing that this much work has been made so far, most of requirements of the software will be fulfilled by the end product of this project. If other requirements seem like they are not worth the project's time, then they may be removed from the list of requirements in order to narrow the scope of the project. Comparing Blaze Brigade to Tactics Heroes at this is point shows that the project is becoming much like it was modelled to do by it's requirements.
 
-\section{Unit Testing Plan}
+Blaze Brigade is based on the strategical, tactical, grid based RPG called Tactics Heroes. All the functional requirements were derived from this existing implementation, and can be categorized into 5 categories: GUI, game structure, unit movement and unit attacking. The comparison between Tactics Heroes and Blaze Brigade for each category are listed below:
 
-The Visual Studio Unit Testing Framework shall be used to write and execute the game's automated unit tests in C\#.
+\subsection{GUI}
+The GUI structure is almost identical to Tactics Heroes, such as the interface, and navigation menu. However, all the graphical assets used is original and either obtained from open sources, or original assets made by the team.
 
-\subsection{Unit testing of internal functions}
+\subsection{Game Structure}
+The game structure involves players taking turns moving their units, and trying to kill off all the opposing enemy units. This game structure is identical between both the existing implementation and Blaze Brigade.
 
-The automated unit tests will test internal functions of the program by passing controlled input(s) into a function in order to ensure correct behaviour or output of that single function. Each testable function in the program shall have corresponding unit tests for each possible type of input, to ensure expected behaviour and/or output of that function under possible edge, regular or abnormal cases. Functions that return a value will have their output tested for the expected output, and void functions shall be tested for correct behaviour, such as changes to the model and its state variables. As such, the unit tests will provide thorough whitebox testing of the game's code. Test coverage tools, which are integrated in Visual Studio 2015, will be used as a metric to determine the degree of unit testing code coverage. The goal of the team is to achieve a minimum of 80\% code coverage to ensure that the majority of the code has undergone white box testing, thus  resulting in fewer errors regarding incorrect coding implementation of the functional requirements.
+\subsection{Unit Movement}
+Unit movement is done by selecting a unit, then clicking another tile within the unit's move range to move it to that location. This way of moving is consistent between both versions.
 
-\subsection{Unit testing of output files}
+\subsection{Unit Attacking}
+Unit attacking is done by clicking on a unit, and selecting an enemy unit within range to perform an attack. Both implementations are similar in this aspect, however there is one major difference. In Blaze Brigade, after a unit performs an attack, they receive a counterattack from the enemy should the enemy survive the initial hit. In Tactic's Heroes, no counter attacks are performed.
 
-The only output file of the game are a collection of windows which comprises the visual representation and graphical aspects of the game. This includes the Main Menu, the How-To-Play, and Game window. To completely ensure proper function of the output file, manual testing must also be taken into consideration to test the expected behaviour of the game. In addition, the game engine XNA Game Studio handles the majority of the rendition from code to output. Our task does not involve testing proper functionality of the game studio, however unit testing of the team's code still plays a key role in ensuring proper output and results. Unit tests for functions that call on the view, as well as unit tests written for the view are necessary to ensuring proper output of the game's visual representation. The unit tests will additionally verify that proper method calls to game studio methods are being executed, most likely with the use of mock objects to simulate the actual game visuals, and to verify that these mock objects are being called upon.
+\subsection{Unit Structure}
+The unit types are different between the two games. In Tactics Heroes, the units are melee and ranged, with all damages only doing physical damage. In Blaze Brigade, there are 3 units - Melee, Ranger (physical ranged), and mage (magical ranged). The stat allocation in Blaze Brigade are also more intricate. The stats that are the same are HP, where a unit dies when their HP falls under 0, Strength which determines their physical attack, and Defense which determines their physical defense. Tactics Heroes only has one more stat - Dodge, which affects dodge rates for attack. In Blaze Brigade, this calculation is calculated from the difference in skill between the two units. Futhermore, there are 3 more additional stats. Firstly is Intelligence and Resistance, which is used for magical damage calculation. The last is Speed which determines if a unit performs consecutive attacks.
 
-\newpage
+\section{Unit Testing Plan}
 
-\section{Appendix}
+The Visual Studio Unit Testing Framework shall be used to write and execute the game's automated unit tests in C\#.
 
-\subsection{Symbolic Parameters}
+\subsection{Unit testing of internal functions}
 
-The definition of the test cases will call for SYMBOLIC\_CONSTANTS.
-Their values are defined in this section for easy maintenance.
+The automated unit tests will test internal functions of the program by passing controlled input(s) into a function in order to ensure correct behaviour or output of that single function. Each testable function in the program shall have corresponding unit tests for each possible type of input, to ensure expected behaviour and/or output of that function under possible edge, regular or abnormal cases. Functions that return a value will have their output tested for the expected output, and void functions shall be tested for correct behaviour, such as changes to the model and its state variables. As such, the unit tests will provide thorough whitebox testing of the game's code. Test coverage tools, which are integrated in Visual Studio 2015, will be used as a metric to determine the degree of unit testing code coverage. The goal of the team is to achieve a minimum of 80\% code coverage to ensure that the majority of the code has undergone white box testing, thus  resulting in fewer errors regarding incorrect coding implementation of the functional requirements.
 
-\subsection{Usability Survey Questions?}
+\subsection{Unit testing of output files}
 
-This is a section that would be appropriate for some teams.
+The only output file of the game are a collection of windows which comprises the visual representation and graphical aspects of the game. This includes the Main Menu, the How-To-Play, and Game window. To completely ensure proper function of the output file, manual testing must also be taken into consideration to test the expected behaviour of the game. In addition, the game engine XNA Game Studio handles the majority of the rendition from code to output. Our task does not involve testing proper functionality of the game studio, however unit testing of the team's code still plays a key role in ensuring proper output and results. Unit tests for functions that call on the view, as well as unit tests written for the view are necessary to ensuring proper output of the game's visual representation. The unit tests will additionally verify that proper method calls to game studio methods are being executed, most likely with the use of mock objects to simulate the actual game visuals, and to verify that these mock objects are being called upon.
 
 \end{document}
\ No newline at end of file

src/Blaze-Brigade/Blaze_BrigadeContent/Blaze_BrigadeContent.contentproj

@@ -104,6 +104,7 @@
       <Name>PixelFont</Name>
       <Importer>FontDescriptionImporter</Importer>
       <Processor>FontDescriptionProcessor</Processor>
+      <SubType>Designer</SubType>
     </Compile>
   </ItemGroup>
   <Import Project="$(MSBuildExtensionsPath)\Microsoft\XNA Game Studio\$(XnaFrameworkVersion)\Microsoft.Xna.GameStudio.ContentPipeline.targets" />