Design

Design

Design goals for the project. This is less about implementation and more about theory.

Goals

Create a world more interactive than Skyrim by trading presentation layer for higher levels of interaction.

Design Pillars

• Least effort possible for content creation
  • Content should be as concise as possible without losing clarity
  • Everything should have a reasonable default
  • Content creators should only need to specify what makes an item etc unique

General Design Notes

Any time an activator adds a new triggered event, it needs to be added to the triggered event when statement

Location positions are always relative to their parent. The parent is always (0,0,0). If a location is compared with a location outside the parent, the parent locations are compared.

An event, command and listener should share a package. Event should end in Event, command in Command, and listener without a suffix, with the same main name. If a listener is player only etc, prefix it with player Ex:

• LookCommand
• LookEvent
• Look
• PlayerLook

Design note

• If a keyword is parsed without args, always show response request
• If an alias is parsed without args, use a reasonable default if it exists, otherwise response request
• A user that knows what he is doing will want the default to be used and will use an alias. A user that doen’t know what he wants will probably use the full default keyword, and will want to know his options
• All print statements should end in a period
• Commands' main keyword is capitalized. Aliases are lower case

Wiki Design Notes

The wiki should document implemented or semi-implemented behavior. For TODOs and planning, other tools should be used (github issues, joplin, etc). This allows the wiki to be more player focused and have less of a mix of true and not yet true information.

The wiki should avoid code if at all possible. This helps prevent code rot and keeps a more consistant focus on high level, human friendly explinations and "whys" instead of "whats". In the case of the DSLs it may make sense to provide some documentation / examples, but it should be done with care.

Testing

If tests are running slow, make sure that json parsing and reflection are not happening as part of unit tests. An easy check is to place a debug point in getImplementation to catch any time a default implementation is being used in a unit test.