三亩地 三亩地SAN MU DI · CODE DIARY
交流投稿
ARTICLE DETAIL

日记详情

真实记录编程学习的某一天，欢迎挑你感兴趣的翻一翻。

首页/学习日记/日记详情

UE5 GameInstance核心职责与架构设计：从新手困惑到最佳实践

发布时间：2026/8/10 9:05:30 三亩地 编程学习日记
UE5 GameInstance核心职责与架构设计：从新手困惑到最佳实践

1. 项目概述：GameInstance的角色定位与新手困惑

刚接触虚幻引擎5（UE5）的新手，在兴奋地搭建完第一个场景、摆弄了几个蓝图节点后，很快就会遇到一个灵魂拷问：我的游戏数据该放哪儿？尤其是在涉及到切换关卡、保存游戏、管理全局状态时，GameInstance这个类总会出现在各种教程和文档里，但它就像一个神秘的“百宝箱”，什么都能往里塞，却又好像什么都不能乱塞。很多新手开发者，包括当年的我，都曾在这里踩过坑：把玩家属性存进去，结果多人游戏不同步；把UI管理器放进去，导致内存泄漏；或者干脆把它当成一个全局变量垃圾桶，最后项目变得难以维护。

GameInstance是UE5 Gameplay框架中生命周期最长的对象，没有之一。它从游戏启动（引擎初始化完成）开始创建，直到游戏进程关闭才会被销毁。这意味着，它跨越了所有的关卡加载、地图切换、甚至是从主菜单进入游戏再退回主菜单的整个过程。官方文档将其描述为“所有你希望在关卡加载间保持的内容都应存于游戏实例中”，这句话既是它的核心价值，也是新手容易误解的根源。它不是一个“万能储物柜”，而是一个“游戏进程的管家”。理解它“该存什么”和“不该存什么”，是构建一个健壮、可维护的UE5项目架构的关键第一步。

这篇文章，我将结合自己从新手到老鸟一路踩过的坑，为你彻底拆解GameInstance的职责边界。我会用具体的实战案例，告诉你哪些数据适合放在这里，哪些绝对要避开，并附上一份详尽的“避坑指南”。无论你是正在制作单机RPG、联网对战游戏，还是简单的演示项目，理清GameInstance的用法，都能让你的代码结构更清晰，bug更少。

2. GameInstance核心职责与生命周期深度解析

要弄清楚什么东西该放进GameInstance，首先必须透彻理解它的生命周期和设计初衷。这不是一个普通的Actor或Object，它在整个游戏进程中是单例且持久的。

2.1 生命周期：从启动到关闭的全程守护者

让我们在编辑器中实际验证一下。创建一个继承自GameInstance的C++类或蓝图类（例如MyGameInstance），并在其Init()和Shutdown()函数中添加日志输出。

// MyGameInstance.h UCLASS() class MYPROJECT_API UMyGameInstance : public UGameInstance { GENERATED_BODY() public: virtual void Init() override; virtual void Shutdown() override; }; // MyGameInstance.cpp void UMyGameInstance::Init() { Super::Init(); UE_LOG(LogTemp, Log, TEXT("[GameInstance] Init - 游戏启动，实例创建")); } void UMyGameInstance::Shutdown() { UE_LOG(LogTemp, Log, TEXT("[GameInstance] Shutdown - 游戏关闭，实例销毁")); Super::Shutdown(); }

或者，在蓝图中重写这两个事件。然后，在项目设置中指定使用这个自定义的MyGameInstance类。运行游戏，你会看到“Init”日志在游戏启动后立即打印。无论你通过Open Level节点切换多少次关卡（比如从“MainMenu”切换到“Level1”），这条日志不会再次出现。只有当你完全关闭游戏编辑器或打包后的可执行程序时，才会看到“Shutdown”日志。

这个简单的实验证明了：GameInstance在游戏的一次完整运行中，只存在一个实例，且不会被关卡加载/卸载所影响。这与GameMode（每个关卡都可能不同）、PlayerController（每个本地玩家一个，关卡切换时可能被销毁重建）形成了鲜明对比。

2.2 核心职责界定：什么才是“关卡间需要保持”的？

