C++ for Engines - The Gang's All Here

Github Repo

From this module, I learned how to structure an optimal behaviour tree, put AMD principles into practice, and make a well functioning framework for designers to work alongside with.

Behaviour Tree & Perception

The behaviour tree I have set up uses the abort system, to be as optimal and simple as possible. Firstly, the AI will move to a random point, unless the branch is aborted by the logic on the left which chases the player. So, the AI can't patrol if it is chasing. The same happens when checking if the AI is close enough to attack, it will move to the player unless the AI is close enough to attack, when close enough it overrides the move to logic.

Anonymous Modular Design (AMD)

Anonymous Modular Design is a design pattern that helps us create completely decoupled systems , to quote "Game Development Patterns with Unreal Engine 5", the book the founded this idea - "If we need to swap out game modes for a different objective-based mode, then we can do that as no class needs a direct reference to the game mode".

With relative ease, we can slot out different classes, and our system should be able to adjust with little modifications. The core three principles are:

1. Use events when going up to a "parent", by parent we mean something that is managing our class. For example, for a player to communicate with their controller, they have to event upwards.
2. Use interfaces when going outside of the hierarchy. AMD works on the principle of large communication hierarchies, somethings, like collectables for example, could be outside of the main hierarchy.
3. Use functions when talking to "children", which means those this class is managing. This is because there will only be one manager in comparison to the descendants.

Here is an example of the hierarchy I designed to help me plan my system. The "Guy" tells the controller when it has been damaged. The controller in turn alerts the HUD to update. This is reflected in my code:

This function is called when the player is damaged, the controller is then alerted by the event.

From there, my controller calls the HUD to update the health. So, in short, we go up from the player via an event when damaged, and function back down to the HUD, as the the diagram shows.

Making a Well Functioning Framework

One major part of this module was to make a framework that can be built on by designers.

Firstly, I used the UPROPERTY macro to allow designers to edit certain variables, like the max look up and down variables, and the health bar colour for each colour.

As you can see, inside the editor the designer can use these variables both in blueprint and the class defaults panel. This is useful due to the fact that I, as a developer, do not know what a designer may want to do later on during the projects development, and it is a very slow process when a designer has to ask for specific variables.

On the other, I do not want the designers to be able to reassign the components, as this could break my system. As a result, I only let them view the variables, I do not let them edit them.

The same is true for the UFUNCTION macro. With it, a designer could add logic to add more win conditions inside of Blueprint.

Rather than allowing designers to override functions, which would force them to rewrite my code, I added hooks for them to attach additional logic to. For example, when ending the level, the designer could play a sound effect with ease.

Overall, I learned A LOT from this module, of which I am very grateful. I can now structure a framework that is flexible, rather than rigid, and is able to be utilised by others.