Dynamic object type in construction script.

[Sanoz]

Disclaimer: This kind of spans across both C++ and blueprint domains. But I do believe here is the “more correct” place to post this.

I have been trying to figure out how a system of mine could be designed before I actually start coding it, and now I’m wondering a bit about how it would work with blueprints. I think some background is needed before the main question comes:

Let’s say I have a base item class called Item from which all game items are created. In a nutshell, the idea is to create items via a “bridge” to a data source, either an XML file or a database or something entirely different. The point is that the concrete implementations for different item types (let’s use Weapon and QuestItem for this example) are hidden from the rest of the game, which is really only interested in the interface. The items would likely be created by asking the bridge “Can you please give me an item with ID 48?” which then instantiates an item of the correct type (because it knows from the data source what type the item should be, and therefore the concrete implementation).

Now, making a blueprint of Item would be nice so that one could easily place various items in the world. The actual item would be determined by setting the ID property. This is where a problem arises:

The placed items are of type Item. While this is not a problem in itself, what happens when I want to select exactly which item it is? Let’s say I want the item to be of ID 48, which could be a sword or some other weapon. Now I’d like the construction script to make the item of the correct type (Weapon) using the bridge as outlined above. Maybe later I would change my mind and change the ID to 352 to have the item be “Sheldon’s magic pen keeper” which would require changing the item to a QuestItem. Is it possible to have the construction script change the type of the item like this? (I’m not talking about changing a variable telling the type of item, I mean the actual class it’s made of)

[Michael_Boeni]

Hmmm, I’m not sure if I understand fully what you are trying to do. Would these dynamically created items follow a hierarchy, i.e. inherit from a parent? Also, would an item of, lets say type ID 48 represent a class which can have multiple instances of this type or would this be a one-to-one thing?

Cheers,
Michael

[Dig_Squid]

The construction script cannot change the class of itself. Maybe QuestItem should just be an option on Item, rather than a subclass.

[Sanoz]

@IMX;22054

Hmmm, I’m not sure if I understand fully what you are trying to do. Would these dynamically created items follow a hierarchy, i.e. inherit from a parent? Also, would an item of, lets say type ID 48 represent a class which can have multiple instances of this type or would this be a one-to-one thing?

Cheers,
Michael

The main problem was solved (see below under JamesG quote) but a follow-up question arised. To answer your thoughts:

Yes, the items would follow a hierarchy. The base class is what the blueprint would be created from. Changing the item would result in having the entire object change type, which JamesG said isn’t possible with construction script (makes sense).

The ID is not the type of item (Weapon/QuestItem), but rather the unique kind of item (Apple, Sweatpants, Jeans, an so forth). Sweatpants and Jeans would both be of the same type (Clothing) but they are distinct items, that is, they have different ID. In the end, it’s not a one-to-one thing because I can have several Apples in a level even though they all share the same ID.

@JamesG;22312

The construction script cannot change the class of itself. Maybe QuestItem should just be an option on Item, rather than a subclass.

I was afraid of that, but it does make sense. Thanks, it was a short answer to a long question

<Sidenote>
I did however come up with another idea during the day that allows me to change item type functionality while still using only the Item class (no derived classes at all). The only things of interest in the editor are ID and mesh in order to place items in the world. The mesh is aquired from the bridge so if I set that as a component of Actor I should be good to go
</Sidenote>

Follow-up question:
I should probably ask this just to clarify, since this deals with combining C++ and blueprints which is completely new to me:
At the end of the day, what I want is for a level designer to be able to place items in the world. The game logic uses the C++ Item class, but if I make a blueprint of that to use for item placement, won’t it be a new class like say, ItemBlueprint (derived from Item)? If that’s the case, is there another way to allow the level designer to place objects of the C++ Item type? The items are derived from Actor so they can be spawned in the world, but in order to work with the rest of my game logic they need to be C++ Item and not BlueprintItem, so to speak.

[PenguinTD]

Actor is already the class you want, you can add static mesh and some other “required” component/variables/functions in it, and then just make sure your level designer inherit it to do stuff he wanted.
After you prototype and fine tune your item class, you can always make your own C++ item class to expose in blueprint(maybe for efficiency consideration).

[Sanoz]

@PenguinTD;22692

Actor is already the class you want, you can add static mesh and some other “required” component/variables/functions in it, and then just make sure your level designer inherit it to do stuff he wanted.
After you prototype and fine tune your item class, you can always make your own C++ item class to expose in blueprint(maybe for efficiency consideration).

You misunderstand me. My Item class is already C++, not blueprint. The latest question is in the last paragraph of my previous post. The issue is that I want to be able to place items (of the C++ Item class) in the world while creating a map.