A few general tips/suggestions

Here I’m going to post what I found out that was useful for me when using Unreal Engine, maybe it will help others as well. I encourage others to post a replay to this with what they think is useful to know, and I’ll edit this main thread and add a quote to that suggestion to keep it more organized, easier to find/see. The following suggestions aren’t in any special order! Use Ctrl + F to search for key names (GameMode, Button, Widget…).

Never be afraid or avoid to experiment with the engine functionalities. Experiment with the capabilities of widgets, actors, timers by event or with anything that you might need but you don’t yet understand how it works. You can always create a testing project so you won’t be afraid to break anything.

You don’t know how to something, and you can’t find the answer on the internet? Don’t be afraid to ask here on unreal engine forum or on other websites. Just ignore the trolls or the “smart people” that just want to show what they know and make you feel bad that you don’t know that. In case the website has a system to give you negative mark (‘-’) on your question, don’t feel bad if you get one, as most websites don’t have a system to balance it, to make it actually mean something, and there are people that don’t even read what you ask and press the - button, just because they can, and know they will make someone feel bad.

I. Widgets

  1. Create a simple square image that is white and use it with any widget element that has Style / Image and don’t just leave it as None in case you aren’t going to set an image, and only use a color. Doing this will display the correct color, as I had a situation where the color I was setting in Tint wasn’t the actual color displayed. Also, in case UE devs are going to change what “None” means, your colors won’t be messed up.
  2. If you are going to have widget elements (Button, Combo Box…) on multiple widgets that are going to have the same style (same color for example), then make a “base widget” that only contains that element (only a button for example), and use that widget as a replacement inside other widgets (instead of adding a button, add the ButtonW you created). Doing it like this, if you want to change the color of that button on all the widgets, then you won’t have to go into each one and apply the change, you only have to go into ButtonW for example and change that with the new style, which will change the style to any widgets that used it.
  • As an example I made a widget ButtonW that only contains only a button. The widget is set to Desired size. Then when I’m using this in other widgets, I’m getting from ButtonW the button and I’m using Bind Event to On Click to set what the button should do. You can even create combinations of widgets that you created. As a more complex example I made a TextW, and a TextBoxW and combined them in a 3rd widget LabeledTextBoxW (in this I added a HorizontalBox and inside it the two widgets, I also added two variables SizeLabel, SizeTextBox that are instance editable and I’m setting them on Event Construct, to be able to have a dynamic way to change the size they take inside the HorizontalBox). This way I can add a TextBox that already has a Label to it. And the same, I only have to change the style of the base TextW and TextBoxW. At first it may take some time making them as you want (with any variables you may want to have, and maybe be instance editable) but for me it was well worth it.

II. General

  1. Try to get used to create a parent actor for any situation where more then 1 actor is going to have some of the same variables (values can be different, and most likely will be), functions and events, and from that create as many children’s as you need.
  • As an example, I’m using this for GameMode, GameState, PlayerState, PlayerController, where I have a parent for each of them that contains general functions, events and variables (ex: player spawn function, variables nickname / is player ready / team id…), and then from those for each map I’m making a child that has functions, events and variables that are only used on that map.
  1. If you want to add in memory a number / string / … (anything supported by wildcard) that is random generated and use it in multiple locations but you don’t want to set that as a variable, then create a Blueprint Macro Library, inside it a Macro (I choose Set Aux as name) with the following content.
    image
    Usage:

  2. You should learn to use Soft Object References as they will be useful to manage memory usage in some situation, like when you don’t know what character the player will use and to avoid adding all of them into memory. This video can be useful to watch to learn a bit more about this subject.

  3. If you need two variables with the same name (especially in a function), just add a space at the end of the 2nd (3rd…) one. This way Unreal Engine will allow you to have them “the same name”. In the following example you can’t have the same variable name for input and output, but I just added a space at the output value name.
    image

1 Like

How sure are you about #4? Imho it’s asking for trouble and goes strongly against any reasonable naming conventions I’ve ever heard of. Even the very basic UE’s one mentions ambiguity avoidance:

“This runs the risk of creating redundant variations of assets you’re experimenting with, or introducing ambiguity with overly similar names.

More here:

To each their own but if you ever worked in A Team, you’d quickly become The Villain ;p


I really like #2.

I’m not a “professional developer”, but I noticed that the engine can get confused in some situation about naming and this worked really well for me to get past some issues.

An easy to reproduce example is this situation:
Create a new User Widget and inside it add a Text Box. Then create a function named Change IsPassword with a boolean as input and in content set for the Text Box / IsPassword the input. Then inside the widget add a variable named IsPassword and after the variable is created, change its type. The editor will get confused and ask you if you really want to change the type as the variable is already used, even tho you just created. Its confusion lies in the fact that inside the function when you call Set IsPassword for the Text Box, that function already has a input with the name IsPassword and think your variable is the same with that input, even tho in reality they don’t have any connection. Now if for variable name I add a space at the end when it is created, then I don’t have any problems. By having the variable named without a space at the end, and because by default it was created as a Boolean which I would have set it myself anyway, I didn’t noticed the problem, and in a situation I have, when I wanted to call Set IsPassword for the Text Box, it wasn’t changing the Text Box to password field. And yes, you can add something to that variable name to make it different, I choose the space route because I made it be more intuitive when used as Instance Editable:
image

Images from the example I mentioned to reproduce the issue:
image
image
image
image
image

I think this works because in programming (C++ and Java at least), you can’t have variables with a space in their names, and yet in Unreal Engine you can have spaces in blueprint mode even tho it is made in C++, and I think the reason for this is that in the background, when a space it is used (or any other characters not allowed as naming), it is replaced by a character or string of characters in the code it is creating, and when the blueprint is viewed it replaced that character or string of characters with a space or any other character that normally you can’t use them inside a variable name.

As an example this:
image
You can’t have in C++ or Java in variable name the sign { or } as those are use to delimit bodies, or [ ] which are used in arrays.

If it does not confuse you, that’s fine. You asked for input, here’s mine:

• adding spaces to the END of variable names is not a good tip or practice, same for parameters :face_in_clouds: I could look the other way if you were passing by-ref but you are not :innocent:

It is totally fine, as I do get it. Having to variables with the same visual name, and only different by a space at the end that you don’t see can lead to problems if you don’t pay attention which one you use.

Even in this situation, while yes, in the list of variables you’ll see them like this:

image
image

Where they are grouped and you know which one is used where, but if you look at its use:

image

Then it can cause confusion if you don’t know what you are doing, as those two are different gets (you can see if you look closely at the text, that the second is a little more to the right), but they look 99% similar and don’t offer a distinct way to differentiate between them. These are some situations that are fine for me to use them, but I get it that it might not be for everyone, but I still consider them useful to know.

But in the case of a function, I don’t think it can cause a problem if you have the same name for input and output, as you can’t use the output inside the function anyway.

Any input is welcomed (good, bad, constructive, question, answer…), as I can miss or misunderstand some things. :slight_smile: