Multiplayer
Game System

What is included

Nice Lobby supplies the multiplayer front end. The gameplay plugins extend it with components on PlayerState, GameState and the existing character children. Character movement stays in the inherited CMC or Mover implementation.

Build and enable the plugins

1. Open MultiplayerGameSystem.uproject in Unreal Engine 5.8. Build the NiceLobbySystemEditor target after native changes, with the editor closed so plugin DLLs can link.
2. Check Edit → Plugins for Nice Lobby, Nice Game Core and the desired feature plugins. Enable Python Editor Script Plugin and Editor Scripting Utilities for the editor tools. Customization also needs Mutable. Restart after changing native plugins.
3. In Project Settings, check the Nice Lobby data asset references. The project uses /Game/NiceLobby/Data for lobby assets and /Game/NiceGame/Data for gameplay catalogs.
4. Use the existing child characters BP_NGSCharacter_CMC and BP_NGSCharacter_Mover. Keep their parent locomotion graphs; add feature configuration to these children or components.

Set up the playable example

1. Save your work. In the editor choose Tools → MGS → Set up playable demo. This imports included equipment meshes, assigns example catalog presentation, creates or updates L_MGS_Demo, and points the lobby level list at it.
2. The setup also configures example audio routing, input authoring and demo introductions. Read its report at Saved/Automation/MGSPlayableSetup.json; resolve warnings before relying on those optional settings.
3. Start from the character selection screen. Select a character and play solo. The configured single-player destination should be MGS Field Camp. For co-op, use Lobby → Host Game and select that map.
4. Look at a nearby pickup and press F / X · Square. Open the menu with Backspace. Inspect Equipment, learn a skill, track a quest, then visit a ride workshop.

Your four lobby assets

Select these in Project Settings → Nice Lobby. Gameplay catalogs are selected separately in each plugin’s settings. A catalog that is not active is not used to populate reference pickers.

Default controls at a glance

These are example defaults. Settings → Controls stores player bindings. Releasing the companion modifier restores the normal combat D-pad behavior. Input contexts and existing project mappings may have additional actions.

What the Lobby does

The lobby lets players discover or create sessions, manage the current team, connect with friends and view online records. Use LAN for local network sessions or Epic Online Services for configured online play. The same gameplay components run in solo, listen-server and dedicated-server worlds.

1. Open DA_NLS_Levels and add your map with a readable name and stable ID. Choose its map asset and compatible game modes.
2. Open DA_NLS_GameSettings. Keep the intended PlayerController and the extended NGSPlayerState / NGSGameState integration. Changing these back to plain engine classes removes feature state.
3. Add Player Starts to the map. Use Tools → MGS → Nice Lobby: Add Player Starts for the existing example placement helper.
4. Host with one player, join from another process, and verify both clients can open the same organized menu.

Find Games

Search the selected online or LAN service, review the returned sessions and join an available session. Empty results can mean no compatible session is advertising; it does not mean that items or character data are missing.

1. Use Settings → Connection for the intended network mode and sign-in.
2. Refresh the session list after the host has created a session. Check compatible build/version, map availability and free player slots.
3. Select the session and join. A password-protected session requires its password.
4. If a local test fails, check host advertisement, firewall and LAN subnet before changing gameplay catalogs.

Host Game

Choose a hostable map and mode, then configure the offered session options. The map/mode entries come from DA_NLS_Levels, rather than arbitrary typed package names.

1. Add your map to Multiplayer Maps and associate it with the desired mode.
2. Configure the mode’s minimum players, countdown and ready requirements. The field-camp example is intended for immediate exploration.
3. Host, then ask a second test process to join. Use Team for party management and subsequent level changes.
4. For packaged builds, include every destination and its content in cooking rules. A working editor map reference is not proof that the packaged map exists.

Team

Shows the connected roster and the match/team controls allowed by the current mode and player role. Ready checks, leadership and level changes belong here. The old persistent “Press READY…” world-screen hint has been removed.

1. Set ready/countdown behavior on the mode definition, rather than adding instructions to the world HUD.
2. Test host and non-host permissions separately. A client should not gain host controls simply by opening Team.
3. When changing maps, retain the configured seamless travel settings and test both character families. The project includes an optional pawn-retirement workaround for Mover travel.

Friends

Uses the configured online identity and friends service for the exposed friend and invitation actions. Available actions depend on the signed-in service; a LAN-only player will not acquire an Epic friends list.

