Project Structure

How to organise a well-structured ARDEM mod plugin.

A well-organised plugin is easier to maintain, share, and expand. This page describes the recommended directory layout for an ARDEM mod.

Recommended Layout

bash

MyMod/
├── MyMod.uplugin               # Plugin manifest
├── Content/                    # Blueprints, textures, sounds
│   └── Icons/
├── Resources/
│   └── Icon128.png             # Plugin thumbnail (128x128)
└── Source/
    └── MyMod/
        ├── MyMod.Build.cs
        ├── Public/
        │   ├── MyMod.h             # Module interface
        │   ├── Items/
        │   │   └── MyCustomItem.h
        │   └── Subsystems/
        │       └── MyModSubsystem.h
        └── Private/
            ├── MyMod.cpp
            ├── Items/
            │   └── MyCustomItem.cpp
            └── Subsystems/
                └── MyModSubsystem.cpp

Using UE5 Subsystems

For mods that need persistent state or a central manager, derive from UGameInstanceSubsystem. This gives you a singleton that lives for the lifetime of the game instance and is accessible from anywhere.

MyModSubsystem.h

#pragma once

#include "Subsystems/GameInstanceSubsystem.h"
#include "MyModSubsystem.generated.h"

UCLASS()
class MYMOD_API UMyModSubsystem : public UGameInstanceSubsystem
{
    GENERATED_BODY()

public:
    virtual void Initialize(FSubsystemCollectionBase& Collection) override;
    virtual void Deinitialize() override;

    UFUNCTION(BlueprintCallable, Category = "MyMod")
    int32 GetPlayerCount() const;

private:
    FDelegateHandle JoinHandle;
    FDelegateHandle LeaveHandle;
    int32 PlayerCount = 0;
};

Module vs Subsystem

Use the IModuleInterface to register delegates on load/unload. Use a UGameInstanceSubsystem for stateful logic that persists across map loads. Both can coexist in the same plugin.