Yes, there is a difference. I don't know what you're saying, though. I previously thought you were saying I was wrong in saying that one of the differences between "camera.x += 1*time_step;" and "Camera.main.transform.Translate(move*Time.deltaTime);" is that the latter demonstrates encapsulation, the use of which is not intrinsic to Object Oriented programming.

Now it appears you just want to explain components. That's great, but why quote me?

Jibb

camera.x += 1 * time_step;

but this can also be encapsulated in modern languages that support properties.

http://msdn.microsoft.com/en-us/library/x9fsa0sw%28v=vs.80%29.aspx

First of all for encapsulation I mean :

"Encapsulation is the process of combining data and functions into a single unit called class "

If so

Camera.main.transform.Translate(move*Time.deltaTime);

It is not, in my opinion, a case of encapsulation

Translate is combined into the class Transform (Upper case)
transform (lower case) is some how similar to the pointer "my" which is used to link the method Translate() to the Game Object Camera

In other engines Camera is a class which encaspulate all the camera related data and methods , such as Translate()

This is a very limited view of encapsulation, from what I've been taught.

Encapsulation can be broken in some languages. Consider the use of an Abstract Data Type in C, for example. The programmer/client shouldn't have to worry about how something is done, just that it gets done. You might implement linked lists and provide a "lLists.h" with headers to a whole bunch of functions you've written to manipulate your linked lists. The client should never open "lLists.c", nor be aware of how they are implemented, instead interacting with them only through the functions whose prototypes are provided in "lLists.h". This way, the implementation can be changed (to be more memory efficient, speed efficient, remove bugs, etc) without affecting the client in the slightest. When you manipulate its values directly, you "break encapsulation", and implementations of the same ADT are no longer necessarily interchangeable.

Object oriented programming languages like C++ and Java often provide means to enforce encapsulation (private), but encapsulation isn't restricted to OO languages.

Jibb

Well I am not professional programmer so I dont argue with your extended definition of encapsulation

However let's assume that estabilishing a link to an external set of functions is also Encapsulation
What I did not agree was your claim " its own methods "
Nope in component based engines there are generic methods only

Only non component based engines supply methods which are custom made for the category (class) of entities they refer to.

Indeed, "its own methods" was too specific a definition for me to use, as imperative languages don't have objects with methods but it is still a common convention to recognise a relationship between some functions and a data type for the sake of encapsulation.

But I think I still don't understand Unity, or perhaps I don't understand you properly. Perhaps I just don't understand components.

Here is the manual excerpt I quoted before for convenience:The camera (or, in the code example, "Camera.main") has a Transform called "transform", and we call transform's method Translate. Is this not the case?

It appears to me that any and all objects in Unity have an object in them called a Transform that, in the rendering pipeline, will be called upon (likely through more of the Transform's methods if they maintain encapsulation) in order to construct the matrices of each object. The same would happen during physics calculations.

I'm not sure I understand component based programming, but it appears to me that it is a paradigm dependent on object oriented languages by which objects are constructed from many other pre-fabricated objects, but those objects still have their own properties and methods.

Jibb

Components in traditional programming are not just objects, they are more, like a motor/engine is a component of a car, like a potato is a component of your soup, like a printer is a component of your office hardware. A component is often built from many objects, functions, data and whatever belongs to do a certain job. It can be replaced (new printer in your office, new engine in your car). It has a predefined interface. It is similar to an object but often bigger and often comes with wrappers. So many software companies sell the same component working in many program languages.

But in game development components are also often used to get a higher grade of flexibility. They split components into smaller units. They dont add everything into classes but often use components to add certain functionality on the fly to each object/class where it makes sense. This is not as easy and not as comfortable as when you work with classes who use their own built-in methods. But it can be more flexible and classes are more leightweight, have smaller memory size and thus work better in systems like mobile phones or other low end hardware.

So often, even when we personally dont like a certain style of programming, it still can make a lot of sense why this style exists.

Yeah, potato similes are great and all, but my problem here is this: is component-based programming simply a different style of programming in current languages, or is it an alternative syntactic sugar to classes that relies on it being written in particular "component based" languages?

Because "often bigger" isn't helpful, since there's no standard for the size of objects. "Can be replaced" isn't helpful, because as with ADTs in imperative programming languages, abstract classes are common in OO as well (you might replace an array list with a linked list, but it will make no difference to the rest of your program if you are only interacting with it through an abstract "list" class or interface). "It has a predefined interface" doesn't differentiate it from an object (except that this is perhaps enforced in component based programming [as you implied], but an OO language may also have that requirement and still be useful in a strictly OO paradigm).

Basically, what AlbertoT and I appear to have come down to in our discussion is his position that the phrase "its own methods" does not apply to component based programming, and I fail to see how that can be the case, particularly given the short code example Liam gave in the original post and Unity's documentation regarding Transforms.

It appears to me that component based programming is simply a style you might use when writing in C++, Python, Go, or any number of other OO languages, but you'll still have instances of classes and call their methods.

Jibb

Article about game entities composed by components: http://www.gamasutra.com/blogs/MeganFox/20101208/6590/Game_Engines_101_The_EntityComponent_Model.php

There is nothing special to components in game development, it's just a software design pattern where the goal is to simplify certain tasks just like all other software designs patterns out there.

Components allow your entities to be composed of several parts, where each of them get updated independently, probably by a manager. The goal is to get more modular code where you can plug in and out different sort of functionality and behaviour for your entities.

Could be a HealthComponent, adds health functionality to an object so it can get damaged. Now anything that shoots at that entity will damage it. Could be JumpComponent, any entity who has this component can jump now.

Think of it as an extension.

Just some examples

Yes Jibb this has nothing to do with languages at all, it's just a software design pattern.

Great article, and great response. Thank you, Enduriel

So the answer seems to be that it's a design decision in development (EDIT: confirmed in an Edit I missed on the first read -- thanks!) -- a programming paradigm that is relatively language agnostic (I say "relatively" because it doesn't appear to be a reasonable approach in an imperative language [although technically possible since classes are just syntactic sugar]).

I've never done a course on the OO paradigm, and so I always called any instance of a class an "object" regardless of the paradigm used. It appears objects and components are both instances of classes under different paradigms (or different intentions under the same paradigm).

Correct me if I'm wrong in any of that, but I feel a lot has been clarified for me.

Much appreciated

Jibb