Algorithmic Blueprinting Questions

Development Programming & Scripting Blueprint
,
1

Okay, so I have a couple things I want to ask about. I don’t like extremely repetitive work, so I try to find patterns and bust them out by making the method once, and then using it to do the repetitive work I don’t want to do. There is a TLDR section at the bottom. Here are the questions:

  1. As far as blueprinting power use, I minimized the usage of ticks in regular blueprints as well as animation blueprints and the player HUD. Most examples I’ve seen of handling animation blueprints, for example, will have a constant tick to check for falling. I have mine set so I get an event when the movement enum changes to/from falling, set it to the proper integer, and rep/notify the change to wherever it needs to go. Same for when a player takes damage, the HP change is done, and it rep/notifies the hud so that it updates, rather than the hud constantly checking for the HP in question.

Is this more/less efficient? I’d like to think it would be more, but I’d like to get another opinion.

  1. I have a database of items that a player can find, and I’m considering redoing it so I do not have to input every single variation of whatever item. Like in other RPG’s, there are the qualities of:
    Poor
    Common
    Uncommon
    Rare
    Epic
    Legendary

What I’d like to do is have the server simply remember the name, and nothing else of a said quality, more than likely all of the commons. When I input the information for, say, common scalemail gauntlets, the database would work so it takes all the information on the gauntlets, and change it accordingly to whatever you may have. Example:

Base Item: Scalemail Gauntlets - 30 Armor

Poor multiplier: .75
Common multiplier: 1.0
Uncommon Multiplier: 1.10
Rare Multiplier: 1.25
Epic Muiltiplier: 1.45
Legendary Multiplier: 1.6

So with this data, based on whatever the first instance of the name of the item is, and you find the product of the quality multiplier and the armor to get the actual armor (rounded to the nearest integer).

Poor Scalemail Gauntlets armor: 300.75= 23
Common Scalemail Gauntlets armor: 301.0= 30
Uncommon Scalemail Gauntlets armor: 301.1= 33
Rare Scalemail Gauntlets armor: 301.25= 38
Epic Scalemail Gauntlets armor: 301.45= 44
Legendary Scalemail Gauntlets armor: 301.6= 48

NOW here’s another kicker: I will also have materials be a big part of the equipped armor, which will be the second part of the name. They will all have their own traits, and rather than just increase/decrease the armor by a base amount, it will take away armor (based on the metal) and (depending on the metal) it MAY apply it to magical defense. So something like a Titanium Breastplate may give great physical defense (as it will all go to armor), but have 0 magical defense.

Silver
Gold
Aluminum
Brass
Copper
Platinum
Steel
Silverite
Goldite
Aluminite
Iron
Titanium
Damascus Steel
Tungsten

SO! The end result of the item’s name may end up looking like:
Legendary Copper Breastplate of Toughness (26%)
1 2 3 4 5

1 Quality
2 Material
3 Item Name
4 Enchantment
5 Condition level

All of which dictate the item’s final result in its stats.

But: Because the work is done dynamically on the calling of the objects, would it be more or less work than just filling up the database of all the possible items that can be obtained?

TLDR:

  1. Is it cheaper to have blueprints use rep/notify than to constantly tick in other blueprints (I.e. animation/widget) to find variables attached to the player?

  2. Which is heavier on a game: A giant database full of precise equipment, or a tiny database with simple algorithms to dictate the near-countless variations of items?

2

  1. I have no idea.

  2. Probably having a Big Database, it would also be a pain to keep all the stuff organized.

For an example of Algorithm based weapon generation look at Borderlands 2.
You’ve got the Basic Categories of Weapons (Pistols, SMGs, Sniper Rifles, ect…), then They have Rarity which is color coded, There are Elemental effects, and there are Manufactures, There are Prefixes, and then there are Barrels. All these have effects on what the final weapon will be, oh, and they have Levels so that also scales everything.

Essentially there are 7 factors that determine a weapons’s final outcome. You’ll get a lot more weapons for your effort than if you were to make a huge database with every possible weapon.

3

I would generally advice against storing all the possible versions in a database, simply because making adjustments would take a lot more effort compared to having an algorithm and changing the values.

4

I would also advise keeping a smaller database with items and their possible attributes but allow algorithms to determine how those attributes effect the weapon. A big database is a nightmare to make big changes to at the end.