Difference between revisions of "UC MUD Code Planning"

From UtterChaos
Jump to: navigation, search
(→‎Object tables)
(→‎Action tables)
 
(27 intermediate revisions by the same user not shown)
Line 4: Line 4:
 
* Rails?
 
* Rails?
 
* Ruby?
 
* Ruby?
 +
* Python?
  
 
===Brainstorming===
 
===Brainstorming===
Line 25: Line 26:
 
#* Or telnet interface with a text-based browser style? Keep the different windows?
 
#* Or telnet interface with a text-based browser style? Keep the different windows?
  
−
==Database==
+
===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===
 
===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.
+
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====
 
====Object tables====
Line 37: Line 56:
 
| 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 ||  
 
| 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
+
| 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)
+
| 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
 
| 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
Line 45: Line 64:
 
| Creators || Creators are characters that code the MUD || character_id (FK to characters), creator_class_id (FK to Creator Class), creator_start_date
 
| 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
+
| 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, non-room 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.
+
| 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" ||
+
| Weapons || Weapons are items that have item_class "wieldable" || item_id, number of hands(limbs) needed, attack power, skill used
 
|-
 
|-
−
| Armor || Items that have item_classes "wearable" and "protection" ||
+
| Clothing || Items that have item_class "wearable" || item_id, covers_body_part
 
|-
 
|-
−
| Clothing || Items that have item_class "wearable"  
+
| 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?
 
|}
 
|}
  
Line 61: Line 80:
 
! Table !! Description !! Columns !! Notes
 
! Table !! Description !! Columns !! Notes
 
|-
 
|-
−
| Actions ||
+
| 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 ||
+
| 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
 
|-
 
|-
−
| Spells ||
+
| 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.
 +
|-
 +
| Creature actions || Actions that can be taken by a creature || ||
 +
|-
 +
| Character actions || Actions that can be taken by a character || ||
 
|}
 
|}
 +
 
====Metadata tables====
 
====Metadata tables====
 
Tables of table information
 
Tables of table information
 
{| border=1
 
{| border=1
 
! Table !! Description !! Columns !! Notes
 
! 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?
 
| 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
+
| General Rooms || Single source of room description || description columns
 
|-
 
|-
−
| Racial adjustments || Permanent creature adjustments, (including stat adjustments?) || stat, stat_bonus, skill, skill_bonus
+
| 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 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_World_Planning#Items|Items]] for list
+
| 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
 
| Guilds || In-game guild list || guild_name, guild_chat_id
Line 91: Line 116:
 
| 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)
 
|-
 
|-
−
| Wizard Class || class_name, permissions
+
| 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), player_race (bool), elite_player_race (bool), size_id (FK to size) || stat adjustments covered by racial adjustment table?
 
|-
 
|-
−
| 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
 
|-
 
|-
−
| Racial group || superclass of races || description, size limitations
+
| Size || different sizes of creatures || size_name, size_order || 1=tiny (bug), 2=small (halfling), 3=medium (elf), 4=large (ogre), 5=huge (dragon)
 
|-
 
|-
−
| 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 ||   
−
|-
+
−
| 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 ||  
 
| 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
 
| 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 (and later), 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"
 
|}
 
|}
  
Line 117: Line 144:
 
! X !! Y !! This represents ...
 
! X !! Y !! This represents ...
 
|-
 
|-
−
| Characters || Skills
+
| Actions || Objects
 +
|-
 +
| Areas || Rooms
 
|-
 
|-
 
| Characters || Guilds
 
| Characters || Guilds
 
|-
 
|-
−
| Characters || Status adjustments
+
| Characters || Skills
 
|-
 
|-
−
| Characters || Racial adjustments
+
| Characters || Spells
 
|-
 
|-
−
| Actions || Meta-table item
+
| Characters || Status adjustments
 
|-
 
|-
−
| Area || Room instance
+
| Character sort order || Player
 
|-
 
|-
−
| Items  || Item class
+
| General room || Room
 
|-
 
|-
−
| General room || Room ||
+
| Items  || Item class
−
|-
+
−
| Characters || Spells
+
 
|-  
 
|-  
 
| Items || Spells
 
| Items || Spells
 
|-
 
|-
−
| Character sort order || Player
+
| 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
 
|-
 
|-
−
| Racial Adjustment || Races
+
| Creators || Creator Class
 
|}
 
|}
  
−
===Working tables===
+
===State tables===
−
Temp tables to be used while player is logged in, dropped after/at reboot
+
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
−
* Inventory? How to persist, write to more permanent table?
+
−
* Status that wears off
+
  
 +
* 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===
 
===Table brainstorming===
Line 162: Line 212:
 
#* 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.  
 
#* 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?
 
#* 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==
 
==Interaction==

Latest revision as of 14:02, 28 October 2011

Interface and code

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

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?

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

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

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.
Creature actions Actions that can be taken by a creature
Character actions Actions that can be taken by a character

Metadata tables

Tables of table information

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 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
Races creature groups racial_group_id (FK to racial groups), player_race (bool), elite_player_race (bool), size_id (FK to size) stat adjustments covered by racial adjustment table?
Racial group superclass of races description
Size 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 (and later), 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
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

  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?

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

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