Blaze Brigade is a tactical simulation role-playing game that combines the strategic challenges as a form of interactive entertainment for its users. This turn-based game allows users to advance their units into enemy territory, participate in combat and strive to eliminate all of the opposing units. In adaption to the open-source freeware, Tactics Heroes, Blaze Brigade will incorporate new functional and design enhancements that may not be available on the existing open-source project. Such enhancements include the implementation of new features within the unit movement, combat and strategy aspects of the game as well as improved graphical representations of the menu menu and gameplay to improve the overall experience of the game.
Blaze Brigade is a tactical simulation role-playing game that combines the strategic challenges as a form of interactive entertainment for its users. This turn-based game allows users to advance their units into enemy territory, participate in combat, and strive to eliminate all of the opposing units. In adaption to the open-source freeware, Tactics Heroes, Blaze Brigade will incorporate new functional and design enhancements that may not be available on the existing open-source project. Such enhancements include the implementation of new features within the unit movement, combat and strategy aspects of the game as well as improved graphical representations of the main menu and gameplay to improve the overall experience of the game.
\subsection{Context of Module Guide}
The system is fully devised and presents all of its functional and non-functional requirements in the Software Requirement Specification (SRS). As these requirements state the desirable properties of the system, the design documents will further evaluate on how these requirements are identified and achieved. The Module Guide (MG) will serve as a tool to decompose the following system into a modular structure adhering to the principle of information hiding. Upon reaching the finalized version of this document, the Module Guide can be distributed amongst various groups in order to learn and identify parts of the software that is being presented. These various groups are as follows:
The system is fully devised and presents all of its functional and non-functional requirements in the Software Requirements Specification (SRS), stating desirable properties of the system. Meanwhile, the Design Document will further evaluate on how these requirements are identified and achieved. The Module Guide (MG) will serve as a tool to decompose the following system into a modular structure, adhering to the principle of information hiding. Upon reaching the finalized version of this document, the Module Guide can be distributed amongst various groups in order to learn and identify parts of the software that is being presented. These various groups are as follows:
\begin{itemize}
\item\textbf{Developers and maintainers:} Decomposing the system and documenting into the Module Guide will aid the developers and maintainers to understand the system-as-is and recognize what areas of the software are likely to be changed. In addition, a sense of the overall design will be structured and will be maintained in the following developments phases yet to come.
\item\textbf{Designers:} In addition to the design pattern being documented, designers are able to determine whether the designs are constructed as initially specified. With the following anticipated changes to be happening, which areas of software is flexible and feasible to accommodate new design changes.
\item\textbf{New recruits or outsourced resources:} The documentation will onboard the new recruits in familiarizing the overall structure of the implementation adhering to a specific design principle. This will reduce the downtime of debugging and have an advantage of multiple groups working on the system at once. Furthermore, if an external team were to implement the system or would like to carry out further improvements after the project timeline, this document will serve as an aid to determine the existing framework and how further implementation can take place.
\item\textbf{Developers and Maintenance:} System decomposition and the Module Guide will aid the developers and maintenance team in understanding the system-as-is and to recognize which areas of the software are likely to be changed. In addition, a sense of the overall design will be structured and will be maintained in the following developments phases yet to come.
\item\textbf{Designers:} In addition to the design pattern being documented, designers are able to determine whether the designs are constructed as initially specified. Along with the upcoming anticipated changes to be happening, designers can further determine which areas of software are flexible and feasible to accommodate new design changes.
\item\textbf{New Recruits or Outsourced Resources:} The documentation will aid with the onboarding process of new recruits in familiarizing the overall structure of the implementation adhering to a specific design principle. This will reduce the downtime of debugging and have an advantage of multiple groups working on the system simultaneously. Furthermore, if an external team were to implement the system or would like to carry out further improvements after the project timeline, this document will serve as an aid to determine the existing framework and how further implementation can take place.
\end{itemize}
\noindent
In addition to the Module Guide, the Module Interface Specification (MIS) is also a product of the design documentation. The specification defines the syntax and semantics that are associated with the functions provided in the source code. Tools like Doxygen have been utilized to generate a set of documentation that will indicate the characteristics of the functions in terms of the corresponding inputs, outputs, assumptions, exceptions, state and environment variables. These characteristics will further aid in observing how the implementation is taken place and how the design constitutes from these functions.
In addition to the Module Guide, the Module Interface Specification (MIS) is also a product of the design documentation. The specification defines the syntax and semantics that are associated with the functions provided in the source code. Tools like Doxygen have been utilized to generate a set of documentation that will indicate the characteristics of the functions in terms of the corresponding inputs, outputs, assumptions, exceptions, state and environment variables. These characteristics will further aid in observing how the implementation has taken place and how the design constitutes from these functions.
\subsection{Design Principle}
The design principle taken into consideration revolves around the decomposition of the overall system into a modular structure of subsystems. These subsystems are observed in an abstract manner, hiding any details that may complicate the process. This act of information hiding and encapsulation ensures that each modules hides some design aspect from the rest of the system and analyzes which areas are expected to change. Hence, this document follows a design for change pattern and will be in the best interest throughout all of the subsystems presented in the system. For instance, the anticipated changes within the system would have been encapsulated in this process to ensure that any further changes to the design does not disrupt the main design interface of the system. As a principle for the decomposition into modular structure, the instance of low coupling is desired as the result is given as independent modules. In the same respect, high cohesion within the modules is highly desired since the elements of the module are strongly related to the module's characteristics. Therefore, this process is motivated around the concept of design for change as an exercise and validation to protect other modules of the system if any major changes occur in the overall design.
The design principle taken into consideration revolves around the decomposition of the overall system into a modular structure of subsystems. These subsystems are observed in an abstract manner, hiding any details that may complicate the process. This act of information hiding and encapsulation ensures that each module hides some design aspect from the rest of the system and analyzes which areas are expected to change. Hence, this document follows a design for change pattern and will be in the best interest throughout all of the subsystems presented in the system. For instance, the anticipated changes within the system would have been encapsulated in this process to ensure that any further changes to the design does not disrupt the main design interface of the system. As a principle for the decomposition into modular structure, the instance of low coupling is desired as the result is given as independent modules. In the same respect, high cohesion within the modules is highly desired since the elements of each module are strongly related to the module's characteristics. Therefore, this process is motivated around the concept of design for change as an exercise and validation to protect other modules of the system if any major changes occur in the overall design.
\subsection{Outline of Module Guide}
The Module Guide is organized in the given order. Section \ref{SecChange} lists all of the anticipated and unlikely changes that the software system might contain. Section \ref{SecMH} decomposes the system into a list of modules into the module hierarchy. Section \ref{SecConnection} establishes the connection between the software requirements with the modules. Section \ref{SecMD} gives a detailed insight on how the modules have been decomposed with their corresponding descriptions. Section \ref{SecTM} includes three traceability matrices comparing the modules with the software requirements and anticipated changes as referenced earlier in Section \ref{SecConnection}. At last, section \ref{SecUse} pinpoints the use hierarchy between the modules initialized to establish connection between the independent modules.
The Module Guide is organized in the given order. Section \ref{SecChange} lists all of the anticipated and unlikely changes that the software system might contain. Section \ref{SecMH} decomposes the system into a list of modules, and further states the module hierarchy. Section \ref{SecConnection} establishes the connection between the software requirements with the modules. Section \ref{SecMD} gives a detailed insight on how the modules have been decomposed with their corresponding descriptions. Section \ref{SecTM} includes three traceability matrices comparing the modules with the software requirements and anticipated changes as referenced earlier in Section \ref{SecConnection}. At last, section \ref{SecUse} pinpoints the use hierarchy between the modules initialized to establish connection between the independent modules.
The design decisions in this section are likely to change because they are hidden in modules. When these changes are made, they can be done easily and not affect other modules of the project.
The design decisions in this section are categorized as anticipated due to being hidden in modules. When these changes are made, they can be done easily and will not affect other modules of the project.
\begin{description}[leftmargin=1.2cm]
\item[\refstepcounter{acnum} \actheacnum \label{acClass}:] All classes that implement the Class interface are likely to have their stats change for balancing reasons.
\item[\refstepcounter{acnum} \actheacnum \label{acWeapon}:] All weapons that implement the Weapon interface are likely to have their stats change for balancing reasons.
\item[\refstepcounter{acnum} \actheacnum \label{acDamageCalculations}:] The getHitRate() and getCritRate() methods inside the DamageCalculations class are likely to change for balancing reasons.
\item[\refstepcounter{acnum} \actheacnum \label{acSprites}:] All sprites from outside sources. It has been determined that the project should contain all original content.
\item[\refstepcounter{acnum} \actheacnum \label{acSprites}:] All sprites from outside sources are likely to change. It has been determined that the project should contain all original content.
\end{description}
\subsection{Unlikely Changes}\label{SecUchange}
...
...
@@ -169,95 +161,163 @@ The following design decisions are unlikely to change because they affect many m
Behaviour-Hiding Module & Menu Module, GUI Module\\
\midrule
Software Decision Module & Model Module\\
Behaviour-Hiding Module & Menu Module, GUI Module \\
Software Decision Module & Game State Module \\
\bottomrule
\end{tabular}
\caption{Module Hierarchy}
\label{TblMH}
\end{table}
Since Blaze-Brigade consists of purely software, M1 does not apply to the system. The software never interfaces with the hardware itself. The lowest level of interfacing with the software is the OS.
Since BlazeBrigade consists of purely software, M\ref{mHH} does not apply to the system. The software never interfaces with the hardware itself. The lowest level of interfacing with the software is the OS.
% =============== Section 4 ===============
\section{Connection Between Requirements and Design}\label{SecConnection}
The system is intended to satisfy all of the functional and nonfunctional requirements that were initially specified in the SRS. In this section, the system is decomposed into modules and assess the connections between the decomposed requirements with the corresponding requirements. These are shown in the Table \ref{TblRT} and Table \ref{TblNFRT} under Section \ref{SecTM}.
The system is intended to satisfy all of the functional and non-functional requirements that were initially specified in the SRS. In this section, the system is decomposed into modules and connections are assessed between the decomposed requirements with the corresponding requirements. These are shown in the Table \ref{TblRT} and Table \ref{TblNFRT} under Section \ref{SecTM}.\\
\hfill\break
Most of the requirements can be categorized as one of the modules provided in the Module Hierarchy. For instance, the Menu Model extends through all of the requirements that initiate the menu option in one way or another. The model module encapsulate the model classes that represent the structure of the source code. The GUI module is primarily what users get to see as a final product which includes various parameters within the game. The design decisions that are needed to accommodate these requirements heavily rely on the main function criteria that the system holds. For instance, the appearance requirements specify the look and feel that the user should be expecting from the product and heavily focuses on the menu and GUI aspect. These modules initialized will cover those aspects and model this case scenario is such a manner that each module or submodules will be independent and protected if there is design change in the other part of the system.
Most of the requirements can be categorized as one of the modules provided in the Module Hierarchy. For instance, the Menu Model extends through all of the requirements that initiate the menu option in one way or another. The model module encapsulate the model classes that represent the structure of the source code. The GUI module is primarily what users get to see as a final product, including various parameters within the game. The design decisions that are needed to accommodate these requirements heavily rely on the main function criteria that the system holds. For instance, the appearance requirements specify the look and feel that the user should be expecting from the product and heavily focuses on the menu and GUI aspect. These modules initialized will cover those aspects and model this case scenario in such a manner that each module or sub-module will be independent and protected if there is design change in the other part of the system.
% =============== Section 5 ===============
\section{Module Decomposition}\label{SecMD}
Module Decomposition summary TODO \\
The goal of this section is to provide a detailed description of how the system operates. In order to do this, a module decomposition is necessary. The modules in this decomposition are not classes directly from the software code, but instead are a collection of sub-modules that complete an abstract concept. The sub-modules may be classes directly from the software, or be broken down until these classes are reached. This section will also include a pair of diagrams, one that explains the project's chosen architecture, and another that demonstrates how each module fits into said architecture.
\subsection{System Architecture}
The following definitions explain all important terms used to describe the system architecture.
\begin{description}[leftmargin=0.2cm]
\item\textbf{MVC $\rightarrow$} The specific system architecture for this software. MVC stands for Model-View-Controller. The user interacts with the controller, which manipulates the model. The view then updates based on the model. From here, the user sees the result of their interaction through the view.
\item\textbf{Model $\rightarrow$} The central point of the system architecture. The model contains all data, logic and rules of the software. Whatever the view displays to the user is based on the model.
\item\textbf{View $\rightarrow$} The part of the system that displays information to the user. This is where the user sees all relevant information.
\item\textbf{Controller $\rightarrow$} The part of the system that the user manipulates. The controller is what updates all information stored in the model.
\caption{The MVC Architecture of the Software System}
\end{figure}
\end{description}
\subsection{Underlaying Architecture}
Now that the general idea of the system has been explained, this section will take the level of abstraction one step further. This level of abstraction demonstrates the module decomposition of the system. Arrows in the diagram represent sub-modules that help reach the next module in the system. Note that this is not a uses diagram, nor is it intended to be.
\begin{description}[leftmargin=0.2cm]
\item\textbf{Hardware Hiding Module:} This module (and its sub-modules) provide an interface for users to interact with the software. The module will convert the raw input data from the mouse into data that can be used by the controller to update the current game state. The view will also be implemented through this, allowing for users to correctly interact with the software.
\item\textbf{Behaviour-Hiding Module:} This module functions as the controller in MVC, and handles all the software decision making of Blaze Brigade. This includes all visible behavior of the system specified in the SRS. Hence any changes to the SRS will hereby result in modifications to this module.
\item\textbf{Software Decision Module:} This module extends the Model Module, stores the state of the overall game, and contains the state of how everything in the game should currently behave. These results determine what is displayed in the GUI Module (view).
\item\textbf{GUI Module:} This module is the main View in MVC, and displays data to users in the form of graphics according the current game state.
\item\textbf{Menu Module:} This module handles the main menu layout, navigation and controls.
\item\textbf{Model Module:} This module is the main Model in MVC, and contains most of the structure of the game. Most of the elements in this module are simply data, with most methods simply being a C\# property (combination of getters and setters).
\end{description}
The following is a diagram that depicts this level of abstraction of the software system. Note that red arrows indicate the path of the software, whereas the black arrows indicated extended modules.
This module is further broken down into the Game Functions module.
\begin{itemize}
\item\textbf{Game Functions:} All of the algorithms and processes that run during the transition of one game state to another.
\end{itemize}
\begin{description}[leftmargin=1.6cm]
\item[Secrets:]The algorithms and format structures used to provide an interface between hardware and software.
\item[Services:]This module provides an interface for users to interact with the software. The module will convert the raw input data from the mouse into data that can be used by controller to update the current game state. The view will also be implemented through this, allowing for users to correctly interact with the software.
The GUI module is further broken down into Menu, and Display.
\begin{itemize}
\item\textbf{Menu:} The tool that appears on the GUI in which the user interacts with for navigation. This module is still to be broken down. See section 5.3.4 for this further breakdown.
\item\textbf{Display:} The visual representation of all user-relevant data.
This module is broken down into Options, and Navigation.
\begin{itemize}
\item\textbf{Options:} The set of all decisions the user can make while in the menu.
\item\textbf{Navigation:} How the user is navigated through the software based on what option they select from the menu.
\end{itemize}
\begin{description}[leftmargin=1.6cm]
\item[Secrets:]The behavioural process of the software.
\item[Services:]This module functions as the controller in MVC, and handles all the software decision making of Blaze Brigade. This includes all visible behavior of the system specified in the SRS. Hence any changes to the SRS will hereby result in modifications to this module.
\item[Implemented By:] Computer, game.cs
\end{description}
\subsubsection{Model Module}
This module is further broken down into Data, and Logic.
\begin{itemize}
\item\textbf{Data:} All information that is relevant to the units, players, and map of the game.
\item\textbf{Logic:} All rules, and logic that apply to the game. All of the rules and logic are checked based on the current state of the game.
\item[Secrets:] The design decisions that determine \emph{how} the software updates.
\item[Services:] This module extends the Model Module, and stores the state of the overall game, and contains the state of how everything in the game should currently behave. These results determine what is displayed in the GUI Module (view).
\item[Implemented By:]\mref{mBH}
\subsubsection{Mouse Position}
\begin{description}[leftmargin=0.2cm]
\item\textbf{Secrets:} The algorithm used to determine where the mouse last clicked.
\item\textbf{Services:} This module collects the information needed to update the view.
\item[Secrets:] The design decisions that implement the structure of the software.
\item[Services:]This module is the main Model in MVC, and contains most the structure of the game. Most of the elements in this module are simply data, with most methods simply being a C\# property (combination of getter and setter).
@@ -265,20 +325,19 @@ Module Decomposition summary TODO \\
This section show three traceability matrices outlining the comparison between the modules with either the functional requirements, non-functional requirements and anticipated changes.
% the table should use mref, the requirements should be named, use something
% like fref
% the table should use mref, the requirements should be named, use something like fref
\caption{Trace Between Anticipated Changes and Modules}
...
...
@@ -325,12 +384,12 @@ This section show three traceability matrices outlining the comparison between t
\section{Use Hierarchy Between Modules}\label{SecUse}
In this section of the Module Guide, the system has already been decomposed into the desired modular structure and characterized by determining the connection between the initial requirements and anticipated changes to those modules. The uses hierarchy presented in this section compares the independent modules with each other to find the common grounds on which modules uses the instance of another. This practice ensures the correctness of the program when it comes to testing as well as a reference to the integration procedure if the design of the system experiences a major change. For instance, if we model a scenario where Module A uses Module B, then all of the parameters that rely on both module have to be specified to ensure that the valid output of Module B can be efficiently used in Module A to proceed with the execution of the design. This hierarchy also represents the testing environment, as Module A and Module B would first be tested independently then the correlation between the shared parameters of both modules. In theory, Module A would present a similar module entity as it is categorized in the higher level of the hierarchy and relies on Module B on the lower level to provide some set of specified work assignment. The following user hierarchy of the current system is shown in Figure \ref{FigUH}. Notice how the representation is described as a Directed Acyclic Graph, a finite set of modules in phase from the higher levels to the lower levels of the hierarchy with no apparent recurring cycles. Hence the design pattern ensure that the decomposition has been done correctly and the definition of the design can now be distributed amongst the various groups that relate to the context of the Module Guide.
In this section of the Module Guide, the system has already been decomposed into the desired modular structure and characterized by determining the connection between the initial requirements and anticipated changes to those modules. The uses hierarchy presented in this section compares the independent modules with each other to find the common grounds on which modules uses the instance of another. This practice ensures the correctness of the program when it comes to testing as well as a reference to the integration procedure if the design of the system experiences a major change. For instance, if we model a scenario where Module A uses Module B, then all of the parameters that rely on both modules have to be specified to ensure that the valid output of Module B can be efficiently used in Module A to proceed with the execution of the design. This hierarchy also represents the testing environment, as Module A and Module B would first be tested independently, and then the correlation between the shared parameters of both modules. In theory, Module A would present a similar module entity as it is categorized in the higher level of the hierarchy and relies on Module B on the lower level to provide some set of specified work assignment. The following user hierarchy of the current system is shown in Figure \ref{FigUH}. Notice how the representation is described as a Directed Acyclic Graph, a finite set of modules in phase from the higher levels to the lower levels of the hierarchy with no apparent recurring cycles. Hence the design pattern ensures that the decomposition has been done correctly and the definition of the design can now be distributed amongst the various groups that relate to the context of the Module Guide.
