View source for UC MUD Code Planning

==Interface and code==
* Web based?
* AJAX?
* Rails?
* Ruby?
* Python?

===Brainstorming===
# Have defined sections of the page for basic ways to interact with game
#* Room/environment view box
#* Inventory
#** Item view
#* Other characters/NPCs
#** separate from room? or basically like the room is a container and a subwindow that shows what's in the room--items, players, npcs. Things #an go in and out without changing the view of the environment. 
#* Combat
#* Conversations
#** Include emotes here? basically, an action window?
#** Split between chat lines/tells/room actions? If we have chat lines/tells
# Obvious and non-obvious methods of interaction
#* Obvious methods (go north, wield sword, don armor, press button) as clickable links
#* Non-obvious methods not displayed, but given an empty text box to input commands
# Way to script things?
# Mobile site?
# Telnet option
#* Web interface a wrapper around all information given, but with traditional telnet interface of many lines coming at you?
#* Or telnet interface with a text-based browser style? Keep the different windows?

===Thread handling===
* Each login gets a socket
* Single thread to track actions
* When a socket has an action, it notifies the thread. Thread then goes through all sockets and resolves all actions
* When no action, thread waits for notification

The above list keeps there from being race conditions because there is only one thread and it resolves things one at a time.

===Active state===
The current state  of the MUD can either be kept in the database or on the system in a process (or many processes)
* If on the database, requires a lot of updates/deletes/etc. to the database
* If on the system, a system crash would lose state
* Preference is for the database if it is fast enough
* Additionally, multiple machines can be added with the database as the central point, to handle more players

===State changes===
Need to elaborate on what states are available to objects in the MUD, including characters.

