@@ -70,7 +70,7 @@ To create a semantic history of the development process, labels will be used ext
\section{Proof of Concept Demonstration Plan}
\indent
To demonstrate the feasibity of the project, a proof of concept (PoC) will be developed. The PoC will demonstrate the following features:
To demonstrate the feasibility of the project, a proof of concept (PoC) will be developed. The PoC will demonstrate the following features:
\begin{itemize}
\item Basic dungeon generation, including rooms, corridors, and placement of gold, items, monsters, and traps
...
...
@@ -80,7 +80,7 @@ To demonstrate the feasibity of the project, a proof of concept (PoC) will be de
\item Basic movement and very simple environmental interaction (acquiring items, basic combat)
\end{itemize}
If there are no issues implementing the features above, it shall be assumed that there are no fundamental flaws with the requirements or architectural design of the project. Several major features of the project have been excluded from this demonstration (advanced item manipulation and traps, hidden passageways, complex monster AI, etc.) because the PoC is otherwise too ambitious. As long as the underlying code is well-architectured, the more sophisticated features of the application should be able to flow out of the PoC foundation.\\
If there are no issues implementing the features above, it shall be assumed that there are no fundamental flaws with the requirements or architectural design of the project. Several major features of the project have been excluded from this demonstration (advanced item manipulation and traps, hidden passageways, complex monster AI, etc.) because the PoC is otherwise too ambitious. As long as the underlying code is well-architectured, the more sophisticated features of the application should be able to flow out of the PoC foundation.\\
On a positive note, it is unlikely that a straight-forward implementation of the PoC features will prove to be unusually difficult. However, implementing these features in a sufficiently extensible manner (so that they can be reused without readjustment) will undoubtedly be more challenging. It is also important to realize that the reverse-engineering process of the algorithms for various features from the original source will also incur significant effort. From a testing perspective, the Rogue++ development team is relatively new to testing frameworks. As such, writing unit and integration tests may initially take some additional time. At this point in time, the project is planned to be solely developed in a Linux environment; all of the required library dependencies have been installed and a test application of the game is successfully compiling and on all of the developers' machines.
...
...
@@ -97,7 +97,7 @@ With respect to the environment of the technology, the Rogue++ team agreed to us
\indent
In any large-scale project, it is vital for all members to be on the same page. This is especially true for a software project, where every team member must be able to read, understand, and analyze everyone else's code. The Rogue++ project will be utilizing \href{https://google.github.io/styleguide/cppguide.html}{Google's C++ Style Guide} to format and organize the source code. Google offers style guides that span dozens of programming languages and are a professional standard used in every corner of the software industry. Despite its excellence, the team will implement one change to the guide.\\
Google's C++ Style Guide calls for inline comments describing classes, functions, methods, and file contents. While this is a noble goal (and is most definitely necessary), this job has been delegated elsewhere. As mentioned before, the Rogue++ team will be using the Doxygen tool for documenting the source code structure. Doxygen will effectvely encapsulate the design-documentation sphere. The only real diference this will make is the addition of Doxygen's documentation syntax on top of Google's comment standard.
Google's C++ Style Guide calls for inline comments describing classes, functions, methods, and file contents. While this is a noble goal (and is most definitely necessary), this job has been delegated elsewhere. As mentioned before, the Rogue++ team will be using the Doxygen tool for documenting the source code structure. Doxygen will effectively encapsulate the design-documentation sphere. The only real difference this will make is the addition of Doxygen's documentation syntax on top of Google's comment standard.
