diff options
Diffstat (limited to 'plan.tex')
| -rw-r--r-- | plan.tex | 24 |
1 files changed, 12 insertions, 12 deletions
@@ -38,18 +38,18 @@ Finally, because the client does not want to dive deeply into the engine himself \subsection{Goal} -The goal is to develop a custom game engine that meets the client's requirements for maintainability, extensibility, user-friendliness, and adherence to a Unity-like structure. The engine may integrate third-party software (as agreed with the client) to support specific features, such as audio, physics, and rendering. In addition, a validation application is created to show and test the engine's features. +The goal is to develop a custom game engine that meets the client's requirements for maintainability, extensibility, user-friendliness, and adherence to a Unity-like structure. The engine may integrate third-party software (as agreed with the client) to support specific features, such as audio, physics, and rendering. In addition, a \emph{validation application} is created to show and test the engine's features. \subsection{Scope} The requirements document \autocite{crepe:requirements} has several requirements with a MoSCoW `must', `should', `could' or `won't' priority to indicate the project's scope. \subsection{Result} -The expected result is a well-documented, custom game engine that follows a structure similar to Unity. Additionally, a validation application should be provided to test and showcase the engine's capabilities. +The expected result is a well-documented, custom game engine that follows a structure similar to Unity. Additionally, a \emph{validation application} should be provided to test and showcase the engine's capabilities. -\subsection{validation application} +\subsection{Validation Application} -The validation application \autocite{crepe:validation-application} is explained in a document where the features of the validation application are linked to the user stories. +The \emph{validation application} \autocite{crepe:validation-application} is explained in a document where the features of the \emph{validation application} are linked to the user stories. \section{Planning} @@ -61,9 +61,9 @@ The customer specified multiple deliverables throughout the 20 weeks of this pro \textbf{Week\#} & \textbf{Deliverable}\\ \midrule 4 & Project Plan\\ - 7 & POCs\\ + 7 & Some POCs\\ 10 & POCs and Design document\\ - 17 & Game engine, Validation application\\ + 17 & Game engine, \emph{validation application}\\ \bottomrule \end{tabularx} \caption{Planning} @@ -139,28 +139,28 @@ protocols for handling absences or delays, guidelines for addressing inconsisten participation, and procedures for weekly updates and meetings. All team members reviewed and agreed to these terms. -\subsection{Project roles} +\subsection{Project Roles} \begin{description} \item[Loek Le Blansch] Integrator \item[Wouter Boerenkamps] Project Member \item[Jaro Rutjes] Team Leader / Scrum Master - \item[Max Smits] Project Member / Product owner + \item[Max Smits] Project Member / Product Owner \item[Niels Stunnebrink] Project Member \end{description} -\subsection{Work hours} +\subsection{Work Hours} Each project member will keep track of their own working hours and add them to the `file'. -\subsection{Absence or delay} +\subsection{Absence or Delay} If a project member is going to be absent or delayed, they are required to notify the team through either WhatsApp or Outlook. Additionally, the teacher should be informed of the absence as well. -\subsection{Inconsistent participation} +\subsection{Inconsistent Participation} Inconsistent participation will be addressed in a structured manner: @@ -258,7 +258,7 @@ documentation \autocite{crepe:docs-repo}, each in its own respective repository. keeps the documentation and code separate, resulting in ordered and manageable repositories. -\subsection{Code Standard and git workflow} +\subsection{Code Standard and Git Workflow} The code standard and the git workflow can be found in the contributing.md \autocite{crepe:code-standard}. |