@@ -190,6 +190,8 @@ It is assumed users will be utilizing the product in a 64 bit Linux environment,
\freq{The player should be able to pass the turn}\\
\freq{The player should be able to walk around}\\
\freq{The player should be able to open and close doors}\\
\freq{The player must be able to fall under status effects}\\
\freq{The player }\\
\end{tabular}
\subsubsection{The Dungeon}
...
...
@@ -200,8 +202,8 @@ It is assumed users will be utilizing the product in a 64 bit Linux environment,
\freq{Every level must generate rooms, corridors, monsters, treasure, and traps}\\
\freq{The player must be able to see in a 3x3 square centered on the hero}\\
\freq{The player must be able to see the entire room the hero is in, if the hero is in a room}\\
\freq{The player should see the outline of dungeon areas previously explored}\\
\freq{The player should be able to search for hidden doors}\\
\freq{The player should see the \textit{outline} of dungeon areas previously explored}\\
\freq{The player should be able to search for hidden doors and traps}\\
\freq{The player should not be able to see hidden doors without explicitly searching for them}\\
\freq{The Amulet of Yendor must be generated in level 26}\\
\end{tabular}
...
...
@@ -380,8 +382,10 @@ It is assumed users will be utilizing the product in a 64 bit Linux environment,
The waiting room prescribes objectives, requirements, and features that could be implemented in future iterations. The following is a list of such features, for which consideration was given but time could not allow for:
\begin{itemize}
\item\textbf{More Monsters} - The original Rogue has 1 monster per letter of the alphabet, for a total of 26. This is very small number, especially when compared to modern video games. By using different colours, or a tile-set as mentioned above, it is possible to achieve a far greater number of enemies to challenge the player. This
\item\textbf{Infinite Descent} - The concept of a never-ending game is not new. And when dungeon levels are generated on the fly, would not be hard to implement at all. An infinite dungeon would turn the mastery of the game around. Currently, the ''best'' run-through is the one that accomplishes the end goal in the fewest moves. With infinite descent possible, the best run would turn into the one that reached the deepest levels, which of course get progressively more difficult.
\item\textbf{More Monsters} - The original Rogue has 1 monster per letter of the alphabet, for a total of 26. This is very small number, especially when compared to modern video games. By using different colours or a tile-set (see 4.10), it is possible to achieve a far greater number of enemies to challenge the player.
\item\textbf{Infinite Descent} - The concept of a never-ending game is not new. And when dungeon levels are generated on the fly, would not be hard to implement at all. An infinite dungeon would turn the mastery of the game around. Currently, the ''best'' run-through is the one that accomplishes the end goal in the fewest moves and most gold. With infinite descent possible, the best run would knock out end goal from the equation - turning the goal of the game into a strict function of acquired wealth. As the player descends, the levels would become progressively more difficult, and generate more gold for the player to collect.
\item\textbf{Seed Sharing} - A seed is a sequence of bits that dictate which numbers the ''random'' number generator will create. If two separate pseudo-random number generators use the same seed for instantiation, the two will generate the same ''random'' numbers. A direct consequence of this is the ability to generate the same dungeon repeatedly, all one needs is the seed. This would be useful for determining who really is the better Rogue player, as some dungeons may require more steps to complete the end goal.\\
As a side note, for this to work, dungeon generation must not rely on the state of the player, for surely different players will take on the dungeon in different ways.
