Un projet d'ingénierie à long terme · une nouvelle norme, construite à partir de zéro

UE C++ Academy — pas une référence, mais une école d'ingénierie pour Unreal Engine

Chaque sujet explique non pas « quoi utiliser », mais « pourquoi cela existe », « quel problème cela résout », « comment cela fonctionne en interne » et « quand ne pas le faire ». L'objectif est qu'après avoir lu un sujet, aucune question logique ne reste sans réponse, et que vous appreniez à aboutir vous-même aux décisions architecturales d'Epic, plutôt que de les mémoriser comme une liste de faits.

Comment chaque sujet est structuré

Un standard flexible : 11 sections obligatoires pour tout sujet + des sections qui apparaissent automatiquement si le sujet les génère naturellement — sans éléments artificiels tels que « Impact sur le multijoueur » dans un article sur const.

Qu'est‑ce ?

Une courte déclaration d'orientation avant la plongée profonde.

Pourquoi cela existe ?

Problème → cause, pas un fait sans contexte.

Quel problème cela résout ?

Un scénario spécifique et reproductible où l'approche naïve casse.

Comment cela fonctionne ?

Contraintes → solution architecturale → implémentation, avec des exemples tirés du code source du moteur.

Quand utiliser / ne pas utiliser

Les limites d'applicabilité — sans elles, un sujet engendre un culte du cargo.

Exemples

Code entièrement fonctionnel avec une explication ligne par ligne — le pseudo-code est interdit.

Erreurs fréquentes

Séparément pour les débutants et les développeurs intermédiaires, en expliquant le mécanisme de l'échec.

Mise en pratique

Des exercices qui obligent à reproduire le raisonnement, pas seulement à copier l'exemple.

FAQ

Les questions qui surgissent réellement pour un lecteur attentif.

Résumé

Les affirmations que le lecteur devrait pouvoir formuler avec ses propres mots.

+ selon les besoins

GC, Reflection, Blueprint, Multijoueur, sérialisation, performances — si le sujet les génère naturellement.

Avant de commencer

Une boussole sur l'ensemble du cours — pas un sujet, mais une manière de penser qui se répète dans chaque sujet suivant.

💡

Comment pense Unreal Engine — Philosophie du moteur

Douze « Pourquoi » transversaux (UObject, pointeurs, GC, Reflection, Component, Composition, Modules, Plugins, Subsystem, Gameplay Tags, Data Assets, Primary Assets) en un seul endroit — lisez cette page en premier, et dès lors, chaque nouveau sujet du cours sera reconnu comme une variation d'un raisonnement familier, plutôt qu'un nouvel ensemble de faits.

Article de référence

L'étalon-or de qualité et de profondeur pour tout le projet — cela vaut la peine de commencer par là, même si vous êtes déjà un développeur expérimenté.

★

Comment fonctionne Unreal Engine : non pas l'API, mais la pensée d'ingénierie

Moteur → Framework → pourquoi UObject → pourquoi la Reflection → pourquoi le Garbage Collector → pourquoi les macros sont apparues → comment tout cela se connecte en une seule chaîne de causes. Après cet article, les autres sujets du cours ne sont pas lus comme des faits séparés, mais comme des applications de la même manière de raisonner.

Feuille de route — 9 Niveaux

Neuf niveaux séquentiels au lieu de seize clusters séparés — chaque niveau suivant est expliqué à travers le précédent, non en soi. La seule exception est le Niveau 5 : ses six systèmes appliqués sont parallèles, pas séquentiels.

Niveau 0 — Comment Unreal pense

Pourquoi le reste du cours existe : quand la documentation d'Epic est encore suffisante, et quand il est temps d'ouvrir le code source du moteur, et comment naviguer physiquement dans les fichiers .h/.cpp avant même de savoir ce qu'est un UObject.

Documentation Epic : quand elle suffit Comment lire un fichier .h du moteur Comment lire un .cpp du moteur Public/Private/Classes Comment tracer une dépendance

Niveau 1 — Système Objet

S'appuie sur le Niveau 0 — après cela, tout UCLASS()/UPROPERTY() est expliqué comme une conséquence spécifique de la Reflection, du Garbage Collector, du Package et du CDO, non comme une syntaxe magique.

UObject : architecture objet Class Default Object (CDO) UObject::Outer Reflection Garbage Collector UPROPERTY UFUNCTION UINTERFACE EObjectFlags FName / FString / FText UPackage Asset Registry UStruct : la classe de base commune sous le capot TSubclassOf<T> Cast<> vs dynamic_cast NewObject / CreateDefaultSubobject UObject en mémoire