官方说“关卡加载间需要保持”，这具体指什么？我们可以从两个维度来界定：

  1. 数据维度：那些不属于任何特定关卡，而是属于整个游戏进程的数据。

    • 正确示例：玩家的存档数据（经验值、金币、已解锁内容）、游戏全局设置（音量、键位、画面质量）、会话统计（总游戏时长、总击杀数）。
    • 错误示例：当前关卡的敌人数量、场景中某个可破坏物体的状态、玩家在当前关卡的位置。这些属于GameState或Level Blueprint的管辖范围。

  2. 系统维度：那些需要持续运行，为整个游戏提供服务的后台系统或管理器。

    • 正确示例：音频管理器（统一管理背景音乐和音效的切换）、存档系统、在线服务接口（如Steamworks SDK的封装）、数据分析模块。
    • 错误示例：当前关卡的天气系统、某个BOSS战的阶段管理器。这些系统的生命周期应与关卡绑定。

避坑指南1：区分“进程全局”与“会话全局”这是新手最容易混淆的点。GameInstance是“进程全局”的。而一次“游戏会话”（从点击“开始游戏”到“退出到主菜单”）的全局数据，更适合放在GameState中。例如，一局多人比赛的比分、剩余时间，应该存在GameState里，因为它会在服务器和客户端间复制。而玩家的所有存档数据，应该存在GameInstance里，因为退出这局比赛回到菜单，这些数据依然有效。

2.3 与Gameplay框架其他成员的协作关系

理解GameInstance如何与其他核心类交互，能更好地定位它的职责。

  • 与GameMode的关系：GameMode是关卡（地图）的“导演”，决定了本关卡的规则和玩法。GameInstance是“制片人”，决定了整个“电影系列”（游戏进程）的基调和资源。GameMode在每个关卡加载时由GameInstance负责创建（根据地图设置）。你可以通过GetGameInstance()在GameMode中访问到GameInstance，但通常不应该这样做来获取游戏规则数据，那应该是GameState的工作。
  • 与PlayerController/PlayerState的关系：PlayerController代表玩家的输入和视角，PlayerState代表玩家在一局游戏内的状态（血量、得分）。它们都是“会话”层面的。GameInstance持有所有本地LocalPlayer的引用，这是比PlayerController更底层的、与游戏进程绑定的玩家对象。你可以通过GameInstance来管理本地玩家的登陆、登出事件。
  • 与GameInstanceSubsystem的关系：这是UE4.24+（UE5中强化）引入的极其重要的架构。GameInstanceSubsystem是GameInstance的模块化扩展。任何符合“进程全局、需要自动初始化和销毁”的系统，都应该实现为GameInstanceSubsystem，而不是把一堆逻辑和变量直接塞进GameInstance类里。这保持了GameInstance本身的整洁，并利用了引擎的自动生命周期管理。我们会在后面详细讨论。

3. GameInstance存储内容实战分类与案例

理论说再多，不如看实战。下面我将数据/系统分为四大类，并用具体案例说明哪些该放，哪些不该放。

3.1 应该存储的内容（推荐实践）

第一类：游戏进程的配置与元数据

  • 游戏设置：图形质量、音频音量、语言、控制灵敏度。这些设置需要持久化到磁盘（通过SaveGame系统），并在游戏启动时从GameInstance加载和应用到各个模块。
  • 玩家档案：当前活跃的玩家档案ID、档案名称。在多档案系统中，GameInstance负责管理档案列表和当前选中项。
  • 全局功能开关：是否开启作弊模式、调试信息显示、实验性功能。这些开关影响整个游戏进程，而非单次会话。

实战案例：实现游戏设置管理器不要在GameInstance蓝图里堆上百个变量。最佳实践是创建一个USaveGame派生类MyGameSettingsSave来存储所有设置，并在GameInstance中持有一个该类的实例指针CurrentGameSettings。在Init()中加载设置，在Shutdown()或收到修改事件时保存。

// 在GameInstance中 UMyGameSettingsSave* CurrentGameSettings; virtual void Init() override { Super::Init(); // 尝试加载存档，不存在则创建默认 if (UGameplayStatics::DoesSaveGameExist(TEXT("GameSettings"), 0)) { CurrentGameSettings = Cast<UMyGameSettingsSave>(UGameplayStatics::LoadGameFromSlot(TEXT("GameSettings"), 0)); } else { CurrentGameSettings = Cast<UMyGameSettingsSave>(UGameplayStatics::CreateSaveGameObject(UMyGameSettingsSave::StaticClass())); UGameplayStatics::SaveGameToSlot(CurrentGameSettings, TEXT("GameSettings"), 0); } // 应用设置：例如设置全局音量 if (CurrentGameSettings) { UGameplayStatics::SetSoundClassVolume(CurrentGameSettings->MasterSoundClass, CurrentGameSettings->MasterVolume); } }

