|
Re: Unity is a dic*
[Re: AlbertoT]
#383242
09/17/11 18:12
09/17/11 18:12
|
Joined: Mar 2006
Posts: 3,538 WA, Australia
JibbSmart
Expert
|
Expert
Joined: Mar 2006
Posts: 3,538
WA, Australia
|
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
Formerly known as JulzMighty. I made KarBOOM!
|
|
|
Re: Unity is a dic*
[Re: ventilator]
#383253
09/17/11 22:01
09/17/11 22:01
|
Joined: Oct 2006
Posts: 1,245
AlbertoT
Serious User
|
Serious User
Joined: Oct 2006
Posts: 1,245
|
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()
Last edited by AlbertoT; 09/17/11 22:10.
|
|
|
Re: Unity is a dic*
[Re: AlbertoT]
#383254
09/17/11 22:46
09/17/11 22:46
|
Joined: Mar 2006
Posts: 3,538 WA, Australia
JibbSmart
Expert
|
Expert
Joined: Mar 2006
Posts: 3,538
WA, Australia
|
"Encapsulation is the process of combining data and functions into a single unit called class " 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
Formerly known as JulzMighty. I made KarBOOM!
|
|
|
Re: Unity is a dic*
[Re: JibbSmart]
#383279
09/18/11 14:52
09/18/11 14:52
|
Joined: Oct 2006
Posts: 1,245
AlbertoT
Serious User
|
Serious User
Joined: Oct 2006
Posts: 1,245
|
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.
Last edited by AlbertoT; 09/18/11 15:11.
|
|
|
Re: Unity is a dic*
[Re: AlbertoT]
#383322
09/18/11 23:56
09/18/11 23:56
|
Joined: Mar 2006
Posts: 3,538 WA, Australia
JibbSmart
Expert
|
Expert
Joined: Mar 2006
Posts: 3,538
WA, Australia
|
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: Every object in a scene has a Transform. It's used to store and manipulate the position, rotation and scale of the object. 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
Formerly known as JulzMighty. I made KarBOOM!
|
|
|
Re: Unity is a dic*
[Re: JibbSmart]
#383340
09/19/11 08:34
09/19/11 08:34
|
Joined: Nov 2004
Posts: 7,121 Potsdam, Brandenburg, Germany
Machinery_Frank
Senior Expert
|
Senior Expert
Joined: Nov 2004
Posts: 7,121
Potsdam, Brandenburg, Germany
|
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.
Models, Textures and Games from Dexsoft
|
|
|
Re: Unity is a dic*
[Re: Machinery_Frank]
#383353
09/19/11 14:36
09/19/11 14:36
|
Joined: Mar 2006
Posts: 3,538 WA, Australia
JibbSmart
Expert
|
Expert
Joined: Mar 2006
Posts: 3,538
WA, Australia
|
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
Formerly known as JulzMighty. I made KarBOOM!
|
|
|
Re: Unity is a dic*
[Re: JibbSmart]
#383357
09/19/11 15:18
09/19/11 15:18
|
Joined: Aug 2008
Posts: 133 Sweden, Stockholm
Enduriel
Member
|
Member
Joined: Aug 2008
Posts: 133
Sweden, Stockholm
|
Article about game entities composed by components: http://www.gamasutra.com/blogs/MeganFox/20101208/6590/Game_Engines_101_The_EntityComponent_Model.phpThere 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.
Last edited by Enduriel; 09/19/11 15:26.
|
|
|
Re: Unity is a dic*
[Re: Enduriel]
#383359
09/19/11 15:46
09/19/11 15:46
|
Joined: Mar 2006
Posts: 3,538 WA, Australia
JibbSmart
Expert
|
Expert
Joined: Mar 2006
Posts: 3,538
WA, Australia
|
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
Last edited by JibbSmart; 09/19/11 15:48.
Formerly known as JulzMighty. I made KarBOOM!
|
|
|
|