@@ -104,13 +111,35 @@ This document describes the requirements for the Rogue Reborn project. The temp
\subsubsection{Other Stakeholders}
Other stakeholders include playtesters of the game, as well as the 3XA3 TAs. Playtesters of the game will be recruited to play the game, and therefore have stake in the success of the project. The 3XA3 TAs will be evaluating the success of the project, as well as providing feedback and guiding the project while it is still in development.
\subsection{Mandated Constraints}
As a constraint imposed by the project client, there are a number of deadlines for the project throughout its development. In particular, the final demonstration of functionality will be on november the 30th, and the final draft of the project documentation must be produced by the 8th of december. The goal of replicating the gameplay of the original without significant change restricts the platforms for which the project can be developed. In particular, the interface for the original is extremely ill-suited to touch-input environments such as phones and tablets.
\subsection{Naming Conventions and Terminology}
Listed below are a number of video game and/or roguelike specific terms used in this document.
\begin{itemize}
\item Rogue: Both the name of the 1980 computer game, and the a reference to the player character (we will always use the term player character).
\item Roguelike: A genre of games similar to Rogue. Membership in the roguelike genre is largely determined by the presence or absence of permadeath, but many games feature many more similarities.
\item Permadeath: A feature of roguelikes where the game is restarted from the beginning upon character death.
\item Hitpoints: A positive integer value that measures the health of a character (more is healthier).
\item Strength: A key statistic of the player character, strength determines how likely they are to successfully land a hit with a melee weapon and how much damage it is likely to do.
\item Item Identification: A common feature of roguelikes where items are scrabbled at the beginning of a game, with the player not knowing which corresponding to which effect. Certain effects or simply using these items can identify items. For example, a blue potions may be potions of healing in one game, but in the next they could be sleeping gas. Item identification also refers to determining whether a given item is cursed.
\item Cursed equipment: Equipment that once used reveal itself to be harmful to their user and difficult to remove.
\item Dungeon: Consisting of a stack of 30 floors, the dungeon forms the game world in Rogue.
\item Gold: Gold coins can be found throughout the dungeon, the number of gold coins collected is the primary basis for the player's score.
\item Level: Can refer to a floor of the dungeon, or to the player character's experience level, which determines their hitpoints.
\item Experience: Experience is gained by defeating monsters, and sufficient quantities will cause the player character to level up.
\item Searching: Certain features of the dungeon, such as traps and hidden doors are not immediately visible to the player. The player character can explicitly search their immediate surroundings for such features.
\end{itemize}
\subsection{Relevant Facts and Assumptions}
User characteristics should go under assumptions.
It is assumed users will be utilizing the product in a 64 bit Linux environment, with a keyboard and monitor of at least [INSERT DIMENSIONS]. Users are assumed to be at least moderately familiar with the original, no extra material describing how to play the game is planned to be produced.
User characteristics should go under assumptions. [DELETE]
\section{Functional Requirements}
...
...
@@ -348,4 +377,4 @@ additional information.
Their values are defined in this section for easy maintenance.
