RPG project

Primary goal:

Create a website that allows for multiple users to create and track RPG campaigns while resolving combat and maintaining their characters in real-time.

Secondary goal:

Allow content creators to post and sell their content to users securely.

Development roadmap:

  1. Content Management System with user administration and security levels
    1. Player User
      1. Player users are the type of user that will eventually use the game aspects of the site.
    2. Client Content User
      1. Client content users will be creating the content for the Player users to utilize. They have restricted access to the game systems and campaigns they are assigned by their Client Content Administrator.
    3. Site Administrator
      1. Site administrators should not be able to affect client content, but can handle problems that player users are having such as forgotten passwords or forum administration.
    4. Client Content Administrator
      1. These are the managers of the client content users. They don’t have the access to change things with the player users, but they can change information in the tables for their content.
    5. Login for Client Content
      1. A separate login page for client content users and client content administrators.
      2. Client content creators will have tools very like the tools used to write a blog.
      3. Client content administrators will have the same tools as client content creators, but they can also delete and modify users that have the same client and a lower security level.
    6. Login for Site Administration
      1. Site administrators will be able to see security levels and change them.
      2. Site administrators cannot set security levels equal to themselves or higher.
      3. They can delete, ban, and unban accounts.
    7. Login for Players
      1. A cookie should be set for language selection.
      2. Leads to a page showing site news and a means for the player to see their characters and latest game sessions.
      3. Players administrate their own characters.

        NOTES: I’d like to make it so people can select their native language and get a translated version of the site text. If the site text has not been translated, the English text should appear. If it’s easier to start from scratch and make a secure site, that’s fine by me, but if it’s easier to create additional tools for an existing CMS, that’s fine by me.

  1. Client play system with versioning
    1. Play systems
      1. Play systems are the highest level of distinction for content.  Play systems cannot interact with each other because the rules that govern them are so different.
      2. A client may have several different types of play systems they administrate.  Example:  Dungeons & Dragons and Magic the Gathering are both games owned by the same company, but their play mechanics are so different they won’t share any terminology or functions.
      3. Multiple versions of the same play system may have to exist (Ex: Dungeons & Dragons Ver 3.5, Ver. 4.0, Ver. 5.0)
    2. Core sourcebook
      1. Core sourcebooks fit within play systems, but their content can interact with each other.
      2. Example:  Dungeons & Dragons has several large settings such as Forgotten Realms and Dark Sun.  They share similar rules and if a group has purchased both books, they may want to use a mix of creatures and items from both.
    3. Campaign
      1. The main difference between a campaign and a sourcebook is for marketing purposes.  They don’t change many rules, but to make it easier for people to find content from the possibly hundreds of available products it is easier to let the client separate them out.
      2. Example:  Dungeons & Dragons is the play setting, Forgotten Realms is the core sourcebook, and a player can purchase a campaign such as the Temple of Elemental Evil to play within.
    4. Supplement
      1. Supplements are like campaigns in that it is mainly a marketing designation.  They work with sourcebooks but are not necessarily required to fit within a campaign.
      2. Example: A book on types of armor that can be used in any Dungeons & Dragons setting.
  2. Player character creation
    1. Player character table
      1. Almost all player character information between games breaks down to similar data types.  It is very likely that all player character information can be kept in the same tables.
      2. Players will probably want to create multiple versions of the same character and import/duplicate them into various game sessions.
  3. Player character attribute/skill modification
    1. Attributes from random rolls
      1. Many games require some form of character information to be randomly generated. Unfortunately, there are many different acceptable methods we will have to accommodate to make players happy with the outcome.
      2. Best of “x” rolls (Ex. A player is supposed to roll a set of 3 six-sided die. This would normally give an outcome between 3-18. It is easy to set up a minimum and maximum range in this case. However, as this decides the fate of a character the player will hopefully be using for many hours, it is considered “fair” in some games to allow the player to roll 5 six-sided die and choose the 3 highest outcomes.)
      3. Bonuses are sometimes added to attribute rolls if the result is high enough. (Ex: if the player rolls a 16-18, they may be allowed another roll to add to the total.
      4. The players will need to be able to see what the outcome of all the rolls are.
      5. “House rules” may require that a different approach to determining outcome is best. In this case, a separate selectable function may be required for each roll.
      6. Some players may want to enter their own values, so editing and modification of each value will be required.
    2. Attribute bonuses granted by external tables
      1. Bonuses may be granted based on external tables.
      2. Ex: If a player has a high value of a Size attribute, his rolled Dexterity attribute may decrease. If the character Epsilon started with a size of 5 (no modification to Dexterity) and increased his Size to 6, the Dexterity will decrease by 1. It doesn’t have to be reflected in real-time, but the user should be able to update character sheet values and see the results without committing to changes that cannot be undone.
      3. There should be a final action to commit all changes and save the character sheet.
    3. Attribute and skill descriptions
      1. There are usually hundreds of skills in each core sourcebook and the rules involving them can be confusing. I’d like to have help files in the database for each that update a widget when certain things are clicked on. When a field label is clicked or a skill/power selection is made, the appropriate help file should display in this space.
      2. The description will have to appear in the default language of the player user. If the language is not available, English should default.
    4. Martial arts
      1. Some play systems allow for martial arts, race, or class to affect player skills and attributes. Abilities will unlock or attributes may increase/decrease.
    5. Character levels
      1. As player users progress through their chosen play system, they will gain abilities based on the level they have attained. These bonuses may be different based on attributes they currently have.
      2. Ex: A player with a Constitutions of 13 may get 1d6 hit points per level, but a player with a Constitution of 16 may get 1d6 +1.
  4. Player character biography and avatar storage
    1. Player biographies may include the use of special characters and will include a lot of random text that may be used to break the site. Security needs to be in place to prevent this.
    2. Players will want to be able to upload an avatar of their own eventually. There needs to be the eventual capacity to block pornographic or otherwise inappropriate images from being utilized.
  5. Player character powers and table lookup
    1. A lot of foreign key checks will be used to look at data from different tables.
      1. Skills and powers will likely adjust attributes and be purchased on a point system that will decrease as powers are selected. Eventual AJAX programming may be required that will immediately show the effects of different choices so the player can weigh their options.
      2. If AJAX programming is too difficult from the beginning, then maybe a button that shows the value, then commits the values or resets them can be used.
    2. Ideally, only options that are available according to the play system rules should be selected.
      1. To allow for certain house rule configurations, a toggle that will show all available options according to the play system and core sourcebooks available to the player user should be created.
  6. Items and Equipment management
  7. Game session creation and administration
  8. Game session chat room
  9. Game session skill rolling
  10. Combat session pop-up
  11. Combat session multiple targets
  12. Combat session resolving and recording
  13. Security overhaul
  14. Content sales
  15. User and session ranking
  16. Player generated content

Declaration of common terms:


Comments are closed.