Question Need a feedback on design approaches

Hi all,

I'm currently working on a project which have been progressing slow lately due to me not being sure which of the below approaches are best, below is one simple example:

Suppose you have a "MoveRotation" component/script that has all of the rotational related functions that I may need for the project, now the question is,
1. Do I attach this component on all of the objects that require to be rotated?
2. Or should I have one main "MoveRotation" object, and then have any object that needs to be rotated call?

For the first option, suppose I have 100 objects then there would be 100 MoveRotation Components attached to each
For the second option, I will have 100 objects then only 1 Object holding 1 MoveRotation that can call/being called inputting the 100 objects as a paramter.

The above is a simple example for a more complex problem but I would like some input on this

 

Option 2 will be faster.

Dots will be even faster.

C++ and Direct3D/OpenGL will be even more faster.

 

And yet, all pointless if the project doesn't necessitate such systems.

Option 1 is the easiest to implement, and the most versatile. And probably will be fine unless we're talking tens of thousands if not more objects.

If there is a performance issue... that's why we have the profiler.

 

^ ^ ^ ^ That's your main problem. You are analyzing things that:

a) likely won't matter much

b) can be instantly and easily tested both ways so you learn empirically!

Within a VERY short period of time you should be able to test each approach in a simple empty scene and see how it goes.

Check out this guy's approach... ask yourself again and again, "Can I ... ?" It really works.

Imphenzia: How Did I Learn To Make Games:

 

The normal monobehavior gameobject workflow will likely result in unplayable performance issues way before that (hundreds to low thousands), depending on object complexity. But generally speaking, most projects wont have anywhere close to that amount of non static gameobjects. And even if they do, there is usually other things you can do to optimize. So yeah, while the first answer is correct from a performance perspective, this is the right approach for getting stuff done.

Unless you really know what you are doing, only worry about performance problems once there is an actual, tangible problem. You can then use the profiler to figure out what is the problem and either fix it or ask for help for a specific problem. Premature optimizations (even just in your mind) will kill your progression speed and thus your motivation, which more often than not leads to you not finishing the project at all, over things that may never have become a problem in the first place. There is only a small hand full of topics where optimizations are necessary from the get-go (some procedural generation topics, other heavy number crunching algorithms, some shaders, RTS or simulations with tons of entities or complex real time physics..). Usually when you work on such a topic, you also know what that entails.

Edit: Keep in mind, modern hardware is, for most intents and purposes, orders of magnitude stronger than what you really need to make most games run well. So you have a lot of leeway for performance issues that wont ever be noticed. And if there is a performance issue, the solution is usually a different data structure which allows to reduce the necessary computations by an order of magnitude. It's never about squeezing out a couple percent here or there. Never! With that in mind, do quick iterations. Get stuff done, progress your vision of your project, and if somewhere along the way you notice a problem, you have something tangible to deal with.