1. Configure and sign in to EOS with authorized test accounts.
2. Verify the expected account identity before testing friends or invites.
3. Test invitation delivery and joining with two real accounts. Local synthetic network tests do not validate the Epic social overlay or account permissions.

Online Stats

Displays the online statistics supported by the lobby’s configured subsystem. Define the intended stats and service policies for your product. Gameplay XP, equipment modifiers and shared story progression have their own authoritative feature records; they are not automatically the same thing as an online leaderboard.

Using Customization

Choose a configured appearance profile, then edit its exposed scalar, color, option, toggle or mesh choices. The inspection stage shows the character and supports rotation and zoom. Appearance choices replicate; generated geometry is built locally from the same authored content.

Author a Mutable profile

1. Create or open a Mutable Customizable Object and compile it. Start with a skeletal mesh and output component compatible with the target character.
2. Create parameters in the Mutable graph first. In DA_NGS_Appearance, add a profile with a stable ID and readable Name; assign its Customizable Object.
3. Choose the Mutable output component from the list. Leave Pawn Mesh Component at None for automatic body selection, or choose the intended skeletal component when a character has multiple meshes.
4. Add exposed parameter definitions. Select an existing graph parameter and the matching type; configure labels, ranges, defaults and option/mesh mappings.
5. Select this catalog in Project Settings → Nice Character Customization. Test one profile on CMC and Mover before adding more.

Skeletons, idle preview & missing choices

Mesh options must match the character’s animation skeleton or use an intentionally retargeted character setup. A Manny, Quinn or UEFN mesh is not interchangeable merely because it appears humanoid. Rider animation sets also need explicit skeleton matches.

1. In Project Settings → MGS Presentation → Character inspection, assign a compatible idle sequence for each supported skeleton.
2. If the preview is blank, verify the pawn has a visible rendered skeletal component and that the inspection target/material is available.
3. If generation never completes, compile the Mutable object, check its output component name and examine the Output Log.
4. If an option is absent, add it to the active Mutable graph and profile; reopening a selection list reads currently configured definitions.

The Mutable documentation is the upstream graph reference. This chapter describes the project adapter; it does not replace Mutable’s graph authoring manual.

Equipment board & inspection

The board places wearable slots beside the central weapon groups. Backpack is its own equipment slot below Back. Wearable boots belong in Equipment; supplies and quest objects belong in the Backpack storage tab. Ammunition rows show only owned ammo types.

1. Select a gear slot or weapon group. The inspection panel filters to relevant owned items.
2. Cycle Previous / Next or use left/right navigation. With multiple candidates, the focused item is emphasized and neighboring candidates remain selectable.
3. Read white candidate values and green/red changes compared with equipped gear. Zero changes are neutral.
4. Choose EQUIP or UNEQUIP. The server checks ownership, skill requirements, capacity and slot compatibility.

Give the carousel real item art

1. Open /Game/NiceGame/Data/DA_NGS_Items and choose the item definition. Assign Icon and/or a Preview Mesh. Armor Mesh supplies a skeletal presentation fallback.
2. For weapons, assign the mesh in DA_NGS_Combat; inspection can resolve the corresponding weapon definition.
3. Give the player at least two or three compatible variants through pickups or trusted grants. One owned item creates only one candidate.
4. Test selecting a neighbor and equipping it, then return to the character preview. Static Equipment Mesh, socket and relative transform can attach a wearable prop; skeletal armor must be compatible with the body skeleton.

Backpack storage sections

Non-equipment objects are grouped by their item category, such as consumables, materials, gems, quest items and other supplies. Set a meaningful category when authoring an item. Capacity and carried weight still apply to the entire inventory, including equipped items.

Food or water being visible in this tab does not by itself create eating, thirst or healing behavior. Author or extend the associated use action before describing an item as consumable in your finished game.

Create an item and its stats

1. In DA_NGS_Items, add a definition. Enter a unique stable ID once, then Name, Description, rarity, maximum stack and weight.
2. Choose an Equipment/Armor Slot for wearable gear, or no equipment slot for a stored object. Configure category and art.
3. Add Modifiers and select an existing Character stat. Add new stats in Project Settings → Nice Game Core → Base Attributes.
4. Place an NGSItemPickupActor, select the Reward Item and Count, and assign a visible mesh. A data asset alone does not spawn a pickup.
5. Use a new character or pick up the item in play. Starter loadouts are one-time grants, not a refresh after every edit.

