Understanding the Examples in the Project

The project contains several example implementations to help you understand how to create and integrate new content into the game.

Folder Organization

The project follows a structured folder organization to separate different types of assets:

• Blueprints: Generally organized under the GameLogic folder, which contains various gameplay-related elements such as traps, items, and player interactions.
• Characters visual assets: Stored in the Characters folder, where you can find the meshes, animations, and textures for different in-game entities.
• GameLogic Subcategories:
  • MapLogic: Contains elements related to game mechanics, including Items, Submarine, and Traps.
  • Player: Holds components related to player customization and behavior, such as Costume, Gameplay, Inputs.

Additionally, it is easy to imagine other folders such as Environment for world assets, Effects for visual and sound effects, or other categories depending on the mod's complexity.

Mod Initialization

The first blueprint to look at is BP_Mod_InitGame, where the mod initialization takes place. You can also find some example code inside, such as a demonstration for spawning a body part.

The first example adds a new item to the dispenser.

Creating a New Item

This example demonstrates how to create an item that heals the player and triggers a visual effect when used. The item is based on a child blueprint of BP_Maplogic_Item_Base and utilizes the Use Item Event to send a gameplay event for healing.

Additionally, a multicast event is used to replicate the visual effect across all clients.

For this item to be available in the dispenser, a special feature designed for mods called SystemModifier must be used. This system also allows adding costumes or modifying expedition spawns.

This system works quite simply: an object must implement the BPI_DispenserSystemModifier interface in the case of the dispenser, and this object must be added to the system modifier list of the mod manager.

In the example project, all system modifiers are added in BP_Mod_InitGame.

It is important to remove them from the mod manager during the End Play event.

In this object implementing BPI_DispenserSystemModifier, there are two interface functions: DispenserSystem_Modifier_EditDispenserRow and DispenserSystem_Modifier_GetAdditionalDispenserRows.

DispenserSystem_Modifier_EditDispenserRow allows modifying an entry in the dispenser. All entries will call this function, and when you want to modify an entry, you simply need to return true in the output variable Edited.

In the example, the entry EmptyItem5 is replaced with our item.

• Mesh: mesh in the dispenser to visualize the item.
• Scale and Offset: for the mesh placement in the dispenser.
• Code: to tap on the dispenser to get the item, check if it is not already used in the game.
• Class: class of your new item.
• Category: where on the dispenser the item will be. IsEmptySlot: false.

It is possible to add new entries using DispenserSystem_Modifier_GetAdditionalDispenserRows, but they will not appear in the dispenser as they are not linked to a page. However, they can still be purchased by entering their code.

Creating a New Trap

This example showcases a trap (BP_Mod_TrapTest) that creates a damage zone when hit with a taser stick. The trap is implemented as a standalone blueprint actor with the BPI_Trap and BPI_TaserStickInteraction interfaces.

When activated, it checks for overlapping players and applies damage using a gameplay event. It utilizes the collision profile TriggerPlayer, which is set to overlap only with players. In this code, functions from the GAS Utility plugin are used. You can find more information on this page: GAS Utility.

As with other system modifiers (e.g., Creating a New Item), an object is created within BP_Mod_InitGame and implements the BPI_SpawnerSystemModifier interface. This allows it to add a new spawn to the expedition spawn system (BP_SpawnSystemModifier).

In Murky Divers, a budget-based spawn system is used. The Cost value represents its impact on the spawn budget, while Level Factor determines its spawn probability. In this example, we have intentionally set a low budget and a high spawn chance. The Spawn Cap represents the maximum number of instances allowed, defined as an array of five integers, where each value corresponds to a different expedition level.

Creating a New Ability

The example ability (BP_AMC_PlayerMod_TurnBack) and (BPA_PlayerMod_TurnBack) allows a player to rotate 180 degrees when pressing the K key. It is built using an Ability Manager Component (AMC) derived from BP_PlayerAbilityManagerComponent_Base, and an ability class based on BP_Phare_Player_GameplayAbility_Base.

Blueprint Files and Their Roles

BP_AMC_PlayerMod_TurnBack

An AMC (Ability Manager Component) is a replicated actor component that must be added to players using the AddAMC function. Check the BP Graph Abilities section in BP_Mod_InitGame.

This component adds an ability to the player, manages when the ability is active, and handles all replication aspects of the ability's effects.

The function Handle New Trigger is responsible for triggering the ability.

For more information, please refer to: Abilities Overview.

In BP_AMC_PlayerMod_TurnBack, we have overridden several events that allow the initialization of the AMC in different cases: For example, Bind Ability Event On Owning Client is called only if the component is on the player's own character (and not on another player's character). In this case, we add the input mapping context IMC_RotatePlayer.

There are other initialization functions:

• Bind Ability Event On Server: Triggered when the server initializes the component.
• Bind Ability Event On Other Clients: Triggered on other clients, opposite of On Owning Client.
• Bind Ability Event On All Roles: Triggered in all cases.

It is not recommended to use Begin Play, as at this stage, the role is not yet determined.

The Ability Class is specified in the settings of the AMC.

For this example, we simply rotate the player by 180°.

Adding a New Costume

This example demonstrates how to introduce a new player costume to the costume station. The costume is created using a player rig in Maya or Blender and imported into the MD_Mod plugin content folder.

As with other system modifiers (e.g., Creating a New Item), an object (BP_CostumeSystemModifier) is created within BP_Mod_InitGame and implements the BPI_CostumeSystemModifier interface. This system allows modifying existing costume entries or adding entirely new ones. Parameters such as unlock conditions, visibility settings, and notification texts define how the costume appears and behaves in the game.

Inside the BP_CostumeSystemModifier, in the 'Costume System Modifier Get Additionnal Costume Rows', you can add of change the existing 'Make Struct_Costume' to define the properties of this new costume.

For the costume to be visible and behave correctly, you need to create a gameplay tag only for your own skin. On the EquippedTag, clic the drop down arrow of the Costume category and add a Sub Tag.

Now name the tag with a unique naming and it should always end with .IsEquipped. An exemple would be Costume.HatsuneMikuSkin.IsEquipped.

For the UnlockTag, to allow every player to acces the skin from the start, set it to Player.Identify. If you wish to set a condition to its accessibility, create a tag that you can control in your code. It should always end with .IsUnlocked. An exemple would be Costume.HatsuneMikuSkin.IsUnlocked.

The Make Struct_Costume is composed of :

• EquippedTag: tag added when the costume is equipped on the player.
• UnlockedTag: tag on the player when they have completed the costume condition. Condition text: printed on the costume station.
• Unlock notif text: printed on the HUD when the costume is unlocked.
• isHidden: costume and condition are blurred.
• ShouldBeShown: is printed in the costume station.

Next Page