From Peragro Tempus
Jump to: navigation, search


Browser-based Lightweight Access to Stored Templates

Everything in the World of Peragro is an Entity, which contains Components, which contain Properties. To manage these Entities, Components and Properties is BLAST's Job. (*Note* BLAST used to be called WEED (Web Editor for Entity Data) but was renamed so we could have a little fun with names - now we have DAMN and BLAST!)



A Component is a collection of Properties. Which kinds of Properties go in a Component is decided by its Definition, of which every Component has exactly one. The Definitions provide a name and a datatype for each Property, but no value. This way, we can have several components that have the same structure, but contain different data. (In Programmer-Lingo: ComponentDefinition is an aggregation of PropertyDefinitions).

The Components in turn contain the actual Properties (Component aggregates Properties). Every Component CAN have a Parent, from which it would inherits all Properties. (If it doesn't have a parent, and no properties, it's empty.) Only those Properties which differ from the Component's Parent need to be changed. When looking for a certain Property in a certain Component of an entity, this Entity's Component hierarchy is searched bottom-to-top. When changing it, it's automatically changed at the bottom level, so we don't accidentally change all entities at once. It is important to mention that not all Properties defined in a Components Property-Definition need to have a value - If any Entity contains Components which have values missing, they are automatically templates and can never be instances.


Entities contain Components. Entities can have parents too, which means that they just inherit all components from them. However, Entites have an additional field which decides whether they Appear in the world or not (the latter makes them templates effectively). Only Entities where all PropertyDefinitions in the Component Definitions actually have a Property Value for the Component with that definition can be instances.


An NPC that carries certain items and sells them at default prices. The NPC Vendor would be the Entity, and since it walks around in the world it will have basic Components like

  • Mesh (3D Model)
  • Placement (Coordinates)
  • AI Script (Calculates the path it should walk)

and more specific components, like

  • Inventory Component (to carry stuff - basically a list of items it's carrying)
  • Dialogue Script (defines how the NPC will talk to the player and how they can Interact, which in this case means buying and selling things.)

We can now define this Entity. We will give it an empty Placement Component, since we don't want to define yet WHERE the NPC will be, only that it will be in the world somewhere, We'll give it an empty Mesh Component, and an Empty Inventory. We will give it an AI Component, but this time we can already set the Script that calculates the route, which will just be to randomly walk around. This is identical for all NPCs of this kind. Also, the Dialogue is the same for each of these: "Hello, would you like to buy something? I can offer you [list of stuff in the NPCs inventory with prices here]!".

Now, if we want to have several of these guys, we can just create one template, AmblingVendorNPC, and then Create multiple Entities that have this as parent, and just overwrite the mesh, placement and inventory properties, and leave the rest as it is. This way, we save space (because we don't have to save redundant components), time and opportunity for error (becasue we don't have to manually enter it every time), and we have a clean way of editing the scripts if we find an error (we just modify the AmblingVendorNPC and all changes will carry down).

Interface (NOT GUI, but Code Interface)

BLAST uses managers to edit components. These are jQuery UI widgets that are managed by the blast interface, and alway receive an HTML div area to display their contents (a tab). Certain Methods, Events and other Mechanisms need to be defined for each manager so it can be used by the system. If a component definition does noit have a manager, a defualt manager will be used.

When editing Entities, an Entity manager is created in a tab in addition to the managers of the entity's componets in the other tabs. This is the same for all entities. ComponentDefinitions and PropertyDefinitions are also edited with managers that cannot be changed.


On the Left, a Tree Structure to select Component Definitions and Entities for editing. Directly in the Components Node are the Component Definitions.

The Top Nodes "Component Definitions" and "Entities" Will allow you to create a new one. The "Property Definitions" Node will let you add/edit/remove Property Definitions. Entities are Laid out just in their parent-child hierarchy. Clicking an entity or an entity template will open it for editing in the tabs.

When editing an Entity, Multiple tabs may open on the right. The first will always be an Entity Tab, which allows adding/removing Components to/from the entity, creating child entities, changing descriptions/instances or saving/reverting the entity to/from the server.


Current: basic functionality with preparation for integration of remaining functionality.

Tasks for BLAST:

  • Client side:
    • Editing of Entites, Component Definitions, Property Definitions
  • Server Side:
    • Synchronization and Access management
  • Both Sides:
    • Synchronisation of Data between Client and Server (AJAX/AJAJ)
    • Synchronisation of Data between Server and Game/Anvil/DAMN (the latter for assets)
  • Managers:
    • Placement - WebGL Map with click-to-place
    • Abilities - Sliders and Balancing Data
    • Inventory - Grid
    • Default Manager - List of Properties - Owners - Types
    • Component Definition Manager - List of Properties
    • Property Definitions Manager - List of Names and Datatypes