Modifier calculation: max(0, (base + total flat) × max(0, 1 + total percent)). Percent 0.10 means 10%. Critical chance 0.05 as a flat value means five percentage points; the final chance is clamped to 0–1.

Inventory checks & common problems

Browse branches and preview a skill

Select a branch to inspect its connected skills. The preview describes the focused skill, rank, cost, requirements and effects. Learn a rank when its requirements are fulfilled. XP and skill points are authoritative character progress.

Add a skill, branch or prerequisite

1. Open DA_NGS_Skills. Add a node with stable Skill ID, readable Name and a description of the actual effect.
2. Select Branch from the authoring list. To add another, use Project Settings → Nice Game Authoring Lists; branches then become available to the UI and selectors.
3. Set Max Rank and Point Cost. Add required skill/rank pairs by selecting existing nodes.
4. Add Per Rank Modifiers using the Character stat list. Define new stats centrally instead of typing unknown modifier IDs.
5. Test the node both before and after learning prerequisites, then reload the character and confirm its rank.

What an unlock actually does

Multiple prerequisites require all listed conditions. Missing references, duplicate IDs, cycles and impossible required ranks invalidate a skill catalog. Server learning rejects overspending and invalid ranks.

Accept, track and claim

1. Select an available quest and accept it. Read the objective before collecting or interacting with its target.
2. Track it to send its destination to the map and minimap. Only one destination is actively tracked at a time.
3. Perform the objective. The example Gather Supplies requires acquiring three Wood after acceptance; existing stored Wood is not newly acquired progress.
4. Claim the reward when complete. If inventory or skill requirements prevent a grant, clear the problem and claim again. Claims are recorded to prevent duplicate rewards.

Create a quest without memorizing IDs

1. Add a definition in DA_NGS_Quests: stable ID, Title, Description and Main Quest flag.
2. Choose Required Completed Quests from the available quest list. This means those quests must be completed and rewards claimed first; an empty list imposes no prerequisite.
3. Add objective Description, Progress Event, Event Subject and Count. Select an existing subject appropriate to that event.
4. Set XP, Item rewards and Skill Unlocks using the corresponding catalog lists. Set the map location to the actual destination in your level.
5. Select the active catalog in Nice Quests settings. Test acceptance, incremental progress and a single reward claim.

Custom events and reward safety

A new name in an event list is only a selectable definition. Trusted server gameplay must emit it through UNGSProgressionComponent::RecordEvent. Do not expose an RPC that lets clients submit arbitrary objective counts.

Quest references must not point to the same quest or form prerequisite cycles. Reward grants preflight the bundle and use persistent claim identifiers. Keep definition IDs stable after release so saved progress continues to resolve.

Equip and use combat

1. Acquire the physical weapon and any required ammunition. Learn its skill prerequisites.
2. Select the weapon or an unlocked fighting style. Toggle combat input with C / D-pad Right.
3. Aim with right mouse / left trigger, attack with left mouse / right trigger, and reload with R / X · Square.
4. Holster or leave combat mode before relying on the same button for world interaction. Hold the companion modifier to route D-pad commands to the companion; release it to restore combat behavior.

Author physical weapons and fighting styles

1. In DA_NGS_Combat, use Physical Weapons for guns, rifles, machine guns, rocket launchers and melee objects. Select Required Skill and Required Inventory Item from existing definitions.
2. Choose melee, hitscan or rocket behavior, damage, range, attack interval, stamina, magazine and ammunition settings as appropriate.
3. Assign the hand socket, transform, mesh and compatible attack montage. Match the montage skeleton and the slot used by the character’s animation graph.
4. Use Fighting Styles for Fists, Kung Fu, Street Fight, Kick Boxing and Karate. Configure timing, damage, reach, stamina, required skills and attack animation there. Styles have no weapon mesh or magazine.

Attachments, paint and mesh variants

1. Create attachment definitions with an attachment slot, compatible weapons, required inventory item, socket/transform and mesh.
2. Configure supported modifiers such as damage, magazine size, aim FOV, laser or flashlight. Only one attachment occupies a slot.
3. Unload the weapon before modifying attachments. Maintain ownership of required parts.
4. For finishes use the configured Color/BaseColor material parameter, permitted mesh variants or valid decal materials. Preview and test the actual material; a parameter name alone cannot recolor a material that does not expose it.

