Difference between revisions of "UC MUD Code Planning"
From UtterChaos
(→Action tables) |
(→Metadata tables) |
||
| Line 94: | Line 94: | ||
| Skills || In-game skill list || skill_name, guild_requirement (null = no guild membership required to learn skill) | | Skills || In-game skill list || skill_name, guild_requirement (null = no guild membership required to learn skill) | ||
|- | |- | ||
| − | | | + | | Creator Class || class_name, permissions |
|- | |- | ||
| Player Races || || race_id (FK to races), player race boolean, elite player race boolean | | Player Races || || race_id (FK to races), player race boolean, elite player race boolean | ||
Revision as of 14:39, 27 October 2011
Contents
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?
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
| 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) | 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 | |
| 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. |
| 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
| 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
| Table | Description | Columns | Notes |
|---|---|---|---|
| General Rooms | Single source of room description | description columns | |
| 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? |
| Status adjustments | Temporary creature adjustments | metadata_id, modification | |
| Racial adjustments | Permanent creature adjustments, (including stat adjustments?) | metadata_id, modification | |
| 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 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 | class_name, permissions | ||
| Player Races | race_id (FK to races), player race boolean, elite player race boolean | ||
| Races | creature groups | size limitations, racial_group_id (FK to racial groups) | stat adjustments covered by racial adjustment table? |
| Racial group | superclass of races | description, size limitations | |
| 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 | area_id, | |
| 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 |
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
| X | Y | This represents ... |
|---|---|---|
| Actions | Objects | |
| Area | Room | |
| Characters | Guilds | |
| Characters | Racial adjustments | |
| Characters | Skills | |
| Characters | Spells | |
| Characters | Status adjustments | |
| Character sort order | Player | |
| General room | Room | |
| Items | Item class | |
| Items | Spells | |
| Racial Adjustment | Races |
Working tables
Temp tables to be used while player is logged in, dropped after/at reboot
- Inventory? How to persist, write to more permanent table?
- Status that wears off
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?
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?