Niveau 2 — Objets d'exécution

S'appuie sur le Système Objet — d'abord l'Actor et ses composants, et seulement lorsque la question « comment stocker la liste des composants » surgit naturellement, les outils : TArray/TMap et les deux mondes non chevauchants de pointeurs.

Cycle de vie de l'Actor UActorComponent Transform et RootComponent Tick SpawnActor et Destroy Owner et GetOwner() TArray TMap et TSet TSharedPtr / TWeakObjectPtr / GC TSoftObjectPtr World Context Object TActorIterator Architecture des collisions Line Trace, Sweep, Overlap Chaos Physics et Gameplay

Niveau 3 — Gameplay Framework

S'appuie sur le Niveau 2 — l'ensemble complet des rôles du framework (Pawn/Controller/Character/GameMode/GameState/GameInstance/Subsystem) et les Delegates comme outil, avant que l'IA/l'UI/le GAS ne commencent à s'appuyer silencieusement sur eux.

UWorld Pawn / Controller / PlayerState ACharacter vs APawn GameMode et GameState UGameInstance Subsystems Delegates : Single/Multicast/Dynamic PlayerController de l'intérieur ULocalPlayer et GameViewportClient UGameplayStatics

Niveau 4 — Données

S'appuie sur UObject et les références logicielles — comment décrire un contenu croissant sous forme de données, pas de code, avant que le GAS et l'IA ne commencent à être construits dessus.

UDataAsset UDataTable UAssetManager FGameplayTag UPrimaryDataAsset UPROPERTY(Config) UDeveloperSettings

Niveau 5 — Systèmes

Six systèmes appliqués parallèles, pas une séquence — l'ordre entre 5.A–5.F n'est pas strict, chacun s'appuie seulement sur les Niveaux 0–4 (et Network Prediction dans GAS aussi sur le Niveau 6, Multijoueur).

5.A — Entrée (Input)

Comment l'intention de gameplay est séparée de la touche physique : Input Actions et Mapping Contexts au lieu de Action/Axis Mappings codés en dur.

Enhanced Input EnhancedInputLocalPlayerSubsystem

5.B — Interface Utilisateur (UI)

Comment construire une interface avec UMG, comment gérer la pile d'écrans et le focus avec CommonUI, et comment rompre la connexion directe entre le widget et les objets du jeu avec MVVM.

UMG : UUserWidget CommonUI MVVM Slate : sous le capot de UMG Cycle de vie de UUserWidget CommonInput

5.C — Gameplay Ability System

Un framework d'abilités au-dessus de UFUNCTION : mise en réseau, annulation, coûts de ressource et compatibilité des effets dans une solution cohérente — jusqu'à Network Prediction à l'intersection avec le Multijoueur.

GAS : pourquoi un framework au-dessus de UFUNCTION AttributeSet GameplayEffect GameplayAbility : cycle de vie GameplayTags dans GAS Network Prediction dans GAS Execution Calculation GameplayModMagnitudeCalculation GameplayCue

5.D — IA

Comment la décision de « ce que le PNJ doit faire » est exprimée comme un arbre de nœuds réutilisables, comment les tâches et l'arbre échangent des données via un stockage partagé, et comment trouver déclarativement le meilleur point dans le monde.

Behavior Tree Blackboard Environment Query System AIPerceptionComponent NavMesh et Système de Navigation Smart Objects

5.E — World Streaming

Comment un monde de jeu qui ne tient pas physiquement en mémoire dans son ensemble est chargé par parties : manuellement, automatiquement par grille, et avec des couches logiques par-dessus.

Level Streaming World Partition Data Layers PCG Framework Foliage instancié HLOD Nanite Lumen

5.F — Animation

Comment la logique de pose squelettique est séparée dans son propre objet avec son propre graphe, comment les actions one-shot sont jouées par-dessus le blending continu, et comment la pose s'adapte à la géométrie en temps réel.

UAnimInstance UAnimMontage Inverse Kinematics Animation State Machine Blend Space Linked Anim Layers Motion Warping Root Motion Anim Thread

Niveau 6 — Multijoueur

S'appuie sur UPROPERTY et Owner/GetOwner() — le serveur et le client voient le même acteur différemment, et cela suffit pour revenir en arrière et véritablement boucler Network Prediction du Niveau 5.

