It's not the first time I have this discussion, and I doubt it will be the last. Basicaly, it goes down like this;

Since Unity is Component-based architecture, how do you do it without the advantage of Object-Oriented Programming?

 

You could replace "Unity" by any kind of video game engine, code architecture or anything else, really. It's about at the middle of the sentence that the urge for a very loud facepalm starts to overcomes me. I don't want to be rude, but it's hard since I've heard that a dozen time already, and it's never easy to explains what exactly "Object-Oriented Programming" or "Component-based" means. With most coder, I would simply gives snippet of code as examples, but even then it often ends up not being enough.

Let's start with the basic, you should go read;

- http://en.wikipedia.org/wiki/Object-oriented_programming

- http://en.wikipedia.org/wiki/Component-based_software_engineering

 

If you're like most people, you will finish reading them, and will come back scratching your head.

OOP (Object-Oriented Programming) is a language paradigm. This means some language have it, some don't. OOP simply doesn't exist in C, is optional in C++ and is enforced in C#. Which means, in C your code is never an object, in C++ it may or may not be one, and in C#, it is always an object. OOP is simply the means of encapsulating logic-related members within the same container.

Where it begins to be annoyingly confusing, is when people start to see OOP as a philosophy of coding. I've even heard someone saying that the "static" keyword should never be used because it goes against the notion of instanciable objects!

OOP is a tool within a toolbox. You use it the way it makes the most sense. Refusing to use it, or discarding other tools because they don't match perfectly with your "belief" of how it should be used is simply, and plainly retarded.

 

Component-based software are how you build your code. Code is split into smaller chunk that define a specific behaviour. You have a root - in Unity it's a GameObject - that you plug components in it. The advantage of this kind of approach is the endless number of combinaison that you can perform.

It has nothing to do with the language you use. I've used a video game engine built on C (no object) that was component-based. On the other hand, Unity is using C#, which enforces the use of object. As you can maybe see, OOP and Components are not mutually exclusive... because they absolutly don't mean the same thing. One is a language paradigm, the other is an architecture paradigm.

An example of this, component in Unity are a class, which is, once instanciated; an object. Therefore Unity is OOP and Component-based.

 

The mix-up is often based on what someone define as being "an object". In a pure coding approach, as soon as you have an instance of a class, you have an object. However, some people believe that to be a "proper" object, that class must work in a way similar to real life. Therefore, if you want to have a chair in a video game, you should have a class named "chair", that would probably derive from "sitable furniture", which itself derive from "furniture", and so on.

A lot of video game engine won't use this kind of rigid approach for many reasons. First, it's not flexible. Everytime you want a new object type, you need to derive from one existing class. If that class is missing some of the behaviour you need, but another has it, you're kinda screwed; you have to rewrite what's missing. Second, it's a pure code-driven approach. (For the record, I hate pure code-driven as much as I hate pure data-driven.) In this case, it means if we want an new object, we must have a coder around to create it for us. If it was with components, someone else could simply match existing component together and it would give what we need. New code might not be required.

For a more direct example, in a game, you often need to have visual without collision, collision without visual, and visual with collision. Someone could simply go and code that kind of pattern and possibilities. On the other hand, he could code a "visual" component, a "collision" component and just tell people to use the one they want. It starts to make a lot more senses when you add "skeleton", "animation set", "sound emitter", "rigid body" and many other parts that are used to build video game characters. That same "rigid body" could be use on a character... but also on a crate we blow up. Or a closing door. It's logical to have this code exist within a smaller, self-contained, reusable chunk.

Write comment (6 Comments)