A Question about

Hello,

what is the best way to handle the following thing?

I have 2 scripts A and B. Both scripts are attached to a large number (<500) of game objects. Both scripts need to do some calculations when the camera has moved.

Shall I put the camera moved check in both scripts so that they can work independently or is it better to put the check e.g. to script A and let A call B to tell B the camera has moved?

How do you handle such things?

Thanks,

Alex

 

I would keep them independent, and let them each do their own check. The check is pretty trivial (comparing one Vector3 to another), right? So, do whatever keeps your code as simple, clear, and easy to maintain as possible.

 

I'm missing a good guide that discusses the best architectures for a game.

 

Best is relative. A simple and small game can be written with spaghetti code, without any fundamental structure or with a really well defined architecture which will be maintainable and extendable all the time. In a large project, you won't get really far with spaghetti code as you'll soon find yourself trapped in a structural disaster.

As every game differs, you won't quickly find THE guide for a good game, only some rough schemes that allow you to wrap your head around some structural ideas and even those cannot be generalized and will need to be extended. But if you keep writing some kind of moduls / subsystems with a well defined interface you're not doing too much wrong.

Also, regarding your original question: it's difficult to give advices because we don't know much about your code and your programming skills.

One way to achieve this is by having a script that determines whether the camera has moved (at all or a certain distance) or not and keeping track of that with a boolean which will then be accessible in other scripts.
Instead of the full check, that would only require a boolean comparison in each script that has to react to it.

E.g. 1000 boolean comparisons are quickly done, anyway, you could have a CameraMoved event which fires when the camera has moved. Every subscriber would then (and only then) be called without even checking the state again. That would reduce the check down to a single one no matter how many actions depend on it.
Please note, that these subscribers won't be called in Unity's script execution order though, but most of the scripts shouldn't rely on it anyway.

 

because there isn't one best architecture. not every game is the same so no one architecture will work for all of them. Design Patterns are a solutions for specific problems, not some carpet bomb that would work for every situation. the best way to learn is to constantly experiment.

there are several Software Principals that you could adhere to:
Composition>>>Inheritance: Favor Composition over Inheritance, Composition allows for dynamic changes at runtime.
Liskov Subtitution: components of a class should be interchangeable with others of the same subtype.
Loose Coupling: the less your classes need to know about each other, the easier it is to maintain
Open-Closed: Classes are open to Extension, Closed to Modification
Least-Knowledge: classes shouldn't access objects through other objects.
Single Responsibility: a class should have only one purpose, one reason to change
Hollywood: "Don't call us, we'll call you" Low-level component classes shouldn't call higher-level manager classes
Dependency Injection: give your classes the abstract instances they need, don't force the class to find/create concrete instances.
Interface Segregation: no class should know about methods it doesn't use

and many more... but they are just principals, not rules, nor laws. Their just guidelines for helping keep your code maintainable. in reality you'll often find reasons to not follow them. maybe because doing so would take far too long and you have a deadline, or the code needs to run really fast (software principals prioritize code maintenance, not performance).

You can also look into SOLID programming. writing classes to adhere to 5 specific prinicipals
S: Single Responsibility
O: Open-Closed
L: Liskov Substitution
I: Interface Segregation
D: Dependency Injection

 

I always throw out the Game Programming Patterns book for these kinds of questions. It's free online, or it's well worth purchasing if you find it useful. As others have said, there isn't really One Best Way to structure a game - it's going to vary with the game and the problems needing solved in that game. Programming patterns can give you some building blocks to use to build that unique structure though.

 

Hey guys,

so much advice

Thank you all!