Using Public Voids - Performance question

Hi
I have an adventure style game with a framework that employs collection of 'helper' scripts. At some point in time, depending on player actions, these scripts may need to cross talk. Therefore I'm using a lot (well about 60 public voids here and there that can get called, but NOT all, just the specific ones!) of public voids so I can update and do necessary state crosschecks prior other actions.

A number of my helper scripts have public voids declared. Many of these only get called rarely. i.e. when clicked on. None of these have Update() functions (not necessary and to maintain optimisation).

My question is how are Public Voids handled in terms of performance if they sit there until called?

I ask this in anticipation of how many "LAME" interactable objects I could throw in a scene without concern about them containing public voids. Each object does have a MouseEnter then a MouseOver check which reads a double click event. That's unavoidable and acceptable. No performance issues with them yet.

Many thanks
Arch

 

Methods and variables just existing will not cause a loss of performance. They will take up processing time when they get executed and that's it. If the scripts are Monobehaviors just make sure to remove any unnecessary empty methods (like Update if you dont use it), since Unity will still call these even when they are empty.
Unless i'm totally missing the point here i'm not seeing you run into performance problems anytime soon.

As a rule of thumb, dont think about performance problems too much, unless you know from experience that something will cause problems down the line. More often than not it's better to just get things working and fix performance problems when they get tangible - which also lets you profile what exactly is causing the problem and fix that specifically.

That said, i think 60 public variables / properties / functions seem a bit much. So there may be a better approach architecturally for what you attempt, but as far as performance is concerned, functions do not take up any unless called.

 

Cheers Yoreki !
Yeah it seems a lot but I've kinda built a whole framework for an adventure game builder. This includes Dialogue systems with flexible multi character control, lookat, go to, animate walk talk lipsync etc, plus a quiz system and other custom interactions. Its all Dynamic so I can now construct a multi dialouge system. Everything is sleeping (disabled) until they are called by custom triggers etc. It allows much more including activating and deactivating GO's, running timelines etc. Plus it allows Sequenced dialogues ie. if visited before play another dialogue. Each dialogue is dynamic and each option can control ALL the other components (hence the many Public Voids) to make up a cut scene style event. Its for a Mining Adventure and Simulator system that I've been messing with for several years. There's a certain amount of cross checking going off but so far Im not seeing any major hits. I tried to ensure a lot of this is event driven and only active when necessary. It allows me to break larger scenes into ZONES .. the list goes on LOL .. Thanks for the advice !!

 

Lots of public's can be bad for a different reason -- it's not a performance problem. It's just a programmer confusion problem.

Suppose you want a script heal thing A for 20. You type A-dot and the pop-up shows addHealth, healHelper, health (a regular variable), setHealth... . It's easy to use the wrong one that does the wrong thing. That sounds silly, but as a project grows things get more and more confusing and these are tough bugs to find.

 

I would agree 100% - I like to think I've designed the system well enough to manage it. One of the reasons for building my own adventure framework was so I understand what Im using.

 

That's definitely a thing -- even if you're going to be using a commercial system you often have to write your own to really understand it. But "I'll always understand it because I wrote it" isn't true.. Think about regular writing. You can explain something, read it back, and it seems to make sense. But a month later you read it again and don't know quite what you meant by it. Programs are the same way. It's all fresh in your mind as you write it, and everything is easy to find. A month later you're setting A.health+=20;, completely forgetting that you need to call A.addScoreImmediate(20) if you want to update the display and check for winning.

 

I understand your wisdom buddy trust me. I'm 57 with over 30 years consulting worldwide in I.T. industry from tech to senior PM roles. Done a lot but I'm relatively new to game design, so I retired and did a BA in Concept Art and illustration. that gave me time to get clued up some .. now I'm an ever learning Indie or Oldie LOL ;-)

 

Snapshot

 

I have no idea what I'm looking at here but it looks wonderful.

 

In that case my advice is that 1/2 of what you read is correct, and the other 1/2 is junk. For example, SendMessage sounds pretty cool, but it's just a slower system for game designers who don't know how to find a specific object or use listeners. But removing empty Update() from scripts that don't need it -- that's a thing (and mostly obvious. Of course Unity will waste cycles running them). People implying certain C# commands work better or worse in Unity are generally wrong -- C# is C# -- but not always. And so on.

 

The massive part of the learning curve is siftng through the bullshit thats for sure. Like anything, digest it with a pinch of salt and double check the facts.

 

This -