3 Principles Every Game Programmer Needs to Know in Unreal Engine

[00:00:00]Making a system that works in Unreal Engine is easy.

[00:00:04]But making one that works 6 months later with 10 times as many features in your game, that is the challenge.

[00:00:11]And no one is teaching you how to do that on YouTube. Even though the solution is basic programming principles. So, let me show you exactly how to apply three of those principles in any system you build in Unreal Engine. In this video, I'll be designing a basic ability system, show you some of the problems with it that don't allow it to scale when you build it in a bad way, and then we will start scaling the system step by step. So, let's take a look at step zero, no system at all.

[00:00:41]Just start building abilities all in one place.

[00:00:45]So, first I will create an actor component to hold all of my abilities instead of putting everything on the player class.

[00:00:53]And we add that component to the player.

[00:00:55]It's a cleaner solution than everything on the player class, but far from perfect. And let's see why when we start building our first ability.

[00:01:04]This is a shoot laser ability. When the player presses a button, a laser comes out of their chest and damages any enemy in front of them.

[00:01:12]So, what does this ability actually do?

[00:01:16]Well, it needs to check if the ability is currently on cool down.

[00:01:20]It also needs to apply damage by doing a sphere trace, seeing if it hits an enemy. It also plays an animation.

[00:01:28]It spawns visual effects, sound effects.

[00:01:31]It starts a cool down timer.

[00:01:33]It updates the UI to visually show that the ability is on cool down.

[00:01:37]And not only that, but it needs to keep track of a lot of variables as well. Is the laser on cool down? What is the montage to play? What is the damage amount to apply? Etcetera. And after doing all of that, here is what the ability looks like.

[00:01:53]Great, the ability works. So, where's the problem?

[00:01:57]Well, the problem is that all of this logic, all of these variables are in one place with hard-coded references and values and multiple systems talking directly to each other, animations mixed with visual effects mixed with damage logic.

[00:02:11]And it may look fine now, but once you add just three abilities, your actor component looks like this.

[00:02:19]You can imagine what 20 abilities would look like. Impossible to debug when things go wrong, duplication everywhere, no common structure, and one change has the potential to break everything. And that means it is not scalable. What worked for one ability won't scale to 20. So, we will fix this by applying the three core programming principles one by one.

[00:02:45]These principles are separation of concerns, loose coupling, and data-driven design.

[00:02:53]Now, in this video, I'm going to walk you through all three of these, but if you actually want to build this from scratch step by step, I have a much deeper dive video on Patreon where we implement everything from the ground up along with project files, a lot more exclusive content and digital assets to download. Link is in the description.

[00:03:14]Let's start with step one. Separation of concerns.

[00:03:19]This principle is all about splitting our system into smaller parts, each with a specific functionality.

[00:03:27]Consider the car engine as the perfect example. It is a complex system made up of very small specialized parts, like an oil filter, fuel pump, and these parts connect together using gaskets and seals, and components can be replaced or upgraded without redesigning the entire engine.

[00:03:47]In our system, there are many things that can be split into their own part.

[00:03:51]But the obvious thing is the ability itself split from the ability component.

[00:03:58]So, to do that, I will create a separate ability object that will be the parent class of all of our abilities.

[00:04:05]And now we start thinking of the system itself rather than a single ability.

[00:04:11]By asking ourselves the question, what do all abilities have in common? Well, they're probably going to have an activate ability and ability and start cool down function. And they will all have a cool down variable and a reference to the ability system itself.

[00:04:28]And finally, a function to tell us whether we can activate the ability or not. So, each ability can define its own activation rules.

[00:04:37]And these events and functions can have default implementations that is common for all ability. For example, ending an ability deletes the object and sets its state to not active. That is common for all children of this class.

[00:04:50]And starting a cool down adds the cool down duration to a map of cool downs.

[00:04:54]And now to create my shoot laser ability, I simply make a child of the base ability, override the activate function, and move all the logic from the ability system component to here. So, now all of the custom logic for shooting a laser is separated into its own class. And what is the ability system components responsible for now?

[00:05:16]The component is only responsible for the activation logic.

[00:05:20]That means constructing the ability object, checking if it can be activated or not, then calling its activate function.

[00:05:29]And also storing cool downs because cool downs should be centralized, not dependent on the run time of the ability object itself.

[00:05:37]Now, this component doesn't care what each ability does. It only knows about the functions that it provides. So, they are completely separated. Which means that scaling to 20 abilities just means creating 20 blueprints that are completely separate from each other, but follow the same structure.

[00:05:57]So, we fixed a lot of issues with our previous approach. But, we still have a lot of duplication and dependency issues.

