If you're developing a game and have if/elif or switch or match statements to adapt the behavior of an object based on a given condition, you need to understand the Strategy pattern.

I created a video in September 2025 about the Strategy Pattern, but people struggled to understand it in practice. So in this post, I'm going to show you how you can build a flexible, scalable, and maintainable interaction system for your enemies using the Interactive Area and the Bumping Enemy recipes.

Video 1 - A video published in September 2024 from my channel explaining the Strategy pattern.

Why Conditional Statements Are Killing Your Game

Conditional statements can slow down your game and may even break your code mid-production. Every new condition you have to cover using a conditional statement is a new bug you will likely introduce. Plus, your class may become a massive spaghetti mess.

You should design your classes to abstractions instead of trying to cover concrete cases, simply because you may have more use cases than you imagined.

Building a Rich World with Interactive Enemies

Let's take the Bumping Enemy recipe and add some spice to it. We saw in the 5 Tricks to Enrich your World Design post that the core of a rich world design is making the objects in this world interactive. But we stopped at the "interactive for the player" layer.

The most effective way to make your world design feel rich is to add more agents to this world. Actors that also can change this world just like the player does. This adds conflict and raises the perception that this world is truly alive apart from the player, and the player is only another piece of a bigger picture.

For that, we are going to make our Bumping Enemy interact with four elements in the game world we've created in the Making a Playable Level with Godot's Platformer Essentials post:

• The Player, hitting it
• The Crates, breaking them
• The Bombs, picking and throwing them
• The Cannon, firing it

Maybe in the future, we want to add more behaviors to this enemy, right? So to get everything ready to support numerous interactions in the future, we are going to use the Strategy pattern.

What Is the Strategy Pattern?

Simply put, the Strategy pattern delegates to the client object the responsibility of providing the instructions to interact with it. So instead of adding conditional logic on the Bumping Enemy, we are going to make the Crates and Bombs tell the Bumping Enemy what it should do when interacting with them.

Usually, this is how people implement that: when the Bumping Enemy detects something it can interact with, they check what it is and then establish the behavior the actor (in this case the Bumping Enemy) should perform accordingly.

Figure 1 - The BumpingPigBrain class' code for when it interacts with an object.

The idea behind the Strategy pattern is to turn each one of these possible behaviors into distinct strategies and allow the objects that the Bumping Pig can interact with to carry these strategies and provide them to the Bumping Pig upon interaction.

Creating the InteractionStrategy Interface

We can create an abstract InteractionStrategy class to provide an interface and then implement each behavior accordingly. The Strategy pattern only demands two things to work:

• A context variable to work on. This is a reference to the class that carries the responsibility of performing the behaviors we are going to define. In this case, the BumpingPigBrain, the class responsible for "intelligence" in the Bumping Pig.
• An execute() method that is going to be common in every member of the Strategy family. In other words, in every subclass. This means these subclasses will override this method with their own behavior.

On top of that, you can add whatever you need to perform said behaviors. In this case, it's important to provide the Area2D the Bumping Pig triggered an interaction with, so we are also going to add an interacted_area variable to carry that reference in the InteractionStrategy class.

Figure 2 - The InteractionStrategy class interface.

Extracting Behaviors into Individual Strategy Classes

With the InteractionStrategy class serving as an interface class, we can create new strategies using polymorphism to override its execute() method. The idea here is to extract each of the behaviors that were previously part of a conditional statement branch into individual InteractionStrategy subclasses. This way, we end up with the following:

Figure 3 - The Player, Bomb, Crate, and Cannon InteractionStrategy classes

Attaching Strategies to Objects

With the behaviors extracted as independent classes, I just have to attach them to the proper objects. For that, I use the VisibleArea2D node which is the node that bridges that interaction with the Brain node. In the VisibleArea2D class, I export a file path to the InteractionStrategy class file the Brain is supposed to use to interact with the object. Then I load the file, create an instance of the script, and store it in the VisibleArea2D.interaction_strategy variable.

Figure 4 - The VisibleArea2D class code

Then, using the Inspector, I change the path of the interaction_strategy_file variable to match the proper InteractionStrategy class.

For instance, in the Bomb scene, this is how its VisibleArea2D.interaction_strategy_file property looks:

Figure 5 - The Bomb scene VisibleArea2D's Interaction Strategy Path variable value

Making It All Work

Finally, to make this all work, I can remove every conditional statement from the BumpingPigBrain._on_vision_area_2d_area_entered() callback and instead get it from the area it interacted with, injecting the BumpingPigBrain and other dependencies on the interaction strategy and executing it.

Figure 6 - BumpingPigBrain code after implementing the Strategy pattern 

By doing that, whenever I have a new object I want the BumpingPig to interact with, I don't need to make any changes to the BumpingPigBrain class. Instead, I just have to create a new InteractionStrategy subclass, override the execute() method describing the behavior (how the BumpingPig should interact with the object), and set this new class's file path on the object's VisibleArea2D.interaction_strategy_path property.

With that, the BumpingPig can interact with anything, as seen in the GIF below:

Figure 7 - The BumpingPig pick and throwing a crate on the player, then picking and throwing a bomb, then attacking the player, and finally lighting the cannon and shooting the player

Stop Hacking Things Together

In this post you saw how the Strategy pattern removes a ton of if/elif spaghetti from just one enemy interaction. The Cookbook does the same at the project level: it gives you ready-made, battle-tested, documented recipes for movement, combat, interactions, level flow, and more, all following the same principles.

You don't need to be a senior or advanced programmer for design patterns. The book was written exactly for people who feel they're not advanced yet but want to stop hacking things together.

Join 534+ Godot indie devs shipping cleaner platformers today. Grab the Platformer Essentials Cookbook, get a playable level running in about 1 hour, and when you are ready to add dialogues and quests, jump into the Godot Adventure Essentials course.

That's it, thank you for your support. Keep developing and until the next one!

— Henrique Campos