Immutability important in blueprint code?

Hi, I am a blueprint coder but I try to learn more about traditional coding here and there.

One thing I see talked about often in traditional coding is immutability. I get the premise, some things should be allowed to be changed and others shouldn’t, and this can effect performance at a low level (referring back to same thing rather than creating new).

But putting aside low-level performance, for somebody making simple games as a solo-dev, does it make any real difference to consider setting things protected/private? Is there some problem I could run into if I just ignore that stuff? So far I haven’t considered it in my blueprint code and haven’t faced any problems. I wonder if its something that might be important for larger applications, or team-created applications, etc.

Generally you don’t have to write clean code to get a functional game, but it can save you time and prevent bugs in the long run if you do so. Making all variables and functions public doesn’t affect performance, but it results in your classes being more entangled and thus it becomes harder to change something. Let’s say you have a public boolean bIsAlive on a character and lots of other classes are accessing to to know if the character is alive. Now you decide that you don’t want the flag bIsAlive but rather a float with the health percentage, you will have to go to all references of bIsAlive and fix them. If you hide the implementation behind a function like IsAlive() you can change it much more easily

3 Likes

thanks, that practical example helps me understand more clearly.