Download

Looting System C++

Development Discussion C++ Programming
#1

Hi folks,

currently I’m planning a looting system for looting barrels, crates and stuff. I’ve done stuff like that in C# in Unity (A language I’ve always hated since C++ was always my favorite language), but I’m new to Unreal Engine and I’m a bit confused about Unreals classes and functions like UFUNCTION and UPROPERTY and stuff (not difficult to understand, but a bit confusing to know how to use them correctly). Therefore I’m planning more carefully in this case.

Image:

Now my question (I’m sure there will be more during the development):

Should the class Loot be derived from the class AActor? From what I understood AActor should only be used for assets that will be placed in the level (or spawn) but this class should just include the basic looting functions. classes like barrel will be derived from this class.

So is it wrong to make it class ALoot : public AActor if class ABarrel will inherit from ALoot?

Should I use a different prefix, since Loot is not a classic Actor?

Sorry for dumb questions

#2

If you want your Barrel, Crate and Chest objects to be able to be placed in the world then your base class should inherit from AActor.

The naming conventions in Unreal use the ‘A’ prefix for any object which is derived form AActor, so naming your class ALoot, would be fine.

However I’m unsure as to why you are making your barrel, crate and chest separate classes. Do they have different functionality, or it purely cosmetic?
If barrel, chest and crate are identical except for their appearance, I would suggest having a single Loot class, which has a mesh component. In the case of the chest, you would then create a Loot object, and set its mesh to the chest mesh. This way you only need to deal with a single class and you don’t have to create a new class if you want more than just a crate, barrel and chest.

#3

Thanks Rejjan,

the main idea behind the different classes for barrels and others is because they call different item generator classes, playing sounds and animation (in case of opening a chest and lockpicking). For example: in barrels you will find more food, potions and random clutter like spoons, pots and other **** to sell, but you have a very low chance to find a weapon and zero chance for a piece of armor…stuff like that.

#4

Like Rejjan said you probably do want to inherit from AActor.

Have you thought about making your lootable containers data driven? Instead of using code to make different containers (ABarrel, ACrate, etc) you could specify the sounds, animations, meshes, and loot drops in data. Here’s an example for how you can set this up in your header file:


UPROPERTY(EditDefaultsOnly, BlueprintReadOnly, Category=Loot)
USoundBase* OpenSound;

You’d have something similar for all of the other things that you want to be different for your different loot types. You don’t need all of those things in the UPROPERTY but they may be helpful. The first two help to make sure your data doesn’t get changed in unexpected places. The “Category” is useful for grouping all of your customizable data in the editor.

One of the big advantages of having this all in data is that you can change it without needing to recompile. If you’re working with a team it also means that people that can’t write code can make changes to your loot.

#5

Thanks Fred K,

yes, I see. The whole Blueprint topic is new to me, but it seems to be worth to get into it, instead of doing everything hardcoded in various header and cpp files.

If I understand it right, the best choice is to provide the basic framework for loot via Code and to edit the type specific tasks in the blueprint, is it correct?

#6

Yes, that’s the approach I would take.

If you’re new to blueprints I’d suggest you try it out with a simple example before you write your whole class. Try implementing a simplified version of your loot class that doesn’t do much but has one variable that you can set in the editor (using the UPROPERTY macro). You can try passing different parameters to the macro to get a better idea of what it’s doing. You can also take a look at ObjectBase.h to see some of the options you can specify in the UPROPERTY and related macros. You should be able to do what you’ve described with the UPROPERTY parameters (or very similar ones) from the example I gave.

#7

I got a little problem, but I don’t really see why.

I’ve added a USphereComponent in the code and attached it to the RootComponent
bfa41ab52512ed3984c22b73fa925bd99bb90ac6.jpeg

but for any reason it doesn’t appear as a NativeSphereComponent in the Blueprint component hierarchy. The Sphere seems merged with the capsule component, you can’t select it seperate. However in the default tab it appears as a seperate component.

97370faf096d4605553aaa6b6eb5e3603fc32ede.jpeg

To be honest, I have no clue why this isn’t working as intended…did I miss something?

#8

I have fun with this all the time, adding new subobjects in code is not registered by the engine and you have to recreate your blueprint in order for them to show up in the editor. There is a hack for removing them (Changing components in c++ doesn't remove old ones from blueprint - UE4 AnswerHub) but as far as I know there is none for adding new ones.

#9

ohh, that’s annoying. That means everytime I want to test or polish a new feature like sneak or lockpicking I have to recreate the character blueprint.

Is Epic working on a fix for this problem? Is it known to epic or should I report it as a bug?

#10

I remember reading somewhere that they were working on it, but another report might bump the importance up a bit :wink:

#11

Prefer composition over inheritance, specially for games. You’ll be re-writing much less code that way. You can have a single ALoot class that uses different item generators selected at spawn time: just add an UPROPERTY specifying the item generator class that is to be used. Example:

.h:


UPROPERTY(Category = Loot, EditAnywhere, BlueprintReadWrite)
TSubclassOf<class AItemDropGenerator> ItemDropGeneratorClass;

UPROPERTY(Category = Loot, BlueprintReadOnly)
AItemDropGenerator* ItemDropGenerator;

.cpp:



if (ItemDropGeneratorClass)
{
    ItemGenerator = ConstructObject<AItemDropGenerator>(ItemDropGeneratorClass, this);
}

Then you can simply select the ItemDropGeneratorClass property in the ALoot actors you place in the level editor or when spawning them via code or blueprints. The picker pop up menu will only show classes derived from AItemDropGenerator.

#12

Hey pedro_clericuzzi,

If I am not mistaken, ConstructObject is only for UObjects and not AActors. Please correct me if I am wrong. I am still new to UE4 so I am still learning a lot. I have been using the SpawnActor from the World to create actors and store them into the pointer variable. At least this is how I created a random actor spawner to spawn a random actor in a list of actors provided in the editor. Also I am using the SpawnActor for my character’s inventory. I just wanted to put my input on how I was doing it and to learn if that is way of creating an actor without actually spawning it. Just my 2 cents and if that is correct as well, then I am happy to learn a new way to create actors without using the spawn.

#13

Thanks for your input guys,

I’m still a bit confused about the Unreal Code I have to integrate in my plain C++ code. Is there a detailed documentation about all of UE 4’s classes and when exactly I have to use which class?

Now I’m planning the basic item generator code…usually I would just write my class in C++ and everything would be fine…but from what I understood I have to inherit classes from UE classes, but since a generator is no actor that is placed in the scene I couldn’t inherit it from AActor nor it’s a pawn or a character, gamestate or whatever. Is this the case where i choose none(empty C++ class) when none of the UEClasses is matching my needs?

#14

You could make loot a component, so you can just attach it to any actor.