Create and configure a project

Open Builder → Config → Game appearance. Owners and Managers can paste direct public HTTPS URLs for the banner and game icon; there is no file upload. The preview shows your changes before you save configuration.

Use a 16:9 banner (recommended 1280 × 720) and a square icon (recommended 512 × 512). Saved artwork appears in Games cards and details when the catalog is loaded again, provided the project is already published. Artwork alone does not publish a draft.

Remove an image URL and save to restore the default artwork. Broken links fall back to default visuals. Images load from the external host, so use reliable hosting and artwork you have permission to distribute.

Open Dashboard → Projects and choose New project. Give the project a clear name that identifies the game or prototype, then select the target orientation before entering the Builder.

Orientation is not cosmetic: project canvas settings drive Scene Editor and live preview. Vertical projects use a portrait stage for phone-first experiences; horizontal projects use a landscape stage for desktop, menus and wider games.

After creation, the project opens with an empty flow. Add a Create Scene block first so the project has a visible starting screen.

• Choose orientation before designing scenes; changing it later changes the canvas proportions.
• Use a meaningful project name so support, collaborators and future you can identify it.
• Keep the project page open while you build; Save writes the current builder state to the project.

Scene IDs should be stable and descriptive because scene actions can select them statically or resolve them dynamically. Prefer values such as main_menu, level_one, pause_menu or game_over over temporary names.

Object IDs and element IDs serve different purposes. Object IDs identify reusable Sprite definitions. Element IDs are created automatically and allow Edit Component to target a specific item in a scene.

Do not duplicate identifiers intentionally. Duplicate IDs make dynamic references ambiguous and are harder to debug in a large flow.

• Use lowercase words and underscores for IDs.
• Keep display names human-friendly; keep IDs stable for logic.
• Use variables such as {current_scene} only when a target genuinely depends on runtime state.

Open Project → Webhooks to connect a project to another service. Receive events creates a private Morgames endpoint that an external backend can call. Send events sends signed Morgames notifications to an HTTPS endpoint you control.

For an incoming endpoint, create a When an incoming webhook is received Custom Event in Builder. Send a JSON object with an event name and optional data object. Every open game session receives the event with {webhook_event}, {webhook_id}, {webhook_received_at} and {webhook_data}; simple data values are also exposed as {webhook_field_name}.

When an outgoing webhook is delivered is a second Custom Event. It runs only after an external endpoint returns a successful HTTP response, exposing {webhook_delivery_id}, {webhook_endpoint_id}, {webhook_event} and {webhook_response_status}. It never fires for a failed request.

Incoming requests use POST with Content-Type application/json and Authorization: Bearer followed by the secret shown when the endpoint is created or rotated. The secret belongs in server-side environment variables or your automation platform’s secret field, never in browser JavaScript or a published game.

• Incoming endpoint: POST /api/webhooks/incoming/your_endpoint_key.
• Example payload: event purchase.completed with data such as coins or playerId.
• Pause, delete or rotate a key immediately from the endpoint row.
• Incoming payloads are limited to 64 KB and event names use lowercase letters, numbers, dots, dashes or underscores.
• Outgoing deliveries are signed with X-Morgames-Signature and include event, timestamp and delivery headers.

The Builder header reports the current save state. When meaningful content changes, it reminds you to save; moving nodes alone does not create an unsaved-content warning.

Live collaboration shares a temporary draft through WebSocket, but it never saves that draft automatically. If everyone leaves before an Editor, Manager or Owner selects Save, those live-only changes are intentionally discarded.

If you try to leave with unsaved changes, the Builder asks for confirmation. This protects node settings, scene layouts, branches and connections from accidental loss. A Create Scene without at least one scene component is invalid and cannot be saved.

• Save after adding or removing blocks, editing settings, connecting branches or changing scene elements.
• Use the Event Log and preview before relying on a saved flow.
• Resolve validation errors before leaving the Builder.

Open a project and use Custom Event Builder to choose a trigger such as On key press, On scene loads, On button click or On game starts. The selector intentionally cannot be dismissed until you choose a trigger or import a valid event share code, so every custom-event Builder has a clear runtime entry point.