Vitals and multiplayer behavior

The server validates skill/item ownership, cooldown, stamina, ammunition and aim, then performs the hit or projectile action. Clients do not choose damage or confirmed hit actors. Vitals replicate; equipment and skills affect maximums and relevant combat values. Player damage is off by default in Nice Combat settings.

Keyboard and D-pad command mode

Summon an owned companion and select it for commands. The small cross-shaped command HUD corresponds to the four D-pad directions. Default commands are Up Attack, Down Defend, Left Follow and Right Stay.

1. On keyboard hold Left Alt, then press 1, 2, 3 or 4. On gamepad hold L1 / left shoulder and use the D-pad.
2. Assign the four quick commands in the Companion tab. Change the actual input bindings in Settings → Controls.
3. Aim at the relevant actor/location for a targeted command. Ensure the companion has a valid navigation route and permission for the requested interaction.
4. Release the modifier. Normal D-pad combat behavior becomes active again; companion mode is not latched on.

Create an NPC or companion

1. In DA_NGS_NPCs, define a character with stable ID, readable name, faction, presentation and behavior settings. Define factions and their relationships in that catalog.
2. Assign compatible skeletal mesh/animation assets. Set idle/movement animations or an appropriate Anim Blueprint for the authored NPC.
3. Grant companion ownership through trusted gameplay or the configured starter companion option. Ownership is separate from placing an ordinary NPC in the level.
4. Provide navigation and reachable interaction targets. Test Follow, Stay, Attack and Defend, then targeted fetch/interact actions.
5. To support mounting, configure the mountable component, seats and matching rider animation sets as described in the Rides chapter.

Relationships and behavior

Faction relationships can make an NPC friendly or hostile as gameplay changes reputation. Apply faction/reputation changes through trusted server events. Companion inventories, command permissions and dialogue routing must remain tied to the owner; public NPC appearance and movement can replicate to nearby players.

Optional conversational provider

Start with offline guidance. For a model-backed guide, use Services/CompanionAI on the trusted server and enable conversational AI in Nice NPC settings. Provider credentials stay in the gateway process environment.

The adapters include OpenAI-compatible endpoints, Anthropic, Gemini, Azure OpenAI, Bedrock and Cohere, plus named compatible presets including Ollama, Groq, Mistral, DeepSeek, xAI, OpenRouter, Together and Fireworks. Provider selection and exact model availability are operator configuration, not a promise that every model supports every API feature.

1. Read the gateway setup in CompanionAI.md. Set the gateway URL/token on the Unreal server and the provider/model/credentials on the gateway.
2. For local inference choose an installed, licensed Ollama model suitable for the machine. Hosted free tiers may have quotas and changing eligibility; check current provider terms.
3. For a new compatible provider, add a preset or use the compatible adapter. For a native API, implement the adapter contract in providers.py, register it, and add injected-transport fixture tests.
4. Test a live account explicitly before release. AI dialogue must not directly award items, execute commands or override server permissions.

Buy, preview and fit parts

1. Select an owned ride. Choose a category to see compatible paint, cosmetic or performance parts.
2. Select a candidate to preview it and compare current values with green/red differences. Previewing does not buy or fit the part.
3. Buy & Fit requires a nearby open workshop that stocks the part and enough of its configured currency.
4. Fit Owned Part and Restore Stock Part work anywhere, including while mounted or driving. Purchased ownership remains when stock parts are restored.

Create a ride profile

1. Add a profile in DA_NGS_Rides. Choose a static mesh, skeletal mesh, or a complete Actor Class / driver Blueprint. A skeletal mesh takes priority over the static example mesh.
2. Configure speed/turning for the native example driver, or implement NGSRideDriver on your custom actor and connect validated ride input to its actual movement system.
3. Configure seats: transform, saddle/seat socket, safe exit offset and driver/passenger role. Keep a single driver seat.
4. For skeletal rides assign an Anim Blueprint or compatible idle/move clips. The Anim Blueprint takes priority and can read SpeedForAnimation.
5. Add customization points for the categories the ride supports. Repeat Wheels four times for a car or twice for a motorcycle; place each point/socket on the actual mesh.

How the system selects a riding animation