==Database(?)==
===Fact tables===
Every fact table has a non-null primary key (not listed b/c I don't want to have to type "PK" over and over). If a column is a FK link to another table, it will be noted. This may also be modeled by classes and sub-classes on object oriented programming, where "columns" would become variables and actions, methods. I'm setting them up like this because it's how I conceptualize things.

====Object tables====
Objects and derivative tables

{| border=1
! Table !! Description !! Columns !! Notes
|-
| Objects || All items start as objects. Objects can use actions. Objects have a capacity that defaults to 0 if unset || creator_id (FK to creators), creation date, mass/weight, capacity || 
|-
| Rooms || Rooms are objects that can contain creatures. Rooms should have an exit as an action. || max_size_id (FK to size), room_description_id || max_size_id limits what size creatures can enter said room. Default to largest available size, or no limitation if null
|-
| Creatures || Creatures are objects that can have stats || size_id, race_id (FK to races), name (can be blank), stats, hp/mp/sp (if we're using that)
|-
| Characters || Characters are creatures controlled by a player || creature_id, name (unique), player_id, level, player_text || name should be equal to creature.name for creature.creature_id = character.creature_id
|-
| Creators || Creators are characters that code the MUD || character_id (FK to characters), creator_class_id (FK to Creator Class), creator_start_date
|-
| Players || Players are the link between characters by the same person. The player is probably not a creature || user_id, password (encrypted?), character_sort_order_id || Need a method for changing password, recovering password when forgotten. And possibly an encrypted password history table.
|-
| Items || Items are non-creature objects|| description, obviousness || Unobvious items will not show up in room until searched for. They will show up in player inventories and bags. Depends on capacity of container and weight of object.
|-
| Weapons || Weapons are items that have item_class "wieldable" || item_id, number of hands(limbs) needed, attack power, skill used
|-
| Clothing || Items that have item_class "wearable" || item_id, covers_body_part
|-
| Armor || Clothing that has the item_class "protection" || clothing_id, defense power || How do we make clothing and armor wearable? Maybe any amount of clothing, but only one piece of "armor" on a given limb?
|}

====Action tables====
Actions and derivative tables
{| border=1
! Table !! Description !! Columns !! Notes
|-
| Actions || An action is linked to an object. The action command is called either by the object or by another object interacting with said object || action_command, creator_id, date_created
|-
| Exits || Action object X can take to move an object Y contained in X to be contained in object Z instead. Model for putting and taking things out of bags, and moving from one room to another. || Moving_item, starting_object, ending_object 
|-
| Emotes || An emote is an action that only has the effect of putting a message to the system. ||
|-
| Energy || An energy action changes the value of a energy points of the target, positive or negative || targeted_id, energy_type || Might need a way to put either a number or an algorithm for the amount of change into this field. Also, a single action can have multiple types of energy change (HP/MP/SP) but each one can only go up or down once. So it could increase HP and decrease MP, but not increase MP 10 and decrease MP 5.
|}

====Metadata tables====
Tables of table information
{| border=1
! Table !! Description !! Columns !! Notes
|-
| Metadata || Table information || table name, column name, PK_flag, FK_flag, FK_link (FK to metadata_id, self-referential) || Can we have this auto-generate? Based on system tables?
|-
| General Rooms || Single source of room description || description columns
|-
| Energy Points || || energy_point_name, description
|-
| Status adjustments || Creature adjustments, temporary or permanent || metadata_id, modificatio
|-
| Item personalization || Items that are different from standard according to the player || item_id (FK to items), character_id (FK to characters), new field name, description
|-
| Item class || Different kinds of items || item_class_name, item_class_description || see [[UC_MUD_Items|Items]] for list
|-
| Guilds || In-game guild list || guild_name, guild_chat_id
|-
| Guild Membership Requirements || skill levels required for creature membership in a guild || guild_id , skill_id, minimum_skill_level
|-
| Skills || In-game skill list || skill_name, guild_requirement (null = no guild membership required to learn skill)
|-
| Creator Class || Jobs for creators (stackable) || class_name, permissions
|-
| Player Races || || race_id (FK to races), player race boolean, elite player race boolean
|-
| Races || creature groups || racial_group_id (FK to racial groups) || stat adjustments covered by racial adjustment table?
|-
| Racial group || superclass of races || description
|-
| Sizes || different sizes of creatures || size_name, size_order || 1=tiny (bug), 2=small (halfling), 3=medium (elf), 4=large (ogre), 5=huge (dragon)
|-
| Random monster generation parameters || necessary information for generating random monsters ||  
|-
| Areas || areas are groups of rooms used for wandering monster limitations. areas can overlap || area_name, description || 
|-
| Character sort orders || Options for players to sort list of characters || sort column, asc/desc
|-
| Features || Features are options for creatures that can be visible in descriptions of those creatures. These are the things that get set to personalize a character upon character creation, but are also valid for NPC creatures || feature_name, feature_description
|-
| Languages ||  || language_name, parent_language || may need more than one parent language to mimic proper language "trees"
|}

===Dimension tables===
Where X and Y are items in different fact tables.
* If X will have at most one of Y, then X should have a foreign key to Y's primary key (noted above)
** If X will always have one Y, then that foreign key should be constrained to not null
* If X can have many Y, and Y can have many X, then X and Y need a dimension table. Said table should consist of only two items: the primary keys of X and Y

{| border=1
! X !! Y !! This represents ...
|-
| Actions || Objects
|-
| Areas || Rooms
|-
| Characters || Guilds
|-
| Characters || Skills
|-
| Characters || Spells
|-
| Characters || Status adjustments
|-
| Character sort order || Player
|-
| General room || Room 
|-
| Items  || Item class
|- 
| Items || Spells
|-
| Races || Status Adjustment || Permanent status adjustments per race
|-
| Features || Races || Racial options for features
|-
| Creatures || Features || Features for a given creature
|-
| Areas || Random Monster Generation Parameters
|-
| Races || Random Monster Generation Parameters
|-
| Racial Group || Sizes
|-
| Races || Sizes
|-
| Creators || Creator Class
|}

===State tables===
Tables that keep the current state of the character/player, to be updated frequently. Chances are anything that can be changed should probably be here

* Location - What room is the character in?
** Inventory - What items is the character holding? Can this be expanded to "what items is the object holding?"--Probably. That way it also covers chests, and in turn, location. 
* Experience/Level
* Skill Level/% to next level
* Energy Point Pools
* Spell List
* History tables - history of what?
** Might just use a database with built-in history/records
* Communication - open issue for privacy. 
** Either everything is logged (and we put up a disclaimer for this) and we have the (restricted) ability to grep through the logs for evidence of real-life crime or inter-player harassment
** Or we give the player the ability to turn on logging to be sent to us 
** Or should we log all input from a user to be able to recreate bugs?
** If we do save everything, it has to be seriously restricted and possibly encrypted.

===Table brainstorming===
# Everything as an object
#* Rooms are containers
#* Characters and Monsters/NPCs modeled the same, also containers
#* Object table includes very basic information common to all objects. PK/FK link to other tables
# All actions have common ties
#* Actions include spells and attacks, but also skills, emotes, buying, etc. 
#* Any interaction with an object, including yourself.  Leveling up is an action. 
#* Not all actions can be called directly. Some can only be called by computer/other action. This flag can be one of the common ties
#* Actions PK/FK link to other tables to further define them
#* Are actions also items? Or can items have actions? Or can items have access to a class of actions?
# Classes of items/actions
#* Clearly defined definitions of items and actions. Adding a new item/action must go into one of these groups. Adding a new class rearranges the DB a bit. 
#* Subclasses/Superclasses can be defined to combine/narrow things down. Probably superclasses are more likely, to make things have only one class?

==Algorithms==
The important bits on getting things to work.

===moving around===
Moving from room to room requires the player using the exit-action for their current room. 
====large rooms====

===finding things===

===combat===

===learning skills===

===casting===

===learning languages===

===taking damage===

===chat===

===riding===

==Interaction==
* Modeling NPCs as computer-controlled PCs
* Objects with built in calls for actions?
* Characters as special kinds of items?
* Rooms as special kinds of items?



[[UC_MUD]]