This page is to serve as a reference to the intended design of these features. Feel free to comment to discuss, but the master post will be edited to match the current implementation as the work progresses.
Permissions
Permissions are handled in a RBAC fashion. Each account can be assigned multiple roles, and roles can define permission statements of what is allowed. By default, every permission is denied.
Accounts when they are created will be given a default role that will enable minimal permissions that allow a player to navigate public Cognitions and create their own Cognitions.
Authors can allow collaboration by granting other people permissions to edit their creations.
Avatar
Each account has a customizable avatar. A unique handle/screenname allows people to mention you in messages.
Avatars can have data and items stored within it.
Character
When an Avatar enters a Cognition, the Cognition may require that the Avatar has a compatible Character. For example, if someone created a Cognition that utilized a rule system such as Dungeons & Dragons, it could require you to create a Character that had the required attributes.
Characters are defined by a ruleset of sorts. This is something that needs to be brainstormed Characters can be shared between different Cognitions created by different authors, because the behavior of the Character is agreed upon.
When Characters enter a Scene, the Character is represented in the Scene by a Component, and therefore it has all of the same types of storage available to it.
Assets
An asset is a media file such as an image, audio file, source code, or other object that can be utilized within ncog.link’s creation tools. It supports storing past versions of assets and keeps track of copyright and licensing information.
Libraries
A library is a collection of assets. All works in a library must adhere to the same licensing scheme, and to submit an asset to a library you must agree to license that asset with the required license. The licensing scheme is decided at the time of library creation, and the license cannot be changed.
In the future, changes to licenses could be allowed by forking and requiring each contributor to re-license in the new terms. However, each contributor would not be required to, and so a “forked” library would potentially be missing assets. Because of how complicated this process could become, it is not being considered for the initial implementation.
Cognitions
A Cognition is sort of the concept of a world or universe inside of ncog. It is defined by a Character type and one or more Libraries. Each Cognition must have a “Lobby” Scene, which will be where every Character joins upon connecting.
Scenes
A scene is a layered dynamic 2d canvas that is defined by a unique name and a Component tree. Scenes live as long as they are accessible in some way from the Lounge. This means if the Lounge has a Component that creates an instance of a new Scene, as long as that Scene has Characters inside of it or the Scene is linked from some door/portal/other mechanism to the Lounge, the Scene will remain active and all Components will still update.
Components
A Component is a scripted object that has various events that fire as Scenes are updated. Certain events will run once per server-frame, and other events will allow customizing how the scene is laid out visually on a per-user-basis.
Components have data storage options available to them:
- Shared storage is shared between all Instances of the Component across all Scenes. This would allow, for example, a NPC-like Component to have memories when you interact with it in different Scenes.
- Scene storage is shared between all Instances of the Component within the current Scene.
- Instance storage is unique to each Instance of the Component.
Components can create other Components so that functionality can be shared through Composition.
The scripting language is to be determined.
Idea in progress: Each Component should define a state machine, and part of the event lifecycle should encompass transitioning between states. I think this is a key design idea that helps organize behaviors, and it needs to be front and center.
Ideas of built-in components
Tile Map
An easy-to-use map type that would allow for static maps as well as dynamic maps. Tiles could have walls and other occlusions, and basic lighting support would be available.
NPC
An easy-to-use component that allows creating dialog trees that also support options for conversing with multiple Characters at once.
Flashes
A Flash is a temporary graphical component that a Component can trigger. These are typically informational, and examples could include showing hitpoints after an attack, or showing an emote animation.
User Interface
Display information for the Character in a HUD, but control information windows or dialogs that block the Scene behind it. The User Interface is a powerful system that will enable running entire games within a window inside of a Scene.
This would be useful, for example, to display a custom interface for picking tracks on a Jukebox Component.