Components of the 
engine
Universal components:
Universals are components which can exist in all four parts of the engine; the world, viewports, backend and frontends.
When you read the future documentation, it will indicate where entities can exist. With universals, they can exist in any of the cores.
Entity
The entity represents anything in the simulation that carries information and is associated with items. Entities can also contain child entities. Compared to a box which contains smaller boxes, which in-turn contain items, each box inside of the largest box represent the child entities of the large box. It is possible for entities to contain both children and attached items at the same time.
Not all entities are visual 3D or 2D renderings, sounds are entities that emit audio, and interpolators are entities which transition vectors (or coordinates).
One example of a world entity is a ray-caster, used to detect collision along a line from one point in space to another.
An example of a viewport entity is a tree; each model that makes up the tree are items. More on items below.
Items
Items are the building blocks of the world. Entities are used to organize items into interdependent groups. When a 3D object is loaded into the viewport, it becomes an item or becomes part of one. Items can also exist in the form of limbs; which are objects-in-objects. Note however that items are not always 3D based or visible in nature as is the case with entities. One example of an invisible item is the network item; a component used to transmit network packets; information about things that need to be shared in multiplayer
Sports Fiction gameplay, or information about things that need to be shared in collaborative networked
X-Producer world development sessions.
Network items are used to transit properties and triggers over authorized networks. Therefore it is possible to create an object in the X-Producer that has certain attributes downloaded from somewhere in the local area network or the internet.
More information about items will be found in future documentation.
Worlds - and their technical attributes
A ZeroOne world is something that separates all of the elements of the engine from those that exist in other worlds. Entity-1 in World-1 cannot interact with Entity-2 in World-2. There cannot be two Entity-1s in the same world; but there can be two Entity-1s if they both exist in different worlds.
When a world is initialized, a new world-engine is started.
Domain
A domain is something that seperates all of the elements of the engine from those that exist in other domains, however; domains exist inside of a world, therefore, domains prevent entities inside a world from interacting with each other.
An example use for domains is to stop particle physics objects from colliding with a certain set of collision trigger objects; placing these objects in separate domains prevents unwanted interaction, unless you make links between them manually, foreign domain entities will not understand that they co-exist.
Sites
Sites are a grid based set of areas used to determine what elements need to be loaded into or unloaded from the world. When a player enters into a world-site in a Sports Fiction scene, all of the necessary objects related to the scene within its site that is near the player are loaded. This procedure is performed as the player travels through sites.
Sites need not be defined manually when creating sports, but can be used in complex situations to optimize performance and improve the artificial intelligence (AI).
Sites also determine whether a timeline, updater or scheduler should be processed or not. For example, a flickering light bulb would contain an updater which affects the shader brightness of surrounding objects in a room; however, if this room is 10 miles away from the player; or the player is not able to enter the room anytime soon, the site of the light bulb is shut down; any inactive site containing such processes will terminate or pause the processes according to your requirement for scene playback optimization, or for
Sports Fiction’s game performance.
In the X-Producer World Creator, sites can be used to preserve system resources for intense calculations and shading whilst navigating the world.
Site grid cells can be given a set of rules, events and triggers to determine what to do with what is inside of them. Examples of events could occur when no players are in them, or when a number of players are in them.
Sites can be structured into one or more grid cells used to form a shape which contains scenes and areas. AI waypoints are used to indicate whether artificial intelligence can travel from one site to another.
Sites are not subject to domains but are subjected to worlds; this means all objects in a site are in the same world, but can be part of their own unique domains.
There exists a global site, site number zero which cannot be deactivated or removed; and it has its size set to infinite; all objects exist in the global site. It is possible to be in more than one site at once.
The cells of the site grid are always the same size. Only in X-Producer projects for non SF related products can grid size changes be made. The Sports Fiction site grid is static. X-Producer sites are dynamic; their size can also change during the simulation for whatever reason you see fit.
Nodes
X-Nodes are a series of instructions produced by X-Producer using a flowing diagram linking initial nodes to target nodes, and variables to other variables.
Most instructions for the tools in the editor or the elements in the Sports Fiction game have been programmed into the engine. Nodes are used to produce new instructions without tampering with the engine source code.
Nodes act as instructions for the world and its entities to perform actions, and can also contain LUA mathematical expressions.
To create an instruction, a node is dragged onto the canvas of the node editor where the user must select pre-defined node functions. Each function contains a variable amount of parameters which need to be connected to the output result of other nodes. This mechanism is popular in texture production software culture, however the X-Nodes can do much more than create textures. Players and users interact with nodes as they trigger custom events in the simulation.
Nodes contain input ports which can be constant or obtained from XData, other properties or function returns. In addition, on the right hand side are the output ports which send information about what happened in the node.
Also, at the top of certain nodes are flow ports; these are calls to action based nodes in a sequence of instructions that support logical gates.
Nodes can contain inner nodes; and can be grouped into node groups. All default nodes are added to a global node group in your project.
When developing generated textures, the user interface creates nodes for you, unless you opt to manually produce your own nodal algorithms.
Nodes can be used in all of the engines, however the functions available differ. X-Nodes can be parsed from XML, here is an example which initializes a number of properties:
<Nodes Name="EngineStartNode">
<Node Name="StartWorldSites">
<!-- Select select and load site at character position -->
<Set String="Domain">
<!-- All sites will load from WorldData\ + World String -->
<S>TestRooms</S>
</Set>
<!-- Enable sites to cause the objects located near the camera to be loaded into the simulation -->
<Set Int="SiteLoaderEnabled">
<I>1</I>
</Set>
</Node>
</Nodes>
Properties
Properties are variables that either contain data or link with other data on the same computer or over a network. There are three simple types of properties in the engine; strings, integers and floats; these are text, whole numbers and floating point numbers respectively. Other more complicated property types are the Forces, Ranges, Images, Zones, Vectors and Interpolators.
Examples of properties include:
Time of day
Character Speed
Texture Size
Number of completed objectives
Number of goals
Score
Experience Level
Experience Points
Vector X Value
Password
Image Width
File Existence Check
Selected Inventory Item Name
Terrain Scale
Slider control value
Properties can be attached to triggers. This is where it is the responsibility of a getter and setter trigger to authorize or determine a requested change to a property value. Properties with no setter or getter trigger are classified as source properties; properties which contain their data and do not self-constrain it.
Properties with a getter, but no setter, are read only; in-turn properties with setters but no getters are write only, and can only be read by core engine components; an example of a write only property is the password; only the property function and user can know it.
Binders
Properties can be bound to other properties by using binders. When bound, a property change requests other properties to be affected its changes. For example, the experience level is affected by the experience points; and the experience points are affected by number of goals and the number of completed objectives.
In world creation, the terrain scale property could be bound to the slider control value; so that you can use the mouse to drag the scale value of the terrain. This is how most of X-Producers tools work with its scene’s entities; and how Sports Fiction allows the players to interact with its entities.
Binders are used to quickly alter related data without needing to define triggers or events; or carry out any programming.
Special input binders include the key, mouse and gamepad binders. These entities bind key strokes, key patterns, mouse movement and simple gestures into triggers which alter properties and raise events.
Any property can be bound to a button state; and button states are context and modifier key reliant. For example the [A] key, the [CTRL+A] key combination, and the [CTRL+A] key combination in context number 2 would each be considered separate binders. Pressing A and control will not trigger the binder assigned to the A key until the control key is released; the third example is only possible when the interactivity context under the index of 2 is active.
Triggers
Triggers are custom function calls that fire up when certain events occur. For example in the X-Producer, when a button is pressed by the user, a trigger could be attached to the button which runs a custom command prior to running the button command. In the world-engine, a trigger could cause a game level to load when a character reaches a location. In the viewport-engine, a trigger could be used to call a brightness update to a shader whenever the position property of a 3D object changes.
Triggers always pass on a reference and a value to the function so that the function can act upon the referenced item with the given value. Triggers can also return values; this is how they are used when attached to properties as value getters. In node form, these are the wires that connect property getter ports with function output ports.
In a nutshell, triggers are simple events that call functions; but there is more to events than this as will be explained.
Events
When a character completes an objective; a certain number if points are added to the score and the objective requirement is removed from the game level. This is an event which requires a certain number of actions to be performed when it occurs; in this case, the removal of the objective and the awarding of points.
Events are similar to triggers however they are more complex because they activate numerous triggers attached to them. Like triggers, events can be fired up when anything takes place in the simulation. However, events can have a series of predicates attached to them; these are triggers which determine whether or not the event can proceed to call its attached triggers.
Another example of an event is when a goal is scored in a goal-orientated sport; when this occurs a certain team is awarded a number of points. A trigger would be activated and set to call the award goal function with a reference to the scoring player's team.
When using X-Producer World Creator to build worlds for your 2D or 3D games in Dark BASIC, these events need to be defined in the event editor; and can be given a series of instructions to perform when triggered; these instructions could be written in the Dark BASIC language to be generated using your chosen template; or they could simply be given a function name to call.
Selectors
Selectors are hierarchical lists of Boolean checks used to determine what index in the range to choose. Selectors are used to make choices for elements such as entities, triggers and timelines, based on a series of 32bit or 64bit logical Boolean operations with a given value.
An example of selector usage is with determining what shaders to supply to what objects without any advanced node development or programming.
Simply define a set of flags in each option and the selector will pick the first option that is true of the object. Because selectors can contain inner selectors, options can lead to further options which could narrow down the flags.
As a property type, selectors can be attached with events or triggers, and can be synchronized over a network.
XData
XData is an XML format used to define databases for game data, nodes for designing instructions and properties containing variable game data linked with other data. You need not have any programming experience to create these components, they are created for you as you work with the interface; and are saved in for you when you save your project files.
For those who wish to draw data from external sources or game engines, it is a format which can be used to describe information that want to bring into the X-Producer. Sports Fiction server hosts can choose to use XData to create rules and policies for players; however the XData would be generated by the user interface, unless you wanted to go low-level with XML code.
For those who are familiar with XML and might have a need to generate XData in their own programs can view a brief summary of the format below until the official documentation is released.
XData XML Format:
XData contains title-cased XML tags which represent a series of complex tags used to define core classes such as forces and ranges, and data-types such as strings (text), integers (whole numbers) or floating point (decimal point) numbers used to define modular structures; classifications of things in the world.
In most cases, XData is contained inside of a parent XML element of a different format usually representing an advanced property or entity. For example, characters are entities, and therefore contain the entity XML format, which contains physics properties such as weight and running speed, which in-turn contains XData which supplies the values for these properties.
Nodes which are a diagram of instructions all make use of XData to set properties or activate triggers.
Like most ZeroOne XML, tags have alternative names and are always in written in title-case:
XData String tag: <String> or <S>
XData Integer tag: <Int> or <I>
XData Float tag: <Float> or <F>
XData Force tag: <Force> or <FF>
XData Range tag: <Range> or <R>
XData 4D Vector tag: <Vec3> or <V3>
XData 3D Vector tag: <Vec3> or <V3>
XData 2D Vector tag: <Vec2> or <V2>
Individual XData elements are identified by their names, which are sometimes used to bind them to components or override property values when they are loaded. The Name attribute in the following X-Node indicates a day of the week.
XData: <String Name="Day" Value="Monday"/>
The following XData node indicates the name of a building as being 'The Red House'.
XData: <S Name="BuildingName">The Red House</S>
Notice that it is possible to use XML attributes or content to define values in XData; as shown respectively in the day and building name examples.
Further details of this XML format will be documented and demonstrated.
Tuples and Arrays
Tuples and arrays both contain a list of information; but the arrays are used in programming level, not with nodes. Tuples refer to lists that can be defined by X-Nodes and trigger calls defined by the user. The Zero-One tuples differ from the Microsoft .NET tuple class.
Most users of the X-Producer are unlikely to need to understand these components because they are created automatically when defining a list of items or data. But for those interesting in creating advanced sports events or for those interested in extending the X-Producer plugin range, this is an important thing to remember when reading the documentation; tuples can be created by nodes, arrays cannot be created by nodes, not directly anyway.
Moving on to the final part of the first 0.45 preparation update