第二类：跨关卡的进度与资产引用

  • 剧情标志与任务状态：在RPG游戏中，玩家是否已经与某个NPC对话、是否完成了某个关键任务。这些标志位需要跨越多个地图（如从村庄到森林）持续存在。
  • 玩家资产与库存（概要）：注意，这里存储的是“概要”或“引用”，而不是具体的Actor。例如，存储玩家拥有的武器ID列表、装备的模板ID、金币数量、材料数量。具体的Actor实例化应该在关卡中根据这些ID来生成。
  • 解锁内容：已解锁的角色、皮肤、关卡、难度模式。

第三类：全局系统与管理器（强烈推荐使用Subsystem）

  • 音频管理系统：管理背景音乐的平滑切换、全局音效池、动态混音。
  • 存档/读档系统：封装SaveGame的复杂操作，如多存档位管理、自动存档、存档截图。
  • 本地化/本地化管理器：管理字符串表加载，响应语言切换事件。
  • 数据分析与遥测：向后台服务器发送匿名游戏数据（需遵守隐私政策）。
  • 平台服务接口：如Steam、Epic Online Services的成就、云存档、好友列表的封装。这些服务通常从游戏启动到关闭都需要保持连接。

避坑指南2：使用GameInstanceSubsystem进行模块化直接在GameInstance类里写一个5000行的ManageAudio()函数是灾难。应该创建一个UMyAudioManagerSubsystem类，继承自UGameInstanceSubsystem。

