Design  Document

                          Final Turnin Update

=============================================================================== With a very small number of exceptions, I believe that I have at least met my vision of what the end result should be. I am thankful that I had to cut very few of the original ideas from the final result.

A brief description of the game: I have been using the working title for my game "ROgre", which is a composite of Rogue, the game after which mine is modeled, and Ogre, the rendering system for my game. One of the best features ROgre has to offer the player is customization. When creating the game, the player has the option to name his or her character and adjust many of the game's settings to make the game as easy or difficult as the player wishes. These features are:

• Seed This is what the game's PRNG is seeded with. Supplying the same seed in different generations will cause the same exact game to be generated twice which allows a player to play another player's "world" or repeat a past game in the exact same way.

• Starting monster level By default, monsters start out at the same level as you are and increase by 1 every time the player descends further into the game. If the player desires a harder game, he or she can simply increase this value (max 20).

• Starting monster difficulty This increases the power of the monster by a direct percentage. Default is 50% and goes up to 200%. This multiplier affects every monster's hitpoints, armor and strength.

• Blind mode If enabled, blind mode causes previously explored rooms to be hidden again.

Another great feature of ROgre is that everything is randomized to provide for unique experiences across multiple playthroughs. I believe this is the signature for every Roguelike game out there. Rooms are randomly generated and doors are randomly placed. Chests contain a random number of random items. Monsters are randomly generated in rooms with randomly generated names and randomly generated loot that drops when they are killed.

ROgre is also quite easily mod-able. Inside the data/ folder, there are a few text files which contain the data for almost every major aspect in the game and can be easily modified by the player to change the feel of the game in a few different ways. Most notable of these modifiable features are:

• Item names and descriptions The player can modify an item's name, description, rare items and adjectives which can spawn on equippable items.

• Monster names The player can modify the first, last, prefix and suffix titles that can spawn on a monster.

• Tips These are the strings that are displayed when the player is loading the game. Do note that these files are quite sensitive, so the format must be strictly followed or the game may crash during runtime.

ROgre allows for continuation. The player can save his or her game, quit and come back to it at any point and continue their progress. Everything is saved, but the room is regenerated (which can allow for exploits, unfortunately).

                       Second Milestone Update

=============================================================================== I feel as though a lot of work has been done for this update. For starters, I have added the Player as a Game Object, currently represented as a Ninja. The user can move the Player object by clicking within the world; it is animated and turns toward the direction it is walking.

I have also implemented a rudimentary Zone generator that simply creates N rooms, given a seed (currently set by time(NULL) so this feature can be easily demonstrated without recompilation), and randomly positions them in the game world by picking a wall to add another room to. I am satisfied with the Zones generated by this algorithm and probably won't be changing it.

The actually Room generation has not yet been implemented, though it does spawn a "monster" in a random location within the Room. I plan to add chests and make monsters randomly spawn in random numbers so that not every Room will contain exactly 1 monster.

Since we do not have a real monster mesh that is animated, I am using the Ogre Head mesh that bounces in the game world.

I have also added simple path-finding that seeks out the player and moves itself toward him/her until it is within range (defined as 1.0 unit, but can be changed for other types of monsters). I have drawn out basic logic in comments within the EntityObject's update() function but none of it is currently implemented. In short, the Entity will first check if it can see the player before attempting to run toward it.

Walls do not block pathing (in part because I have yet to add doors to the game) but neither the Player nor the monsters can walk off the Zone.

                        First Milestone Update

=============================================================================== Most of the work that we have completed so far has been dedicated to sketching our a solid design in the code for us to follow for the rest of development. However, we do have a runnable application that displays two Room game objects that were created within the rules of our design.

When our game is completed, we will have no keyboard movement - all the movement of the player's character will be via mouse clicks as is typical in modern dungeon crawlers. For now, we have enabled left (A) and right (D) panning of the camera so that you can see that two rooms are displayed.

I have included a couple of images that lay out some design features that we will be implementing in this game.

To summarize, this is what I have designed for our game: Firstly, I have segmented the code into two distinct categories: game objects and game mechanics.

Game Objects
* An ObjectManager Singleton class manages all of our Game Objects (e.g., 
  Room and Monster objects) and allows for their addition into the game.
  Objects must be added this way so that they can be updated for rendering 
  and allow for input handling from the user's mouse and keyboard. 
* Game Objects are created by their Game Mechanic counterparts. That is, a
  RoomObject is spawned by the Room class when appropriate.
* To make this easier, all Game Objects are contained in the gameobjects/
  directory.

Game Mechanics
* As previously mentioned, classes that fall into this category have a 
  corresponding Game Object, which is their graphical realization within 
  the game world.
* I am using a hierarchy of classes to closely mirror the abstract concept
  of the game. 
    - A World class is the entire game world, represented as Game Mechanics
      classes. It contains a Player and is responsible for loading new 
      Zones when the user starts the game and when the user takes a Nexus 
      to another Zone.
    - A Player is an Entity (as is a Monster) with an Inventory of Items 
      and gold.
    - A Zone is a collection of Rooms within the World with at least one
      Nexus.
    - A Room is a collection of Loot (the game world's representation of 
      Items), Entities and Doodads.
    - A Nexus is a stairway or some other means of travel from one Zone to
      the next.
    - A Doodad is an object with which the user can interact, like Chests
      and Doors.  
    - A Chest is a collection of Items.
    - A Door connects two Rooms together.

===============================================================================

                             Overall Design

=============================================================================== We are planning on making a simple dungeon crawler as our final project. We will be looking into other dungeon crawlers like Rogue (1980), Diablo and the like for our inspiration when designing the gameplay. Unlike more modern dungeon crawlers (like Diablo 3), our game will not be as action- oriented; instead, our players will be focused on trying to survive while descending further and further into an infinite, randomly generated world, collecting items and fighting monsters.

                      Software Architecture & Plan

=============================================================================== Our first goal is to create a very basic engine as we will be starting this game from scratch as opposed to using our previous game engines. The camera will be locked from a top-down perspective (as in your typical action RPG) but we may allow for a mousewheel zoom-in feature if required or desired.

Initially, we will just create one or two hard-coded levels instead of procedurally generating them for testing purposes. We may find at a later date that procedurally generated levels are not going to be implemented by the deadline and we will end up leaving these hard-coded levels in the game.

Our player object will be comprised of several attributes: strength, armor and health. These can be boosted by items that are randomly generated when dropped by a monster.

We plan on using as many textures from the Ogre library as possible, but we may have to look other places for textures that we want but aren't in the library by default.

The AI for our monsters will most likely be very rudimentary to begin with and we may expand it later if we have time. Our goal for the AI is to make sure that our monsters will eventually find and attack the player when the player is near enough. As long as the monster doesn't get stuck somewhere or ignore the player right in front of it, we will be happy.

We want sound effects for when the player moves and when an attack is performed at the very least. We might also get some ambient sound effects if we are able to find some.

                           Division of Labor

=============================================================================== Nick Plans on working on monster and player models for the game. He will also be in charge of implementing the physics for collisions with the help of Matt. Also will be responsible for creating the GUI for the game.

Alex Responsible for locating sound files that we can use in our game. Will be looking into AI for our monsters and gathering some textures for items and rooms. He will be helping Nick with the GUI stuff.