Selecting a trigger creates a dedicated event flow. It contains only the selected trigger root and starts with no actions, connections, scenes or settings copied from Main Flow. Saving this Builder writes only that event’s flow and never overwrites the project’s main flow. Importing a share code instead copies the shared trigger and flow into a new event owned by the current project.

Main Flow is the protected game-initialization root and has no configurable trigger. A custom-event root is also protected, but managers and owners can change its event type and nickname. It deliberately contains no key, Object, scene or element filter: every occurrence reaches the flow and explicit Condition blocks decide which payload continues.

Event variables are scoped to the event which created them. For example, On key press makes {pressed_key} and {pressed_key_code} available in its own flow; On button click makes {button_id}, {button_label} and {scene_id} available. Compare those variables immediately after the root when the event should react only to one source.

• Use Comparison Condition with {held_key_code} equals KeyW for one physical key.
• Use {object_id} equals player or {scene_id} equals main_menu to filter Objects and scenes.
• Managers and owners can create, import or delete events; editors can edit event flow content and viewers remain read-only.
• A custom-event trigger root is protected just like Main Flow and cannot be deleted.

Open Team from the project detail page before entering Builder, or from the Builder header, to invite a collaborator by username or email. The invitation appears in their Notification Center and remains Pending in Team until they accept or decline it. Project access and the selected role are granted only after acceptance. Live Builder updates are synchronized through the project WebSocket, so flow, branches and scene changes appear without requiring a manual reload.

If the recipient declines, the inviter receives a notification that opens the project directly with Team visible. Owners and authorized Managers can cancel a pending invitation from Team. Invitation decisions and member-list changes are delivered in real time, so neither person needs to refresh the page.

Viewer is read-only: they can follow the current work and run Preview, but cannot change the Builder. Editor can create and edit flow blocks, connections and scenes, but sees Project Config as read-only. Manager can do everything an Editor can, change project configuration and manage Viewer or Editor access. Only the project owner can assign or manage Managers, publish, or delete the project.

Permissions are enforced on the server and refreshed in the active Builder as soon as a team change arrives. Changing someone to Viewer immediately disables editing and Config; removing them returns them to Projects. Desktop collaborators share a live pointer, while mobile collaborators share a temporary touch beacon only while their finger is on the Flow. Collaboration updates never flood Event Log: that terminal remains reserved for preview and execution feedback.

• Use Viewer for playtesting and review sessions.
• Use Editor for designers and logic builders without configuration access.
• Use Manager for trusted project leads.
• Search Team by display name, username, role or Pending status.
• Keep one person responsible for final publish and deletion decisions.

The Builder, Scene Editor, Object Editor, Map Editor and properties panels are responsive. On a phone, tapping a flow node opens its properties directly; closing the properties deselects it so the screen stays uncluttered.

All 2D editors use the same permanent bottom navigation. Object Editor provides Canvas, Draw and Setup; Map Editor provides Canvas, Chunks and Setup; Scene Editor provides Canvas, Elements and Setup. Each choice opens one focused full-width workspace, while the canvas retains the exact project proportions. Setup is disabled in Scene Editor until an element is selected.

On wide desktop screens, editor sidebars remain visible and scroll independently instead of scrolling the entire workspace. The 3D Object Editor continues to use its specialized Blender-style workspace and compact drawers. Assets cards and search collapse into a single-column project catalog. The Docs and Support Center use dedicated mobile navigation, so help remains accessible without shrinking the reading area.

Context menus always follow the item that opened them. Right-click on desktop, press Shift+F10 from a focused control, or long-press on touch. A flow block exposes properties, pin, Docs, duplicate and delete; a scene element exposes visibility and layer actions; an animation frame exposes edit, reorder, duplicate and delete; a chunk exposes open, reorder, duplicate and delete. Disabled actions remain visible when they explain a boundary, such as the first frame being unable to move left.

On mobile, the same context actions open as a scrollable bottom sheet instead of a tiny floating menu. This preserves the meaning of the clicked item while keeping every target large enough to tap.

• Test portrait projects and every dedicated editor on a narrow viewport before publishing.
• Use the permanent bottom navigation consistently across Object, Map and Scene editors.
• Canvas always returns to the visual workspace without clearing your saved work.
• Object sharecode remains inside Object Editor on every screen size.
• Long-press the exact block, element, frame or chunk whose actions you need.