There’s nothing about the engine limiting you here… You can have an array of Structs no different to C++. You can also manually add entries to the array in the C++ Constructor if you don’t want to do it in BP.
You can still have pointers to the ammo class if you want to, but it’s more costly. You would have to instantiate copies of those actors in the world, then iterate the array each time to find that item, cast to the right one, then modify it’s ammo. If you do this every time you subtract ammo from a weapon you’re eating through performance for no real reason, and the cost is no longer static either.
I still don’t understand how doing this in standard C++ makes it any different…? The logic doesn’t change.
As for the firing system, it depends. I’d make one weapon class that has a primary and secondary fire, then override those functions in the inherited classes.
Actually I have two Weapon classes deriving from the Base Weapon class: those who are **instant **and those who spawn **projectiles **(a bit like ShooterGame)
Well, now if in my game there are 5 InstantWeapons and 8 ProjectileWeapons, each one with their OWN FireWeapon() function (which is declare virtual in the base class), should I make as many C++ classes as the number of weapons?
Have the base weapon class store a reference to its owning player when it is added to the player’s inventory.
Have the player have its inventory of ammo in whatever method you like, be it an array of structs or just a dictionary sorted on an enum or whatever.
Have the player have a public “decrement ammo” or “Adjust inventory” or whatever method that takes appropriate arguments to its data type (ie a key value pair or a, object reference and an argument structure like in C# delegates).
When the weapon fires have it call the decrement ammo method on the player as appropriate.
Something like this but reworked for your actual codebase
//weapon class
playerClass owner = this.owner;
FiringArgs ammoToUse = new FiringArgs(AmmoClassorName, Amount);
void onFire()
{
//projectile spawn logic here
owner.UseAmmo(this, ammoToUse);
}
If you plan on having multiple ammo types used per shot type just add an additional call to decrement the ammo with a second FiringArgs struct.
Thanks, but all those things you mentioned have already been done for a while.
The Weapon base class has a property called AmmoPerShot. So each time the PrimaryFire() is called for that weapon, it will decrease AmmoPerShot ammos from the player inventory.
For now, I don’t have a second variable that determines AmmoPerShot for the SecondaryFire(), I just have it for the primary.
But, there could be the case where my weapon’s SecondaryFire(), decreases **BOTH **the PrimaryType-Ammo and the SecondaryType-Ammo.
In that case, should I create a C++ class dedicated only to that specific weapon?
For example, I could have a weapon that shoots **Bullets **on the PrimaryFire() and **ElectricBullets **on the SecondaryFire().
An Electric bullet is a **combination **between a Bullet-Ammo and an Electricity-Ammo. So I need to decrease both in order to shoot electric bullets!
OK so if there could be that case then change up your weapon definition to allow for that sort of behavior. Don’t just have an AmmoPerShot property on your weapon class, but have an array of WeaponAmmoInfo structs (or something multiple data containing objects)
At the very least something like this perhaps
class WeaponFireInfo
{
map<Ammoclass,int> AmmoToUse;
//constructors + whatever else is useful
}
//in your weapon definition
WeaponAmmoInfo SecondaryAmmo;
SecondaryAmmo.AmmoToUse.add(bullets,3);
SecondaryAmmo.AmmoToUse.add(Electricity,1);
void SecondaryFire()
{
owner.UseAmmo(secondaryAmmo);
//do weapon logic here.
}
//in the player
void useAmmo(weaponAmmoInfo Ammo)
{
for each( KeyValuePair Shot in Ammo.AmmoToUse)
{
DecrementAmmo(Shot.Key, Shot.value) ; assuming decrement ammo finds the class from Shot.Key in the players inventory and subtracts Shot.Value from its quantity.
}
}