Some info on editing scalability settings in UE5

Didn't find much info about this, so i thought I'd write a quick blog post.

There's quite some info on the topic of how to actually make an UI that changes graphics settings at runtime, so this won't focus on that. Here's a video from GorkaGames who has good blueprint tutorials on Youtube, which should help you get that covered.

So to the main part, when you have all the settings set up but you want to change what happens when you select low, medium or high settings.

So in the Config folder of your code projects engine folder you have a file called BaseScalability.ini, which looks something like this at the beginning of the file.

What you first want to do is to figure out at how low settings your game still looks like it should. Here's a screenshot from our settings menu after testing in build what worked for us:

To my understanding how unreal handles these settings is in a waterfall kind of sense, it always starts at the engine's BaseXYZ.ini file, then goes to the projects Config folder to see if there's a override called DefaultXYZ.ini, then I think it goes to the game's Config folders platform specific overrides which would probably be under Project/Config/Windows etc. Here's the Lyra Scalability documentation article I used to find out this info (It has a lot of stuff there, which is unrelated to this issue, but useful nonetheless).

The next step after this is to create this file, in this location and copypaste all the content from the BaseScalability.ini file into it.

What i did then was just to make sure the lower options are just duplicates of the lowest option that still kept the game visually similar figured out in the previous step.

So for example my Reflections setting needed to be at a minimum on the Medium level of the what is set up in the BaseScalability config, like here:

I didn't test if you could remove settings completely in the DefaultScalability config file and what would happen if you did. Would it just bring the lowest setting from the Base file or, would it not show up at all.

This solution solved the problem i was facing to the extent that was necessary right now, so I'll do the experiment potentially later in production.

Thanks for reading and hopefully this saved you some time if you ran into a similar issue.

Issues when adding Actor Components to Character in c++

As i was using quite a lot of time in troubleshooting this and it's probably an issue that might come up to others as well, i thought I'd make a blogpost about it.

So i was building my Character in c++ and adding components to it in c++ in the constructor like this after creating my blueprint derivative from my c++ class:

It was all fine and dandy until i needed to add references to these components that i would like to assign in the details panel and was shown a blank details panel when highlighting the component in the editor.

After some heavy googling and troubleshooting to see if my UPROPERTY() macros were set properly i found out that this seems to be a bug in the editor that has been there for some time as referred in this forum post:

https://forums.unrealengine.com/t/solved-blank-detail-panel-for-ustaticmeshcomopnent-in-child-blueprint-class-of-a-c-class/141378

So one workaround that actually worked was to reparent the blueprint back to its base level which is Actor and then back to my derived class which is Entity Character, which you can do like this:

This would indeed work, but it also corrupted my blueprint quite drastically and i had to redo o a lot of stuff, references exploded etc.

Also any blueprints referring to these components (like Animation Blueprint for this character and UI blueprints) would get broken in the process, so this wasn't really a solution.

There were some other known workarounds where you would rename component variables -> compile and it could fix the issue which i never tried.

In the end what i ended up doing was just to make sure my actor components are blueprint spawnable components with these UCLASS parameters:

Add the components in blueprint and the details panel seems to be there, which solves the major issue at hand here, but not all.

The whole reason i ran into this issue was that i needed to refer to some SkeletalMeshComponents in my EquipmentComponent to update those meshes when i change the equipment on the character.

As I'm coming from unity i would have assumed that making pointers to said components in c++ with the right UPROPERTY() macro would make it so that i could assign them in the editor like in unity, when you use the [SerializeField] or public keyword for variables in c# for a component, but it only gave me this:

So i can't assign any references to the mesh components nested under my character here like in unity.

I read about FComponentReference which kinda would maybe do the thing, but required some casting to the right types etc. So after some googling i came to the conclusion that just setting these references in the blueprint construction graph would do the trick:

Will post some updates and workaround if i run into further problems as we finish the equipment functionality for the game, but for now there doesn't seem to be an easy way to set component references in the editor like in unity which is a bit of a bummer, but taking into consideration the other benefits of shifting to unreal, this seems like a small price to have to pay.

Shifting from Unity to Unreal Engine

Quite a long post so TLDR: if you care about knowing about my workflows in unity and how I'm trying to find ways to shift them to unreal as smoothly as possible, continue reading.

Been messing around with blueprints in Unreal Engine 5 now, even though working in the code editor is what i like the most. There's so many features that are handled with blueprints in unreal, that i think it's quite vital to learn them at least if you work on a team where other team members are more familiar with visual interfaces for binding up things (Animations, materials etc. ).

However some things just turn into relatively complex structures in blueprints that are quite simple to do with a couple lines of code. Found out about Blueprint Function Libraries, where you can implement c++ code to get the benefit of both worlds.

In unity i like to build static libraries for core functions that my game or interactive things in the game uses. Then i just call whatever i need in a Mono Behavior update to define how it will work. Keeping my logic outside of the objects, so i can easily change their behavior by just changing what methods they are calling in their update. I also tend to like to not adopt a OOP approach, and keep my data separated from the objects, as most systems only care about reading data of an object, but in traditional OOP fashion you can't have data and functionality separated, so you end up passing around both even if you only care about the other. Haven't come up with any better solutions thus far to two determining factors that seem to apply to all game play code.

1. Everything needs to be able to know about everything, every frame with a minimal as possible overhead.

2. The code should never be a bottleneck for the design to change if there's a valid reason for changing the design to create a better game.

Gonna try to do something similar in unreal, where i build useful functions in a library of blocks that i then tie together in a blueprint graph, to create the functionality that i like. The benefit of unreal towards unity is that with blueprints you can also create supplementary logic in a blueprint as a designer, artist or an animator and not fully depend on the programmer having to implement all those functions in code. Also you can more easily as a non code person change the call order, bind stuff to input etc. than in unity in this regard, without the programmer having to interfere.

So my work in unity would be:

1. Talk with the designer about the wanted functionality and how it should work.

2. Declare the data types required for that feature.

3. Build the tools for creating that data for designers in the editor (scriptable objects, editors whatnot)

4. Build the system / functions that operates on that data.

5. Make a first proposition of how that design works in play.

6. Discuss with the designer what needs to be reiterated.

7. Tweak the tooling, functions or whatever required and make a new proposition until we reach the functionality our game requires.

How i see this could potentially work in unreal based on my current knowledge.

1. Talk with designer who hopefully already has some bare bone version of the functionality made in blueprints to communicate their vision.

2. Implement a c++ function of that logic that can replace the logic in the blueprint the designer has created and is more fleshed out and has only the parameters that the designer cares about exposed for tweaking.

3. Keep building more blocks of useful core functionality as the project goes on.

4. Eventually new content will be added to the game by just calling the wanted methods in the blueprint that the designer builds on their own.

I still need to figure out where to store my runtime data, while keeping sure that I'm not shooting myself in the foot with data replication as I'm working on a multiplayer game.

I don't know if this is a good approach, but it has proven itself reliable in unity compared to other approaches i have worked with in the past.

Also linking this video here that i found, which seems to go through quite well different tools and tricks in unreal which supplements this approach I'm trying to take.

Leave a comment if there's something you think i should improve on the format or you feel like something is missing as I'm quite new to blogging!

Cheers,

Kim Ordén - Lead Game Developer @ Potion 8