introduction
The previous article introduced the mechanism of AddComponents, the most commonly used Action. So far, the principles of each component of GameFeatures have almost been explained. After learning these principles, you will definitely start to wonder about one question: How should I make good use of GameFeatures? The answer to this question should be divided into two parts. First, in the process of using GameFeatures, you will inevitably need to modify and expand it to a certain extent; second, there are some principles and experiences that you can learn from and avoid pitfalls. detour.
Expand
1. Action extension
Next, let’s talk about how we extend Action. This is also an operation that we often and need to do. It's still the same old routine. Some very useful Actions have been implemented in "Ancient Valley". Compared with the original 4, the new Actions are very useful, such as input mapping, SpawnActor, and adding Ability to the Actor. We can start with these Actions to learn how to write an Action.
One thing worth noting when implementing Action is that because GFS inherits from EngineSubsystem, the action mechanism of Action is also from Engine. Therefore, when playing the game and stopping the game in the editor, these Actions are actually activated. . Therefore, a base class of WordActionBase is specially defined, and the OnStartGameInstance event is specially registered to execute logic when the game starts. Of course, when actually using it, you still need to use IsGameWorld to determine which world is the world to play a role in.
2. GameFeatrues dependency mechanism
Here I want to talk about what makes GameFeature different from ordinary plug-ins. Ordinary plug-ins are generally referenced by CoreGame to implement CoreGame's support functions. GameFeature injects new functions into already running games, so CoreGame should theoretically know nothing about the existence and implementation of GameFeature, so CoreGame must not be able to reference GF, but will in turn be referenced by GF. The same applies to asset references. GF's assets can reference CoreGame's, but they cannot be referenced in reverse. So after having the GF framework, the architecture of a game should be as shown in the picture. The bottom layer is the engine and some other modules, and above it is CoreGame and some plug-ins. Up to this point it's the same way as before. Now that GF is available, another layer is added on top, allowing some GF to inject some logic into CoreGame.
The reason why we need to make this clear is that when we extend or customize our own classes, we often have a doubt, where should I define this custom class? Should it be written in CoreGame or GameFeature? Therefore, dependencies must be clarified in advance.
3. Classes that can be inherited and extended
Of course, as mentioned before, you may also need to carry out secondary development and expansion of the GameFeature framework. Therefore, I will also list for you the classes that you may need to inherit:
- UGameFeaturesProjectPolicies, the policy that determines whether to load GF, CoreGame
- UGameFeatureStateChangeObserver, registered in GFS to monitor GF state changes, CoreGame
- GameFeatureData, add more description data to GF UGameFeaturesSubsystemSettings::DefaultGameFeatureDataClass, CoreGame
- GameFeatureAction, more Action, CoreGame&GF
- GameFrameworkComponent, more Component, CoreGame&GF
- ModularActor, MoreActor, CoreGame&GF
- IAnimLayerInterface, change character animation, CoreGame&GF
I said before that we can extend Actor, Component, and Action. Where should these our custom classes be defined? I've marked it for you in bold at the end of each one . We should note that when GF is not loaded, the C++ classes defined in it will not be loaded into the editor, so classes like Policy should be written in CoreGame. The extensions of Action and Component can be defined in GameFeature.
4. GameFeature module collaboration
Some friends may ask a question. There are quite a lot of modules used in a game. Can GameFeature cooperate with them to make logical changes? In the picture below, I have listed some collaborative interaction methods between modules and GameFeature. You can take a brief look at them. If other modules need to interact, this can also be achieved by adding a new Action type.
Best Practices
1. Refer to "Ancient Valley" and Lyra
The first recommendation is of course the "Ancient Valley" project. You may only pay attention to the dazzling scene, but not the C++ code of the project. In fact, the "Ancient Valley" project actually integrates many new features of UE5 EA, so it is worth studying the implementation inside. For example, the implementation of two GameFeatures, HoverDrone from the perspective of a drone at the beginning, and Ancient Battle that fights in a dark world. In addition, the project has also implemented the modules mentioned before, ModularGameplayActors, and the code below Framework and GameFeatures are all implemented quite well. Then you can also take a look at how the Actions in these two GFs are configured. The Lyra beginner project released with the official version of UE5 is also a very good learning material.
Second, CoreGame has reserved logic injection points.
Although the emergence of GameFeature has greatly decoupled the connection between the gameplay and the game itself, CoreGame should theoretically know nothing about GF. In the ultimate ideal situation, CoreGame does not need to make any changes. But GF obviously can't do this yet. You still need to modify some of CoreGame's codes and reserve logical injection points in advance. The main points to be modified are:
- The original Gameplay Actor is modified to inherit from the previous Modular, or the AddReceiver call is added manually.
- In terms of animation, you can use the Anim Layer Interface. Different animation blueprints can be defined in GF to implement this interface. Then you can modify the animation by binding Link Anim Class Layers in the component.
- Regarding data configuration, you can use AddDataRegistrySource to add a data source to the existing DataRegistry in CoreGame, or you can use AddDataRegistry to add a new data registry in GF.
As for other module parts, such as UI and input, I have already mentioned that they can be done with the combination of Action and Component. The following figure takes animation injection as an example:
Third, how to convert existing logic to GF?
At this time, a question arises. If my project has been developed for a period of time, and now I want to apply GameFeature to our project, what should I do? I've listed some steps here for your reference:
- Create the Plugins/GameFeatures directory
- Create .uplugin file
- assets
- Move assets to new GF directory
- Fixup redirectors in the original directory
- Fix all asset validation issues
- code
- create.Build.cs
- Migrate project code to Public/Private under GF
- Fix include path error
- Fix code reference errors
- Add CoreRedirects +ClassRedirects=(OldName="/Script/MyGame.MyClass", NewName="/Script/MyFeature.MyClass" to DefaultEngine.ini
You may encounter other problems, but they should be relatively easy to solve just by changing the structure. Wish everyone good luck~
四，Rethink in GF
GameFeature is a new framework that changes more in the logical organization and module architecture division of the project. Therefore, you need to upgrade your brain and think in terms of GameFeatures again.
- First, when faced with a project, you need to think about which game functions should be split into GF? What are the basic mechanics of the game? What are the functions that can be dynamically switched on and off? It is to determine which things should be extracted to form a GF.
- Actor logic is split into Components and re-thought in terms of (component == function) instead of all logic being piled in the Actor. Then these logics were often written directly on various Actors before. Now you need to think in a (component == function) way. In the past, we advocated that Component is the basis for implementing relatively mechanical and independent game logic. Functionally, now in order to adapt to GameFeature, we need to use some Components simply as game logic for dynamic insertion and removal of Actors. Therefore, you need to split these logic from Actor to Component, and do the corresponding glue connection work of event callback registration and forwarding.
- Consider the possibility of injecting logic into all aspects of Gameplay, such as data, UI, Input, gameplay, etc. If you are working on a new project or gameplay, you must anticipate the possibility of supporting GameFeatures in the future when you first design, and leave various logic injection points.
- Divide asset areas, which ones are CoreGame and which ones are GameFeature. Of course, in the asset section, it is necessary to divide the areas, which assets are used by CoreGame and which assets are only used in Game Feature, and they are divided into different folders.
- Consider the common communication mechanisms of GF and CoreGame, event bus, distributor, message queue, etc. At some point, it may not be enough for you to just use Action and Component. In order to decouple CoreGame and GF, you may also need to use some general communication mechanisms, such as event bus distributor message queue and the like.
- PAK and DLC are supplements to the main game. GF is a dynamic loading and unloading function, although it can also be loaded dynamically through PAK. Naturally, some people may think that GF is a little similar to Pak and DLC, so can they be combined? Please note here that pak and dlc are patches at the asset level. Generally speaking, they supplement the game itself in terms of asset content. GF is a dynamic switch that emphasizes game functions at a logical level. However, GF can indeed be packaged into a pak for independent distribution, downloading and loading, so GF can also be used with hot updates.
Five, pay attention to the key points
Although GameFeature is easy to use, I recommend everyone to use it. But you still need to pay attention to some points to avoid stepping into pitfalls.
- Ensure that GF is self-contained and does not require external dependencies. First of all, it cannot be overemphasized. When you implement a GF, you must maintain an awareness that this GF is self-contained and does not need to rely on the outside. Of course, at some point, GFs can also depend on each other. If you want to use GF1 to add components to the Actor in GF2, it is not impossible, as long as you add GF2 to the plug-in dependency list of GF1.
- At the code level, we should pay attention to some special points. For example, GF's StartModule will be loaded once during Mounting and will not be released after that. Therefore, ShutdownModule will not be called, so do not think that you will write logic like Deactivating. In addition, the AddComponent receiver Actor Class configuration should not be configured as the Actor class itself, otherwise all Actors in the scene will be checked, greatly affecting performance.
- We said before that Action is at the Engine level, which means that GF can actually be used in Editor mode. For example, opening a GF can open a new toolbar in the editor. However, for relatively static functions such as Editor, I don’t really recommend this hassle.
- Of course, GF may not be suitable for all projects. For games with relatively fixed gameplay, such as stand-alone games or corporate projects, GF may not be suitable. It may be more convenient for you to put them together directly in the original way.
Summarize
Finally, let's summarize. The entire GF framework is actually to add a GFD asset to each plug-in to define the Action list of each GF. Among them, the most commonly used AddComponent will register the combination of ActorClass and ComponentClass into GFCM for management.
I hope that my series of articles can bring benefits to everyone and understand this framework diagram. If you have any questions or concerns about GameFeature, you are welcome to ask them in the comment area.