[00:06:06]If we look at the reference viewer for the shoot laser ability, which tells us what asset this ability references, we see that most things make sense. The shoot laser ability should know which montage to play, which sounds and effects and so on. But, why does the shoot laser ability depend on the enemy class? This is because when applying damage, we cast to the BP enemy class to make sure we are hitting an enemy. And adding a cast or a hard reference here means that this ability now depends on the enemy class.

[00:06:37]We also have another dependency in the ability system component itself. It depends on the HUD class. Because we need to reference the HUD to update the UI when an ability goes on cool down.

[00:06:49]Now, what is the problem with these hard dependencies?

[00:06:53]Well, the main issue is it doesn't scale.

[00:06:56]Because what if you want to damage actors that are not enemies? Or what if you decide to change the UI so it's not a HUD, but an indicator on your weapon?

[00:07:05]Then, this logic breaks. You have to go to each individual ability and make changes in its core. Right now, this may seem like a trivial problem, but as your dependencies grow, making a simple change might mean changing how the whole system works.

[00:07:20]And that's not scalable. Which brings us to step two, the principle called loose coupling.

[00:07:27]This principle is all about having classes depend on each other as little as possible, or have no dependencies.

[00:07:36]By communicating through contracts and events. The simplest example of a contract is interfaces.

[00:07:44]Instead of casting to my enemy to call apply damage to them, I instead create a damageable interface that describes what functions a damageable actor should have.

[00:07:56]Then implement the interface on all my actors that can take damage.

[00:08:01]Then I can remove the cast and replace it with a single interface call. The ability doesn't care what it's hitting as long as it implements the damageable interface. This is the contract between actors, an agreement that says as long as you provide a function called take damage, then I will call this function without caring what type of actor you are or how the function even works. This allows for much more flexibility in how damage is handled by different actors and decouples the ability itself from the actor that it is hitting. Thus, the term loose coupling.

[00:08:37]You want to learn more about dependency management, I have a full video on that topic. Now, what about the HUD reference?

[00:08:45]The ability system component itself still needs to reference the HUD to update the cool down UI. Now, this is a very common coupling issue where developers tie their UI and their gameplay logic tightly together.

[00:08:59]Meaning that when one changes, the other has to change as well. And that is an enemy of scalability. A very nice solution for this and a common pattern for separating UI from game logic is to create a separate system in the middle that handles communication between them through events. To implement this, I created a subsystem in Unreal Engine called the event manager subsystem.

[00:09:24]This has to be done in C++ and its responsibility is very simple.

[00:09:30]It has two delegates or event dispatchers that can be broadcasted and listened to.

[00:09:36]On cool down started for any ability and on cooldown ended for any ability.

[00:09:42]And now the ability system component can use this subsystem. It no longer needs to reference the HUD, nor know anything about how the UI is updating. It just calls the function to broadcast the event that an ability has went on cooldown or its cooldown ended and then doesn't care what happens after that.

[00:10:02]Then the player HUD widget itself also references the event manager and binds to the cooldown start and end events.

[00:10:10]Meaning it waits for these events to be called and then updates itself.

[00:10:15]It doesn't care who calls it, so it is completely decoupled from the ability system.

[00:10:20]As long as the event is called, the UI will update.

[00:10:24]Now we have two completely decoupled systems with no direct dependencies communicating through a mediator.

[00:10:32]Each system can be updated and replaced without affecting the other.

[00:10:36]Which means it is now much more scalable.

[00:10:39]Now we move on to our final big problem.

[00:10:43]The data.

[00:10:45]Currently all variables for all abilities have hard-coded values in the ability blueprint itself.

[00:10:53]Changing damage amounts or animations or sounds or visual effects, all these things need a change in logic or the code. They don't belong here and they don't empower game designers to come up with unique abilities without rewriting logic.

[00:11:09]And the solution is step three.

[00:11:12]Data-driven design.

[00:11:14]Data-driven design is all about prioritizing data structures as the foundation of your system's architecture.

[00:11:22]Let's see how that works.

[00:11:24]To implement this, I created a data asset that contains all the common variables an ability may have, like a name, icon, the class, cool down, etc. Then, I use this data asset as a variable inside the ability class and read the data from it instead of having it hard-coded in the ability.

[00:11:45]Okay, that's nice. All variables live in one place, but is it really that different? We just moved values from one blueprint to another.

[00:11:54]Also, where are all the other variables for visual effects, animation, sound effects, and so on?

[00:12:00]Not all abilities have these things. Are we going to add fields in the data asset for them anyway?