UCLASS() class MYPROJECT_API UMyAudioManagerSubsystem : public UGameInstanceSubsystem { GENERATED_BODY() public: virtual void Initialize(FSubsystemCollectionBase& Collection) override; virtual void Deinitialize() override; void PlayBackgroundMusic(FName MusicTrack); void SetGlobalVolume(float Volume); private: UAudioComponent* CurrentBGMComponent; // ... 其他私有成员 };

然后，你可以在游戏中的任何地方，通过GetGameInstance()->GetSubsystem<UMyAudioManagerSubsystem>()来优雅地访问音频管理器。引擎会自动创建和销毁它，生命周期与GameInstance完全一致。这让你的代码清晰、可测试、易复用。

3.2 绝对不应该存储的内容（常见误区）

第一类：任何与具体关卡或场景绑定的Actor或状态

  • 错误做法：在GameInstance里保存一个APlayerCharacter*指针，或者保存一个TArray<AEnemy*>敌人数组。当关卡卸载时，这些Actor指针会变成“悬空指针”，指向的内存已被释放，再次访问会导致崩溃或不可预知的行为。
  • 正确归属：玩家角色是Pawn，由当前关卡的GameMode生成和管理。敌人数组应该由关卡中的某个管理器Actor（如AEnemySpawnManager）或GameState来持有。

第二类：应该在GameState或PlayerState中存储的会话数据

  • 错误做法：在GameInstance里存储当前比赛的比分、剩余时间、玩家当前的实时血量和弹药。
  • 正确归属：在多人游戏中，GameState用于存储所有客户端需要同步的全局游戏状态（比分、时间）。PlayerState用于存储单个玩家的公开状态（血量、弹药、得分）。在单机游戏中，你也可以用它们来组织逻辑，保持架构清晰。

第三类：大量的临时计算数据或缓存

  • 错误做法：把一些复杂的计算中间结果、临时加载的资源句柄存在GameInstance里，指望下次关卡加载时还能用。
  • 正确做法：临时数据应该有明确的生命周期和作用域。如果需要在函数间传递，使用参数或返回值。如果需要跨帧，可以放在任务所属的对象中。GameInstance不是垃圾堆。

第四类：UI控件的具体实例

  • 错误做法：在GameInstance中创建并持有一个UUserWidget控件实例，比如主菜单界面，希望它永远不消失。
  • 正确做法：UI的生命周期最好由其逻辑控制。主菜单界面应该在打开主菜单关卡时创建，在离开该关卡时销毁。如果需要全局的UI管理器，应该实现为一个GameInstanceSubsystem，这个子系统管理UI的创建和销毁逻辑，但通常不直接持有控件实例，而是持有它们的类引用或创建方法。

避坑指南3：悬空指针崩溃的噩梦这是我早期犯过的严重错误。我在GameInstance中保存了对一个关卡中特殊道具Actor的引用，打算在下一个关卡检查它是否被收集过。当切换关卡后，旧关卡被垃圾回收，那个Actor指针依然在GameInstance里，但指向的对象已经没了。下一次我访问这个指针的属性时，游戏立刻崩溃。教训是：永远不要在GameInstance中持有来自动态加载关卡的Actor或UActorComponent的原始指针。如果需要引用，使用TSoftObjectPtr（软引用）存储资产路径，或者使用唯一的标识符（如FName或GUID）来记录状态。

4. 基于GameInstanceSubsystem的架构实战

理解了该存什么之后，我们来设计一个健壮的架构。直接把所有东西都写成GameInstance的成员变量和函数，会让这个类迅速膨胀成“上帝类”，难以维护。GameInstanceSubsystem是解决这个问题的银弹。

4.1 设计一个存档管理系统子系统

假设我们的游戏需要一个复杂的存档系统，支持多个存档位、自动存档、存档元信息（截图、游戏时间）。

  1. 创建Subsystem类：

    // MySaveGameSubsystem.h #pragma once #include "Subsystems/GameInstanceSubsystem.h" #include "MySaveGameSubsystem.generated.h" USTRUCT() struct FSaveSlotInfo { GENERATED_BODY() FString SlotName; // 存档位名称，如 "Save_01" FDateTime SaveTime; // 存档时间 int32 PlayerLevel; // 用于在UI显示 UTexture2D* Screenshot; // 存档截图 }; UCLASS() class MYPROJECT_API UMySaveGameSubsystem : public UGameInstanceSubsystem { GENERATED_BODY() public: virtual void Initialize(FSubsystemCollectionBase& Collection) override; virtual void Deinitialize() override; // 对外接口 UFUNCTION(BlueprintCallable, Category = "Save System") TArray<FSaveSlotInfo> GetAllSaveSlotInfos() const; UFUNCTION(BlueprintCallable, Category = "Save System") bool SaveGameToSlot(const FString& SlotName, class UMyPlayerSaveGame* SaveGameObject); UFUNCTION(BlueprintCallable, Category = "Save System") UMyPlayerSaveGame* LoadGameFromSlot(const FString& SlotName); UFUNCTION(BlueprintCallable, Category = "Save System") void DeleteSaveSlot(const FString& SlotName); // 自动存档触发（例如在完成任务、进入新区域时） void TriggerAutoSave(); private: // 内部辅助函数 FString GetSaveGamePath(const FString& SlotName) const; void CaptureSaveScreenshot(const FString& SlotName); // 内存中缓存的存档信息，避免频繁读盘 TMap<FString, FSaveSlotInfo> CachedSlotInfos; FTimerHandle AutoSaveTimerHandle; };

  2. 在GameInstance中访问： 现在，在你的游戏代码中，任何需要存档读档的地方，你都不需要知道GameInstance的具体实现，只需：

    // 在某个Actor或Widget中 if (auto* SaveSystem = GetGameInstance()->GetSubsystem<UMySaveGameSubsystem>()) { SaveSystem->SaveGameToSlot(TEXT("QuickSave"), CurrentSave); }

    或者，在蓝图中，你可以通过Get Game Instance节点，然后Get Subsystem (My Save Game Subsystem)来访问所有暴露为BlueprintCallable的函数。

4.2 设计一个音频管理子系统

音频管理是另一个典型的全局系统。

// MyAudioManagerSubsystem.h UCLASS() class MYPROJECT_API UMyAudioManagerSubsystem : public UGameInstanceSubsystem { GENERATED_BODY() public: virtual void Initialize(FSubsystemCollectionBase& Collection) override; UFUNCTION(BlueprintCallable, Category = "Audio") void PlayBackgroundMusic(USoundBase* Music, float FadeInTime = 1.0f); UFUNCTION(BlueprintCallable, Category = "Audio") void StopBackgroundMusic(float FadeOutTime = 1.0f); UFUNCTION(BlueprintCallable, Category = "Audio") void SetSoundClassVolume(USoundClass* SoundClass, float Volume); // 动态根据游戏状态调整混音（如进入战斗、水下） void ApplyAudioMixSettings(FName MixProfileName); private: UPROPERTY() UAudioComponent* BackgroundMusicComponent; UPROPERTY() USoundMix* CurrentActiveMix; };

这个子系统在Initialize中创建AudioComponent，在游戏进程中管理所有背景音乐的交叉淡入淡出，并响应来自GameInstance中游戏设置的变化，调整全局音量。

避坑指南4：Subsystem的初始化顺序依赖有时候，你的Subsystem A需要在初始化时访问Subsystem B。你不能在构造函数中做这件事，因为那时其他子系统可能还没创建。正确的方法是在Initialize函数中，通过传入的FSubsystemCollectionBase& Collection参数来获取其他子系统。

void UMyAchievementSubsystem::Initialize(FSubsystemCollectionBase& Collection) { Super::Initialize(Collection); // 确保音频管理器已初始化，以便播放解锁成就的音效 UMyAudioManagerSubsystem* AudioManager = Collection.InitializeDependency<UMyAudioManagerSubsystem>(); if (AudioManager) { // 现在可以安全使用AudioManager } }

使用InitializeDependency可以确保依赖的子系统在你之前被初始化。这是管理复杂子系统间关系的安全方式。

5. 实战避坑指南与性能优化

掌握了核心原则和架构后，我们来看看实际开发中那些最容易导致崩溃、bug或性能问题的“坑”。

5.1 内存泄漏：未正确管理UObject引用

GameInstance生命周期很长，如果你在其中持有了对其他UObject（特别是非GameInstanceSubsystem）的强引用（UPROPERTY()指针），而这些对象本应在关卡切换时被垃圾回收，就会导致内存泄漏。

  • 坑：在GameInstance中有一个UPROPERTY()变量引用了某个关卡中的管理器Actor。关卡卸载后，这个管理器Actor因为被GameInstance引用而无法被GC回收。
  • 解决方案：
    1. 使用弱引用：如果只是为了偶尔查询状态，使用TWeakObjectPtr。
      TWeakObjectPtr<AMyLevelManager> CachedLevelManager;
    2. 使用标识符而非引用：存储该管理器的唯一ID或名称，当需要时在当前的关卡世界中通过查找来获取。
      FName LevelManagerTag = TEXT("LevelManager"); // 在需要时查找 AMyLevelManager* FindLevelManagerInCurrentWorld() { UWorld* World = GetWorld(); for (TActorIterator<AMyLevelManager> It(World); It; ++It) { if (It->ActorHasTag(LevelManagerTag)) return *It; } return nullptr; }
    3. 使用Subsystem：如果这个管理器真的是全局需要的，考虑将其重构为一个GameInstanceSubsystem或WorldSubsystem（如果它的生命周期与世界绑定）。

5.2 多人游戏（网络复制）的误解

这是重中之重！GameInstance不参与网络复制。它在服务器和每个客户端上都独立存在一个实例，且彼此之间不通信。

  • 坑：在多人射击游戏中，试图在GameInstance里存储当前比赛的玩家列表，并期望所有客户端都能看到相同的内容。
  • 后果：服务器上GameInstance里的列表是权威的，但客户端上的GameInstance里的列表是空的或者不同步的，导致UI显示错误或逻辑混乱。
  • 正确做法：所有需要同步的游戏状态，必须存储在GameState或PlayerState中，并正确设置Replicated属性。GameInstance只应存储本地客户端的本地信息，如本地玩家的键位设置、本地图形选项、本地玩家的单机存档数据（如果游戏支持单机进度）。

5.3 初始化与关闭的顺序问题

GameInstance的Init()调用得非常早，早于任何关卡加载，早于大多数引擎子系统完全就绪。Shutdown()调用得很晚，很多对象可能已经被销毁。

  • 坑：在Init()中尝试访问GetWorld()并生成Actor。此时世界可能还不存在，会导致崩溃或生成失败。
  • 解决方案：将依赖于世界存在的初始化操作延迟。可以使用FTimerHandle延迟一帧，或者监听World的PostInitializeComponents事件。
    void UMyGameInstance::Init() { Super::Init(); // 立即执行一些不依赖世界的初始化，如加载配置 LoadConfig(); // 延迟一帧执行依赖世界的初始化 GetTimerManager().SetTimerForNextTick(FTimerDelegate::CreateUObject(this, &UMyGameInstance::DelayedInit)); } void UMyGameInstance::DelayedInit() { if (GetWorld()) { // 现在可以安全地执行依赖世界的操作 InitializeWorldSpecificSystems(); } }
  • 关闭时的坑：在Shutdown()中，一些子系统（如渲染线程）可能已经停止。避免在这里进行复杂的渲染操作或访问可能已无效的渲染资源。

5.4 性能优化：避免每帧Tick

默认情况下，GameInstance没有Tick函数。这是好事。但如果你为它添加了Tick，或者在你的GameInstanceSubsystem中添加了Tick，一定要非常小心。

  • 原则：GameInstance级别的逻辑，绝大多数都不需要每帧执行。它应该是事件驱动的（响应加载完成、存档请求等）或低频定时驱动的（如每10秒进行一次自动保存检查）。
  • 优化建议：如果确实需要定期检查（如监测网络状态），使用FTimerManager设置一个间隔较长的定时器（如1.0秒），而不是启用Tick。
    // 在Initialize中 GetTimerManager().SetTimer(NetworkCheckTimerHandle, this, &UMyNetworkSubsystem::CheckNetworkStatus, 1.0f, true);

5.5 蓝图与C++的混合使用

对于新手，可能先从蓝图继承GameInstance开始。这没问题，但项目规模扩大后，建议将核心逻辑迁移到C++的GameInstanceSubsystem中。

  • 蓝图友好设计：在C++Subsystem中，将需要蓝图调用的函数标记为UFUNCTION(BlueprintCallable)，将需要蓝图访问的变量标记为UPROPERTY(BlueprintReadWrite)（注意线程安全）。
  • 数据传递：复杂的数据结构在蓝图和C++间传递可能麻烦。考虑使用USTRUCT定义清晰的数据结构，并标记为BlueprintType，这样在蓝图中也能创建和操作。
  • 调试：在蓝图中调试GameInstance的逻辑有时不如C++直观。善用Print String节点输出日志，并在C++代码中使用UE_LOG配合详细的分类（LogTemp,LogYourSystem）来追踪执行流。

6. 总结与最佳实践清单

回顾一下，GameInstance是你的游戏进程的基石，是存放那些“从游戏启动到关闭都需要存在”的数据和系统的中央枢纽。滥用它会导致架构混乱、难以调试的bug和性能问题。通过使用GameInstanceSubsystem进行模块化设计，可以有效地保持代码的整洁和可维护性。

最后，我将一份“该做与不该做”的快速检查清单送给你，在开发中随时对照：

✅ 应该做（Do‘s）：

  • 存储真正的进程全局数据：游戏设置、玩家档案、跨关卡剧情标志、解锁内容、总游戏时长统计。
  • 管理全局系统：使用GameInstanceSubsystem来管理音频、存档、本地化、平台服务、数据分析。
  • 持有对其他Subsystem的引用：Subsystem之间可以通过InitializeDependency安全地相互访问。
  • 使用软引用或唯一ID：如果需要记录关卡中某个对象的状态，存储其TSoftObjectPtr路径或一个FName/GUID，而不是原始指针。
  • 在Init/Shutdown中做轻量级操作：加载/保存配置，初始化/销毁子系统。

❌ 绝对不要做（Don‘ts）：

  • 存储关卡特定的Actor或组件指针：这会导致悬空指针和崩溃。
  • 存储需要网络复制的游戏状态：这是GameState和PlayerState的工作。
  • 把它当成全局变量垃圾桶：临时数据、计算中间结果不要放这里。
  • 直接持有大量UObject引用：小心造成内存泄漏，优先使用弱引用或标识符。
  • 在Init中访问可能不存在的World：依赖世界的操作请延迟执行。
  • 轻易为它或它的Subsystem启用Tick：优先使用定时器或事件驱动。

理解并善用GameInstance，是你在UE5开发道路上从“脚本小子”迈向“系统架构师”的关键一步。它强迫你思考数据的生命周期和系统的职责边界，这对于构建任何中型以上的游戏项目都至关重要。希望这篇指南能帮你避开我当年踩过的那些坑，让你的UE5开发之旅更加顺畅。

编程学习 学习日记 实战经验
← 返回列表