Every seat has Rider Animations entries keyed by the rider’s skeleton. The runtime matches the current rendered character skeleton to that list; it does not guess a horse or car animation from the ride name.

1. Add one entry for each supported character skeleton.
2. Assign a looping Riding Pose or a rider Animation Class. The rider seat pawn exposes RideSpeed for your blend logic.
3. Optionally assign compatible Enter Montage and Exit Montage. The rider/restored character graph must contain the required montage slots.
4. Test each seat with both character families. Boarding trajectories, root motion and retargeting are authored animation work; an empty entry leaves the replaceable default pose.

Create a garage, stable or specialist vendor

1. Open DA_NGS_RideCustomization. Define categories, ride stats, currencies, part definitions and services. References select available definitions.
2. Create a child of BP_NGS_Garage, BP_NGS_Stable, BP_NGS_BikeShop, BP_NGS_Hangar or BP_NGS_Marina. Replace its building art as needed.
3. Configure accepted profiles, Parts For Sale, Services and service radius independently for each vendor. Empty stock sells nothing.
4. Place the building in the level and test a purchase while near it and while out of range. Keep Require Workshop For Fitting disabled to retain anywhere fitting.
5. For production physics implement NGSRideTuningReceiver.ApplyRideTuning to apply engine/performance values to the actual movement component. Connect authoritative condition/fuel logic to UpdateRideCondition if using repair/refuel services.

What the example driver provides

The built-in rides are replaceable kinematic examples. A mesh alone does not provide Chaos tire physics, helicopter dynamics, buoyancy, animal gait or a train track system. Paint presets require compatible material parameters. Dynamic construction-script visuals may need an explicit profile preview mesh because inspection does not execute gameplay construction behavior.

For all part fields and the future generic-car integration recipe, see RideWorkshops.md.

World map and waypoint controls

1. Open World Map. Select an accepted quest or place a custom marker. Name the marker if desired.
2. Track one destination. The world map draws the server’s complete navigable route when available. The minimap points toward the destination, including targets beyond its edge.
3. For controller placement choose Focus Map, move the cursor with left stick, pan with right stick, place with X / Square, center with Y / Triangle, and zoom with D-pad Up / Down.
4. Use the marker list to track, rename or delete private markers. Markers remember their map, so travel does not draw another level’s points at incorrect coordinates.

Show the level, not an empty square

1. In Project Settings → Nice Maps, enable automatic level capture and geometry bounds, or set explicit World Center and World Span.
2. Provide visible loaded level geometry. The local renderer captures a top-down atlas; the server performs navigation and does not render map images.
3. Optionally assign an authored World Texture with matching coverage and north-up orientation. North is Unreal +X.
4. Use a separate authored map strategy for floors/interiors or unloaded world-partition regions. The capture can only show loaded geometry and may see roofs rather than rooms.

The minimap projects over the shared terrain atlas each frame so player motion need not wait for a moving scene capture. Terrain imagery refreshes less often than icons and player tracking; changing geometry may appear on the next atlas refresh.

Home, vendors, quests and other icons

1. Add NGSMapIconComponent to an actor or place an NGSMapLandmark. Select the category and readable label.
2. Use Home for the start location, Vendor for shops, Quest for objectives, Companion for owned guides/friends, and Ride for mountable vehicles/animals. Treasure, NPC, Resource and custom categories are also supported.
3. Define additional categories in Nice Game Authoring Lists. Keep replicated world actors’ icon state on the authoritative actor.
4. Check labels and icons at multiple zoom levels. The minimap intentionally emphasizes only the actively tracked destination, rather than every world icon.

Build a usable shortest path

1. Add a Nav Mesh Bounds Volume covering walkable space and the relevant destinations. Build navigation or enable runtime generation. Press P in the editor to inspect coverage.
2. Ensure the player and target can project onto the navmesh. Put quest destinations on reachable ground, not inside a wall or above an inaccessible roof.
3. Track a destination around an obstacle. The route should follow the navigation path instead of crossing the obstruction.
4. If no complete path exists, use the reported status to fix navigation coverage. Direction guidance is still useful, but it is not a fabricated walkable route.

Default navigation area costs give the shortest navigable route according to the navmesh query. Custom costs can prefer safer or cheaper terrain. Walking navigation does not implement separate air, water or rail routing.

Focus, prompt and interaction

