Difference between revisions of "UC MUD Code Planning"

From UtterChaos
Jump to: navigation, search
(→‎Database)
Line 32: Line 32:
 
! Table !! Columns !! Notes
 
! Table !! Columns !! Notes
 
|-
 
|-
−
| Objects || wizard_id (FK to wizards), creation date, mass, size_id || wizard_id is id of wizard who created object
+
| Objects || wizard_id (FK to wizards), creation date, mass, size_id || wizard_id is id of creator of object
 +
|-
 +
| Actions ||
 
|-
 
|-
 
| Sizes || size_name, size_order
 
| Sizes || size_name, size_order
 
|-
 
|-
−
| Room instance || area, actions,  
+
| Rooms || actions, general_room_id (FK link to general room)
 +
|-
 +
| Room transitions || Starting_room_id (FK link to rooms), ending_room_id (FK link to rooms),  
 
|-
 
|-
−
| General room || description columns
+
| General Rooms || description columns
 
|-
 
|-
 
| Items || object_id (FK to objects)
 
| Items || object_id (FK to objects)
Line 48: Line 52:
 
| Characters ||  
 
| Characters ||  
 
|-
 
|-
−
| Races || size limitations, stat modifiers, racial_adjustment_id (FK to racial adjustments),  
+
| Player Races || race_id (FK to races), player race boolean, elite player race boolean
 
|-
 
|-
−
| Random monster generation parameters ||  
+
| Races || size limitations, stat modifiers, racial_adjustment_id (FK to racial adjustments), racial_group_id (FK to racial groups)
 
|-
 
|-
−
| Actions ||
+
| Racial group || description, size limitations
 +
|-
 +
| Random monster generation parameters ||  
 
|-
 
|-
 
| Guilds ||
 
| Guilds ||
Line 58: Line 64:
 
| Skills ||
 
| Skills ||
 
|-
 
|-
−
| Areas ||
+
| Areas || area_name, description || areas are used for wandering monster limitations. areas can overlap
 
|-
 
|-
 
| Item class ||
 
| Item class ||
Line 99: Line 105:
 
|-
 
|-
 
| Actions || Meta-table item
 
| Actions || Meta-table item
 +
|-
 +
| Area || Room instance
 
|-
 
|-
 
| Items  || Item class
 
| Items  || Item class
 
|-
 
|-
−
| General room || Room instance ||
+
| General room || Room ||
 
|-
 
|-
 
| Characters || Spells
 
| Characters || Spells

Revision as of 12:27, 25 October 2011

Interface and code

  • Web based?
  • AJAX?
  • Rails?
  • Ruby?

Brainstorming

  1. 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
  2. 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
  3. Way to script things?
  4. Mobile site?
  5. 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 creator of object
Actions
Sizes size_name, size_order
Rooms actions, general_room_id (FK link to general room)
Room transitions Starting_room_id (FK link to rooms), ending_room_id (FK link to rooms),
General Rooms 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
Player Races race_id (FK to races), player race boolean, elite player race boolean
Races size limitations, stat modifiers, racial_adjustment_id (FK to racial adjustments), racial_group_id (FK to racial groups)
Racial group description, size limitations
Random monster generation parameters
Guilds
Skills
Areas area_name, description areas are used for wandering monster limitations. areas can overlap
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
Area Room instance
Items Item class
General room Room
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

  1. 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
  2. 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?
  3. 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?


UC_MUD

Retrieved from "http://wiki.utter-chaos.net/ucwiki/index.php?title=UC_MUD_Code_Planning&oldid=14719"