Project Lunaris

I’m working as C++ programmer on an Unreal Engine 5 survival RPG inspired by Rust and Valheim. I work across UE5 C++ and Blueprints, owning multiplayer/replication and core gameplay systems (AI, party system, world map & waypoints/compass, interaction, and UI/UX). My focus is a modular, data-driven architecture with safe pointers (TObjectPtr/TWeakObjectPtr), const-correctness, and early-out guards—plus ongoing profiling and optimizations to keep Gameplay smooth and the codebase scalable.

Screenshots

StateTree-Driven Animal AI — Network-Safe & Data-Driven (UE5)

This AI Chicken uses Unreal Engine 5’s StateTree to drive clean, data-driven behavior switching (idle, wander, flee, death) while remaining fully server-authoritative and multiplayer-safe. The character owns its health and leash data, while the StateTree reacts purely to replicated state and gameplay events.

StateTree overview — Graze/Patrol → Run → LookforPlayer → Returnhome

In-game behavior — StateTree reacting to threats, Player, and Home Area constraints

Leash Initialization & StateTree Bootstrapping

void AChicken::SetLeash_Implementation(
	const FVector& Center,
	float Radius,
	AActor* SpawnerOwner)
{
	if (!HasAuthority())
		return;

	HomeLocation = Center;
	WanderRadius = Radius;
	bLeashActive = true;
	OwningSpawner = SpawnerOwner;

	if (StateTreeComponent)
	{
		StateTreeComponent->SendStateTreeEvent(
			FStateTreeEvent(
				FGameplayTag::RequestGameplayTag(
					FName("AI.Event.SetLeash"))));
	}

	GetWorldTimerManager().SetTimerForNextTick([this]()
	{
		if (StateTreeComponent && !StateTreeComponent->IsRunning())
		{
			StateTreeComponent->StartLogic();
		}
	});
}

Key design points:

• Server-authoritative AI: All state changes originate on the server and replicate cleanly to clients.
• Event-driven StateTree: AI reacts to gameplay events instead of polling or ticking heavy logic.
• Safe multiplayer startup: Clients only start StateTree logic once replicated leash data is valid.
• Component-based health: Death, cleanup, and destruction are handled through a reusable HealthGauge component.

Why this matters:

• Easy to extend with new animals or behaviors
• State logic lives in data, not hardcoded branches
• Predictable replication and debugging

void UWorldMapUI::AddWaypoint(const FVector2D ScreenPosition) const
{
    const UMapSubsystem* MapSubsystem = UMapSubsystem::Get(this);
    if (!IsValid(MapSubsystem) || MapSubsystem->RegisteredMarkers.Num() >= 3)
    {
        LOG_WARN(MapSystemLog, "Cannot add more than 3 waypoints. Remove one first.");
        return;
    }

    if (!MapTexture)
    {
        LOG_ERROR(MapSystemLog, "MapTexture border is null!");
        return;
    }

    const FGeometry Geo = MapTexture->GetCachedGeometry();
    const FVector2D LocalPt = Geo.AbsoluteToLocal(ScreenPosition);

    const FVector2D Size = Geo.GetLocalSize();
    if (LocalPt.X < 0 || LocalPt.X > Size.X || LocalPt.Y < 0 || LocalPt.Y > Size.Y)
        return;

    const ULandSubsystem* LandSubsystem = ULandSubsystem::Get(this);
    if (!IsValid(LandSubsystem)) return;

    FVector WorldPos = LandSubsystem->TextureToWorld(LocalPt, Size, 0.f);
    if (UMapSubsystem* MSS = UMapSubsystem::Get(this); IsValid(MSS))
    {
        WorldPos = MSS->ProjectToGround(WorldPos, 100000.f, 20.f);
    }

    if (IsValid(MarkerClass))
    {
        FActorSpawnParameters Params;
        Params.Owner = GetOwningPlayer();
        if (GetWorld()->SpawnActor<AActor>(MarkerClass, WorldPos, FRotator::ZeroRotator, Params))
        {
            LOG_INFO(MapSystemLog, "Spawned Marker at %s", *WorldPos.ToString());
        }
        else
        {
            LOG_ERROR(MapSystemLog, "Failed to spawn Marker actor!");
        }
    }
}