Look at a nearby object to focus it. The HUD displays its label and interaction key. Press F / X · Square outside the combat input context. The server still checks distance, line of sight, requirements and capacity before granting anything.

Place a door, harvest node or chest

1. Place NGSInteractableActor or a Blueprint child. Choose Door, Button, Harvest, Dig, Pickup, Break Rock or Chest.
2. Assign a suitable visible mesh/collision and an action Label. Door examples rotate their mesh; harvested/depleted objects hide and disable collision.
3. Select any Required Skill, Required Key, Reward Item/Count and XP. Enable Consume Key only when intended.
4. Place the object within reachable space, then test both success and missing-requirement cases. Add a map icon if players should discover it on the world map.

Custom behavior and persistence

Implement NGSInteractable on a custom actor for CanInteract, Interact and InteractionLabel. Keep server-side permission checks for AI and other trusted callers too. The owning player component is the client RPC entry point; focus alone grants no authority.

Play and vote on the story

Read the active scene and fulfill any required event. Choose a branch by voting. A strict majority is required: one solo vote, both players in a two-person party, or two of three players. Votes can change before a branch wins; ties wait. Departures recalculate the active roster.

Rewards are tracked once per character per campaign, including eligible history rewards for late joiners. A full backpack can leave a reward pending rather than discarding or duplicating it.

Author an episode and its branches

1. In DA_NGS_Story, add stable node IDs and readable narrative. Use the authoring lists for episode, scene, event, area and boss references.
2. Add choices and select existing next nodes. Configure an optional required progress event and subject for scenes that wait on gameplay.
3. Assign rewards, area unlocks, boss unlocks and optionally a Level Sequence. Keep sequence actor bindings valid in the destination map.
4. On doors, spawners or encounters query IsAreaUnlocked / IsBossUnlocked before allowing access. A story flag does not create a level or boss encounter by itself.
5. Test solo voting, a party tie, a majority, a player leaving and a late joiner. Check reward claims after save/travel.

Campaign ownership

Shared story is stored on the authoritative host/server under the configured Campaign Slot in Nice Story settings. Character quest/reward records are separate. Different hosts do not automatically share a campaign file through EOS sessions. Multiple independent story parties in a single server and automatic host migration need a backend/party extension.

Host weather controls

1. As host, enable or disable Day Cycle. Choose the current hour to set the time. Remote clients can inspect the state but cannot change shared weather.
2. Enable Season Cycle for calendar progression, or disable it and select Spring, Summer, Autumn or Winter.
3. Leave Automatic Weather enabled for weighted seasonal presets, or select Clear, Overcast, Rain, Snow or Fog manually.
4. Selecting a manual preset disables automatic replacement. Re-enable Automatic Weather when the authored climate should resume selecting presets.

Set up climate and visuals

1. Select DA_NGS_Weather in Project Settings → Nice Weather & Seasons. Configure real seconds per day, days per season, latitude, start hour and transition duration.
2. In the catalog, author each preset’s name, season, selection weight, duration range and climate values.
3. Place one NGSWeatherEnvironment in a level. Avoid overlapping independent sun/fog systems unless you deliberately integrate them.
4. Assign Niagara rain, snow and leaves systems/materials as desired. The example fallback effects are replaceable. Connect the surface parameter collection to your actual landscape and prop materials for wetness or snow response.
5. Verify a joining client receives the current calendar/preset and that travel restores the evaluated calendar, rather than reusing a previous world’s timestamp.

Weather checks

Visible precipitation is separate from accumulation gameplay, temperature damage, tire friction or animal behavior. Those systems should read the climate and apply their own authoritative rules.

Save and load a checkpoint

1. Dismount before making or loading a checkpoint. This restriction is separate from ride-part fitting, which is allowed while mounted.
2. Enter a checkpoint name and choose one of five manual slots. Save Here creates a save; an existing slot requires Confirm Overwrite.
3. Select Load Checkpoint, then Confirm Load. Loading replaces current host/world progress for the saved supported features.
4. Autosave uses its own slot about every two minutes when the local host is eligible. The page lists the available checkpoint metadata.

What is saved, and who can load it

Checkpoint load requires the same character and an available map. A previous valid checkpoint is kept as a backup. Invalid data is rejected; if the primary record is invalid, the reader can try its backup. Saves are stored under the game’s Saved/SaveGames directory.

Checkpoint limits to understand