Fondation

Replication : rôles et Autorité RPC : Server/Client/NetMulticast Pertinence réseau (Relevancy) Dormance réseau (Dormancy)

Avancé

UActorChannel Net Driver Property Replication de l'intérieur Replication Graph Fast Array Serializer Prédiction côté client hors GAS Listen vs Dedicated Server Seamless Travel

Niveau 7 — Internes du moteur

Un niveau complètement nouveau — ce qui se passe entre « écrire le code » et « le joueur lance l'exe » : Header Tool, UnrealBuildTool, modules, plugins, sérialisation, Cook, chargement à l'exécution, threads et allocateurs mémoire.

Fondation

Compilation : du .cpp au jeu ★ article phare UnrealBuildTool Modules et .Build.cs Plugins et .uplugin FArchive : sérialisation Cooker Chargement à l'exécution Game Thread et Task Graph FMalloc : allocateurs mémoire

Avancé

UBT : le graphe de compilation UnrealHeaderTool de l'intérieur Build.cs et Target.cs Le pipeline de compilation complet À l'intérieur de .generated.h Hot Reload vs Live Coding Packaging : Build+Cook+Stage+Package Comment un plugin est chargé en mémoire FMemory et GMalloc Alignement et lignes de cache TArray de l'intérieur TMap / TSet de l'intérieur

Niveau 8 — Production

Un niveau complètement nouveau, concluant le cours — comment non seulement écrire du code, mais aussi diagnostiquer et corriger du code existant, respecter le budget de frame, sauvegarder la progression et structurer un projet qui survivra à plus d'un développeur.

Débogage

UE_LOG Visual Logger Gameplay Debugger DrawDebug* Unreal Insights commandes stat

Optimisation

Optimiser Tick et Timer AsyncTask et ParallelFor Le profilage comme mode de pensée

Sauvegarde

USaveGame

Architecture

Architecture de grand projet

Profilage (Avancé)

Trace de l'intérieur Canal de trace personnalisé CSV Profiler Gameplay Debugger à travers le réseau LLM : Low Level Memory Tracker Profilage GPU Analyse d'une simple frame

Patterns architecturaux

Composition vs héritage Pattern Subsystem Observateur via delegates Pattern Factory : SpawnActor Pattern Command dans GAS Injection de dépendances dans Unreal

Postface — articles de bout en bout

Pas du nouveau matériel, mais un examen pour voir si vous pouvez percevoir le système comme un tout : cinq articles relient tout ce qui a été étudié séparément en histoires de bout en bout — de l'appui sur une touche à une frame à l'écran, du lancement du processus au cycle de vie complet du jeu.

✦

Postface — Flux d'ingénierie

S'appuie sur l'ensemble du cours comme un tout — chaque article trace un chemin de bout en bout à travers des événements étudiés séparément dans les Niveaux 0–8, les assemblant en une chronologie unique vérifiable dans le code source.

Cycle de vie complet du jeu Le chemin complet des assets Le chemin complet de l'entrée Le chemin complet d'une frame Le chemin complet de la réplication

Mettez tout cela en pratique

Parcourir les 9 niveaux isolément suffit pour comprendre chaque idée — pas assez pour ressentir comment des dizaines de telles idées coexistent dans une seule classe vivante. La deuxième voie, parallèle, du cours — le même personnage, grandissant au fil de la progression dans les niveaux.

🎮

Projet de synthèse : AAcademyCharacter, de l'Actor au GAS et à l'Animation

Un projet unique en croissance continue au lieu de seize jalons parallèles — presque chaque niveau ajoute une pièce réelle et fonctionnelle du même jeu de survie : d'un Actor nu et de composants, en passant par Enhanced Input, les items DataAsset, UMG/MVVM, le multijoueur, les abilités GAS et l'ennemi IA, jusqu'à la sauvegarde et au profilage, avec la condition obligatoire que les décisions des étapes précédentes ne soient pas réécrites silencieusement, seulement via un refactoring explicite — exactement comme dans un projet réel.

Comment l'ancien projet a été utilisé

Le projet précédent (le dossier un niveau au-dessus) n'a pas été supprimé et reste comme matériel de référence — une source d'idées, d'explications toutes faites et d'exemples de code. Aucun article ici n'est une copie : chaque sujet est analysé à nouveau, vérifié, complété et amené au standard commun décrit ci-dessus.