Working Title Design Document

This is the design document for "Working Title" - a new browsergame project by one of the writers at http://buildingbrowsergames.com.

Brief Description

Working Title is going to be an online browsergame(or PBBG) modelled after old text adventure games. It will have a textbox for users to enter commands into, and will use Ajax to dynamically update the screen.

Features

Rooms

Users will move between rooms. When they are inside a room, that room's description will be displayed - along with clickable links to all of the (non-secret) exits of that room, and an explanation of any other players, monsters, or items within the room.

Monsters

There will be monsters in each(but not every) room, which users will have the option of attacking. Some monsters will be flagged as aggressive(this will be a database setting), meaning that they attack the player the moment he/she enters the room. Monsters, when defeated, will drop items which a player can pick up.

Items

Players will all have inventories. Their inventory will be limited to begin with - however, if they happen to obtain a Bag of Holding, their inventory limit will increase. A player can only have one "____ of holding" at a time - although a sack of holding is better than a bag, and a bag is better than a sock, and so on.

The Codex

The Codex will be an accessible area on the main website that displays all entities currently in the game - all monsters, items, and so on. It will use each object's toHTML() function to generate its display HTML, and users who have logged in will be able to comment on particular entities within the database.

Player Stats

Commands

This is a list of the commands that a user will be able to use anywhere.

• attack foo - attack a monster/player once. (can only attack a player in a PVP-allowed room).
• attack foo until dead - attacks a monster repeatedly until the monster is dead.
• equip foo - equip the item for the user - could be a weapon, armor, etc.
• unequip foo - unequip item(see above)
• pick up foo - picks up an item and adds it to the inventory.
• drop foo - drop an item from the player's inventory.
• open foo - opens a 'container' type item
• close foo - closes a 'container' type item
• pick lock - if the player has a lock pick in their inventory, attempts to pick the lock that was most recently shown to be closed in the room. For example, a player tries "open door" and gets the message "that door is locked" - when they try "pick lock", it will attempt to pick the lock of that closed door.
• use/apply foo - uses an item from the player's inventory. If it's a consumable item, the number in the player's inventory is decreased.
• give foo bar - gives the item 'foo' from the player's inventory to the player 'bar'(should this work for monsters too?)
• cast foo - casts a spell the player knows.
• cast foo on bar - casts a targeted spell 'foo' on the entity 'bar'.

Implementation

• The project will be built using Object-Oriented techniques.
• Objects will exist for most of the main entities in the game - players, monsters, items - their constructors will accept an ID and retrieve all information.
• The base of all objects will have a method called toHTML(), that will convert the object into human readable HTML output for display in the Codex.
• Objects will have methods that do what's needed for them - like Player->giveItem(Item/ItemID).
• BoxOver will be used to provide neat tooltips for everything.
• There will be two 'main' templates - the template for the outer page/general style, and the inner template for that page's specific content.
• Actions will have a large dispatch table composed of all actions available - using the first word of the command, we will switch off on what function needs to get called.
• HTML::Entities will be used to escape comments on the codex.
• Javascript will be used for the onsubmit, and actions will spit out XHTML.
• player, monster, and item statistics will be implemented using a flexible stats system.
• The game will be turn-based, because that's the pattern that IF seems to follow. This means that there may be items that are only usable for so many times, and there may(eventually) be a daily turn limit to keep users coming back(although there could be ways to boost the daily limit)
• In order to handle all of the actions performable by a player, we will capture them using a simple regex like (.+)\b, to retrieve the first word - and use that to call code out of a dispatch table, which will actually handle the values passed in.
• It would be nice to use Ajax for our postbacks, because we don't need to send huge amounts of data - all we send is the user's command, which actions parses - it then spits out XHTML, which the script can just add to the user's log window.

Website

The website will have a few, self-explanatory(for the most part) pages on it. This is what they are:

• Home - the home page
• Design Document - this document
• Register, Login, Logout - the pages for user authentication
• Codex - The Codex(see above)
• Play - the area where the game can actually be played.

Entities

Because we are using a flexible statistics system, any and all statistics are available for all players, monsters, and items.

Player

Attributes:

• name
• password

Methods:

• attack - attacks a target
• give_item - puts an item into the player's inventory
• move_to - moves the player to a different room

Monster

Attributes:

• name
• description

Methods:

• attack - attacks a target/player
• drop_loot - drops loot from the monster's drop table, when the monster dies

Item

Attributes:

• name
• description

Methods:

• use - uses the item. This is achieved using a dispatch table based on the item's type(weapon,armor,usable,eatable,etc.)

Room

Attributes:

• name
• description