Merge branch 'master' of https://gitlab.cas.mcmaster.ca/andrem5/RogueReborn

.gitignore

@@ -4,6 +4,7 @@
 # Compiled files
 *.exe
 *.o
+*.synctex.gz
 
 # Editor files
 *.swp
@@ -16,4 +17,4 @@
 .idea/*
 
 # Library files
-src/*.so
+src/*.so
\ No newline at end of file

Doc/DevelopmentPlan/DevelopmentPlan.out

+\BOOKMARK [1][-]{section.1}{Team Meeting Plan}{}% 1
+\BOOKMARK [1][-]{section.2}{Team Communication Plan}{}% 2
+\BOOKMARK [1][-]{section.3}{Team Member Roles}{}% 3
+\BOOKMARK [1][-]{section.4}{Git Workflow Plan}{}% 4
+\BOOKMARK [1][-]{section.5}{Proof of Concept Demonstration Plan}{}% 5
+\BOOKMARK [1][-]{section.6}{Technology}{}% 6
+\BOOKMARK [1][-]{section.7}{Coding Style}{}% 7
+\BOOKMARK [1][-]{section.8}{Project Schedule}{}% 8
+\BOOKMARK [1][-]{section.9}{Project Review}{}% 9

Doc/DevelopmentPlan/DevelopmentPlan.tex

@@ -2,56 +2,135 @@
 
 \usepackage{booktabs}
 \usepackage{tabularx}
+\usepackage{indentfirst}
+\usepackage{hyperref}
 
-\title{SE 3XA3: Development Plan\\Title of Project}
+\title{SE 3XA3: Development Plan\\Rogue Reborn}
 
-\author{Team \#, Team Name
-		\\ Student 1 name and macid
-		\\ Student 2 name and macid
-		\\ Student 3 name and macid
+\author{Group \#6, Team Rogue++\\\\
+	\begin{tabular} {l l}
+		Ian Prins & prinsij \\
+		Mikhail Andrenkov & andrem5 \\
+		Or Almog  & almogo
+	\end{tabular}
 }
 
-\date{}
+\date{Friday, September 30, 2016}
 
 \input{../Comments}
 
 \begin{document}
 
-\begin{table}[hp]
-\caption{Revision History} \label{TblRevisionHistory}
-\begin{tabularx}{\textwidth}{llX}
-\toprule
-\textbf{Date} & \textbf{Developer(s)} & \textbf{Change}\\
-\midrule
-Date1 & Name(s) & Description of changes\\
-Date2 & Name(s) & Description of changes\\
-... & ... & ...\\
-\bottomrule
-\end{tabularx}
+\begin{table}[hp]s
+	\caption{Revision History} \label{TblRevisionHistory}
+	\begin{tabularx}{\textwidth}{llX}
+		\toprule
+		\textbf{Date} & \textbf{Developer(s)} & \textbf{Change}\\
+		\midrule
+		09/23/2016 & Or & Created outline .tex\\
+		09/25/2016 & Ian & Added Meeting Plan, Team Roles, and Proof of Concept Plan \\
+		09/25/2016 & Mikhail & Added Communication Plan and Technology\\
+		09/26/2016 & Mikhail & Added Git Workflow Plan\\
+		09/30/2016 & Mikhail & Edited and Proofread Document\\
+		09/30/2016 & Or & Added Coding Style \& Project Schedule\\
+		09/30/2016 & Or & Fixed typos\\
+		09/30/2016 & Mikhail & Added More Hyperlinks\\
+		... & ... & ...\\
+		\bottomrule
+	\end{tabularx}
 \end{table}
 
 \newpage
 
 \maketitle
 
-Put your introductory blurb here.
+\indent
+The Rogue Reborn project aims to rewrite the classic video game \textit{Rogue} in a modern programming language using contemporary software development techniques.  The purpose of this document is to outline the development plan of the project.  Included below are the strategies for \hyperref[communication_label]{team coordination} and \hyperref[roles_label]{work partitioning}, details of the \hyperref[tech_label]{technology} and \hyperref[workflow_label]{development process}, and an overview of the \hyperref[schedule_label]{project schedule} including details of the requirements for the \hyperref[poc_label]{proof of concept} deadline.
 
 \section{Team Meeting Plan}
+\label{meeting_label}
+
+\indent
+Team meetings will be held on a weekly basis in Thode library at 3:30 PM every Wednesday.  These weekly meetings will be chaired by the team leader whose will be responsible for developing and enforcing a rough meeting agenda.  Although this agenda will not be posted, it will be briefly outlined for the participants of the meeting.  In addition, full meeting minutes will not be recorded; however, the meeting scribe will be responsible for recording the outcomes of the meeting discussions.  These transcripts will be posted to the team Git repository.  If a team member cannot attend the meeting, a brief summary of the meeting (including a reference to the Git commit) will be posted to the team Slack channel by the meeting scribe.  Any changes to the meeting format, location, or time will also be posted to the team Slack channel by the meeting chair.
 
 \section{Team Communication Plan}
+\label{communication_label}
+
+\indent
+Team communications will be distributed across several social platforms.  This way, conversations can be grouped together according to the degree of formality and desired visibility.  Specifically, Slack will be used to exchange informal messages for purposes such as conveying meeting times or briefly discussing topics.  Team members will be required to check this service at least once per day in order to facilitate quicker response times and encourage more open communication.  Next, the GitLab ITS will serve as an official means of tracking bugs, reporting issues, and announcing any other code correction requests.  All other communications will be performed in person during the lab sessions as well as the weekly group meeting.  Currently, there is no plan to include any other communication streams as this will most likely dilute the conversations to a point where accessibility and traceability is sacrificed.
 
 \section{Team Member Roles}
+\label{roles_label}
+
+\indent
+As of the initial submission of this document, Mikhail is the team leader.  As such, he will be responsible for chairing the meetings, allocating work across the team, and ensuring that all of the team members are up-to-date with respect to the project status and deadlines.  The other team members will alternate between fulfilling the role of the meeting scribe. Outside of meetings, various team members will assume the roles of experts in the project technology area.  In particular, Mikhail will be the Git and LaTeX expert, Ori will be the testing and Linux environment expert, and Ian will be the C++ and \textit{libtcod} expert (more on this library in the \hyperref[tech_label]{Technology} section).  Expert roles do not constitute work allocations; rather, they assign accountability for certain portions of the project and provide a contact for internal questions related to a specific domain.
 
 \section{Git Workflow Plan}
+\label{workflow_label}
+
+\indent
+To minimize the overhead associated with creating, updating, and managing project files, the Rogue++ team will collaborate using several Git integration flows.  In general, all project source files and documents associated with the main (stable) development branch will be hosted in a central GitLab repository.  Any developers (or distinguished stakeholders) may clone, view, and modify this code, given that their changes do not compromise any tested functionality.  Note that it is still acceptable to commit a change to this branch that is not fully integrated; however, the application must be able to successfully compile and run.  In the event that a prototype demonstration is required, a new branch will be created to host any temporary changes that will not be merged back into the main branch.  This way, developers are free to adapt existing source code in any manner they choose in order to showcase their progress to a stakeholder without violating the integrity of the stable branch.\\
+
+To create a semantic history of the development process, labels will be used extensively throughout the course of the Rogue Reborn project.  This will enable stakeholders to oversee the progress of the project more clearly and developers to gauge their own productivity with greater ease.  Milestones will also be incorporated as a means of measuring the progress of the application against the goals of the stakeholders.  These milestones may also be used internally within the Rogue++ team to coordinate feature implementation or debug deadlines. If done correctly, this system will allow for more efficient communication between the involved parties and improve the visibility of the entire development cycle.
 
 \section{Proof of Concept Demonstration Plan}
+\label{poc_label}
+
+\indent
+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
+	\item Line of sight and pathfinding implementation
+	\item Non-functional items and traps
+	\item Minimum viable monster AI
+	\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.\\	
+
+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.
 
 \section{Technology}
+\label{tech_label}
+
+\indent
+The technology behind the Rogue Reborn project was selected to facilitate a productive development process and a powerful user experience. At its very core, C++ will serve as the primary programming language for this application.  This decision was heavily influenced by the superior performance benefits and community support behind the language, not to mention its prevalence in the professional game developer industry.  Another factor that motivated the use of C++ was its compatibility with \href{http://roguecentral.org/doryen/libtcod/}{\textit{libtcod}}: a lightweight graphics library that offers a simple interface to draw ASCII-style art and collect user input.  For these reasons, the development team believes that developing a C++ project would yield the best experience from both a technical and practical perspective.\\
+
+With respect to the environment of the technology, the Rogue++ team agreed to use Linux as the primary development platform (attempting to achieve cross-platform portability from the start could significantly hinder progress).  Otherwise, every team member is free to use a text editor of their choice: imposing a constraint on an IDE could result in unnecessary complications and may interfere with productivity during the early coding stages.  To gain confidence in the correctness and versatility of the code, the \href{http://www.boost.org/doc/libs/1_54_0/libs/test/doc/html/index.html}{Boost Test} framework will be heavily utilized to perform unit testing across the project.  This library was selected on the merits of its superb documentation, simple approach to test creation, and robust assertion support.  On a final note, the Rogue Reborn documentation will be generated using two tools.  Specifically, all design documentation will be generated using LaTeX, while all source code documentation will be delegated to the Doxygen tool.
 
 \section{Coding Style}
+\label{style_label}
+
+\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 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.
 
 \section{Project Schedule}
+\label{schedule_label}
+
+\indent
+Over the course of a one-hour meeting, the Rogue++ team decided on an overarching timeline for the development of the project.  The timeline consists of several components, tasks, and deadlines that occasionally overlap.  This timeline exists as a way of benchmarking the project's completeness; a guideline, not a rulebook.  It will be wise to refer back to this schedule at least once a week (most likely during the weekly meetings), update the project status accordingly, and assess any complications that could arise.  The schedule will be created in the form of a Gantt chart (soon to be made available).  Listed below are the deadlines that were established in the previous team meeting:
+
+\bigskip
+
+\begin{table}[h!]
+	\centering
+	\caption{\textbf{Project Deadlines}}
+	\bigskip
+	\begin{tabular}{lll}
+		Requirements Document				&	Sept 26	&	Oct 7\\
+		Milestone 1	(Rev -1)				&	Oct 10	&	Oct 14 (Break)\\
+		Technology Exploration				&	Oct 17	&	Oct 21\\
+		Test Plan + Boost Integration 		&	Oct 24	&	Oct 28\\
+		Design Document						&	Oct 31	&	Nov 11\\
+		Revision 0 (Milestone 2)			&	Oct 21	&	Nov 19\\
+		Revision 1 Fixes (Milestone 3)		&	Nov 18	&	Nov 30\\
+		Final Design Document				&	Nov 26	&	Dec 7
+	\end{tabular}
+\end{table}
 
-Provide a pointer to your Gantt Chart.
+\section{Project Review}
 
 \end{document}
\ No newline at end of file

Doc/DevelopmentPlan/Gantt Ideas.txt

+Require Docs				Sep 26		Oct 7
+Milestone 1	(Rev -1)		Oct 10		Oct 14 (Break)
+Explore Tech				Oct 17		Oct 21
+BOOST + Test Plan			Oct 24		Oct 28
+Design Doc 					Oct 31		Nov 11
+Rev 0 (Milestone 2)			Oct 21		Nov 19
+Rev 1 fixes	(Milestone 3)	Nov 18		Nov 30
+Design Doc Final			Nov 26		Dec 7

Doc/DevelopmentPlan/ProposedUTFrameworks.txt

+upp11
+tinytest
+Boost
+CppUTest
+CUTE
+Fructose
+Google test
+NullUnit
+mockpp
+

Doc/DevelopmentPlan/README.md

 # Development Plan
 
 The folders and files for this folder are as follows:
-
-Describe ...
+<p><br></br></p>
+| File | Description |
+| -------- | ------- |
+| **DevelopmentPlan.pdf** | Official development plan document |
+| ProblemStatement.tex | TeX file which generates the development plan PDF |
+| DevPlanMarkingScheme.pdf | Marking scheme reference |
+| Gantt Ideas.txt | Rough deadline estimates |
+| ProposedUTFrameworks.txt | List of unit test frameworks under consideration |
+| WorkDist.txt | Distribution of work for the development plan |

Doc/DevelopmentPlan/WorkDist.txt

+Ian
+
+Team meeting plan
+Team Member Roles
+Proof of concept demonstration plan
+
+
+Mikhail
+
+Team communication plan
+Technology
+Git workflw plan
+
+
+Ori
+
+Coding style
+Project Schedule + Gantt Chrt
+

Doc/SRS/SRS.bib

+%% This BibTeX bibliography file was created using BibDesk.
+%% http://bibdesk.sourceforge.net/
+
+%% Created for Spencer Smith at 2016-09-22 10:01:42 -0400 
+
+
+%% Saved with string encoding Unicode (UTF-8) 
+
+
+
+@book{RobertsonAndRobertson2012,
+	Author = {James Robertson and Suzanne Robertson},
+	Date-Added = {2016-09-22 13:54:40 +0000},
+	Date-Modified = {2016-09-22 14:01:42 +0000},
+	Edition = {16},
+	Publisher = {Atlantic Systems Guild Limited},
+	Title = {Volere Requirements Specification Template},
+	Year = {2012}}
+
+@article{ParnasAndClements1986,
+	Author = {David L. Parnas and P.C. Clements},
+	Date-Added = {2016-09-10 13:11:57 +0000},
+	Date-Modified = {2016-09-10 13:11:57 +0000},
+	Journal = {IEEE Transactions on Software Engineering},
+	Number = {2},
+	Pages = {251--257},
+	Title = {A Rational Design Process: How and Why to Fake it},
+	Volume = {12},
+	Year = {February 1986},
+	Bdsk-File-1 = {YnBsaXN0MDDUAQIDBAUGJCVYJHZlcnNpb25YJG9iamVjdHNZJGFyY2hpdmVyVCR0b3ASAAGGoKgHCBMUFRYaIVUkbnVsbNMJCgsMDxJXTlMua2V5c1pOUy5vYmplY3RzViRjbGFzc6INDoACgAOiEBGABIAFgAdccmVsYXRpdmVQYXRoWWFsaWFzRGF0YV8QQy4uLy4uLy4uLy4uL3NlNHNjL1NjaUNvbXBBbmRTb2Z0RW5nUGFwZXJzL1Bhcm5hc0FuZENsZW1lbnRzMTk4Ni5wZGbSFwsYGVdOUy5kYXRhTxEB9gAAAAAB9gACAAAMTWFjaW50b3NoIEhEAAAAAAAAAAAAAAAAAAAA0khroUgrAAAAhfxhGVBhcm5hc0FuZENsZW1lbnRzMTk4Ni5wZGYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACF/LDT7aEvAAAAAAAAAAAABAADAAAJIAAAAAAAAAAAAAAAAAAAABdTY2lDb21wQW5kU29mdEVuZ1BhcGVycwAAEAAIAADSSKPhAAAAEQAIAADT7dlvAAAAAQAUAIX8YQCF7/8AILODAAlg3gAGKpoAAgBcTWFjaW50b3NoIEhEOlVzZXJzOgBzbWl0aHM6AFJlcG9zOgBzZTRzYzoAU2NpQ29tcEFuZFNvZnRFbmdQYXBlcnM6AFBhcm5hc0FuZENsZW1lbnRzMTk4Ni5wZGYADgA0ABkAUABhAHIAbgBhAHMAQQBuAGQAQwBsAGUAbQBlAG4AdABzADEAOQA4ADYALgBwAGQAZgAPABoADABNAGEAYwBpAG4AdABvAHMAaAAgAEgARAASAEpVc2Vycy9zbWl0aHMvUmVwb3Mvc2U0c2MvU2NpQ29tcEFuZFNvZnRFbmdQYXBlcnMvUGFybmFzQW5kQ2xlbWVudHMxOTg2LnBkZgATAAEvAAAVAAIADf//AACABtIbHB0eWiRjbGFzc25hbWVYJGNsYXNzZXNdTlNNdXRhYmxlRGF0YaMdHyBWTlNEYXRhWE5TT2JqZWN00hscIiNcTlNEaWN0aW9uYXJ5oiIgXxAPTlNLZXllZEFyY2hpdmVy0SYnVHJvb3SAAQAIABEAGgAjAC0AMgA3AEAARgBNAFUAYABnAGoAbABuAHEAcwB1AHcAhACOANQA2QDhAtsC3QLiAu0C9gMEAwgDDwMYAx0DKgMtAz8DQgNHAAAAAAAAAgEAAAAAAAAAKAAAAAAAAAAAAAAAAAAAA0k=}}

Doc/SRS/SRS.tex

+\documentclass[12pt, titlepage]{article}
+
+\usepackage{booktabs}
+\usepackage{tabularx}
+\usepackage{hyperref}
+\hypersetup{
+    colorlinks,
+    citecolor=black,
+    filecolor=black,
+    linkcolor=red,
+    urlcolor=blue
+}
+\usepackage[round]{natbib}
+
+\title{SE 3XA3: Development Plan\\Title of Project}
+
+\author{Team 6, Team Rogue++
+		\\ Ian Prins prinsij
+		\\ Mikhail Andrenkov andrem5
+		\\ Or Almog almogo
+}
+
+\date{October 7, 2016}
+
+\input{../Comments}
+
+\begin{document}
+
+\maketitle
+
+\pagenumbering{roman}
+\tableofcontents
+\listoftables
+\listoffigures
+
+\begin{table}[bp]
+\caption{\bf Revision History}
+\begin{tabularx}{\textwidth}{p{3cm}p{2cm}X}
+\toprule {\bf Date} & {\bf Version} & {\bf Notes}\\
+\midrule
+September 28, 2016 & 1.0 & initial setup\\
+\bottomrule
+\end{tabularx}
+\end{table}
+
+\newpage
+
+\pagenumbering{arabic}
+
+This document describes the requirements for ....  The template for the Software
+Requirements Specification (SRS) is a subset of the Volere
+template~\citep{RobertsonAndRobertson2012}.  If you make further modifications
+to the template, you should explicity state what modifications were made.
+
+\section{Project Drivers}
+
+\subsection{The Purpose of the Project}
+
+\subsection{The Stakeholders}
+
+\subsubsection{The Client}
+
+\subsubsection{The Customers}
+
+\subsubsection{Other Stakeholders}
+
+\subsection{Mandated Constraints}
+
+\subsection{Naming Conventions and Terminology}
+
+\subsection{Relevant Facts and Assumptions}
+
+User characteristics should go under assumptions.
+
+\section{Functional Requirements}
+
+\subsection{The Scope of the Work and the Product}
+
+\subsubsection{The Context of the Work}
+
+\subsubsection{Work Partitioning}
+
+\subsubsection{Individual Product Use Cases}
+
+\subsection{Functional Requirements}
+
+\section{Non-functional Requirements}
+
+\subsection{Look and Feel Requirements}
+
+\subsection{Usability and Humanity Requirements}
+
+\subsection{Performance Requirements}
+
+\subsection{Operational and Environmental Requirements}
+
+\subsection{Maintainability and Support Requirements}
+
+\subsection{Security Requirements}
+
+\subsection{Cultural Requirements}
+
+\subsection{Legal Requirements}
+
+\subsection{Health and Safety Requirements}
+
+This section is not in the original Volere template, but health and safety are
+issues that should be considered for every engineering project.
+
+\section{Project Issues}
+
+\subsection{Open Issues}
+
+\subsection{Off-the-Shelf Solutions}
+
+\subsection{New Problems}
+
+\subsection{Tasks}
+
+\subsection{Migration to the New Product}
+
+\subsection{Risks}
+
+\subsection{Costs}
+
+\subsection{User Documentation and Training}
+
+\subsection{Waiting Room}
+
+\subsection{Ideas for Solutions}
+
+\bibliographystyle{plainnat}
+
+\bibliography{SRS}
+
+\newpage
+
+\section{Appendix}
+
+This section has been added to the Volere template.  This is where you can place
+additional information.
+
+\subsection{Symbolic Parameters}
+
+The definition of the requirements will likely call for SYMBOLIC\_CONSTANTS.
+Their values are defined in this section for easy maintenance.
+
+
+\end{document}
\ No newline at end of file