Difference between revisions of "UC MUD Code Planning"
From UtterChaos
(→Table brainstorming) |
(→Database) |
||
Line 25: | Line 25: | ||
==Database== | ==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. |
− | * Characters | + | |
− | + | {| | |
− | * | + | ! Table !! Columns !! Notes |
+ | |- | ||
+ | | Objects || wizard_id (FK to wizards), creation date, mass, size_id || wizard_id is id of wizard who created object | ||
+ | |- | ||
+ | | Sizes || size_name, size_order | ||
+ | |- | ||
+ | | Room instance || area, actions, | ||
+ | |- | ||
+ | | General room || description columns | ||
+ | |- | ||
+ | | Items || object_id (FK to objects) | ||
+ | |- | ||
+ | | Item personalization || item_id (FK to items), character_id (FK to characters), new field name, description | ||
+ | |- | ||
+ | | Living creatures || size, race_id (FK to races), | ||
+ | |- | ||
+ | | Characters || | ||
+ | |- | ||
+ | | Races || size limitations, stat modifiers, racial_adjustment_id (FK to racial adjustments), | ||
+ | |- | ||
+ | | Random monster generation parameters || | ||
+ | |- | ||
+ | | Actions || | ||
+ | |- | ||
+ | | Guilds || | ||
+ | |- | ||
+ | | Skills || | ||
+ | |- | ||
+ | | Areas || | ||
+ | |- | ||
+ | | Item class || | ||
+ | |- | ||
+ | | Actions || | ||
+ | |- | ||
+ | | Spells || | ||
+ | |- | ||
+ | | Status adjustments || | ||
+ | |- | ||
+ | | Racial adjustments || | ||
+ | |- | ||
+ | | Metadata || 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? | ||
+ | |- | ||
+ | | Players || user_id, object_id (FK to objects), password (encrypted?), | ||
+ | |- | ||
+ | | Character sort orders || sort column, asc/desc | ||
+ | |- | ||
+ | | Wizards || character_id (FK to characters), wizard_class_id (FK to Wizard Class), wizarding_start_date | ||
+ | |- | ||
+ | | Wizard Class || class_name, permissions | ||
+ | |} | ||
+ | |||
+ | ===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 ... | ||
+ | |- | ||
+ | | Characters || Skills | ||
+ | |- | ||
+ | | Characters || Guilds | ||
+ | |- | ||
+ | | Characters || Status adjustments | ||
+ | |- | ||
+ | | Characters || Racial adjustments | ||
+ | |- | ||
+ | | Actions || Meta-table item | ||
+ | |- | ||
+ | | Items || Item class | ||
+ | |- | ||
+ | | General room || Room instance || | ||
+ | |- | ||
+ | | Characters || Spells | ||
+ | |- | ||
+ | | Items || Spells | ||
+ | |- | ||
+ | | Character sort order | Player | ||
+ | |} | ||
+ | |||
+ | |||
+ | |||
+ | ===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=== | ===Table brainstorming=== | ||
− | # Everything as an | + | # Everything as an object |
#* Rooms are containers | #* Rooms are containers | ||
#* Characters and Monsters/NPCs modeled the same, also 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 | # All actions have common ties | ||
#* Actions include spells and attacks, but also skills, emotes, buying, etc. | #* Actions include spells and attacks, but also skills, emotes, buying, etc. |
Revision as of 12:16, 25 October 2011
Contents
Interface and code
- Web based?
- AJAX?
- Rails?
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.
Table | Columns | Notes |
---|---|---|
Objects | wizard_id (FK to wizards), creation date, mass, size_id | wizard_id is id of wizard who created object |
Sizes | size_name, size_order | |
Room instance | area, actions, | |
General room | description columns | |
Items | object_id (FK to objects) | |
Item personalization | item_id (FK to items), character_id (FK to characters), new field name, description | |
Living creatures | size, race_id (FK to races), | |
Characters | ||
Races | size limitations, stat modifiers, racial_adjustment_id (FK to racial adjustments), | |
Random monster generation parameters | ||
Actions | ||
Guilds | ||
Skills | ||
Areas | ||
Item class | ||
Actions | ||
Spells | ||
Status adjustments | ||
Racial adjustments | ||
Metadata | 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? |
Players | user_id, object_id (FK to objects), password (encrypted?), | |
Character sort orders | sort column, asc/desc | |
Wizards | character_id (FK to characters), wizard_class_id (FK to Wizard Class), wizarding_start_date | |
Wizard Class | class_name, permissions |
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 ... |
---|---|---|
Characters | Skills | |
Characters | Guilds | |
Characters | Status adjustments | |
Characters | Racial adjustments | |
Actions | Meta-table item | |
Items | Item class | |
General room | Room instance | |
Characters | Spells | |
Items | Spells | |
Player |
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?