Understanding proper use of Access Modifiers in Game Development

[strong salmon]

Hello everyone! So generally I've got some understanding of writing scripts and implementing some mechanics to my game projects. However, one thing I've never really understood properly is when and why I should use public/protected/private etc. for variables and methods. Most of the time, I try to keep everything as private as possible, to the point where I even duplicate logic between scripts just to avoid referencing variables from outside.** I only reuse logic** if I can pass variables to a method within the same script. That way, I don’t have to make anything public or protected between scripts.

But here is the thing I've always wondered:

• How does this impact RAM/ROM usage while running a game?
• Does code privacy actually change after obfuscation?
• Can hackers access variables/methods if they’re marked public, more easily?
• I’ve also seen people use public void Start() and others use private void Start() or even protected override void Start(). What’s the point of changing access levels for Unity in-build methods like Start()?

To give you a better idea of what I mean, I’ve attached a screenshot of a ThrowGrenade() method from my game. Right now, I duplicate the same logic for each type of grenade, instead of making one reusable function and passing specific variables like:

• The current grenade prefab
• The grenade’s script component

I think that this could be handled with cleaner code and proper use of access modifiers, inheritance, etc. , but I'm unsure how to structure it without sacrificing privacy or breaking variables' flexibility between different scripts.

So my final question is: How do I decide which access level like: public/protected/private & internal/abstract/override/virtual to use for my variables and methods?

I would be very grateful for some responses to my inquiry as I’m trying to do my best to improve and get better at writing clean, efficient code.

Thanks for reading all the way to the end :)

[dire marten]

dont worry about hackers right now public = can access from somewhere else in code, private = cant access from somewhere else in code, say you have something you dont want to clutter up a namespace make it private or something you only want to change with a set function etc

[strong salmon]

But that's literally the point of my inquiry, to understand the way professional game programmers write code.

[dire marten]

https://tenor.com/view/missthepoint-the-point-gif-7984004

[violet stump]

Hackers can access anything, whether it is private, public , static or instanced.... It depends on the individuals skill's nothing is unbreakable, I mean it helps to keep parameters hidden but there really is no way to hide it at all. Hence why Triple AAA multimillion dollar companies still have hackers and most of the " Hackers " are amateurs that learned a thing or two from you tube, or studied a portion through some form of learning portal. I cannot think of a single game off the top of my head that has never been hacked and had hacks ( Covered up as Mods ).

The best ways to make it harder for hackers is the following. Sorry it is not much and i don't want to go into detail. If you are passionate, do some research on these.

Using Code Obfuscation.
Use AES to work on Encrypting.
Anti-DLL injection's

This could be a start. There is a lot of resource's for this. How ever you will be diving for hours. Good luck to you.

[cedar surge]

• Access Modifiers have no impact to game RAM
• Yes, compiled code becomes more unreadable, all variable names becomes hidden
• No. You could see these access modifiers as compiler only thing to check if you have violated access in your not compiled C# code. In already compiled code, all this is not taken into account since compiled already checked at compiling stage that you didn't call any private methods from external classes
• if you have public Start then you can call it outside of class, if you have private then it can be called only by Unity itself, if you have protected Start then it can be called only by derived classes. If you want to have Start in both derived and base class, you can use virtual Start and in derived class call base.Start()

[cedar surge]

Final question:

• If you know that some variable/method could be helpful only for your class and should not be used by derived/external class then use private. Example: You have some grenade throw function which is public and you have some Calculate grenade throw trajectory function which is private because you need to calculate it only in your class
• If you know that some variable/method for this class only, but not sure maybe it will be used in derived class then use protected. Example: You have some MovementComponent which have Position variable, it can be both used by MovementComponent class and derived class to change your position, but external class can't use this Position variable since it is using only some simple functions like MakeMove(Vector2 direction) but not changing position itself
• If you know that some variable/method should be available everywhere, then make it public. Example: MakeMove which could be accessed from external class PlayerController/PlayerInputHandler

• internal used if you are using multiple asmdef's in your project(I didn't used it at all, you can don't worry about it for now)
• abstract for some classes, that you know should be only derived from and not be instantiated. I used it when I needed to make some interface, but with logic and functions. For example make some class MovementStrategy, which should have current Position variable that is updated every frame and abstract method in MovementStrategy MakeMove(Vector2 direction), which should be defined in derived class. After you defined this MakeMove function in derived class you can use CurrentPosition variables which you are defined in abstract MovementStrategy class to make code more DRY(Don't repeat yourself) and don't make everywhere this CurrentPosition logic
• virtual should be used in base classes methods that you know could be overriden by derived class(this don't mean you have to override it in derived class). Calling virtual methods is more expensive in terms of resources, but allows you to override the method in a derived class so don't use it if you don't need it
• override used for overriding virtual methods in derived class

[strong salmon]

@violet stump @cedar surge tysm, that really helped me! 😀

[pearl parcel]

"How does this impact RAM/ROM usage while running a game?"
It doesn't.

"Does code privacy actually change after obfuscation?"
It doesn't exist in compiled code.

"Can hackers access variables/methods if they’re marked public, more easily?"
No.

"I’ve also seen people use public void Start() and others use private void Start() or even protected override void Start(). What’s the point of changing access levels for Unity in-build methods like Start()?"
None.

Didn't see that it was answered just above.

Now, to be honest, if people want to change your variables, let them.

There is a thing called Unity Cheat Engine or something like that, that will decompile your code and let them modify any serialized attribute.

Let them.

If it's an online game and modifying local variable on the computer can allow them to cheat during online matches, then the problem is in your online conception.

[teal quiver]

"I’ve also seen people use public void Start() and others use private void Start() or even protected override void Start(). What’s the point of changing access levels for Unity in-build methods like Start()?"

I personally think that Unity methods like Start, Awake, etc. should never be public or internal simply because, by design, they're not meant to be manually called anywhere. They're not regular methods to be called, they're "messages" (a Unity concept) that get sent by Unity based on its internal logic. (https://docs.unity3d.com/Manual/execution-order.html)

protected override is a different story. To be clear, if you have a protected override void Start() in a class, that means there's a protected virtual void Start() in the base class (you can only "override" virtual members - C# concept). And if you do have a base class and want to change the behavior of methods like Awake, Update, etc. then you should use override (and virtual in the base class).

[teal quiver]

UnityExplorer

[static sierra]

This has been answered fairly elaborately, but I'll just add that access modifiers have virtually no effect on security. C# in particular can do reflection and basically reproduce all the original code even after it is compiled. It won't have all the proper function names and the reproduced code may look different than the original but it is functionally equivalent. Compared to other languages, C# is very easy to reverse engineer.

You should not be worrying about security now at your experience level. There's not much you can do without getting fairly advanced. Most of the time, the only thing those security mechanisms do anyways, is make your code slower.

Maybe ask another question here about when you should consider adding security mechanisms to your game. Understand why you might need to secure your game before you start worrying about it.

[strong salmon]

I guess making a custom anti-cheat in the future might be the solution (If I gain more experience).

Especially when making a multiplayer game (I am not making one now)

[strong salmon]

"Compared to other languages, C# is very easy to reverse engineer." - Oh, I actually didn't know about that, thanks for letting me know

[upper fiber]

xenu_0001 thanked gaticushax