[00:12:06]Well, this is where fragments become useful.

[00:12:10]The idea of fragments is to create separate smaller objects to define data used in specific cases.

[00:12:19]And the ability data asset contains an array of these fragments.

[00:12:24]So, I created an animation fragment, a damage fragment, VFX, sound effects fragment. That way, when an ability wants one of those things, it adds the fragment to the array. And if the ability doesn't have an animation, then it doesn't need to add the animation fragment. So, let me show you what the animation fragment looks like. It not only contains the data of which montage to play, but it also contains logical information.

[00:12:48]Like, should it play as soon as the ability starts? Should it end the ability when the montage ends?

[00:12:54]Now, it's not just data we're defining here, but also how the ability behaves.

[00:13:00]And here's what the damage fragment looks like.

[00:13:03]Contains how much damage, the type of damage, and so on. But more importantly, the data asset guides the designer.

[00:13:10]So, if I say that this damage is over time by checking this box, the data asset reveals two new fields for the designer to input. How often does the damage tick and for how long?

[00:13:21]This is a very cool way to use data assets to show and hide fields optionally and can be configured easily, but only in C++ through meta properties.

[00:13:30]Now, for these fragments to do anything, we have to handle them in the ability.

[00:13:34]We have to read the data asset, see which fragment is there, and do something with it. Now, if you remember previously, all the logic for animations, visual effects, and so on for our shoot laser ability was in the ability blueprint for shoot laser.

[00:13:49]But now we want a centralized place that handles the fragment logic for all abilities.

[00:13:55]So, I moved all that logic to the base ability, depending on whether a fragment exists on a data asset or not. If there's an animation fragment, do this.

[00:14:05]If there's a VFX fragment, do that, and so on.

[00:14:09]And since this is in the base ability, this logic is now shared between all abilities because they inherit from the same class.

[00:14:17]And the shoot laser ability is now much, much simpler. It looks like this.

[00:14:23]Now, the shoot laser ability only defines what's unique to it, the sphere trace and applying the damage.

[00:14:31]Even some of those can be moved to fragments if you find yourself reusing the same pattern over and over again.

[00:14:36]But the most beautiful thing about this data-driven design now is that a game designer can change this ability completely without changing a single piece of logic.

[00:14:47]I created a new data asset for a ground slam ability. It plays a different montage, spawns different visual effects and sound effect, and even spawns them at a different time, not when the ability activates, but when the montage triggers a notify event. So, this is completely new logic that the shoot laser didn't handle. But this data-driven design allows me to create a new ability with this new logic without rewriting anything.

[00:15:15]And just to prove it, I went to the shoot laser ability, and I replaced the shoot laser data asset with this new ground slam data assets.

[00:15:24]This is how the shoot laser used to look like.

[00:15:30]Now with the ground slam data asset, it looks like this.

[00:15:35]Something completely different just by changing data.

[00:15:47]Now we have designed a much more scalable system with separated parts, each with their own responsibility, no direct dependencies between our systems, and everything is configurable through data assets.

[00:16:02]Of course, this is just scratching the surface, and there is a lot more to improve in this system, but we can keep applying these principles again and again until the system satisfies all of our design requirements.

[00:16:15]And if you keep doing that, you will end up with Unreal Engine's own gameplay ability system.

[00:16:22]Because they built it on the same principles we discussed today.

[00:16:25]Data-driven, component-based, and separation of concerns.

[00:16:30]Now to build this system, I had to use a lot of different tools and techniques in Unreal Engine, like custom data structures, subsystems, and dynamic data assets, just to name a few. And I went through them very quickly in this video just to explain the overall architecture. But if you want to learn these things in detail, which are really, really cool to learn, then you can watch the full-length tutorial that I have on Patreon, and you would be supporting me so much by doing so. Now this is the only way that I monetize from the work I do. I try to create YouTube tutorials and lessons for everyone for free, and every now and then I make a dedicated deep dive for the Patreon members. So you will find a lot of those dedicated lessons and exclusive content. Of course, you also get access to the project files and everything else that I make, early access to my latest videos, and so many more things. So, please check it out if you like what I do here and you want me to keep making new videos. And a huge huge thanks to all my existing patrons.

[00:17:27]None of this would be possible without you. So, thank you and I will see you all in the next one.

[00:17:42]Just got these spaceships.

[00:17:44]I'm a huge fan of the TV show and book series The Expanse. So, these are the newest additions to my collection and I am super happy with them.

[00:17:59]This is not sponsored content, by the way. I'm just I'm I'm just a geek and I like these things.

[00:18:07]Okay, bye now.