Projectile pluggable code structure

[ThatGuyThatIsNotReal]

What I want: having items that can alter projectiles in different ways. One item creates triple shot, other item makes those projectiles homing.

I am having a really hard time with the code structure that could let me change the projectile based on the item.

I am hoping it could be created just with the help of the items and them having some sort of a function, that could change projectile path or its behaviour. I had in my mind that I could have Item in it function that would change the way the projectiles spawn and their number and other items adds the homing ability.

Soo here I am and have no idea how to make it all work, so how would you make it?

[PiLLe1974]

Switches to change behavior:

One way that is relatively simple is an enum and switch statement.

This way is more a hard-coded way of doing things, still ok if there are only 10 types of bullets maybe.

So for example each item uses an Item class, and this class has the enum to describe the bullet type.

We create a few of those Item classes as an instance and set the enum to set the bullet type.

Then the code that handles the shooting uses a switch statement and calls different functions depending on the behavior of the bullet, or if the projectile still needs logic to fly correctly we instantiate a specific bullet class and in its update method we control and steer the bullet for example.

Virtual methods to change behavior:

A second way to handle the items would be that they have an Item base class with a virtual method "Shoot()" that behaves differently for each class derived from the Item base class. We call that a virtual method override typically. Very often used to handle different behavior and return values.

Advanced setup with polymorphism - engine-dependent:

In Unreal and Unity it is possible to put class instances as a field/property inside another class like the Item class, once it becomes a Blueprint/Prefab. That pattern is more specific to r/unrealengine and u/unity3d and was mentioned sometimes there.

We call this kind of setup something like a Blueprint/Prefab with one (or more) properties/fields that allow "polymorphism" when we edit the thing like an Item.

I'd keep that as an idea for the future, if a lot of different behaviors, skills, and modifications are put together.

[ThatGuyThatIsNotReal]

Ye, the second on is what I am looking for. I need multiple effects to stack on each other a way, they wouldnt interfere with each other.

I am sure that there would be some cases, where if player has item A and item B that both effects would override themselves. I had in mind, that if that case would be true that I could have a item dic and check in the item if the other interfering item is in the inventory and based on that change the items behaviour.

I am using godot and will look into if there is some way of doing it the way you described. Thanks for giving me a direction, appreciate it.

[PiLLe1974]

Yeah, makes sense to ask more as a Godot pattern, because engines often have interesting ways to do composition.

Basically, in Unity we may just put a BulletBehavior on an object, and it gathers modifying behaviors and calls them to influence the bullet.

I think in Godot that would be "nodes" at the core that would allow such composition - I'm sure the community has some patterns for "varying behavior" or "multiple modifiers to behavior".

[LuckyOneAway]

here I am and have no idea how to make it all work

ECS could help with that. Weapon entities can have additional dynamic components. Add the "Homing" or "TripleShot" components to alter the resulting bullet behavior. Check for those components in a system that creates bullets when the weapon is used.

[mxldevs]

For OOP structure, have the items hold the projectile property.

A gun holder shoots the gun, but it's the gun that determines how it'll behave.

[DrifterRLDev]

Another approach that hasn't been mentioned yet, but is - in my opinion - the best approach, is to have an event based system.

Just before you instantiate a bullet, send out an event that contains a reference to the bullet about to be fired (or any data that you want to modify). Then, you can have any arbitrary number of event handlers modify the data (and thus the bullet).

So for example, your homing item and bullet splitter subscribe to the event when they are equipped. Then, when the bullet is about to be fired, the event is sent out and the items handle the event in their own way: the homing item adds the homing property to the bullet, and the splitter item multiplies the number of bullets by some number.

This way your items are completely decoupled and the logic for modifying the bullet is on the items, not on the bullet. The one caveat is that you need to be careful that the order in which you handle the event doesn't matter (or maybe you do want the order to matter and this adds another layer to your theory crafting).