Cross-host cloud persistence, multiple character selection slots and automatic campaign host hand-over are not supplied by the local save system. Keep stable definition IDs so records remain resolvable after content updates.

Graphics and view mode

Adjust the existing quality/display settings and choose first- or third-person view. The example shortcut is V / right stick click. First person uses the character’s head position and control rotation; the original character camera remains the basis for third person.

1. Test camera switching on each supported character, while moving and after respawn.
2. Check head/body visibility, camera clipping, equipped props and any character-specific camera modifier.
3. Treat camera animation, weapon sights and first-person hand animation as authored presentation work when replacing the character.

Audio routing: master, music, SFX, dialogue & mic

1. In DA_NLS_UI, assign Master, Music, Effects and Dialogue Sound Classes plus the Volume Sound Mix.
2. Route Sound Waves / Cues to the appropriate classes. A slider cannot distinguish music from effects if every sound is routed to one class.
3. In Settings → Audio, adjust the channel levels, voice playback and microphone preferences. Test with known sounds in each class.
4. For voice, configure the supported online voice service and permissions. Microphone preferences alone do not establish an online voice session.

Controls and action rebinding

1. Choose a listed action, begin rebinding, then press the desired key/button. Use Reset to return to the shipped defaults.
2. Native MGS actions include companion modifier/directions, view, interact, attack, reload and combat toggle. Movement and other Enhanced Input actions must expose player-mappable settings in their active mapping contexts.
3. Give custom Enhanced Input mappings unique names and useful display names. Enable Enhanced Input user settings and register active mapping contexts when extending the input flow.
4. Test the new binding in actual play, including after possession, mounting, travel and restart. Resolve overlaps between combat, interaction and the original sample’s actions.

Chat & voice preferences

Use the lobby’s existing chat and voice preferences for the exposed communication behavior. The current service determines voice availability. Test mute, channel behavior and microphone permissions with separate participants; a local text chat or UI toggle does not validate an EOS voice connection.

Go online or continue offline

1. Choose Go Online to select online preference and start the existing service sign-in flow. Use Lobby → Host Game or Find Games to create/join a session afterward.
2. Choose Continue Offline to retain the supported personal feature snapshot locally and leave a multiplayer session through the existing leave flow.
3. Review where gameplay progress is stored: online host records and a local offline character snapshot are distinct from a universally synchronized cloud character.
4. Test both host and remote-client transitions. The client should not import or load the host’s shared campaign file just by disconnecting.

For the publisher’s EOS product setup and account-level acceptance, see the final chapter. No portal credentials are embedded in this handbook.

Available editor commands

Populate a map safely

1. Open a saved gameplay map with ground collision and a Player Start. Keep a backup/source-control checkpoint.
2. Choose Tools → MGS → Populate current world randomly. The tool uses the first Player Start as its origin and traces for ground placement.
3. Review spawned pickups, harvest nodes, doors, workshops, rides and category markers. Adjust positions for your level; the random tool is an example-content aid, not a level designer.
4. Generated actors are tagged MGS.Generated. Running the tool again replaces prior actors with that tag. Untagged designer actors are preserved. Do not tag your own permanent content this way.
5. Use editor Undo to reverse the population transaction if needed. Save only after reviewing placement and navigation.

Commandlet setup and reports

The supported Python entry points include Tools/setup_gameplay.py, Tools/setup_playable_world.py and the dedicated feature setup tools described by their engineering notes. Run through Unreal’s Python environment, after building native classes. Regular system Python cannot import unreal.

Check the Output Log for Python exceptions and the setup completion marker. A commandlet process exiting is not by itself proof that every setup stage succeeded.

Readable definitions and categories

1. Create a new definition with a unique stable ID and readable Name/Title in its active catalog.
2. Reference it using the available-item/skill/quest/profile selector. If missing, confirm the intended catalog is active and reopen the list after editing.
3. Add new shared names such as branches, equipment slots, weapon groups, map categories or story events in Nice Game Authoring Lists. Add new character stats in Nice Game Core → Base Attributes.
4. Use the grouped definition panels: identity, visual presentation, requirements/progression and effects/rewards. Expand the group relevant to the task rather than scanning every field.

Add a gameplay feature plugin

1. Declare module/plugin dependencies on NiceGameCore and NiceLobby, plus only the features you actually call.
2. Derive a replicated UNGSFeatureComponent with a stable FeatureId. Register it through FNGSFeatures. Choose owner-only versus public replication per field.
3. Implement validated versioned WriteSave / ReadSave records. Restore dependencies before consumers and reject malformed/newer data without granting resources.
4. Derive a UNGSFeaturePage, register a named menu extension and choose Lobby, Character, World or Settings as its group. Activate by feature ID instead of a hard-coded tab index.
5. Use DA_NLS_UI → Menu Extension Classes for a Widget Blueprint override. Preserve focus, input and authoritative action calls when redesigning it.
6. Test standalone, an owning client, another observing client and a dedicated server. Add meaningful invalid-input and persistence checks.

Preserve CMC and Mover

Gameplay state belongs on the extended PlayerState/GameState, with pawn presentation and input supplied through components. The project’s new character children inherit the sample locomotion and animation graphs. Do not paste the same movement logic into a second base character.

Resolve the actual rendered skeletal component, including child actors when needed. Use explicit skeleton compatibility for appearance, armor, preview idle and rider animations. When adding a new pawn type, verify possession, camera, vitals, interaction, equipped visuals, mounting and travel together.

EOS configuration and developer portal

The gameplay plugins use Unreal replication and the existing lobby transport. EOS does not automatically save an entire world, retarget animations or turn LAN tests into online certification.

1. In your EOS product, verify the intended product, sandbox, deployment and client policy match the project’s configured artifact. Keep secrets out of documentation and source control.
2. Enable the required identity/session/social/voice or player-storage capabilities for the features you actually use. Configure the artifact encryption key when using the lobby’s optional profile cloud storage.
3. Use authorized test accounts with deployment access. Test login, session discovery, host/join, invitations, reconnect, travel and voice with separate accounts and machines.
4. Review the existing EOS project configuration before changing portal policies. No additional portal service is required merely to replicate inventory, quests or ride appearance.
5. Package and test the same build that players will use. Validate network permissions, cooking, connection failure and account sign-out behavior.

Repeatable development checks

& Tools/run_gameplay_validation.ps1 -Mode Solo
& Tools/run_gameplay_validation.ps1 -Mode RenderedSolo
& Tools/run_gameplay_validation.ps1 -Mode Network
& Tools/run_gameplay_validation.ps1 -Mode ListenNetwork

Run Network and ListenNetwork sequentially because the runners share a port. Native tests are under NiceGame in the Automation window. Reports go to Saved/Automation; rendered captures go under Saved/Screenshots. Provider contract tests live under Services/CompanionAI.

The runtime harness activates only with -NGSValidate in non-Shipping builds and uses transient test records. Also test the ordinary character-select → solo/host flow without that flag; a fixture-populated validation map does not prove the normal player’s map contains anything.

Normal-player acceptance walkthrough

1. Launch normally, choose CMC, enter the field camp and pick up a visible item using the on-screen prompt. Repeat with Mover.
2. Acquire multiple boots, open the equipment carousel, compare and equip them. Confirm idle preview, rotation/zoom and equipped appearance.
3. Learn a required skill, harvest Wood, progress a quest and claim its reward once.
4. Summon a companion; use the keyboard modifier commands and the gamepad command cross. Release the modifier and verify combat mappings resume.
5. Track a quest/custom marker. Confirm terrain, icons, a route around an obstacle and minimap direction without camera stepping.
6. Customize an owned ride, buy near a stocked workshop and refit an owned part while mounted. Confirm another client sees the change.
7. Switch view, adjust routed audio, rebind an action, set weather as host and verify remote behavior.
8. Save/load, travel, leave for offline and join again. Inspect private/public records and shared-story voting, then repeat with a packaged build.

Find the source of a problem

Production work and further references

Remaining production acceptance includes real EOS accounts/machines, physical gamepads, packaging/cook audits, latency/loss and production-world travel. Finished weapon, ride, animal, armor and interaction animation sets; realistic materials/audio; profession activities; production vehicle physics; broad world-actor persistence; and cross-host storage require their own content and integration work.

The included generated props and native examples are replaceable development content. The system does not claim that a selectable skill is a finished activity or that every arbitrary Blueprint vehicle is plug-and-play physics.

• Architecture and ownership notes
• Detailed authoring field guide
• Ride parts and workshops
• AI gateway and provider extension instructions
• Quest events and majority-vote story rules
• Dated engineering validation report